.svg)
The industry focus is on assigning identities to agents but identity doesn’t equate to “should be authorized”.
As a case-in-point, at RSAC 2026, Crowdstrike’s CEO, George Kurtz shared an incident where an AI agent rewrote the company’s security policy:
Every identity check passed. Authorization was based on the agent’s underlying rights, not what it was trying to do at that exact moment and the context of that action. The agent was authorized to accomplish a task but chose a different action — one still within its granted permissions, but no longer aligned with the original intent.
“Most of the existing IAM tools that we have at our disposal are just entirely built for a different era,” Matt Caulfield, VP of Identity and Duo at Cisco told VentureBeat. “They were built for human scale, not really for agents.”
Identity is critical. Period. But for it to be truly useful, it must be bound, in a cryptographic and verifiable manner to its immutable definition:
Without that, an identity is simply a label, even if that label is a cryptographic asset such as a certificate. You know a local name but no idea what it does or why – it isn’t even consistent across IAM boundaries.
A2A 2.0 partially addresses this gap by supporting signed Agent Cards. We must do the same for tools and resources that agents use.
A recent article on CSA’s website rightfully captures that traditional software and APIs are deterministic. Because of that, we can assign access deterministically. The intent is defined and controlled by the application layer as are fine-grained decisions such as exceeding your spending authority. Agents foundationally break this model – on purpose.
The non-deterministic nature of agents with their ability to observe, plan, discover, act, assess, and repeat is precisely why they are so powerful – and also why current IAM solutions fail for agents. Consider the differences between traditional systems and Agents:
In a true agentic model, the flow is defined at runtime. Because of this, we must assume that agents, tools, and resources will be used in unexpected ways. Identity doesn’t address this – context does.
Consider a delete_file tool. The identity of that tool is necessary for audit and logging but isn’t a deciding factor for authorization. That decision lies with who wants to delete the file, for what overall purpose, and the step that’s being executed. A delete_file tool must have the permissions to delete or it is useless. Whether it should execute is an authorization question that is only answerable in the context of the request.
Determining whether this invocation of this component should be allowed requires assessing, together, at every invocation:
None of these can be evaluated in isolation. They aren’t five gates with five independent decisions. They’re five inputs to a single decision that must be made at every invocation.
Three things to note about this list.
First — originator authority is intent-scoped. The originator’s scope of authority for a given intent is bound to that intent. It describes what is allowed in functional terms, not technical implementation terms. An approving manager has authority to approve a vendor payment in the context of a vendor-engagement process, not in the context of a payroll modification — same person, same role, different process-bound authority. The originator’s authority must be evaluated against the intent declared at the start of the workflow.
Expressing authority in functional vs technical terms is important. The process does know, at start time, its goal – approving a payment in the example above. It has no idea what steps, agents, tools, or resources will be utilized to achieve that goal. Therefore, it is impossible to prescribe what technical access is required thus authorized.
Second — runtime context changes; the authority does not. The originator’s authority for an intent doesn’t change when an item goes on backorder, a shipping date slips, or a price moves. What changes is whether the current invocation still fits the original intent. That’s why these five inputs must be evaluated together at every invocation. Every observe-plan-discover-execute iteration is a new invocation with potentially new context to weigh against the same authority.
Third — this is a policy decision, not an identity decision. Evaluating these five inputs together belongs in a policy engine that can reason about entitlements, runtime context, and process state. SADAR provides the mechanism to serve this information to that engine but is not, itself, a policy engine.
The industry has recognized the problem but is still trying to solve it at the wrong layer.
At RSAC 2026, five major security vendors shipped agent identity frameworks. Cisco’s own identity lead publicly acknowledged that existing IAM tooling was built for an entirely different era. The summary across the conference, captured in VentureBeat’s coverage, was unambiguous: the industry shipped identity, not authorization.1
We are extending identity systems:
These each differ in approach but none close the gap. Most approaches still presuppose the technical access required before the execution path, participants, tools, and resources are known.
Rich Authorization Requests (RFC 9396) are valuable for expressing functional authorization — such as spending authority or process intent — but cannot define invocation-level technical access because the execution context does not yet exist.
You can read a more detailed analysis at SADAR Specification Overview.
Helpful? Yes
Sufficient? No
The diagnosis is right. The architectural response is incomplete.
For authorization to work in agentic flows, six properties must be present in the architecture. None of them are properties of identity; they’re properties of the layer that makes the authorization inputs verifiably available at the enforcement point.
These six properties provide the trust framework for the authorization context.
Identity is critical for attribution, audit/logging, and trusting the component’s invocation.
Identity-based authorization has worked because traditional systems control the execution. Dynamic agents break this model because the system no longer controls execution. Authorization must move from static capability assignment to runtime contextual adjudication.
The five inputs of authorization, within the six foundational principles are the substrate to provide the context to an enforcement layer
Is this action appropriate given the context at this exact moment – checked every time.
This is Zero Trust applied to agents, tools, and their resources — not as a choice, but as the only architecturally available position.
SADAR specifies the substrate that provides this context – across models, Agentic frameworks, hosting boundaries, and multiple hops. Agent identity is cryptographically bound to its meaning which is grounded in industry standards you already know and use. Discovery is deterministic and supports federation with bilateral, agent-to-agent trust.
