Most teams building AI agents think about PII protection as a single problem: don't let sensitive data leak in what the user typed. That's a real risk, but it's only one of three distinct paths sensitive data takes into an agent's context. The other two get missed far more often, usually because they're less visible while you're building.
The three paths PII actually takes into agent context
Direct user input
A user types their email, account number, or medical detail directly into a chat interface. This is the path most teams already guard against, with input validation, redaction, or basic filtering, because it's the most obvious one.
Tool call responses
An agent calls a tool (a CRM lookup, a database query, an internal API), and the response contains customer PII the agent never explicitly asked for but now holds in its working context. This path is much easier to miss, because the sensitive data didn't come from the user's own words; it came from a system the agent trusted to return relevant data.
Accumulated session context
Over a long conversation or a multi-step agentic workflow, PII mentioned early can persist in context long after it's relevant, get passed into logs, traces, or debugging tools, and end up somewhere it was never meant to be. This is the easiest path to lose track of entirely, because no single step looks like a PII-handling decision. It's the cumulative effect of context that never gets cleared.
Why the second and third paths get missed
Most PII-handling effort naturally concentrates on the interface the user interacts with directly, because that's the obvious point of contact. Tool responses and accumulated context don't have an obvious "entry point" moment the way a chat input field does, so they don't get the same deliberate scrutiny unless a team specifically designs for them.
What actually protecting all three paths looks like
Tiered detection instead of one blanket filter
Running the same heavy-weight detection on every single input and tool response is expensive and slow. A more practical pattern: fast pattern matching for structured PII (emails, phone numbers, ID formats) on everything, with more sophisticated detection reserved for unstructured text or for operations with real consequences if they go wrong.
Treat tool responses as untrusted for PII, not just for content
Just as prompt injection defense means not blindly trusting content a tool returns, PII defense means not assuming a tool's response is automatically safe to keep in context and logs just because your own system built the query.
Keep sensitive data out of your observability pipeline by design
The pattern that scales is to keep the trace and log structure your observability system needs for debugging while storing the sensitive values externally and referencing them. Don't write raw customer data into logs and traces, which are often retained longer and accessed more broadly than the original conversation.
Set explicit context expiration, not indefinite retention
Sensitive details relevant early in a session shouldn't necessarily persist in full for the entire session, let alone in downstream logs. Explicit rules for what gets cleared from working context, and when, close the gap that accumulated context otherwise leaves open.
This isn't just a compliance checkbox
In compliance-heavy industries this is a hard regulatory requirement, but the underlying discipline matters for any production AI system handling real customer data, regulated or not. A data exposure through an overlooked tool-response path is just as real as one through direct user input; it's just less likely to be the one your team already tested for.
How we approach this
We design PII protection around all three paths sensitive data actually takes into an agent's context, not just the interface a user types into. Tiered detection, external storage for sensitive trace data, and explicit context expiration are built in from the start.