Julian Durand Chief Security Architect at Intertrust Technologies.
Autonomous AI agents are arriving in the enterprise whether security teams are ready or not, so it is good news that the frameworks are catching up. Anthropic published “Zero Trust for AI Agents,” a thoughtful guide to applying zero trust to agentic systems, and it is worth any CISO’s time.
It offers one test worth taping to the wall: when evaluating a control, ask whether it makes an attack impossible or merely tedious. Against an adversary with unlimited patience and near-zero cost per attempt—which is what an AI-driven attacker is—tedious is not a defense.
The framework deserves to be built on rather than picked at. Still, I found one gap worth naming, a familiar one that I’ve watched the energy sector wrestle with for a decade in operational technology. AI agents turn out to be that problem in new clothes.
Stripped down, many of the guide’s strongest recommendations come to two things:
1. Isolate the agent through sandboxes, segmentation, least agency and a contained blast radius.
2. Prove its identity using cryptographic credentials, short-lived scoped tokens and hardware-bound keys.
Both are necessary, but neither is sufficient on its own. The guide’s own list of threats points to the gap: even an isolated, strongly authenticated agent can still create operational risk if its authority is not properly governed.
The Missing Layer: Authorization At The Point Of Action
Consider three attacks the guide describes:
1. Tool chaining, where an agent is steered into combining legitimate tools in a harmful sequence
2. The confused deputy, where a lower-privilege agent persuades a higher-privilege one to act
3. Unscoped privilege inheritance, where a manager agent passes its full access to a worker
In each case, the agent may be acting within its granted permissions, as the guide itself notes: traditional access controls can’t prevent tool misuse “because the agent operates within its granted permissions.”
That is the crux. Isolation limits how far a bad action can travel. Identity establishes who is acting. Neither answers the question that matters at the moment of action: Was this specific action, right now, authorized?
Authentication establishes identity: an actor is who it claims to be. Authorization establishes permission: that actor is allowed to perform a particular action under the circumstances. The first is a mature discipline. The second is too often an afterthought.
An analogy makes the gap concrete. Onboarding a brilliant new hire involves verifying their identity, issuing a badge and handing over a master key and a to-do list. The badge is real, the key works and no one checks whether each door they open was theirs to open. An autonomous agent with broad tool access and a manipulable goal is that new hire, except it acts thousands of times a second, never tires and will faithfully carry out an instruction quietly slipped into the data it was reading.
Encouragingly, the guide describes continuous authorization, evaluated “at each action rather than session start,” and that is exactly right. But it sits in the guide’s “Advanced” tier, which Anthropic describes as “aspirational capabilities for most organizations” and a baseline only for high-risk or heavily regulated deployments. I believe that ordering is backwards. For any agent that can take a consequential action, per-action authorization belongs in the foundation. Identity and isolation are the walls; authorization is the lock on the door the agent is standing in front of.
Making Authorization Part Of The Agentic Security Model
None of this is a knock on Anthropic, which did the field a service by writing this down, and its own conclusion points toward the fix. The controls it says survive a patient, automated attacker are hardware-bound credentials, expiring tokens, cryptographic identity and “network paths that do not exist rather than paths that are merely inconvenient.” That instinct—make the bad action impossible, not merely costly—leads directly to binding authority to the action itself.
So keep the boxes and keep the cryptographic identity; an actor that cannot be named cannot be authorized. Then add the layer the boxes and badges leave out: authority that travels with the request and is verified at the point of action, against the specific thing being asked at the moment it is asked.
The building blocks exist, though none are yet the default. Policy engines such as Open Policy Agent and AWS’s open-source Cedar can evaluate each request against policy at runtime. OAuth 2.0 Rich Authorization Requests let a client ask for permission to take specific actions on specific resources instead of receiving broad scopes.
I’ve seen a similar approach in the energy sector through the Trusted Energy Interoperability Alliance (TEIA), an industry alliance founded by energy companies including E.ON, JERA and Origin Energy together with Intertrust (where I serve as chief security architect). The alliance publishes open specifications that bind authority to each command. The receiving device checks every instruction against what the sender is actually permitted to do, building on network isolation and device identity rather than replacing them.
None of these are a finished answer. Devices and services must be built or updated to carry and check authority, which is slow across legacy fleets. Managing fine-grained grants across many parties needs tooling that is still maturing. And per-action authorization proves an instruction was permitted, not that the decision behind it was sound; an agent manipulated into a bad choice within its authority still needs monitoring and human oversight.
Operational technology spent a decade learning (the hard way) that proving who sent a command is not the same as proving the command should be obeyed. The same lesson is about to arrive far faster, carried by agents that act on our behalf at machine speed. It need not be learned the hard way this time. The frameworks are nearly there. They just need one more word.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
