Your Agents Will Leak. The Question Is Whether You Built for It.

Agents are doing more on their own now. They write code, run searches, move data, talk to other agents. That is the upside everyone sells. The catch is that the same autonomy that makes them useful makes them risky in ways your old security model never planned for. The research that landed this month is blunt about it. Let me catch you up.

Treat your agent like a new hire you don't fully trust

DeepMind's new framework starts from a cold assumption: what if a capable agent is not actually aligned with your goals? Their answer is to treat untrusted agents the way a company treats a potential rogue employee who already has office access. Not malicious, just someone with permissions you have to watch.

The model they use is a driving instructor with dual controls. The agent drives. A trusted system sits ready to grab the wheel. Agents earn more access by behaving well over time, not by default.

Here is the part worth bringing to your team. After analyzing a million coding agent tasks, DeepMind found the majority of flagged events were not attacks at all. They came from agent misinterpretation or overeagerness to finish a job. Your bigger risk is a helpful agent doing the wrong thing fast, not a villain.

The fix you reach for first barely works

When ServiceNow researchers built MosaicLeaks, they tested whether a research agent could keep a secret. The setup is simple. An agent reads private company docs, then runs web searches to finish a task. No single search gives away the secret. But the full query log, read together, reassembles private facts. They call it the mosaic effect.

The obvious fix is to tell the agent not to leak. So they tried it. The prompt cut leakage a little and hurt task performance, and significant leakage stayed. Their line is the one to remember: "You can't prompt privacy in. You have to train it in."

It gets worse before it gets better. When they trained the agent only to solve more tasks, leakage climbed from 34% to 51.7%. Making it smarter made it leak more, because it packed more context into each search.

A better query for the task is often a worse one for privacy

That tension is the whole problem. The agent that retrieves the right document is also the agent that carries private fragments like "15%" or "January 2025" into its public searches. Good for the answer, bad for you.

ServiceNow's training method, PA-DR, rewards the agent for how it builds each query, not just whether the chain succeeds. The result: strict success rose to 58.7% while answer leakage dropped to 9.9%, lower than the untrained model started. The agent kept finding the right public docs. It just stopped dragging private details along.

The practical read for you: privacy is a property of behavior over time, not a checkbox in a prompt. You can measure it and train it down, but only if you treat it as a real objective.

The risk you can't see is between the agents

Single-agent thinking misses the next wave. DeepMind and partners just put up a $10M funding call for multi-agent safety, and the reason is honest: when millions of agents from different companies start talking and transacting, new group behaviors can show up suddenly, and we lack the tools to predict or measure them.

The builder's view backs this up. A hands-on Rust series on agent crews warns about "the multi-agent trap": adding agents usually raises latency, cost, and error surface. More agents is not free. Each one is another place for things to go sideways.

So before you wire up a crew of specialists, ask whether the roles are genuinely distinct. If they are not, you are buying complexity and risk for no real gain.

The deep cut

Proving an agent forgot something is harder than it sounds. A Google research team found that standard tests for machine unlearning flagged perfectly safe, retrained models as failures, because any tiny difference reads as a leak. Their better test caught a real privacy violation with a few thousand samples where older methods needed millions.

Why this matters on Monday: if a customer or regulator asks you to prove you deleted their data, "we ran an unlearning step" is not an answer. Most of the methods they tested, including finetuning and pruning, did not truly forget the data. Only one passed. If deletion is a promise in your product, you need a verification plan, not a vibe.

Three questions for your team

1. If one of our agents misreads a task and deletes or exposes data, what trusted system catches it before damage, and how fast does it respond?
2. Are we logging and reviewing our agents' outbound queries as a group, or only checking each one in isolation, which is where the mosaic leak hides?
3. When a customer asks us to prove we deleted their data, can we actually verify the model forgot it, or are we just trusting the delete step ran?