Agents leak data three ways: through the arguments they forward in a tool call, through what they write to conversation memory, and through what they echo back in a response. A policy memo doesn’t stop any of the three — they all look like the agent doing its job. What stops them is a runtime tokenization layer that intercepts text at each of those three points and strips PII before it crosses your boundary. This is how that layer works.
Redacting what goes into the LLM prompt is table stakes and doesn’t close the gap. An agent’s data path has three places where a raw value can leave the perimeter, and none of them route through the prompt.
The agent decides to call a tool — a calendar API, a CRM, a payment processor — and forwards the data it’s reasoning about as a call argument. MCP doesn’t carry per-field sensitivity metadata, so the tool server receives whatever the agent sends, in plaintext, by default.
Conversation history persists across turns so the agent has context. Whatever text gets appended to that history — including a customer’s SSN or a medical detail surfaced mid-conversation — sits there in plaintext for the life of the session unless something tokenizes it before the append happens.
The final response returned to the caller is built from context the agent retrieved and reasoned over. If tokenization only runs on the way in, a value that entered as a token can still resurface untokenized in the outbound response.
The deeper argument for why the tool call — not the prompt — is where most production leaks actually happen is in Your AI Agent Is Leaking PII Through Tool Calls. Here’s Proof..
VeriSwarm Guard closes all three vectors with the same underlying call — POST /v1/suite/guard/pii/tokenize— applied at the point where each vector would otherwise leak. Text goes through a Presidio-based NER detection engine (Presidio + spaCy NER, plus custom regex recognizers for identifiers Presidio doesn’t cover out of the box) and comes back with every PII span replaced by a typed token — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], and so on. The agent, the tool server, and anything logged in between see the token. The original value is restored, when it’s needed at all, through a separate POST /v1/suite/guard/pii/rehydrate call scoped to the session that created the tokens.
Guard Proxy is a transparent MCP interception layer. Point your agent’s MCP client at the proxy instead of the tool server directly, and it tokenizes PII in the outbound tool-call request and the inbound tool-call response — no agent code changes. Three deployment modes: cloud-hosted, on-prem Docker, local stdio.
VeriSwarm’s own agent runtime calls the tokenization endpoint on the agent’s response before that response gets appended to conversation history and beforeit’s returned to the caller. The value written to memory and the value echoed back are the same tokenized text — not two separate controls that can drift out of sync.
The PII protection pillar covers the broader case for tokenization over prompt-input redaction — why DLP doesn’t cover agent traffic, the GDPR pseudonymization caveat, the Vault audit trail, the healthcare posture. This page is narrower and more operational: it’s a map of the three specific points in an agent’s data path where a leak actually happens, and which mechanism closes each one. Read the pillar for the full architecture and the compliance reasoning; read this page for where, specifically, to point the fix.
Tokenization reduces the PII surface at the three vectors above and gives you an audit trail of every interception when Vault is enabled — it doesn’t guarantee no data ever leaks. A tool call routed around Guard Proxy, or a custom integration that doesn’t call the tokenization endpoint before it forwards data, is a leak path this layer never sees. Guard closes the vectors it’s wired into; wiring in a new one is on you the first time you build a leak path it doesn’t already cover. Injection is a related but distinct risk — a crafted input that manipulates which tool gets called, rather than PII in the arguments of a legitimate one — covered separately in Prompt Injection Detection for AI Agents.
Through tool-call arguments — an agent forwards raw PII to an MCP tool server (a calendar API, a CRM, a payment processor) in plaintext. Through what it writes to memory — a customer's SSN or medical detail gets appended to conversation history and persists there for the life of the session. Through what it echoes back — a response built from tokenized context can still surface the original value if the tokenization step is skipped on the way out. All three share one property: none of them look like a policy violation. They look like the agent doing its job.
No — that stops the leak point that hurts least. The LLM never seeing PII is good practice, but the tool call after the LLM decides to make it is where data actually leaves your perimeter. An agent can be scrupulously careful with what it puts in a prompt and still forward a customer's phone number to a third-party MCP tool server verbatim, because the MCP specification doesn't inherently carry per-field data-sensitivity metadata. Coverage has to extend through the tool call, not stop at the model boundary.
Text is passed to POST /v1/suite/guard/pii/tokenize, which runs it through a Presidio-based NER detection engine (Presidio + spaCy NER plus custom regex recognizers for identifiers Presidio doesn't cover) and returns the text with each PII span replaced by a typed token — [VS:EMAIL:a1b2c3], [VS:SSN:f9e2d1], and so on. The token-to-value map is tenant-scoped and never travels with the tokenized payload. Tokens are reversible only via POST /v1/suite/guard/pii/rehydrate, scoped to the session that created them, for the specific case where a downstream system needs the real value to do its job — writing to a CRM record, for instance.
For the tool-call vector, no. Guard Proxy is a transparent MCP interception layer — your agent's MCP client points at the proxy URL instead of the tool server directly, and it tokenizes PII in both the outbound tool call and the inbound response before either one crosses the boundary. Three deployment modes cover cloud-hosted, on-prem Docker, and local stdio. For the memory and echo vectors, VeriSwarm's own agent runtime already calls the tokenization endpoint before it appends a response to conversation history or returns it to the caller — that plumbing ships as part of the platform, not as something you build.
Guard — PII tokenization, Guard Proxy, and the injection scanning that runs alongside it — is a Max-plan feature. Gate, VeriSwarm's free-tier trust scoring, gives you visibility into agent behavior and event flow before you need the tokenization layer; Guard is where you turn on the enforcement.
No, and treat any vendor who claims otherwise skeptically. Tokenization reduces the PII surface at each of the three vectors covered here and gives you an audit trail of every interception when Vault is enabled. It doesn't cover leak paths outside those three — a misconfigured integration that bypasses Guard Proxy, or a custom tool call path that doesn't route through the tokenization step, still needs to be wired in deliberately.
Guard’s PII tokenization is a Max-plan feature; Gate’s free tier gives you the trust scoring and event visibility to see where an agent’s data actually goes before you turn on the fix.