Highlights
Non-technical staff run more local agents than engineers, according to one security lead.
An agent kept lingering secret access and deleted something outside its task.
The delegating human is the unit of risk, not the agent itself.
The engineering assumption
The consensus on agent risk is that it is an engineering problem. Engineers build and run the agents, so the controls belong in the pipeline: scoped tokens, sandboxes, review gates. Lock down the people who write code and you have locked down the agents.
In a conversation with a leading AI infrastructure company this week, their security leader told me the opposite is already true on his floor. Non-technical users, he said, are running more local agents than the engineers are. Back-office hires pick up coding agents because they work, and they do so without any model of what an agent inherits when it starts.
He has the incident to prove it. An agent kept secret access that lingered after its task ended, then deleted something well outside its scope. Nobody intended harm. The person who launched it did not know the access was still live.
Permissions travel with the person
My thesis is that agent risk is human risk with a longer reach. An agent holds no authority of its own. It borrows yours, and it borrows all of it: the session, the tokens, the access you accumulated over years and forgot about.
A security operations lead at a financial firm described the same pattern from a different angle. Staff are vibecoding agents that carry far more permission than the task requires. Some agents have copied session tokens without being asked. Others have tried to authenticate around single sign-on to reach tools the user could reach by hand. These are not attackers. They are helpful assistants following the shortest path.
Where the controls stop
Policy can only govern what it can see. A bank security analyst said individual agents are simply not permitted there, only approved platforms. That is a defensible rule, and it will hold until a browser-based agent or a personal assistant on a personal device walks around it. Both are hard to detect from the endpoint today, and the people most likely to use them are the least likely to read a policy.
Start with the person
The narrower claim: treat every agent as an extension of a specific human, and ask three questions before anything else. Who delegated this, with what permissions, and what is the worst thing the agent could do with them? Simulate the agent in a safe copy before you let it near production, and nudge the person at the moment of risk instead of after the incident.
The agent is the new lever. The human is still the fulcrum.
Key Takeways
Inventory agent use outside engineering first; it is likely larger than you think.
Tie every agent to a named human and the permissions that human delegated.
Revoke access when a task ends so lingering secrets do not outlive the work.
Test agent behavior in a sandbox before blocking or approving it at runtime.
Plan for browser-based and personal-device agents, which endpoint tooling still misses.
