During EIN application, we process SSN or ITIN. These are the highest-sensitivity data items in the platform.

​
Principle

PII flows through the system once and is destroyed. It never sits at rest in our databases, never appears in logs, and is never embedded in LLM prompts.

​
The lifecycle

User provides SSN/ITIN
  (CLI: stdin with no-echo; API: HTTPS body, not query params)
    ↓
SensitiveData<String> wraps the value
  (Zeroizing<String>, no Debug, no Clone, no Serialize)
    ↓
Passed by reference to EinAgent::obtain_ein(&sensitive)
    ↓
Computer Use agent receives structured tool input
  (NOT system prompt — agent fills form fields from structured input)
    ↓
Agent submits to IRS
    ↓
EIN received and returned
    ↓
SensitiveData dropped → memory zeroized
    ↓
SSN/ITIN no longer exists anywhere in Orgs

​
Invariants

  • SensitiveData does NOT implement Debug, Display, Serialize, or Clone
  • SensitiveData DOES implement Zeroize and ZeroizeOnDrop
  • No function that accepts &SensitiveData may log, serialize, or persist it
  • The Anthropic API request body containing the form data is TLS 1.3 and is not logged locally
  • If the Computer Use session fails, the SensitiveData is dropped; the user must re-enter for retry (no cached PII)

​
Screenshot redaction

Computer Use sessions capture screenshots at every step. Screenshots from EIN filings pass through a PII Redactor before storage:
  1. Known-sensitive regions (SSN field, address field, DOB field) are blacked out
  2. OCR pass detects any PII-pattern strings; regions containing hits are blacked out
  3. If the redactor is unable to confidently identify PII regions, the entire screenshot is discarded (not stored)
This happens before write-to-disk. A crash between capture and store cannot leak PII because there is no unredacted state to lose.

​
Logging

Zero PII in logs at any level — TRACE, DEBUG, INFO, WARN, ERROR. This is enforced by:
  1. Debug not implemented for SensitiveData
  2. Structured logging framework (tracing) with explicit field-level redaction for any candidate-PII fields
  3. Pre-commit hook scanning for common PII patterns in log statements

​
Incident response

If PII is accidentally logged, it’s a P0 incident:
  1. Log is immediately rotated out of storage
  2. All historical logs scrubbed for matching patterns
  3. Affected customer notified within 24 hours
  4. Security incident filed with our SOC 2 auditor
Root-cause analysis and remediation public within 30 days per our security policy.