Keep real values out of the model, check every tool call in both directions, and give real values only to the tools your policy names. Prompts alone will not hold.
SOC 2 Type II · ISO 27001 · HIPAA, BAA available
One tool call, both directions
Agent sendsThe model holds tokens
crm_get_customer(<PERSON>Hq3Vt8Lm</PERSON>)
CRM tool receivesResolved for this tool by policy
crm_get_customer(Tomasz Brennan)
Agent gets backMasked before the model
bill $129 · PIN <PIN_NUMBER>8203</PIN_NUMBER>
Every tool call is checked out and back, and each reveal is logged.
Treat every tool call as a place data can leave, in both directions, and enforce the rules in code outside the model. A system prompt that says “never reveal PII” is not a control.
Detect PII in prompts, retrieved text and tool results, and replace it with consistent tokens before the model sees it. The model can reason over <PERSON>Hq3Vt8Lm</PERSON>; it cannot repeat a name it never had.
Whatever the model writes into a tool argument, even a search query, goes to that tool’s server and often its logs. On the way back, a CRM lookup returns the whole record. Mask results before they enter the agent’s context.
The CRM lookup needs the real customer. A vendor-hosted search tool does not. Decide per tool, user and task, at the tool boundary, and log each reveal.
Per-server credentials, narrow scopes, and separate servers for PII-heavy systems, as the OWASP MCP Security Cheat Sheet recommends. Masking limits what a tool sees; scoping limits what it can reach.
Agent memory, traces and agent-to-agent messages hold whatever passed through. Store tokens there, not real values.
Protecto does steps 1, 2, 3 and 5 in one layer every agent calls. Its agentic detection and classification engine finds 50+ entity types in tool payloads and free text. The Protecto AI Privacy Gateway resolves real values for authorized tool calls automatically, or your team builds its own MCP interception on Protecto Vault APIs. Step 4 stays with your platform team.
Automation Anywhere uses Protecto to protect customer data in its AI agents, with each enterprise tenant’s own policy
Live enterprise tenants protected in Automation Anywhere’s AI agents
Entity types across PII, PHI and PCI, plus custom entities such as your customer ID format
Than AWS Comprehend and Microsoft Presidio in the independent UT Dallas / DataXpert benchmark
A support rep asks an internal agent about a customer’s bill. The agent calls two internal MCP tools and one vendor-hosted search tool.
The rep types: “Why is Tomasz Brennan’s bill $40 higher this month, and is there an outage at his address?” The agent can call crm_get_customer on the internal CRM server, outage_check on the internal network server, and web_search on a server run by an outside vendor.
Without data controls, the CRM returns the full record into the model’s context, PIN and a relative’s card number included. The model then writes the customer’s name and home address into a web search, and the vendor receives both. No one attacked anything. The agent did its job with data no one meant to share.
Switch the view to follow the same run with Protecto in the path.
Rep’s question to the modelReal name in the contextModel holds a token
Why is Tomasz Brennan’s bill $40 higher this month, and is there an outage at his address?
Why is <PERSON>Hq3Vt8Lm</PERSON>’s bill $40 higher this month, and is there an outage at his address?
Agent calls crm_get_customer (internal)Real name sentResolved for this tool by policy
CRM receives: {"customer": "Tomasz Brennan"}
Model sends: {"customer": "<PERSON>Hq3Vt8Lm</PERSON>"}
CRM receives: {"customer": "Tomasz Brennan"}
CRM record comes back to the agentFull record in the contextIdentifiers masked before the model
email t.brennan@example.com · phone 555-0177 · born 1984-03-09 · address 418 Alder St, Springfield · PIN 6620 · plan Fiber 500 · bill $129, was $89 · notes: Promo ended Oct 31. Wife Elena Brennan pays with card 4111 1111 1111 4417.
email <EMAIL>0gN3SkjL@0ffM3CDS</EMAIL> · phone <PHONE>555-8340</PHONE> · born <DOB>5Fd890</DOB> · address <ADDRESS>Vb7Lq2Xn</ADDRESS> · PIN <PIN_NUMBER>8203</PIN_NUMBER> · plan Fiber 500 · bill $129, was $89 · notes: Promo ended Oct 31. Wife <PERSON>Rw4Kc9Te</PERSON> pays with card <CREDIT_CARD>4929 5310 7782 0166</CREDIT_CARD>.
Agent calls outage_check (internal)Real address sentResolved, because your policy names this tool
Network server receives: {"address": "418 Alder St, Springfield"}
Model sends: {"address": "<ADDRESS>Vb7Lq2Xn</ADDRESS>"}
Network server receives: {"address": "418 Alder St, Springfield"}
Agent calls web_search (outside vendor)Name and address sent to a third partyNot named in policy, so it gets the token
Search vendor receives: {"query": "internet outage 418 Alder St Springfield Tomasz Brennan"}
Search vendor receives: {"query": "internet outage <ADDRESS>Vb7Lq2Xn</ADDRESS>"}
Trace logs, agent memory, answer to the repEverything above in clear textTokens stored, each reveal logged
Logs and memory: the full record, PIN and card number included.
Answer: whatever the model chose to write.
Logs and memory: tokens only, plus a record of each reveal.
Answer: “The Oct 31 promo ended, so Tomasz Brennan’s bill went from $89 to $129. No outage at his address.” The PIN stays masked for this rep.
Customer data and tokens are illustrative. Your policy decides which tools get real values; Protecto applies it.
What stays readable either way: the plan, both bill amounts and the promo end date, so the model can still explain the $40. The same customer gets the same token on every call, so the model keeps track of who is who. A masked value can make a lookup fail if it reaches a tool without authorized resolution, which is why the resolve step sits at the tool boundary, not in the model.
OWASP tells you to validate tool inputs and outputs and keep authorization out of the model. It does not say how to keep tools working when values are masked.
| OWASP MCP Security Cheat Sheet | What it means for customer PII | Who handles it |
|---|---|---|
| Data exfiltration via legitimate channelsKey risk | The model can put PII into a search query, an email subject or any tool argument | Protecto: the model holds tokens, and only tools your policy names get real values |
| Confused deputyKey risk | A tool runs with its own broad access, not the user’s | Your platform: per-user identity on tool calls. Protecto applies the user, agent and task your application passes |
| Least privilegeSection 1 | Each server reaches only the systems it needs | Your platform: scoped credentials per server |
| Input and output validationSection 5 | Tool results are untrusted and can carry more data than the task needs | Protecto: results are masked before they enter the agent’s context |
| AuthorizationSection 6 | Decide in code, not in the prompt | Protecto: reveal decisions by policy, outside the model |
| Redact secrets and PII from logsSection 10 | Traces and tool logs hold whatever passed through | Protecto: logs hold tokens, and each reveal is logged |
| Prompt injection via tool return valuesSection 12 | An injected instruction tries to send data somewhere new | Your platform: input checks and human approval. Protecto limits what the agent can send, because it holds tokens |
OWASP MCP Security Cheat Sheet as of November 8, 2026; OWASP AI Agent Security Cheat Sheet as of October 4, 2026.
Each approach scored against the leak at the tool boundary: what goes out, what comes back, and whether the tool still works.
| Approach | Tool arguments checked | Tool results masked before the model | Tool still gets the real value | Reveal by user, agent and task | Business data with no pattern |
|---|---|---|---|---|---|
| System prompt rule (“never reveal PII”) | No | No | Yes, the model holds real values | No | No |
| Output filter or DLP on the final answer | No | No | Yes, the model holds real values | No | Basic |
| Redaction tool the agent callsAn MCP server that redacts on request | Only when the agent calls it | Only when the agent calls it | No, redacted values do not resolve | No | No |
| Redaction built into an agent integration platform | Yes | Yes, masks fields or refuses the result | Not available for masked fields | Basic | No |
| MCP masking proxy with reversible tokens | Yes | Yes | Yes | Basic, by group or policy | No |
| Building it into each agent | Your code | Your code | Your code | Your code, per agent | Custom logic per case |
| Protecto | Yes | Yes, including free-text fields | Yes. The Protecto AI Privacy Gateway resolves them automatically, or your code does it with Protecto Vault APIs | Yes, by the user, agent and task your application passes | Yes, with Context-Based Access Control (CBAC) |
A SaaS company cut cost by 90% compared with building this in-house.
Approaches described from public product documentation, reviewed November 2026.
Your application or gateway calls Protecto at each point where data moves. Protecto masks, resolves and logs by your policy.
Prompts, retrieved chunks and earlier tool results pass through Protecto. Identifiers become consistent tokens like <PERSON>Hq3Vt8Lm</PERSON>, and the same value gets the same token in any session.
When the agent calls a tool your policy names, the Protecto AI Privacy Gateway swaps tokens for real values automatically. Or build your own interception of MCP traffic on Protecto Vault APIs. Other tools receive tokens.
Structured fields and free text such as notes are checked before the result enters the agent’s context, memory or traces.
Real values appear in the answer only for the people your policy names; everyone else sees tokens. Logs cover masking and unmasking, and reports show how each policy was enforced.
Call Protecto from LangChain, LlamaIndex or your own code, with any model provider. On-premises, private cloud, air-gapped or SaaS. You still own agent identity, server credentials and approvals for risky actions. Data access control for AI agents →
No. A prompt instruction is advice to the model, and injected text or a long context can override it. Keep real values out of the model’s context and enforce tool rules in code outside the model, as the OWASP MCP Security Cheat Sheet recommends.
Because tools return more than the task needs. A CRM lookup sends back the full record, notes included, and all of it enters the agent’s context, traces and memory. Masking results before they reach the model keeps those copies as tokens.
The real value is resolved at the tool boundary, for tools your policy names. The Protecto AI Privacy Gateway does this for authorized tool calls automatically. Teams that build their own MCP interception do it with Protecto Vault APIs. Tools your policy does not name receive tokens.
Protecto is not a prompt filter or AI firewall, so pair it with OWASP’s injection controls. It limits what an injected instruction can get: the agent holds tokens, and a tool your policy does not name receives tokens, not customer data.
It can when placeholders carry no meaning. Protecto uses consistent, format-preserving tokens, so the same customer keeps the same token across tool calls and the model can still follow the text.
No. Your gateway or identity tools decide who an agent or user is and which servers it can reach. Protecto works on the data itself, using the identity and policy context your application passes in.
Bring one agent workflow and its tool list, with test data if you prefer. We will show what each tool receives, what the model sees, and what gets logged.
24 yes or no questions across the six places sensitive data leaks in agentic AI, from model requests to tool calls and agent memory.
By submitting you agree to Protecto’s privacy policy.
