OAuth 2.0 is not broken because an AI agent uses it. It remains the right protocol family for issuing and presenting access tokens, expressing delegation, and binding a client to an authorization transaction. RFC 9700 still recommends restricted tokens, audience checks, and sender constraints where applicable. That is not the problem.
The problem is the quiet assumption that a valid token and a permitted API operation fully answer whether an agent should perform a particular consequential action now. An agent can turn one user request into a chain of tool calls, select values that the user did not enumerate, and reach a side effect that no scope string can describe by itself. A valid grant is not a standing instruction to proceed.
The industry needs a distinct agent-authorization domain between token issuance and the business operation. It combines the authorization server's proof of grant and delegation, a fine-grained policy engine's model of principal-action-resource semantics, and a context- and risk-driven decision engine. The resource still enforces the result. No one component should impersonate all the others.
This is also where a future interoperability standard could matter. It would give security teams, agent developers, and application operators one plane for describing an action, carrying an evaluated disposition, and proving what the PEP enforced. Without a shared direction, each vendor will define agent authorization semantics differently. The result is fragmented controls, inconsistent decisions across tool boundaries, and complexity that does not improve the transaction. This is a proposed future direction, not an existing standard.
OAuth proves a grant, not the meaning of an agent transaction
OAuth defines the roles that matter here: an authorization server issues access tokens after a grant, and a resource server accepts a token to protect a resource. RFC 6749 deliberately leaves the resource owner, client, authorization server, and resource server with separate responsibilities. That separation remains valuable when the client happens to be an agent.
A protected API must validate a token intended for it before using it as proof of authorization. Microsoft's access-token guidance is equally clear that the API owns token validation and that clients should treat access tokens as opaque. OAuth security guidance also says tokens should be restricted to the minimum privileges, resources, and actions required, with resource servers enforcing those restrictions for every request. RFC 9700 defines that as a core best practice.
That is standardized token and delegation mechanics. It does not supply a universal semantic model for questions such as: Is this payroll export for an approved case? Is the new payee related to the current supplier? Has this agent already attempted the same action through another tool? Should a proposed bulk deletion be staged rather than committed? Those are business- and transaction-specific questions. They require data the authorization server neither owns nor should be expected to infer.
OAuth Rich Authorization Requests is a useful bridge, not the destination. authorization_details lets a client request structured authorization data that an authorization server and protected resource can interpret, including resource, action, and transaction attributes. RFC 9396 gives the protected API and authorization server that shared vocabulary. It does not turn a bearer or sender-constrained token into a live model of an agent's tool chain, business purpose, or current risk evidence. Use OAuth to establish the authorized envelope. Do not turn the token into a mutable risk dossier.
Fine-grained policy gives the transaction its business meaning
An agent-authorization domain needs a policy decision point that understands the action as the business sees it, rather than only as an HTTP method against a route. Cedar is one example: its policies evaluate a principal, action, resource, entity attributes, and transient request context. Cedar's language documentation describes this model and its separation of policy from application code. Similar fine-grained authorization systems can fill the same role.
That distinction matters because POST /vendors/88421 is not a useful authorization verb. vendor.bank-account.change is. It can have a resource owner, a value change, a financial consequence, a required approver, and a rule that applies to this action but not to a vendor-address correction. The policy layer answers whether the authenticated agent, acting within a valid delegated or application grant, may propose this precise action on this precise resource.
The policy decision point must receive trustworthy attributes, not a bag of agent-generated labels. The resource owner supplies canonical resource attributes. The workflow supplies the operation and the proposed effect. The identity layer supplies validated principal and grant attributes. The agent can supply a declared purpose, but a policy should treat that as an assertion until an authoritative workflow record corroborates it. The agent may describe intent. The authorization domain decides which facts are authoritative.
validated identity and grant canonical business data
| |
v v
authorization server --> policy decision point
|
agent tool plan and request context ---+--> policy result: permitted or denied
The Agent Governance Toolkit architecture is a concrete application-layer reference architecture for this enforcement shape. It evaluates agent actions against policy before execution and separates policy, identity and trust, runtime controls, tool-call interception, and audit components. That makes it useful implementation evidence for putting a governance gate before an agent action. It is not a platform-neutral authorization protocol, and its component specifications and conformance tests describe the toolkit's own architecture rather than a shared interoperability contract. Reference architectures can prove an enforcement pattern. They do not, by themselves, standardize the decision exchange between systems.
This is already more precise than broad scopes. It is still not the complete decision for an autonomous actor, because permission semantics do not determine whether the current circumstances make execution acceptable.
Static policy needs bounded intelligent judgment for changing context
Static policies remain necessary deterministic guardrails. They define non-negotiable constraints: which principals may act, which business actions are categorically prohibited, which resources require an approval, and which conditions must always deny or stage an effect. Cedar, for example, evaluates explicit principal, action, resource, attribute, and request-context inputs against authored policies. Its language documentation describes that decision model. An adaptive system may not weaken a hard policy constraint.
Static policies alone cannot safely resolve every agent-authorization question. An autonomous actor encounters changing, incomplete, and cross-domain context that a policy author cannot enumerate exhaustively in advance. A bounded intelligent decision system can synthesize that evidence and propose, or make, a transaction decision only within an explicit authority envelope. The resource PEP must enforce that envelope, log the evidence and outcome, and reject decisions that are expired, unbound to the proposed effect, or outside its authority. The system must be tested and evaluated for its intended decisions, with human escalation for consequential or ambiguous cases. NIST's AI Risk Management Framework provides voluntary guidance for governing and evaluating AI systems, not an authorization protocol. Adaptive judgment can operate inside policy. It cannot replace policy ownership or resource enforcement.
The third component is therefore a context- and risk-driven decision engine. It evaluates signals that are time-bound, cumulative, or external to the grant: the sensitivity and volume of data, destination reputation, a sequence of failed attempts, an unusual operation rate, an open investigation, or a human approval that has expired. The engine returns a bounded disposition for this transaction. It does not mint access tokens, reinterpret OAuth grants, silently rewrite authorization policy, or become the policy owner for every resource.
This boundary is particularly important for insider risk. Microsoft Purview Insider Risk Management correlates service and third-party indicators to identify potentially malicious or inadvertent activity, then routes evidence through alerts, triage, investigation, and action. Its documented workflow is an investigative and response system, not a generic inline API authorization server. The Risky Agents template detects signals including risky prompts, sensitive responses, access to sensitive or priority SharePoint files, risky websites, external sharing, and activity above an agent baseline for supported agent platforms. The policy-template documentation defines that scope.
Those signals are useful evidence. They are not enough, by themselves, to dictate every API outcome. A risk system may know an agent's activity is unusual; the resource owner knows whether this operation changes a bank account, publishes a document, or merely reads a record. Risk supplies a disposition. The business policy supplies the meaning.
Agent proposes a business action
|
+--> authorization server: is the grant and delegation valid?
|
+--> policy decision point: may this principal propose this action on this resource?
|
+--> risk context engine: should this transaction proceed, hold, or require review now?
|
+--> resource policy enforcement point: commit, deny, hold, or escalate
The resource or application policy enforcement point (PEP) owns the final side effect because it owns the target state. This placement avoids asking an authorization server to understand every business transaction and avoids asking an insider-risk program to become an unbounded authorization service.
A proposed decision contract must bind decisions to the proposed effect
An agent-authorization decision cannot be allow in the abstract. A proposed future decision contract must bind to the proposed effect, the relevant version of policy, the evaluated context, and a short validity period. Otherwise, an agent can obtain a decision for a harmless request and reuse it for a different one.
Consider a procurement agent that receives a valid delegated grant to update supplier records. It proposes changing supplier 88421 from one bank account to another. The policy engine verifies that the agent is allowed to propose this kind of change for that supplier. The risk engine sees that the destination account is new, the amount of pending payments is material, and the agent has already attempted a similar change through a second workflow. The PEP stages the update rather than committing it.
{
"transaction_id": "6bfbdbd2-0f82-4b44-a27a-e1d939bc0d38",
"subject": "agent:vendor-onboarding",
"action": "vendor.bank-account.change",
"resource": "vendor:88421",
"proposed_effect_hash": "sha256:4d2c...",
"policy": { "decision": "permit", "policy_version": "vendor-change-v3" },
"risk": {
"disposition": "hold",
"reason_codes": ["NEW_DESTINATION", "DUPLICATE_ATTEMPT"],
"expires_at": "2026-09-01T14:20:00Z"
},
"enforcement": { "outcome": "staged", "required_approver": "finance-controller" }
}
The hash stands for a normalized representation of the proposed change, not a raw prompt. The PEP must recompute it before committing, reject an expired disposition, and record the policy and risk versions it relied on. This is ordinary transaction integrity applied to an agent decision, not a new claim about what OAuth tokens contain.
allow, deny, hold, and escalate are more useful than a single numerical score. allow permits the PEP to perform the already-authorized operation. deny prevents it. hold preserves a resumable state without the external side effect. escalate routes a specifically described proposed effect to a named approver or workflow. This vocabulary is an example of a proposed product contract, not a standard. Any such contract must be deterministic enough to test and audit. A risk score is evidence. A disposition is an enforceable decision.
Delegation does not erase the human authority boundary
Delegated authority is paramount when an agent operates in a human account context or on behalf of a human. OAuth defines the resource owner as the entity capable of granting access and models the client as a separate role. RFC 6749 preserves that distinction even when the client acts with a delegated grant. The agent may execute within that grant. It does not become the human principal, nor does an earlier authorization settle every later consequential choice.
Long-running operations make the boundary visible. An agent can collect evidence, coordinate tools, and reach a decision point hours after the human's initiating instruction. A future architecture should define a human-authority backchannel through which the agent can present the exact proposed effect, receive an approval, rejection, clarification, or cancellation, and bind that response to the transaction before the PEP commits.
The backchannel must be independent of agent-generated prose. The PEP or workflow service should construct the request from canonical action, resource, effect, deadline, and consequence data, then record the human response with the transaction. A chat message that says "looks good" is not enough unless the system can bind it to one immutable proposed effect. Delegated execution is not delegated sovereignty. The human retains authority over the consequential commitment.
Start with transactions that have a reversible boundary
The sharp edge is timing. An asynchronous investigation system cannot safely become an inline decision point unless its latency, availability, freshness, and failure behavior are explicitly engineered for that job. Purview's documented workflow moves from policy matches to alerts, reviewer triage, cases, and actions. Microsoft's workflow documentation supports a different operational purpose from a low-latency PEP call.
Begin where the application has a natural pending state. A customer-export agent can assemble the candidate set, evaluate sensitivity labels and destination, then hold the delivery link until a data owner approves. A knowledge-management agent can stage an external publication or bulk deletion and submit the exact diff for review. A payments agent can save a proposed bank-account change while preventing release of pending payments until the required approval arrives. For long-running delegated work, this pending state is the practical location for a proposed human-authority backchannel.
authorize grant -> evaluate business policy -> evaluate risk context
-> stage proposed effect -> approve or reject -> commit once
This design creates a real control point before the state change. Trying to reverse an external email, payment, or published document after an alert appears is incident response, not authorization. The PEP is the last trustworthy place to stop a consequential transaction.
Record observed facts, not an invented provenance story
Every agent transaction needs a durable record at the PEP. It should identify the authenticated agent principal, validated grant reference, initiating workflow or user context when observed, action, resource, proposed-effect hash, policy result, risk disposition, enforcement outcome, and correlation identifiers. That lets an investigation connect agent traces, authorization events, application telemetry, and a case without claiming that an access token proves who authored every intermediate model decision.
The privacy boundary belongs in the design, not the postmortem. Purview describes privacy-by-design controls including default pseudonymization, role-based access control, and audit logs. Microsoft's overview documents those safeguards. An agent-authorization record should minimize sensitive context, separate access to raw content from access to decision metadata, and retain each according to a documented purpose and schedule. Observability is not permission to copy every prompt into every audit system.
NIST's AI Risk Management Framework is voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. NIST AI RMF is useful here as a governance frame, but it does not substitute for a transaction protocol or a resource-specific enforcement decision. Risk governance and agent authorization must meet at the operation, where both can be made concrete.
Do not make the authorization server carry the whole system
It is tempting to solve the agent problem by packing richer claims into tokens or by making the authorization server query every risk source. That centralizes business semantics, changing risk data, and resource-specific side-effect knowledge in a component that cannot reliably own them. The result is either a fragile token schema or a shadow business-policy engine hidden behind token issuance.
Keep the four responsibilities legible. The authorization server establishes a valid grant and delegation boundary. Static policy defines deterministic, non-negotiable constraints for the named principal, business action, and resource. The bounded context and risk engine synthesizes admissible evidence into a time-bound disposition inside its explicit authority envelope. The PEP binds those outcomes to the proposed effect, enforces the envelope, records the decision, and controls the commit.
That is the proposed evolution. Current authorization standards and static policies remain necessary, and fine-grained authorization frameworks already solve a meaningful part of the semantic problem. The additional requirement is a bounded intelligent decision capability for context that is changing, incomplete, or spread across domains, with testing, logging, resource enforcement, and a human backchannel for consequential or ambiguous commitments. A future interoperability standard could define common decision and evidence exchanges while preserving resource-specific policy, the authority envelope, and the human authority boundary. This is an architectural argument, not a claim that a standard already defines it.
References
- RFC 6749: The OAuth 2.0 Authorization Framework
- RFC 9396: OAuth 2.0 Rich Authorization Requests
- RFC 9700: Best Current Practice for OAuth 2.0 Security
- Access tokens in the Microsoft identity platform
- Learn about Insider Risk Management
- Learn about Insider Risk Management policy templates
- Cedar Policy Language Reference Guide
- NIST AI Risk Management Framework
- Agent Governance Toolkit architecture
Top comments (0)