Applying Zero Trust to AI Agents with Intent Agent Native Authorization

Watch the End-to-End Reference Implementation

Table of contents

Why Agents Must Earn the Right to Act

Agents earn the right to act. They do not assume it.

AI agents introduce a new authorization challenge. Unlike deterministic software, an AI agent may determine which tools and resources it needs only after it understands the user’s request. As a result, the required authorization is often discovered at the moment of execution, rather than upfront during authentication.

Existing authorization systems can determine whether an individual request is permitted. What they do not define is how an agent discovers the authorization requirements of the services it plans to invoke, obtains explicit approval for its planned operations before execution, and ensures that every runtime invocation remains consistent with that approval.

This distinction is important. Traditional authorization answers a single question:

Is this request allowed?

Agentic systems require an additional runtime guarantee:

Does this request still belong to the execution plan the user explicitly and cryptographically approved?

The plan-before-execute principle addresses this challenge directly. Before invoking any tool, the agent computes its planned operations, derives the required authorization, and presents that authorization request to the user. The user reviews the planned operations, explicitly approves them with a phishing-resistant cryptographic gesture using a Passkey, and only then does execution begin. Every subsequent runtime invocation is verified against that approved execution plan, ensuring the agent cannot silently expand the scope of its behavior after approval.

This approach applies Zero Trust principles to agentic execution. Authorization is established before execution and continuously verified during execution. Rather than granting broad permissions at login time, the agent requests authorization for the specific operations it plans to perform, the user explicitly approves those operations, and every runtime invocation is validated against that approved authorization.

Introducing Intent Agent Native Authorization for Agentic Profiles (IANA-AP)

Existing standards provide many of the building blocks required for secure AI agents. OAuth defines delegated authorization and structured authorization requests through Rich Authorization Requests (RAR). AuthZEN standardizes authorization requests and policy decisions, while protocols such as MCP standardize tool discovery.

What is still missing is the runtime authorization lifecycle that connects these capabilities. Before an AI agent can execute on behalf of a user, it must answer four fundamental questions:

• What authorization does each service require?
• Which operations is the agent planning to execute?
• Has the user explicitly approved those operations?
• Does every runtime invocation remain within that approval?

Intent Agent Native Authorization for Agentic Profiles (IANA-AP) defines a runtime authorization framework for first-party AI agents that answers these four questions. Rather than introducing a new authorization model or replacing existing open standards, IANA-AP composes and extends them into a complete runtime authorization lifecycle, enabling organizations to adopt agent-native authorization using their existing identity infrastructure.

IANA-AP extends traditional login-time authorization with runtime authorization for agentic interactions. Rather than authorizing broad capabilities once during authentication, the framework computes a structured authorization intent from the user’s prompt, obtains explicit user approval before execution, and cryptographically binds that approval to the resulting authorization token. Every runtime invocation is then verified against that approved authorization intent.

The framework is available as an open specification on GitHub. This article introduces the motivation, concepts, and architecture. Readers interested in the normative protocol definitions, message formats, and processing rules should refer to the specification.

The following sections describe the framework through four consecutive phases that together implement the complete runtime authorization lifecycle.

The Four-Phase Runtime Authorization Lifecycle

OAuth provides delegated authorization. AuthZEN standardizes fine-grained authorization decisions. MCP standardizes tool discovery. IANA-AP connects these capabilities into a complete runtime authorization lifecycle across four phases.

Phase 1: Discover Required Authorization

Before an agent can ask for authorization, it needs to understand what authorization each service requires. Rather than embedding this knowledge inside the agent, IANA-AP lets services advertise it through machine-readable Agentic Profiles. This means agents can work with any service dynamically, without requiring service-specific authorization logic built in.

For MCP, the agent reads the Agentic MCP Profile from each server via the MCP Server Card or tools/list response. Each tool that participates in IANA-AP declares its authorization requirements through an x-authz-mapping extension field inside its _meta object. The presence of this field is the opt-in signal that the tool supports pre-computed authorization.

IANA-AP uses the SARC model (Subject, Action, Resource, Context) to represent each authorized operation. This is the same model used by the OpenID AuthZEN Authorization API, which means the intent entries computed in Phase 2 map directly to the structure the PDP expects at enforcement time, with no translation layer.

The x-authz-mapping field carries three sub-objects expressed as CEL (Common Expression Language) expressions:

• action: the SARC action component (e.g. which MCP method is being called)
• resource: the SARC resource component (e.g. which tool on which server)
• arguments: argument names mapped to CEL expressions that resolve values from the user’s prompt (e.g. which specific userId was mentioned)

A conforming MCP Server Card exposes tool definitions with x-authz-mapping like this:

{
  "$schema": "...",
  "version": "1.0",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  ...
  "tools": [
  {
    "name": "disable_user",
    "description": "Disable a user account by userId.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "userId": { "type": "string" }
      },
      "required": ["userId"]
    },
    "_meta": {
      "x-authz-mapping": {
        "action":   { "name": "params.method" },
        "resource": { "type": "'mcp-tool'", "id": "params.name" },
        "arguments": { "userId": "params.arguments.userId" }
      }
    }
  }
  ]
}

The CEL expressions are evaluated against the same context in both Phase 2 (by the agent, against the planned call) and Phase 4 (by the PEP, against the actual MCP request). This ensures that what was planned and what is executed are evaluated by identical logic.

Tools without an x-authz-mapping field cannot be pre-authorized. If the agent calls such a tool, the PEP can request just-in-time re-authorization following the Agent Native Authorization (ANA) framework.

Phase 2: Compute Authorization Intent

Once the authorization requirements are known, the agent determines exactly which operations it plans to execute and translates them into a structured authorization request. This phase does not issue a token yet. It prepares the request that will later be reviewed by the user and approved by the Authorization Server.

Using the authorization mappings discovered during Phase 1 together with the user’s prompt, the framework produces an authorization_details array containing one or more agent_intent entries. Each entry represents a planned operation for which the agent requests authorization before execution.

IANA-AP introduces agent_intent, a proposed Rich Authorization Request (RAR) type for representing an agent’s planned operations. Each entry describes a planned tool invocation at a conceptual level: the action the agent wants to perform, the resource it wants to act on, the intended audience, and the contextual arguments needed to keep runtime execution aligned with the user’s approval.

At this stage, think of the structure like this. It is not meant to be a final wire-level payload; it is a reader-friendly shape of what the approved token will later carry:

  token
  └── authorization_details
      └── agent_intent
          ├── action
          ├── resource
          └── context

Conceptually, this says: “the agent wants to call this kind of tool, on this kind of resource, for this audience, with these contextual arguments.” The specific values are derived from the user’s request and from the authorization mapping published by the MCP server.

The agent produces one agent_intent entry per planned tool invocation and collects them into an authorization_details array. One possible implementation is to delegate this phase to a dedicated Intent Agent. This component is responsible only for authorization planning. It never invokes tools or executes operations; its sole responsibility is to compute the agent_intent entries that will later be presented to the user.

The agent must present the computed authorization details to the user for review before submitting the authorization request.

IANA-AP uses the OAuth 2.0 Rich Authorization Requests (RAR) format to represent agent_intent. This design choice enables interoperability with existing Authorization Servers, such as Keycloak, Ping Identity, Gluu and others, by building on an established authorization mechanism rather than introducing a completely new request format. Future iterations of the specification may define additional token representations optimized for agent-native authorization; however, this initial version focuses on leveraging existing standards to simplify adoption and implementation.

Phase 3: Review and Approve

At this point, the agent knows exactly which operations it intends to perform. Before executing any of them, those operations must be explicitly approved by the user.

The user now reviews exactly what the agent intends to execute. Nothing has happened yet. This is the moment where explicit human approval enters the flow — and it happens natively, without any browser redirect or context switch. I call this Agent Native Authorization: an authorization pattern in which the agent orchestrates the authorization flow defined by the Authorization Server (Identity Provider) directly within its own interface. Unlike traditional browser-based OAuth flows, IANA-AP delivers the authorization challenge to the agent in a structured, machine-readable format. The agent renders the challenge within its own interface, allowing the user to review the planned operations—including the tools to be invoked, the target resources, and the associated arguments—before explicitly approving them. Once approved, the agent completes the required authentication challenge without interrupting the conversational or terminal experience.

This phase is delegated to two existing specifications:

OAuth 2.0 First-Party Applications (FiPA) defines the challenge/response flow. The agent submits the authorization request carrying the authorization_details to the Authorization Server.

OAuth 2.0 Agent Native Authorization (ANA) defines the structured elicitation format. When the Authorization Server receives the request, it returns HTTP 400 with error: insufficient_authorization and an elicitations array. The elicitations array carries a human-readable message summarizing the planned tool invocations and a requestedSchema that asks the user to select an authenticator.

{
  "error": "insufficient_authorization",
  "auth_session": "sess_abc123",
  "elicitations": [
    {
      "mode": "form",
      "message": "The agent wants to perform the following actions:\n- Disable user alice (identity-server)\n- Delete user alice (identity-server)\n\nApprove with your passkey to proceed.",
      "requestedSchema": {
        "type": "object",
        "properties": {
          "authenticator": {
            "type": "string",
            "title": "Authentication Method",
            "oneOf": [{ "const": "passkey", "title": "Passkey" }]
          }
        },
        "required": ["authenticator"]
      }
    }
  ]
}

For more information about the specification, refer to the following proposal.

The agent renders this challenge natively to the user. The user reviews the planned invocations and approves with a Passkey, a phishing-resistant FIDO credential unlocked using the device’s biometrics, PIN, or security key. The WebAuthn ceremony is performed in-band by the agent. On successful authentication, the Authorization Server issues a new token containing the approved authorization_details with the agent_intent entries.

The following shows how the agent presents the planned actions for the user to review:

The user then approves the planned actions with a Passkey gesture:

The issued token is not a broad credential. It is a cryptographically bound record of exactly which tools, on exactly which resources, with exactly which arguments the user chose to authorize.

This article focuses on the interactive case where the user is present and can approve the request directly from the agent experience. Because the architecture is built on open standards and composable authorization flows, the same pattern can be extended to Asynchronous Authentication with CIBA when the user is not currently present.

Phase 4: Runtime Enforcement

Receiving a token does not automatically authorize every future action. Every invocation must still match one of the approved operations from the token. This is what closes the gap between what the user approved and what the agent actually executes.

Approval alone is not sufficient. Every runtime invocation must still be verified before it executes. Runtime enforcement ensures that each tool call remains consistent with the authorization previously approved by the user.

In the simplified architecture shown in this article, the MCP server acts as the Policy Enforcement Point (PEP). It intercepts every tool call and delegates the authorization decision to a Policy Decision Point (PDP): remote via AuthZEN, or local via Cedar or OPA.

OpenID AuthZEN is a standard that defines a vendor-neutral interface for fine-grained authorization decisions between a PEP and a PDP, enabling centralized policy governance across the agentic stack. Any AuthZEN-compliant PDP can be plugged in: Keycloak, Axiomatics, OpenFGA, and others.

In production architectures, a common recommendation is to place additional Policy Enforcement Points (PEPs) at gateway layers, such as AI gateways and API gateways, so authorization decisions can be enforced at multiple stages throughout the request lifecycle. This follows the Zero Trust principle of continuously verifying and enforcing authorization decisions rather than relying on a single enforcement point.

When the agent calls a tool with a Bearer token, the PEP:

1. Validates the token (signature, expiry, audience)
2. Extracts the authorization_details claim and identifies the matching agent_intent entry for the current invocation
3. Extracts the SARC fields from the matching agent_intent entry and translates them into a PDP authorization request: when using AuthZEN, this is an Authorization API access request; when using a local engine such as Cedar or OPA, the same SARC fields are mapped to the engine’s native input format
4. On allow, executes the tool and returns the result; on deny, rejects the request

A critical enforcement detail: the PEP compares the actual call arguments against the approved resource.properties.arguments carried in the agent_intent entry. The user approved a specific resource, not just a tool. If the token was approved for userId: alice and the agent calls with userId: bob, the PEP rejects the invocation. This closes the time-of-check to time-of-use gap at the resource level.

If no matching agent_intent entry exists for an invocation, the PEP can request just-in-time re-authorization following the Agent Native Authorization (ANA) framework.

Putting It Together

The previous sections described each phase independently. The following example shows how the four phases work together during a single user request. A user instructs the agent:

Disable alice’s account, delete her data, and list all disabled users.

The agent has access to one MCP server (an Identity MCP Server) exposing three tools: disable_user, delete_user, and list_users, each with an x-authz-mapping.

The Intent Agent operates only in phases 1 and 2. It receives the tool definitions fetched from the Identity MCP Server in phase 1 (each with their x-authz-mapping) together with the user’s prompt, and produces the three agent_intent entries. From phase 3 onward it plays no further role. The Agent drives the authorization flow, and in phase 4 each tool call is intercepted by the PEP, matched against the corresponding agent_intent entry in the token, and verified via an AuthZEN access request before execution.

This is a simplified view of the flow. Here the Identity MCP Server is the visible PEP, because it is the component receiving the tool calls. In a production deployment, the same enforcement pattern can also be applied at gateway layers, such as an AI gateway or API gateway, so policy checks happen before traffic reaches the MCP server and at the service boundary.

Reference Implementation

The framework described in this post is not purely conceptual. The following demo shows an end-to-end prototype covering the full runtime authorization lifecycle: Agentic Profile discovery, authorization intent computation, user approval via Passkeys, OAuth Rich Authorization Requests, AuthZEN-based policy evaluation, and runtime enforcement across agent interactions.

The implementation is built on TwoGenIdentity components, including the TwoGenIdentity Agent Native Authorization (ANA) Framework and authorization gateways for coarse-grained and fine-grained authorization across the agentic stack. The agent orchestrator supports MCP, Agent-to-Agent (A2A), and MCP Apps protocols, with Keycloak as the Identity Provider extended with advanced authentication and authorization capabilities.

While the prototype demonstrates one concrete realization of IANA-AP, the framework is designed to remain implementation-agnostic and interoperable through open standards.

Composable by Design

IANA-AP is designed as a framework, not a platform. Organizations can adopt individual pieces without replacing their existing identity or authorization infrastructure.

Architectural Layers

The Authorization Server, the Policy Decision Point, and the Agentic Profile are all independently swappable. No redesign. Just composition.

Each layer is built on open, interoperable specifications:

IANA-AP does not replace existing standards. It composes them.

The x-authz-mapping concept builds on ideas explored within the COAZ OpenID AuthZEN work and the AuthZEN MCP Profile. IANA-AP adapts those concepts as part of a broader runtime authorization framework.

What’s Next

The current specification defines the framework for MCP, with Agent2Agent (A2A) Agent Cards and OpenAPI-described REST APIs as the Agentic Profile targets.

Future work also includes multi-agent scenarios involving delegated authorization intent across orchestrated agent chains, token attenuation for multi-service execution and standardized mappings to local policy engines such as Cedar and OPA alongside the normative AuthZEN interface. As the work evolves through community feedback, individual components of the framework may mature into focused, independent specifications.

Final Thoughts

Traditional authorization asks: “Is this request allowed?”

IANA-AP adds: “Does this request still belong to the execution plan the user approved?”

Traditional authorization answers whether an individual request is permitted. AI agents introduce an additional authorization requirement: every runtime operation must remain consistent with the execution plan the user explicitly approved.

IANA-AP defines a runtime authorization lifecycle that provides this guarantee by composing existing OAuth, authorization, and agent protocols rather than replacing them.

Instead of authorizing broad capabilities once at login, organizations can authorize the specific operations an agent plans to perform, verify every runtime invocation against that approval, and incrementally adopt the framework using their existing identity and authorization infrastructure.

The latest specification draft, reference implementation, and ongoing work are available on GitHub.

Licensed under CC BY 4.0 by Martin Besozzi.