Your agent takes a user's message, extracts relevant information from it, and passes that information as arguments to tool calls. This is normal. It's how tool-calling agents work.
The problem: every argument you pass to a tool call is logged somewhere. By the tool itself. By your observability stack. By the LLM provider's API logs. By your middleware. Sometimes by multiple of these at once.
If the user's message contained their name, their email address, their medical condition, their account number — all of that is now in the tool call arguments. And tool call logs often don't have the same data governance controls as chat logs.
How the leak happens
The user asks a customer support agent: "I'm trying to update my payment method. My current card ending in 4242 is being declined. Can you help?"
The agent extracts this information and calls a tool: lookup_account({"email": "user@example.com", "card_last4": "4242", "issue": "payment_declined"}).
The tool call is logged. Your LLM provider logs it. Your observability platform logs it. The API gateway logs it. The tool itself logs it on its end.
The card number fragment and email address are now in at least four different log systems, each with their own retention policies, access controls, and data residency characteristics.
The user never consented to their payment details being stored in your observability stack. Your privacy policy probably doesn't cover it. Your DPA with the LLM provider may not cover it either.
The cases that hurt most
Search agents with sensitive queries. A medical information agent. A legal research agent. A mental health support agent. The query itself contains sensitive information. The agent passes the query as a search argument. The search query — "symptoms of HIV after exposure," "how to file for bankruptcy," "signs of domestic abuse" — is now in your logs.
Document processing agents. An agent that processes uploaded documents extracts key fields and passes them to APIs. The document contained a Social Security Number in a form field. The SSN is now an argument in your API call logs.
CRM agents. A sales agent that pulls prospect data from a CRM and passes it to enrichment APIs is transferring that data to the enrichment provider. If the enrichment provider's data processing agreement doesn't cover this use, you have a GDPR violation on every call.
Conversation memory agents. An agent that stores conversation summaries to provide persistent memory is creating a new data store containing user information. The retention policy for that store is often "indefinite" because no one set a policy.
Why teams miss this
The mental model for agent privacy is usually: "we don't store the conversation." And often that's true for the conversation. But the tool calls are a separate data flow, and tool call logs are not the conversation.
Developers think about tool calls as function calls — ephemeral, gone after execution. But they're API calls. They traverse networks. They get logged by multiple systems. They're stored.
The data that flows through tool calls needs to be governed with the same rigor as any other personal data your system processes.
What to do before you build
Audit your tool call data flows. For each tool, identify what arguments it accepts and whether those arguments could contain PII. Map where those arguments end up: what systems log them, for how long, who has access.
Minimize what you pass. Pass identifiers rather than data where possible. Instead of passing email: "user@example.com", pass user_id: "u_123" and let the tool resolve it internally. The lookup happens server-side; the PII never travels through your argument logs.
Scrub before logging. If your observability stack logs tool call arguments (it probably does), build a scrubber that redacts known PII patterns — emails, phone numbers, SSNs, card numbers — before they hit the log store.
Cover it in your privacy documentation. Your privacy policy and DPA need to cover the tool call data flows explicitly. If they don't, you're processing personal data outside your stated practices.
Check your LLM provider's data handling. Every prompt you send to an external LLM provider may be processed, stored, or used for training depending on your agreement. If those prompts contain user PII, verify whether your agreement explicitly prohibits storage and training on that data.
Faultmap traces the data flows through every tool call in your agent before you deploy. It identifies where PII could travel, which log systems capture it, and whether your documentation covers the flows it finds.
The agent is not the privacy risk. The agent's tool calls are. And those calls are flowing through systems that were built without thinking about the data inside the arguments.