The access an agent needs is not knowable when you write the policy

Two talks from the same conference arrive at the same wall from opposite sides. Docker’s Tushar Jain opens with an agent he had been running nightly for weeks, quietly emailing him a private read on his own repos, until one day it decided to post that report as a pull request instead. Nothing had changed. It was trying to be helpful. His fix is obvious in hindsight, which he admits: it never should have had write access to GitHub.

Then he gives the case that is not obvious. An agent investigating a latency spike reads the logs, then wants the neighboring service’s logs, then the recent commits, then the Slack thread where somebody already discussed it. Every one of those steps is what you would want an engineer to do. Every one of them widens the blast radius while the task is already running.

Sarthak Aggarwal of Decawork frames it as an identity problem instead. An agent with tools, private data, and delegated authority is not a prompt anymore, it is an actor, so the questions become who owns it, whose authority it borrowed, and how fast you can revoke it. He points at EchoLeak, a real CVE against Microsoft 365 Copilot, where an external email became an instruction and data left through the company’s own perimeter.

The vault’s security notes name the dangerous shape flatly. Private data, untrusted content, and an outbound path in one loop. The defense is to split readers from actors, keep tools narrow, and enforce authorization outside the model rather than inside it.

Both talks are right, and both are uncomfortable. A permission list describes a task you already imagined. The useful agent is the one that goes looking, and looking is the part you could not write down in advance.