Why Your AI Agents Are Leaking Data (And How to Stop Them)

AI agents call dozens of APIs, tools, and models autonomously — each step is a potential data leak. Here's how to protect the data flowing through agentic workflows.

AI agents don't just call one API — they call dozens

Single-shot LLM calls are last year's architecture. The AI features being built today are agentic — they use tool calling, function execution, multi-step reasoning, and protocol-based integrations like MCP to accomplish complex tasks autonomously.

A customer support agent doesn't just generate a response. It retrieves the customer's ticket from your CRM, pulls their order history from a database, looks up shipping status from a logistics API, drafts a response using an LLM, and writes a summary back to the CRM. Five external calls. One user message.

Each of those calls is a potential data leak vector. Not the model itself — the data flowing through the pipeline. The customer's name, email, phone number, and order details flow from system to system to system, often to different providers, in different jurisdictions, with different retention policies.

The security model built for single LLM API calls doesn't cover this. When your agent autonomously decides to call an external tool and passes conversation context to it, you need protection that works at every hop — not just the first one.

How agentic workflows create new leak vectors

Traditional LLM integrations have a simple data flow: your app sends a prompt, gets a response. One request, one provider. Agents break this model in several ways.

Tool calling and function execution

When an LLM decides to call a function, it passes arguments that often include data from earlier in the conversation. The model extracts what it thinks the tool needs from the user's message and prior context — and it's not conservative about it.

A scheduling agent asked to "reschedule Sarah Miller's appointment" might call your calendar API with the full name, then call an email API with the name and email address, then update a CRM record with all of the above. The user gave their name once. It ended up in three external systems.

The risk multiplies because the developer doesn't choose what the model includes in tool-call payloads at runtime. You define the function schema, but the model decides what values to pass. You can't review every combination at code time.

Multi-step chains

Agentic workflows accumulate context across steps. Step 3 has context from steps 1 and 2. Step 5 has context from all four previous steps. Personal data introduced at any point can propagate through the entire chain.

A research agent that starts by pulling a customer profile (with PII) might carry that context through ten subsequent tool calls — summarization, classification, database writes, API calls — each one receiving data the user mentioned once, steps ago.

MCP and tool integrations

The Model Context Protocol (MCP) standardizes how LLMs connect to external tools and data sources. It's powerful and growing fast. It also means any tool connected via MCP can receive data from the conversation context — including data the user never intended to share with that specific tool.

An MCP server for file management connected to the same agent as an MCP server for email means both can potentially receive context from each other. The tool boundary that developers assume exists is porous.

RAG plus agents

Retrieval-augmented generation already carries data risk — your retrieval pipeline pulls documents that may contain PII from unrelated records. When RAG feeds into an agentic workflow, those retrieved documents (and the PII in them) flow through every subsequent step.

Agent retrieves 10 documents containing customer data → uses LLM to summarize → calls external API with summary. The PII from those 10 documents just left your infrastructure embedded in a summary.

Memory and persistence

Agents that remember across sessions — using vector databases, conversation logs, or dedicated memory systems — create persistent stores of personal data that weren't designed with GDPR data subject rights in mind. A user's name and problem description, stored in a vector database for "context," becomes personal data processing that's hard to audit, hard to find, and hard to delete.

A concrete example

A customer support agent handles an incoming ticket:

1. Retrieves ticket from helpdesk API — ticket contains customer name, email, phone number, account details
2. Summarizes the issue using an LLM — full ticket content (with PII) goes to the model provider
3. Looks up order via e-commerce API — passes customer identifier and context
4. Drafts response using an LLM — PII from the ticket plus order data now in the prompt
5. Writes CRM note via CRM API — summary containing PII flows to a fourth system

One support ticket. Personal data now in five systems — your helpdesk, LLM provider, e-commerce platform, LLM provider again, and CRM. Each with different retention policies, different DPAs, different sub-processor chains.

Why traditional API-level protections don't work for agents

Most current approaches to LLM security were built for the single-call model. They fall short with agentic architectures in specific ways.

Client-side guardrails only protect the first hop. If you add PII detection in your application code before calling the LLM, that covers the initial request. But when the agent makes subsequent tool calls autonomously, your application-level checks aren't in the loop. The agent decides what to call and what data to include.

Per-model SDKs don't cover tool-call payloads. OpenAI's moderation API checks chat completions. It doesn't scan what your agent sends to Salesforce, Jira, or your internal APIs via function calling. The tool calls happen at the model layer, outside your SDK wrapper.

Rate limiting and API keys don't prevent data from being in the payload. You can restrict which tools an agent can call and how often. But if the tool call is authorized, rate limiting doesn't care that the payload contains a social security number.

Code-time review doesn't scale to runtime decisions. With traditional API integrations, a developer writes the prompt template and a reviewer can check what data goes in. With agents, the model constructs payloads dynamically at runtime. The combinations are unbounded.

What you need is protection at the network layer — something that inspects every outbound request, regardless of what triggered it, what tool initiated it, or which provider it's going to.

The proxy approach: scan every request, every response, every tool call

A proxy sits between your infrastructure and all external endpoints. Every outbound HTTP request passes through it — whether that request was initiated by your application code, an LLM's tool call, or an agent's autonomous decision.

This is the architecture that actually works for agentic AI:

Every outbound request is scanned. PII detection runs on all traffic — chat completions to OpenAI, tool calls to Salesforce, webhook payloads to Slack. The same detection rules apply regardless of the destination. An email address is an email address whether it's going to Anthropic's API or your CRM's REST endpoint.

Every response is scanned too. Data doesn't just leak outbound. LLM responses, tool-call responses, and RAG retrieval results can contain PII that shouldn't be stored, logged, or forwarded. Bidirectional scanning catches both directions.

Mask and restore preserves agent functionality. The agent needs to work. Permanently redacting data breaks multi-step workflows where entities need to be consistent across calls. Mask and restore replaces PII with tokens that the agent can track and use consistently, while real data never leaves your infrastructure.

Detection is uniform across providers. You don't need separate PII detection for each tool, model, or API. One set of rules — regex patterns for structured data, AI models for names and locations — covers everything that passes through the proxy.

Audit trail covers the full chain. Every request, every detection, every action — logged in one place. When your compliance team asks "where did this customer's data go?", you can trace the entire agent execution chain.

Grepture is built for this. Route your agent's traffic through the proxy and every outbound call — to LLM providers, tool APIs, MCP servers — gets scanned automatically. See the quickstart guide for setup, or learn how Grepture works.

Practical checklist for securing agentic AI

If you're building or operating AI agents, here's what to do:

• Map every external API your agents can call. Not just LLM providers — every tool, every MCP server, every webhook. You can't protect what you can't see.
• Route all agent traffic through a proxy with PII detection. This is the only way to get consistent coverage across autonomous tool calls.
• Enable detection for tool-call payloads. Chat completions are only part of the traffic. Function call arguments and responses need the same scrutiny.
• Monitor agent memory and persistence layers. Vector databases, conversation logs, and session storage may contain accumulated PII. Audit what's stored and set retention policies.
• Set up alerts for unexpected data patterns. Agent calling a new endpoint you haven't seen before? Unusual data volumes? These are signals worth investigating.
• Apply least-privilege to agent tool access. Not every tool needs access to every piece of context. Limit what tools can see and what data they receive.
• Audit logs: trace data flow across the full execution chain. When something goes wrong — and with agents, the blast radius is larger — you need to trace exactly which data went where, when, and why.

For prompt injection risks specific to agents (where indirect injection through tool responses is especially dangerous), see our prompt injection prevention guide. For broader guidance on protecting LLM traffic, start with preventing data leaks in LLM API calls.

Key takeaways

Agents multiply your data leak surface. Every tool call, every multi-step chain, every MCP connection, every memory write is a potential leak vector. And unlike single-shot LLM calls, agents make these decisions autonomously at runtime.

Client-side protections don't cover autonomous agent decisions. Per-model SDKs don't scan tool-call payloads. Code-time review doesn't account for dynamic runtime behavior.

Proxy-level scanning is the architecture that works — one inspection point that covers all agent traffic uniformly, regardless of which tool or provider the agent calls. Combined with mask and restore, your agents keep working while real data stays within your infrastructure.

The agents you're building today are more capable than ever. Make sure the data flowing through them is protected at every step.

See how Grepture protects AI traffic — setup takes under five minutes.