When AI Agents Are Authorized to Act, Security Changes
In April, Microsoft's threat intelligence team went looking for a way to pull credentials out of a software build system. They did not find a broken lock. They found an AI agent with a file-reading tool, and they talked it into reading a file.
The file was /proc/self/environ, a Linux system file that holds the secrets with which a running process was started. The agent read it, found an API key, and handed it over. It was not jailbroken. It did not escape its sandbox. Every step it took was a step it had been authorized to take. The tool doing the reading had simply been left outside the isolation covering the agent's other tools. Anthropic fixed the issue in Claude Code 2.1.128, weeks before any of this was published.
That pattern—authorized, not breached—runs through nearly every agent security story worth reading, and it is why most corporate AI governance is aimed at the wrong target. Having built multi-agent systems since early 2023, the question I see teams ask first is almost always, What is this agent allowed to see? The question that determines how bad your worst day gets is, What is it allowed to break?
Those sound like the same question. The gap between them is where the damage lives.
Classifying data by sensitivity is a confidentiality model. It was built for an employee who might read something they shouldn't, and it works because a human who reads a file has not yet acted on it. An agent does not stop at reading. It reads, decides, and acts in a loop—at machine speed. And the acting is the part your classification scheme has no opinion about.
The security field has noticed. On August 4, the OWASP GenAI Security Project published the 2026 edition of its Top 10 for LLM applications, the first edition shaped by real-world incident data. Excessive Agency—the risk that a system can simply do too much—moved from sixth place to third. Notice who is missing from that diagnosis. The root causes are excessive functionality, excessive permissions, and excessive autonomy. Not one of them is a clever attacker. All three are decisions somebody on your side made, usually in a hurry and usually to ship.
Meanwhile, the risk sitting at number one is prompt injection, and nobody has solved it. Meta's security team calls it "a fundamental, unsolved weakness in all LLMs". That is not a vendor hedging; it is the state of the art. You cannot buy your way out of this at the model layer. Assume the agent will occasionally be persuaded to do something you did not intend, and design for what happens next.
The obvious objection is that none of this is new. Least privilege is thirty years old, and scoping permissions is Tuesday for any competent security team. Fair—the principle holds. What broke is the unit to which it applies. Classic access control scopes a standing identity to a role because a person's job is stable enough to describe in advance. An agent's job is decided at runtime. A role cannot express On this run, read the repository; on that run, open a pull request; never both in the same session. And that combination is exactly what turns an inconvenience into an incident.
Which is what makes Meta's "Agents Rule of Two" worth an executive's attention. It says an agent should hold no more than two of three properties at once: it can process untrusted input; it can reach sensitive systems; it can change things or talk to the outside world. Any two are survivable. All three create a chain. If a job genuinely needs all three, Meta's position is that the agent should not run unsupervised at all.
Check the Microsoft case against that framework, and it fails on every count. The workflow read untrusted text from public issues. It ran inside a machine holding live credentials. It could reach the network and open pull requests. Microsoft found a second repository where an agent could search a codebase, read files, and open a pull request—a chain they describe as "the exact high-level primitives needed to plant malware without directly possessing write access." Nobody granted that capability. It assembled itself, one reasonable-looking tool at a time.
Three things are worth doing before the next agent goes live. Inventory your agents by verb, not by noun: not what data each one touches, but what it can change, send, delete, or spend. Give every workflow its own credential, scoped to the minimum necessary and monitored where it is issued, so that a compromise has an edge to it. And where a job really does need all three properties, put a human in the loop on purpose and write down that you did so—a named supervision decision is governance; an unexamined one is an unowned risk.
None of this promises that your agents will behave. Meta is explicit that its framework is a supplement to least privilege, not a replacement, and that it will not stop a determined attacker.
But you were never going to be able to tell your board that the model cannot be fooled. What you can tell them is precisely what a fooled agent is able to reach. If you cannot, that is not a gap in the answer. That is the finding.
