In May, VentureBeat published a well-researched account of a problem security teams are now encountering in practice: an AI agent can pass every identity check and still take an action it was never supposed to take. Cisco's Anthony Grieco described agents reaching data beyond the slice they actually needed, even though the agents themselves were legitimate. The article's conclusion was direct: agent authorization is broken.
I agree with the diagnosis, but I think it leads to another question that may be even more important. When we say an agent was “authorized,” do we mean that one system made an access decision, or do we mean that the system receiving the action can verify the authority behind it? Those sound like two versions of the same thing. Inside one company and one security stack, they often are. As agents, or what I prefer to call “digital workers,” begin working across tools, runtimes, and organizations, they separate. That separation is where the next authorization problem begins.
An authorization decision is local
The enterprise response taking shape today is sensible. Give every agent its own identity. Tie it to an accountable owner. Discover the tools it can reach. Put a gateway in front of those tools. Evaluate each call against current policy, then allow or deny the action.
Cisco now describes its own architecture in almost exactly those terms: Duo decides and the gateway enforces. Its policies can ask whether a particular user's agent may call a particular tool on a particular server at that moment. This is materially better than handing an agent a copy of a human account, a long-lived API key, or a role broad enough to cover everything it might eventually need.
It is also authorization as a local control-plane decision. The gateway trusts Duo. The tool trusts the gateway. The organization operates the policy and the enforcement point. If all of the important systems sit inside that trust domain, this can be a strong design.
The difficulty appears when the work leaves that trust domain. Imagine that a procurement agent inside one company asks a supplier's system to place an order. The buyer's policy engine may have approved the purchase. Its gateway may have logged the tool call. Its identity platform may be able to trace the agent to an employee. None of those facts automatically gives the supplier a way to verify what the employee authorized, whether the amount stayed within the approved limit, whether this agent was allowed to place the order rather than merely prepare it, or whether another agent in the chain narrowed or widened the permission.
The supplier can trust the buyer's assertion. It can call back to the buyer's systems. It can negotiate a shared identity and policy arrangement in advance. Those are valid choices, but they are trust arrangements. They are not the same as receiving evidence that can be verified directly.
The missing object is evidence
Authorization infrastructure has at least three jobs. It has to decide whether an action should be allowed. It has to enforce that decision where the action occurs. And, when another party needs to rely on the decision, it has to provide evidence of the authority behind it.
Most enterprise products are being built around the first two jobs. That is understandable because discovery, least privilege, runtime policy, and reliable enforcement are immediate operational needs. Cisco's RSAC 2026 guidance, for example, tells organizations to discover their agents, control access through a consistent enforcement point, and manage the agent lifecycle. Those controls address real failures and should be deployed.
The third job becomes important when the receiver cannot see or should not be required to trust the sender's internal control plane. A log entry saying “policy approved” is useful to the organization that owns the log. A token issued by a familiar authorization server can work where an issuer, audience, and validation arrangement have already been established. But an unfamiliar receiver still needs answers to a more demanding set of questions. Who granted this authority? Did that principal have authority to grant it? Which agent received it? What action and resource does it cover? What constraints and time limits apply? Was delegation permitted? Is the authority still valid? Does the evidence belong to this request, or was it copied from another one?
These are questions about the provenance and boundaries of authority, not only the identity of the caller or the output of a policy engine. NIST has made the distinction unusually clear. Its 2026 concept paper on software and AI agent identity and authorization does not stop at asking how agents should be identified and authenticated. It separately asks what mechanisms allow an agent to prove its authority to perform a specific action, how “on behalf of” delegation should work, and how agent identity should be bound to human authorization. The fact that these are still framed as open questions is itself instructive. Agent identity and agent authority are related, but one does not complete the other.
A policy reference is not the permission itself
It is tempting to solve the evidence problem by attaching a policy identifier to a request. That can be valuable, but it does not necessarily tell a receiver what was authorized. A policy identifier often points back to rules held by the issuer. The receiver may not possess those rules, may not know which version was evaluated, and may have no way to determine whether the request it received is the request the policy engine approved.
The same limitation applies to audit. A detailed record can help investigators reconstruct what happened. It does not, by itself, give the receiving system a reason to allow the action before it happens. Authorization evidence has to arrive in time to affect the decision, and it has to be bound closely enough to the requested operation that it cannot be replayed as permission for something else.
This is why the emerging standards work is moving toward more structured authorization objects. One current IETF work item, explicitly marked as an Internet-Draft rather than an adopted standard, proposes an authorization token for a specific agent operation, evidence of user confirmation, an agent-to-user binding, and a delegation chain. Another draft on AI agent authentication and authorization argues that user or system context must be preserved when an agent acts on someone's behalf and used in authorization decisions and audit trails. A separate agent auditing architecture draft treats authorization as a state that changes as agents make decisions, delegate work, and cross administrative boundaries.
These drafts differ in architecture and maturity. They should not be presented as settled consensus. What matters is the problem they are all circling: a static identity and a broad grant are poor descriptions of authority for a concrete action in a changing chain of work.
Do not ask one control to do three jobs
The right conclusion is not that gateways, policy engines, or identity platforms have failed. It is that they solve different parts of the system. A policy engine should remain free to use information that is local, sensitive, and dynamic. It may consider an employee's role, the classification of the requested data, current risk signals, the time of day, or an organization's internal approval rules. An enforcement point should still refuse a request that is unsafe or prohibited locally, even when the agent presents valid authority. A monitoring system should still detect behavior that is unusual, because an authorized agent can make a mistake or be manipulated.
Portable authorization evidence should do something narrower. It should allow the receiver to verify the delegation behind the requested action without pretending to replace the receiver's policy. The evidence can establish that a principal granted a defined authority to an agent, that each later handoff stayed within that authority, and that the presented request fits the signed constraints. The receiver can then combine that verified fact with its own rules.
The distinction matters because “valid authority” and “allowed here” are not synonyms. A purchase may be genuinely authorized by a customer and still violate a supplier's sanctions policy. An agent may have valid permission to write a file and still be blocked by the execution environment from leaving a designated directory. A request may satisfy both authorization and local policy and still trigger an anomaly detector. Layered security works when each layer makes a claim it can actually support.
What enterprises should demand next
Security teams evaluating agent platforms should certainly ask whether every agent has a distinct identity, whether access is short-lived, and whether policy is enforced on every consequential action. They should also ask what survives after the action crosses the vendor's gateway.
Can the receiving service verify who originally granted the authority? Can it determine the exact operation, resource, limits, and validity period without reading a private database? If an agent delegates to another agent, can the receiver verify the chain and reject any attempt to widen it? Can authority be revoked upstream? Is the proof bound to the current request and a fresh interaction? Are refusal results deterministic enough for two independent implementations to reach the same conclusion? And which parts of the decision still depend on trusting the vendor that assembled the record?
These questions expose the difference between an authorization feature and an authorization layer. A feature controls access inside a product or administrative domain. A layer gives different systems a common object they can evaluate while preserving their own policies and enforcement boundaries.
This is the distinction we are working on in Ratify Protocol. Ratify represents delegated authority as signed, constrained evidence that a receiver can verify. It is designed to complement identity, gateways, policy engines, sandboxes, and audit systems, not absorb their responsibilities. In our work with Agent Relay, the important test was not whether one platform could make an internal allow decision. It was whether a receiving side could verify delegated authority across a modeled organizational and runtime boundary without trusting the other platform's private logs. The work also exposed where portable authority stops and local resource confinement must begin.
VentureBeat was right to call attention to agents that authenticate successfully and then exceed their authority. The industry should act on that warning now. But if we define the solution only as finer policy inside a gateway, we will rebuild authorization as a collection of private control planes just as agents begin to move between them. The durable question is not only whether an enterprise can decide that an agent may act. It is whether the next system can verify why.