#321 PII / financial-data-class exfil detector (new detection class — future work)

[Anonymous]

Originally created by: fu351

Summary

Doberman's outbound-secret defenses target credential-shaped material (API keys, tokens, private-key blobs, .env/*.key files) and the lethal-trifecta co-occurrence. They do not classify personal or financial data (names+addresses, IBAN/account numbers, one-time auth codes, SSNs, weak/human passwords in a payload) as sensitive on its own. This proposes a new PII / financial-data-class detector as a future, human-approved feature.

Why (honest motivation — not a benchmark tune)

This surfaced while measuring AgentDojo. Of the suite's ~26 attacks, most exfiltrate personal or financial data, not credentials — so the taint/secret floor is correctly inert on them (~0/47 credential-shaped payloads), and the per-action lethal-trifecta "sensitive-target" leg doesn't line up either. Those attacks are real data-exfiltration, but they fall outside what today's rules are built to see.

The point of recording this is not to move a number. A detector must be a genuine, defensible new detection capability — added on its own merits, shipped in shadow → measured → graduated like any raise-side change — never a knob tuned so a specific benchmark lights up. If it happens to move AgentDojo, that's a side effect of covering a real gap, and any published number stays subordinate to the honesty rules in docs/BENCHMARKS.md.

Scope sketch (for discussion, not a spec)

• A Detector/Rule over outbound-action arguments that classifies a data class (PII, financial, auth-code) rather than a single-secret fingerprint.
• Data-class signals only — reason codes + a class label, never the matched value in any log/output (redaction rules unchanged).
• Raise-only and defense-in-depth: it feeds risk, it doesn't replace the secret/trifecta floors.
• Precision is the hard part: PII regexes false-positive heavily (a name or address is not inherently exfil). Likely gated on co-occurrence with an external destination, not presence alone — mirrors the trifecta's structure.

Open question — core vs enterprise boundary

Per the F3 split (CLAUDE.md §2): basic patterns live in core; advanced/proprietary detection is enterprise. A simple structured-format detector (IBAN/SSN/OTP regex) could be a core-basic rule; a UEBA-style or ML PII classifier is enterprise. Decide the boundary before implementing — if it needs core to know an enterprise concept, the boundary is wrong.

Not scheduled

Future work, needs a human go-ahead + a boundary decision. Filed so the AgentDojo measurement gap is recorded and not silently "tuned around."

[Anonymous]

Originally posted by: fu351

Shipped the core-basic half in [#392] (merged): checksum-valid structured formats — payment card (issuer IIN + Luhn), IBAN (mod-97), dashed US SSN (SSA constraints) — co-occurring with an external destination now AUTH in every mode, as pii_data_class_egress. Presence alone never escalates, and only the class label is ever logged.

Recorded ceilings, deliberately out of scope for the structured-format rule: undashed 9-digit SSNs (indistinguishable from ordinary ids), one-time auth codes (bare 6-digit numbers false-positive too hard even destination-gated), free-text names/addresses, and split/encoded payloads (partially covered by the encoded-exfil and blob rules). Those belong to a statistical/contextual detector behind the Detector seam — enterprise territory per the F3 boundary, decided in ADR 0076.

[Anonymous]

Ticket changed by: fu351

• status: open --> closed

[Anonymous]

Originally posted by: fu351

Closing — the core-scoped half shipped in [#392] and is in the current CHANGELOG: checksum-valid structured personal/financial data (Luhn-valid cards, mod-97 IBANs, dashed US SSNs) in an outbound payload to an external destination now steps up to AUTH in every mode.

The remainder this issue named — free-text/statistical PII, OTP codes, undashed SSNs — is deliberately out of core scope per ADR-0076: that detection is enterprise. Nothing left to track in the public core, so I'm closing it. Reopen if I've drawn the boundary wrong.

[Anonymous]

Originally posted by: harshitagrawal2O

Picking up the invitation from [#164]/#352 to look at this one.

Reading the issue, the open question is the core-vs-enterprise boundary, and I think the issue's own scope sketch already answers it: a structured-format-only detector — fixed-shape identifiers like IBAN, SSN, and OTP codes, matched by deterministic regex/checksum (e.g. IBAN's mod-97 check), no statistical/ML classification, no free-text name/address NER — is squarely the "basic pattern" side of the F3 split, same tier as the existing secret-shape regexes in engine/rules/secrets.py. A UEBA-style or learned PII classifier would be the enterprise side; core would ship none of that.

Concretely, if you're good with this scope, my plan would be:

• A new core Rule (mirrors secrets.py's structure) that flags a structured PII/financial identifier class in outbound arguments — IBAN (checksum-validated, not just shape), SSN-shaped, and OTP-shaped codes to start.
• Gated on co-occurrence with an external destination, not presence alone — same structural idea as the lethal-trifecta, so a benign IBAN in a local file read never fires.
• Raise-only, AUTH at most, reason code + class label only — never the matched value, mirroring the existing secret-detector redaction discipline.
• Ship behind the same shadow-measure-graduate discipline docs/BENCHMARKS.md already requires, so this is measured honestly and not tuned to AgentDojo.

If that split matches what you had in mind, happy to take this on — otherwise let me know how you'd want the boundary drawn differently before I start.

[Anonymous]

Originally posted by: fu351

@harshitagrawal2O your boundary read is right, and the good news is it already shipped: PiiDataClassRule landed in engine/rules/data_classes.py on Aug 16 with almost exactly the split you describe, checksum-validated card and IBAN plus dashed SSN, gated on an external destination, raise-only to AUTH, class labels only in logs. OTP codes stayed out deliberately, bare 6-digit numbers false-positive too hard even destination-gated, which is part of why this issue is closed. If you want to build on it, [#405] tests the rule's documented non-detections, but you've got [#198] and [#399] assigned and I'd rather see those first.