Beyond Agent Identity: The Authorization Control Gap

Executive Summary

The central security problem for AI agents is no longer only whether the organization can identify the software actor. It is whether the organization can decide, at the right moment, what that actor is allowed to do. The NCCoE's current Software and AI Agent Identity and Authorization project explicitly frames the problem around identifying, managing, and authorizing agent access and actions. [1] Microsoft's Agent ID documentation likewise separates agent identity management from authentication and authorization. [2] CyberTech Intelligence finds that a defensible enterprise model requires both: attributable agent identity and a separate authorization system that binds task, delegation, resource, action, conditions, approval, enforcement, and revocation.

Research Methodology and Source Selection

This report is a secondary-research synthesis and CyberTech Intelligence operating-model analysis. Eight public sources were selected to cover government agent-identity work, platform identity and authorization documentation, the Model Context Protocol authorization specification, two current authorization standards efforts, cloud agent boundaries, runtime-authorization product direction, and fine-grained agent permission design. Sources are used only within the scope they directly support.

Evidence Universe and Assumptions

No source is used to infer that a specific company has deployed unsafe agents, has excessive permissions, has suffered an authorization failure, needs a particular product, has budget, or is likely to buy. Vendor announcements describe the publisher's own capabilities or viewpoints. Internet-Drafts are proposals and may change. The MCP specification applies to MCP implementations, not to every agent architecture. CyberTech Intelligence frameworks are analytical decision aids rather than external standards.

Evidence Grading

Table 1. Evidence Grading and Permitted Use

Research Limitations

“AI agent” is not one uniform technical object. Agents may authenticate as workload identities, app identities, dedicated agent principals, user-linked accounts, or other constructs. Authorization can be enforced by cloud IAM, an API gateway, a policy engine, a resource service, an MCP server, an application, or a combination of layers. This report therefore avoids universal technology mandates and focuses on the evidence questions that remain useful across implementations.

Key Terminology Distinctions

• Agent identity: the attributable software principal or account used to identify and authenticate an AI agent within a system.
• Authentication: the process used to establish that the actor presenting credentials is the actor the system believes it to be.
• Authorization: the decision about whether an authenticated actor may perform a specific action on a specific resource under current conditions.
• Delegated authority: permission exercised by an agent on behalf of a human, application, or upstream agent within an approved scope.
• Step-up authorization: a stronger approval or assurance requirement invoked only for selected sensitive or high-impact actions.
• Runtime enforcement: a control outside the model that technically permits, denies, or narrows an action before execution.

These definitions are operational aids. Where a specification defines a term more narrowly, the specification controls within its scope.

Research Framework

Findings use the CyberTech Intelligence Agent Authorization Control Framework™: Identify Actor, Preserve Delegation, Define Task, Bound Resources, Authorize Actions, Step Up Impact, Enforce and Observe, and Revoke and Re-evaluate. The framework tests whether authority remains explainable from the initial actor through the final action.

Executive Findings

• Government and platform sources now frame agent security around both identity and authorization rather than identity alone. [1] [2]
• MCP authorization requires audience-aware token handling and explicit resource targeting, reinforcing that a valid token should be bound to the intended protected resource. [3]
• Current standards work is also exploring how identity and authorization context can remain attached to a transaction as it moves through a service call chain, but that work remains draft. [4]
• Cloud platforms are adding agent-specific resource boundaries and action controls to support least privilege. [5]
• Vendor platforms are moving toward runtime authorization for individual agent actions, but these approaches should not be treated as universal standards. [6] [7]
• The OpenID Foundation approved Authorization API 1.0 in January 2026, providing a standard interface for policy decision and enforcement components to exchange authorization requests and decisions. [8]
• Research Desk observation: agent authorization control breaks most often when identity, delegated task, policy decision, and enforcement are owned by different systems without a common record.

Identity Establishes the Actor

Microsoft's Agent ID documentation treats identity management, lifecycle governance, access protection, authentication, and authorization as related but distinct capabilities. [2] This separation is useful. An agent identity can make activity attributable, but attribution alone does not determine which downstream resources, tools, or actions should be available for the current task.

Authorization Establishes Allowed Action

The NCCoE project page uses the phrase “authorize access and actions taken by software agents.” [1] That wording matters because authorization is not merely a property assigned once to an identity. It can be a decision about an action. For an agent, the action may vary by tool, API, parameter, environment, data sensitivity, initiator, or current risk state. 

Delegation Must Preserve the Origin of Authority

Multi-agent workflows can introduce a privilege problem if downstream services see only the identity of the intermediate caller. The IETF Transaction Tokens draft is designed to carry user identity, workload identity, and authorization context through a call chain, including the purpose of the transaction. [4] Because the document is an active Internet-Draft, it is evidence of standards development rather than a finalized requirement. The control question is still valuable: can the downstream service understand the context and authority that originated the task?

Resource and Tool Boundaries Need Separate Policy

The MCP authorization specification requires resource indicators, token audience validation, and protected-resource metadata for HTTP-based authorization flows. [3] Those controls help bind a token to the intended resource server. They do not by themselves determine whether every tool operation inside that server is appropriate for the current business task. Organizations still need action-level policy where tool consequences vary materially.

Runtime Context Can Change the Decision

Google Cloud's June 2026 VPC Service Controls update describes agent identity in directional rules and least-privilege boundaries for agentic workloads. [5] Saviynt's June 2026 announcement describes its own runtime layer as deciding what agents can do while they interact with applications, data, APIs, tools, infrastructure, and other agents. [6] These are different implementations, but they converge on the same operating idea: the authorization decision can depend on current resource and action context, not only on the identity record.

High-Impact Actions Need Stronger Evidence

Auth0's June 2026 analysis argues for a permission model that can distinguish autonomous agent actions and apply fine-grained authorization. [7] A practical enterprise policy can extend that idea by classifying actions according to consequence. Low-risk, reversible retrieval may proceed automatically. Destructive, privileged, external, financial, or production-changing actions may require additional policy conditions or human approval.

Standardized Policy Interfaces Are Emerging

The OpenID Foundation approved the AuthZEN Authorization API 1.0 final specification in January 2026. [8] The specification standardizes how policy enforcement points and policy decision points communicate authorization requests and decisions. It does not prescribe one policy language or one agent architecture. For agent programs, that separation can be useful because policy can remain centrally governed while enforcement appears at multiple tool, API, or application boundaries.

Research Desk Observation: Control Fails at the Handoffs

Identity teams may own the principal, application teams the task, platform teams the gateway, data teams the resource, and security teams the policy. If those facts are not joined, an action can be technically authenticated and still be poorly authorized. Require evidence at each handoff: who or what is acting, on whose authority, for which task, against which resource, through which action, under which rule, and at which enforcement point.

Board-Level Evidence and Decision Metrics

• Percentage of priority agents with an attributable identity and named owner.
• Percentage of delegated workflows that preserve the initiating user or upstream-agent authorization context.
• Percentage of agent tools and APIs with explicit resource, action, and material-parameter policy.
• Percentage of high-impact actions protected by stronger policy conditions or human approval before execution.
• Number and age of standing scopes, roles, or sessions that exceed the current task requirement.
• Percentage of authorization decisions enforced outside the model at a deterministic boundary.
• Percentage of decisions with logs that preserve principal, initiator, task, resource, action, policy, decision, approval, and outcome.
• Time from material workflow change to re-authorization, narrowing, or revocation.

Twelve-Month Implementation Roadmap

0-90 days: Inventory priority agents and action paths; separate identity from authorization; document delegation, task, resource, action, and enforcement. 3-6 months: define high-impact actions, externalize selected policy decisions, reduce standing access, and add approval or stronger controls. 6-9 months: propagate authorization context across agent and tool chains, connect decision logging, and automate change-event reviews. 9-12 months: measure coverage, exception aging, deny-path testing, revocation performance, and decision quality before expanding autonomy.

Strategic Takeaway: Make Authority Explainable

The enterprise does not need perfect prediction of every agent decision. It needs explainable authority. For a material action, leaders should be able to show which agent acted, which task and initiator supplied authority, which resource and operation were requested, which policy decided the request, where the decision was enforced, and how authority can be narrowed or ended. That chain is the practical bridge from identity to control.

Identity-to-Authorization Path

Figure 1. From Known Agent to Measured Authority

Governance and Decision Rights

Figure 2. Agent Authorization Governance Framework

CyberTech Intelligence Agent Authorization Control Framework™

Figure 3. Eight-Layer Architecture

Agent Authorization Readiness Score™

Score each domain 0-4. Maximum 44 points. Readiness percentage = total score ÷ 44 × 100. Suggested internal bands: Critical 0-24%, Developing 25-49%, Defined 50-69%, Managed 70-84%, Adaptive 85-100%. This is an internal decision aid, not certification or prediction.

Agent Authorization Maturity Model

Figure 4. CyberTech Intelligence Agent Authorization Maturity Model

Benchmark Agent Authorization Readiness

About CyberTech Intelligence

CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and claim-safe GTM planning.

Research and Citation Governance

This report uses public sources current through September 1, 2026. Government, standards, official specifications, platform documentation, and vendor research are used only within their stated scope. Internet-Drafts are treated as proposals rather than final standards. CyberTech Intelligence does not infer that a named organization has an unsafe AI agent, excessive permissions, an active incident, buying intent, budget, or need for a specific product. Framework, maturity, and readiness content are CyberTech Intelligence synthesis tools for decision support and are not certification, incident prediction, or financial forecasting.

References

[1] National Cybersecurity Center of Excellence, “Software and AI Agent Identity and Authorization,” Current project, 2026. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization Accessed September 1, 2026. Relevance: NCCoE project page focused on standards-based approaches to identify, manage, and authorize agent access and actions.

[2] Microsoft Learn, “Microsoft Entra Agent ID documentation,” Current documentation, 2026. https://learn.microsoft.com/en-us/entra/agent-id/ Accessed September 1, 2026. Relevance: Official documentation organizing agent identity security across management, governance, protection, authentication, and authorization.

[3] Model Context Protocol, “Authorization - Model Context Protocol Specification 2026-07-28,” July 28, 2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization Accessed September 1, 2026. Relevance: Official MCP authorization specification defining OAuth-based protected-resource discovery, resource indicators, token validation, audience checks, and scope handling.

[4] IETF OAuth Working Group, “Transaction Tokens, draft-ietf-oauth-transaction-tokens-11,” July 30, 2026. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11 Accessed September 1, 2026. Relevance: Active Internet-Draft designed to preserve user identity, workload identity, and authorization context through a call chain; treated as draft standards work, not a finalized requirement.

[5] Google Cloud, “Securing agentic AI with perimeter guardrails: What's new in VPC Service Controls,” June 27, 2026. https://cloud.google.com/blog/products/identity-security/securing-agentic-ai-whats-new-in-vpc-service-controls Accessed September 1, 2026. Relevance: Google Cloud guidance on first-class agent identity and least-privilege resource boundaries for agentic workloads.

[6] Saviynt, “Saviynt Expands Identity Security for AI Solution With Intent-Aware Runtime Authorization for AI Agents,” June 15, 2026. https://saviynt.com/press-release/saviynt-expands-identity-security-for-ai-solution-with-intent-aware-runtime-authorization-for-ai-agents?hsLang=en Accessed September 1, 2026. Relevance: Vendor announcement used only for its stated runtime authorization model across applications, data, APIs, tools, infrastructure, and other agents.

[7] Auth0, “Why AI Agents Need Their Own Permission Model,” June 1, 2026. https://auth0.com/blog/why-ai-agents-need-their-own-permission-model/ Accessed September 1, 2026. Relevance: Vendor analysis used for fine-grained, task-sensitive authorization patterns for autonomous agents.

[8] OpenID Foundation, “Authorization API 1.0 Final Specification Approved,” January 12, 2026. https://openid.net/authorization-api-1-0-final-specification-approved/ Accessed September 1, 2026. Relevance: OpenID Foundation approval notice for the AuthZEN Authorization API 1.0 final specification, supporting standardized communication between policy decision and enforcement components.