Agents share safely by passing the smallest answer the next agent needs, not the record behind it. The governing layer checks that the receiving agent's role permits that data, keeps each fact's source and sensitivity label attached, and refuses handoffs that would move data to an agent, team or customer it was never meant to reach.
Why do agents leak more easily than people?
People absorb context and filter it without thinking. A support colleague who glances at a fraud note knows not to mention it to the customer. Agents do not have that instinct. Whatever reaches an agent's context can appear in its output, be passed to the next agent, or be stored in memory for a later task.
Multi-agent setups multiply the routes. One agent summarises a case for another, which drafts a reply, which a third logs. Each handoff is a chance for data to travel further than intended. The fix is to design handoffs so that leaking is hard by default, rather than relying on each agent to be discreet.
What are the main controls?
Share answers, not records. If the complaints agent needs to know whether a customer's identity is verified, the identity agent returns "verified, on this date, by this method". It does not return the passport image or the address history.
Check the receiver's scope. Before a handoff, the platform checks that the receiving agent's role may hold that category of data. A marketing agent asking for a customer's health disclosure is refused, whatever the reason given.
Keep labels attached. Each fact carries its source and sensitivity. A summary built from special-category data stays labelled as such, so the next agent's scope check still applies.
Scope memory by customer and purpose. Facts remembered while working one customer's case must not be retrievable in another's.
Redact at the boundary. Where an agent must pass a document onward, fields the receiver does not need are removed before the handoff, not after.
Which information needs the tightest handling?
Some information is harmful to share even inside the business. Suspicion of money laundering is the clearest case. If a customer-facing agent learns that a suspicious activity report exists, it may disclose it, which in many jurisdictions is itself an offence. Information flowing to the money laundering reporting officer's team should be one-way: case agents can feed it, but nothing from it should reach agents that talk to customers. The same discipline applies when you prepare MLRO management information with an AI agent.
Employee data is another. An agent connected to your HR information system should answer narrow questions, such as whether someone is on leave, without passing salary or disciplinary history to an agent that books meetings.
What may agents do, and what stays with a person?
| Activity | Agents | People |
|---|---|---|
| Answer another agent's question from data they hold | Yes, the minimum answer, within the receiver's scope | Defining scopes for each role |
| Pass full documents to another agent | Only with redaction and a scope check | Approving exceptions |
| Share data with an outside party | Draft the disclosure | Releasing it |
| Respond to a regulator's information request | Gather and draft | Reviewing and sending |
| Move data across a confidentiality wall | Never | Deciding, case by case |
Regulator requests sit in the people column for a reason: what you disclose, and how it is framed, is a judgement. See whether an AI agent can answer regulator information requests.
What does this look like in practice?
Take a payments firm where a disputes agent handles a chargeback. It needs to know whether the transaction was flagged by fraud monitoring. The fraud agent holds the full alert: device data, linked accounts, an open investigation into a mule network.
The disputes agent asks a narrow question. The platform checks its scope, which covers "fraud flag present, yes or no, and date". The fraud agent returns exactly that. The investigation, the linked accounts and the device data stay where they are. If the disputes agent later drafts a letter to the customer, nothing in its context could reveal the investigation, because nothing about it ever arrived.
What does the platform layer have to do?
- Hold data scopes per role and check them on every handoff.
- Keep source and sensitivity labels attached through summaries and joins.
- Record every handoff, including refused ones, with what was requested and what was sent.
- Isolate memory per customer and purpose.
The customer-data side is covered in depth in how to stop an AI agent leaking customer data. The full design is in the governed agentic operating system guide.
Questions people ask
Is encryption enough to stop agents leaking data?
No. Encryption protects data in transit and at rest. Leaks between agents happen after decryption, when an agent with access passes data to one that should not have it.
Can an agent be trusted to decide what to share?
Not as the only control. Its judgement can be steered by its inputs. Scopes enforced by the platform decide what may move; the agent decides only how to phrase what it is allowed to send.
Should agents share a common memory?
Only for reference data that every agent may see, such as product terms. Customer and case data should be scoped, so one agent's memory cannot become another's leak.