Data leakage is the exposure of data beyond the boundary it was meant to stay within: one customer's details shown to another, or internal figures sent to an outside party. It can be accidental and quiet, with no attacker involved. With AI agents, a common route is an agent that can see more than its job needs.
Why does data leakage matter once agents act?
An agent works by gathering context and acting on it. If it can reach a customer database to answer one customer's question, it can, in principle, reach any customer's record. A cleverly worded request, an instruction hidden in a document, or a plain retrieval error can surface the wrong record in a reply.
Agents also create new places for data to end up: conversation memory, logs, prompts sent to a model provider, drafts saved in shared queues. Each is a boundary someone has to decide on. Treating these as design decisions, not technical details, is part of agent governance is a bound, not a model, and is discussed directly in what an agent remembers is a data decision.
How does data leakage happen with agents?
- Over-broad sources: the agent can query records it has no need to see.
- Prompt injection: an instruction in an email or web page asks the agent to include data in its reply or send it elsewhere.
- Context bleed: details from one conversation carry into another through shared memory.
- Output to the wrong place: a draft or attachment sent to the wrong recipient.
- Third-party processing: data passed to a provider or tool without the right agreements.
The first defence is narrowing what the agent may see to what its role needs, covered in how to decide which data an AI agent may see. The wider controls are in how do you stop an AI agent from leaking customer data?
What does that look like in an example?
A dental group's booking agent can read the full patient records system to check appointment history. A caller gives a name and date of birth that match two patients. The agent picks one and reads back the next appointment, including the treatment type. It was the wrong patient. No attacker, no hack: just a lookup with access far wider than booking needed, and an identity check too weak for health data, which is special-category data under GDPR. The fix narrows the agent to appointment times only and requires a second identifier before it reads anything back.
How is data leakage different from a data breach and from data loss?
A data breach is a security incident in which personal data is accidentally or unlawfully destroyed, lost, altered, disclosed or accessed, and under data protection law it can trigger duties to notify. Leakage is one way a breach happens; many breaches start as a leak that nobody noticed. Leakage also covers non-personal data, such as pricing or strategy, that breach rules may not reach.
Data loss is different again: data that is deleted or destroyed rather than exposed. An agent that wipes records causes loss; an agent that reveals them causes leakage. The controls overlap but are not the same, as covered in how do you stop an AI agent from deleting data?
Where Pryme fits
In Pryme, an agent's sources are part of its role scope, and every fact it receives carries its provenance through the Pryme Context Protocol. An agent sees what its role needs and no more, and a reply drawing on a record outside that scope is refused, with the decision filed.
Questions people ask
Does using a model provider count as data leakage?
Not if the transfer is planned, lawful and covered by the right agreements, such as a data processing agreement and any needed transfer safeguards. It becomes leakage when data reaches a provider that nobody approved, or in ways the agreements do not cover.
How do you detect data leakage by an agent?
Review the verdict record for replies that drew on records outside the requester's own, test the agent with requests designed to surface other people's data, and scan outputs for identifiers that should not appear.