Limit what it can read, control where its output can go, and check what leaves. An agent should see only the records for the customer and task in hand, should send only to destinations you have approved, and should have every outgoing message checked for data that does not belong to the recipient. Most leaks come from reach, not from malice.
How do agents leak data?
Data leakage from agents tends to follow a few routes:
- Wrong recipient. An agent serving many customers carries details from one conversation into another, or attaches the wrong document.
- Over-sharing. Asked about one account, it includes details of linked accounts the caller is not entitled to see.
- Injected exfiltration. A hidden instruction in a document tells the agent to include data in a link or send it to an outside address.
- Unapproved destinations. Drafts sent to personal email, data pasted into outside tools, logs shipped to systems with wide access.
- Ungoverned agents. Staff connect customer data to agents nobody registered; see how to stop shadow AI agents.
What are the practical steps?
- Scope reading to the task. The agent sees the authenticated customer's records for this conversation, not the customer base. Links to related people (joint holders, business partners) need their own entitlement check.
- Clear context between customers. Nothing from one customer's session carries into the next.
- Approve destinations. Outgoing messages go only to the customer's verified contact details or named internal queues. No free-text email addresses, no outside links the agent composes.
- Check outputs before they leave. Scan every outgoing message for identifiers that do not belong to the recipient: other account numbers, names, addresses.
- Strip data from links. The agent cannot build web addresses that carry customer data in them.
- Control what goes to the model provider. Send only what the task needs, under a contract that limits use.
- Protect logs. Records of agent work contain customer data and need access control and retention like any other store.
What may the agent share, and what stays with a person?
| Request | The agent | A person |
|---|---|---|
| Customer asks about their own account | Shares, after authentication | None |
| Joint account holder asks about the account | Shares within the entitlement rules | Disputes over entitlement |
| Someone claiming to be a relative asks | Nothing | Handles under the bereavement or third-party process |
| A police or regulator request | Nothing | Legal or compliance team |
| Internal colleague asks for a customer list | Nothing beyond their own access | The data owner |
A worked example
Take a mobile network's support agent. A caller authenticates as the account holder and asks for the numbers called last month, to check a disputed charge. The account is a family plan with four lines.
The agent's entitlement check shows the caller is the account holder, entitled to billing data for all lines, but the network's policy limits call detail for other adult users to the users themselves. The agent provides call detail for the caller's own line and totals for the others. The output scan confirms no other user's call detail is in the reply. When the caller asks the agent to "email the full breakdown to my lawyer", the address is not a verified contact, so the request is refused and routed to the data protection team.
How does this relate to deleting data?
Leaking and deleting are two failures of the same thing: an agent reaching data it should not. The same narrowing of access protects against both; our answer on how to stop an AI agent from deleting data covers the destructive side.
Which controls make the answer hold?
- Task-scoped reading, checked at the moment of action.
- No context carried between customers.
- Approved destinations only.
- Output scanning before anything leaves.
- No customer data in links or outside tools.
- Logs protected like the data in them.
The topic guide, agent governance is a bound, not a model, explains why these limits sit outside the model.
Where Pryme fits
In Pryme, every fact reaching an agent arrives stamped with where it came from, and every action, including sending a message, meets role scope, certificate, sources, your limits and platform guardrails. Verdicts are filed in an append-only record, so a suspected leak can be traced to the exact message and the data in it.
Questions people ask
Is a model provider seeing data a leak?
Not if it is a contracted processor acting on your instructions, with limits on use and retention. It becomes one if data goes to providers or tools without such terms.
Can output scanning catch everything?
No. It catches identifiers and patterns, not every sensitive fact. Scoped reading is the primary control; scanning is a backstop.
What should happen if a leak occurs?
Treat it as a data incident: contain, assess, and decide on notification under your data protection obligations. The agent's record shows what was sent and to whom.