Identity, authority and policy for AI agents

On this page

Chapter 9 of The Hitchhiker's Guide to the Agentic Economy

Report hub · Previous: agent-to-agent coordination · In this chapter: the identity stack · market map · revocation · Authority Record · Next: evaluation, observability and security

Our view

An agent identity answers which software actor connected. It does not answer what that actor may do, who authorised the action, or whether the authority still applies. Production systems need a chain that connects a human or organisation to an agent workload, a bounded policy decision, a credential, the resulting action and an accountable owner.

The practical test is revocation. If an organisation cannot promptly remove the agent's effective ability to act across cached tokens, active sessions, downstream tools and delegated agents, it does not control the authority it granted.

Key Takeaways

• Human identity, agent or workload identity, delegated authority and policy decisions are separate records.
• OAuth scopes and access tokens can carry bounded access, but the resource still has to make and enforce an authorisation decision.
• Agent-specific identity products are emerging around inventories, sponsors, blueprints, token vaults and lifecycle controls. Product documentation does not establish broad adoption.
• Enterprise products are beginning to assign consequential agents a business sponsor as well as a technical owner.
• Effective revocation depends on the full action path; disabling one identity object is insufficient while another usable credential remains.

This chapter uses standards and provider documentation checked on 13 September 2026. Identity products and agent-specific specifications are moving quickly. The stable subject is the authority chain; named products are dated market records.

Sources and scope

Agentic Economy compared published standards, open-source policy infrastructure and current provider documentation. We label specification and documentation as supply evidence, not proof of deployment quality or use. About Agentic Economy explains the publisher. Source corrections can be submitted through the contact page.

Agent identity is becoming a product category

Identity providers are extending human and workload identity systems to agents. Microsoft is introducing agent identities, blueprints, owners and business sponsors through Entra. AWS and Auth0 are documenting delegated and machine-to-machine token patterns for agent workloads. Policy vendors are adapting existing authorisation engines to decisions made by software actors.

Microsoft's 2026 architecture guidance states that “Every agent should receive an Agent ID” (Microsoft, "How to Build Agents with Microsoft"). That is the clearest incumbent signal in this category: agents are being pulled into the same directories, ownership models and policy systems that enterprises already use for people, applications and workloads.

The category is forming above ordinary authentication. The market now needs to represent the principal, agent application, running workload, delegated purpose, credential and resource decision without treating them as one identity. We expect agent inventories and sponsorship to become standard enterprise features, while portable authority across organisations remains a harder and less settled layer.

The identity stack

A complete authority path has at least seven distinguishable parts:

1. A principal is the person or organisation on whose behalf the work is being done.
2. An agent application is the software product or configuration attempting the job.
3. A workload instance is the running process, session or ephemeral agent that connects to a service.
4. Delegation is the record connecting the principal's intent to the actor and purpose.
5. A credential is the proof presented to obtain or exercise access.
6. A policy decision is the evaluation of actor, principal, resource, action and current conditions.
7. Enforcement and evidence are the systems that permit, deny or modify the action and record the result.

These parts can be compressed by a platform, but they do not disappear. A bearer token may identify an application and name scopes. It may not show the business purpose, current job, human approval, acceptance limit or downstream subdelegation. A signed mandate may preserve more transaction context, but the receiving system still needs to validate it and decide what it means for that resource.

Authentication is the start of the decision

Authentication establishes confidence in an asserted identity. Authorisation decides whether that identity may perform a particular action. Delegation connects the action to another principal. Policy provides the rules and context used for the decision.

The distinction predates current agents. What changes is the frequency and shape of the decisions. An agent may select a tool at runtime, create subagents, work while the user is absent and cross several systems before completing one job. Static access granted to the whole application is a poor description of that moving authority.

The US National Institute of Standards and Technology opened a 2026 project on software-agent identity and authority around exactly these questions: identification, authorisation, audit, non-repudiation and controls for prompt injection (NIST, "New Concept Paper on Identity and Authority of Software Agents"). The project signals an unsettled implementation problem. It is not a completed standard.

Standards already supply useful building blocks

Agent identity does not require discarding established identity infrastructure. Current products mostly extend or combine it.

Building block	What it supplies	What it does not supply by itself
OpenID Connect	Authentication and identity claims for a user or software interaction	A job-specific right to perform every downstream action
OAuth 2.0	Delegated access tokens, scopes and grant flows	Business purpose, acceptance criteria or safe interpretation by a model
OAuth token exchange	A standard way to exchange one security token for another with requested subject, actor, audience or scope	A universal policy for whether the exchange should be allowed
SPIFFE and SPIRE	Portable cryptographic workload identities and trust-domain federation	Human delegation, business accountability or resource policy
OpenID AuthZEN	A standard interface between policy enforcement and policy decision points	The organisation's policies or proof that every resource enforces them
Open Policy Agent	A general-purpose policy engine and policy-as-code decision interface	Identity proof, credential lifecycle or business approval

RFC 8693 specifies OAuth 2.0 Token Exchange and distinguishes the subject of a token from an actor acting on that subject's behalf. That distinction is valuable for agents, but an implementation still has to preserve it across each hop rather than flattening the chain into one service identity.

The SPIFFE Workload API is marked stable and supplies identities to local workloads after the implementation identifies the caller. SPIFFE federation lets trust domains exchange verification bundles. The specification explicitly leaves identity assignment and site policy to the operator. It can prove which workload presented an identity without proving that a user authorised this job.

The OpenID Foundation approved AuthZEN Authorization API 1.0 as a final specification in January 2026. It standardises communication between a policy enforcement point and a policy decision point. Open Policy Agent provides a separate open-source implementation pattern: software submits structured input, OPA evaluates policy and returns a structured decision. Both help separate decision logic from the code that enforces it. Neither determines the correct business rule.

Who supplies identity, authority and policy

Entity or product	Primary buyer	Job supplied	Commercial or operating model	Current evidence and boundary
Microsoft Entra Agent ID	Microsoft enterprise identity and agent teams	Agent identities, blueprints, inventories, lifecycle, access and protection controls	Enterprise identity platform and related licences	Current documentation describes agent-specific identity objects, Conditional Access and governance. It does not establish adoption outside Microsoft's environment.
Amazon Bedrock AgentCore Identity	AWS agent builders	Workload access tokens, OAuth credential providers, user-delegated and machine access, token storage	Managed cloud service tied to AgentCore and AWS identity	Documentation shows operational flows and APIs. Availability does not prove a customer's policies are least-privilege.
Auth0 Token Vault	Application developers	Connect user accounts, store and exchange third-party OAuth tokens, call APIs on a user's behalf	Managed identity platform with subscription and enterprise plans	Documentation states that Token Vault builds on OAuth token exchange and supports named connections. It does not encode the whole business mandate.
SPIFFE and SPIRE	Platform and security teams	Portable workload identity, attestation and federation across infrastructure	Open standards and open-source implementation	Stable specifications support workload authentication. Agent-specific delegation and ownership sit above the workload identity.
OpenID AuthZEN	Identity vendors and application teams	Interoperable authorisation requests and decisions	Open standard implemented by policy products and services	The final API standardises a decision interface. Deployment and policy quality must be checked separately.
Open Policy Agent	Platform, security and application teams	General policy-as-code decisions for APIs, infrastructure and workloads	CNCF open-source project; commercial control planes and support exist around it	Mature general policy infrastructure, not an agent-specific mandate or credential product.
Payment and commerce mandates	Wallets, merchants and payment networks	Bind a proposed purchase to amounts, merchants, time or user consent	Protocol and network-specific	Useful specialised authority records. They do not govern non-payment tools or prove delivery and acceptance. Planned Chapter 13 covers payment credentials and settlement.

Microsoft's current design illustrates the direction of enterprise products. Entra Agent ID distinguishes technical owners from business sponsors and requires at least one sponsor when an agent identity or blueprint is created. Its architecture guidance separates interactive delegated access from autonomous application access and recommends one blueprint per trust boundary (Microsoft, "Plan your agent identity architecture"; "Owners, sponsors, and managers"). These are documented product controls, not evidence that sponsorship alone produces accountability.

AWS and Auth0 show a second product pattern: keep downstream credentials in a vault and let the workload obtain a scoped token when needed. AgentCore documents user-delegated, machine-to-machine and on-behalf-of flows and says its workload access token can bind the agent and end-user identities (AWS, "Supported authentication patterns"). Auth0 documents connected accounts and token exchange without placing long-lived third-party credentials in the client application. The control benefit depends on scope, audience, token lifetime, storage, refresh, logging and resource enforcement.

Policy has to travel to the point of action

A policy written in an agent's system prompt is guidance to a probabilistic component. It is not the final enforcement point for a bank transfer, database deletion, software deployment or customer message.

Models propose actions; deterministic controls constrain their effects:

principal and job
  -> authenticated agent workload
  -> proposed resource and action
  -> policy input: principal, actor, purpose, data, amount, time, risk
  -> allow, deny, modify or require approval
  -> issue or obtain bounded credential
  -> resource enforces decision
  -> action and evidence recorded

The resource or a trusted gateway validates the credential and enforces the decision. An upstream agent saying “the user approved this” is making a claim; the downstream system needs a verifiable representation or its own approval flow where consequences warrant it.

Approval binds to the proposed effect

A useful approval shows what will happen: target, operation, data disclosed, amount where relevant, timing and whether the action is reversible. Approval of “handle my inbox” is too broad to authorise sending every message. Approval of a draft is incomplete if the agent can change the recipient or attachment after review.

Effective approval binds to a canonical action representation or digest, expires, and fails when a material field changes. The record carries the approver and result. High-frequency low-risk work may use standing policy with thresholds; high-impact exceptions return to a person or a stronger mandate.

Policy needs current context

Role-based access is often too coarse for agents. The decision may also depend on:

• customer or tenant;
• job purpose and acceptance boundary;
• data classification;
• resource and requested action;
• transaction amount or cumulative spend;
• geography, device, network or execution environment;
• time and expiry;
• model, runtime or tool version;
• whether the agent is attended;
• prior steps, risk signals and approval state; and
• whether subdelegation is permitted.

Context-aware policy creates more evidence and more failure modes. The inputs must be reliable, versioned where necessary and visible in the decision log. A policy engine cannot repair a false claim about the current user or an omitted target resource.

Revocation must remove effective authority

Effective revocation has two separate objectives. It must block new authorisations and newly issued credentials within a declared propagation target. For requests, browser actions, queue items or child work already accepted downstream, it must issue cancellation where supported, mark any uncertain effect, reconcile the resource and invoke the declared compensation, notification or remedy path. Revocation cannot guarantee that an external effect which already committed is undone.

Disabling the agent's front-end account may leave active OAuth tokens, refresh tokens in a vault, cloud sessions, API keys, queued work, browser sessions and delegated child agents. Conversely, revoking one downstream token may leave the parent able to mint another. For example, a disabled user interface can coexist with a valid refresh token held by a background worker.

Revocation operates as a graph:

principal
  -> agent identity
  -> workload sessions
  -> delegated and exchanged tokens
  -> stored refresh tokens and API keys
  -> queued actions
  -> child agents
  -> resource permissions

Two forms of revocation matter. Prospective revocation blocks new work within a stated target. In-flight revocation attempts cancellation or containment and records residual effects. Each edge has an expected propagation time and a first denied action. Provider unavailability leaves the job outcome_unknown until any possible effect is reconciled.

Microsoft's documented sponsor model allows a sponsor to disable or soft-delete an agent identity without giving that person full technical administration. That separation can improve response time when the business owner sees a problem. The organisation still needs to confirm what disabling the identity does to active sessions, downstream tokens and already queued effects in its exact design.

What the sources establish

Evidence	What it establishes	What it does not establish
Identity standard or protocol	Message, credential or verification semantics	Correct local identity assignment or resource policy
Provider documentation	Supported identity objects, flows and controls at a checked date	Correct configuration, adoption or effective revocation
Authentication log	Which credential or identity was accepted at one boundary	Human intent or authority for the business action
Policy decision log	Inputs, policy version and decision at one enforcement point	That every downstream effect used the same decision
Approval record	A named person approved a represented action	That execution matched the approved representation
Revocation test	Named credentials and sessions failed after a defined revocation event	Absence of every hidden or copied credential
Accepted-job record	The authorised work produced an accepted result	That the same authority design fits other jobs

The cited source set documents agent-specific identity objects, workload identity, token brokerage, policy decision interfaces and lifecycle controls. It does not establish one portable identity-and-authority model across agent platforms, organisations and resource providers, or show that a named sponsor alone carries every legal, privacy, employment, consumer or sector obligation.

An Agent Authority Record

Create one record for each material authority grant. The record is authoritative for principal, actor, purpose, resource, action, constraints, policy, expiry and revocation. Runs and delegations reference it; they cannot widen it by copying an older permission. Chapter 10 defines the shared record ownership and join keys.

Field	Required decision
Principal	Which person or organisation owns the objective?
Actor	Which agent application and workload instance may act?
Sponsor	Which business owner remains accountable for purpose and lifecycle, and which legal controller or regulated entity remains answerable where that is a different role?
Purpose	Which named job or class of work is authorised?
Resource	Which tenant, account, dataset, system or supplier may be reached?
Action	Which reads, writes, sends, executes, purchases or delegations are allowed?
Constraints	Amount, volume, time, geography, data class, environment and other bounds
Subdelegation	Whether another agent may receive authority, and which fields must narrow
Approval	Which actions need a person, which person, and which canonical target, operation, amount or data, timing and approval digest are bound at the enforcement point?
Credential	Token, certificate, key or mandate used, including audience and lifetime
Policy	Decision point, enforcement point and policy version
Expiry and revocation	Natural expiry, emergency stop, propagation target and evidence
Audit link	Identity, decision, approval, action, result and acceptance records
Affected-party and remedy link	Notice, contest or appeal route, incident duty and the organisation responsible for correction, restoration or other remedy

Apply three gates

1. Issue: refuse the grant when the principal, sponsor, purpose, resource or expiry is missing.
2. Exercise: evaluate current context at the point of action and reject a changed or unbound request.
3. Revoke: disable the grant, invalidate or contain every derived path, and run a denied-action test.

The record needs to support machine policy evaluation and accountable human review. Natural-language instructions can accompany it; structured fields still decide access.

What the market has not resolved

Agent identity remains easier to create than delegated authority is to express. Enterprise products can inventory agents, assign sponsors and issue workload credentials. Existing policy engines can constrain access. The market still lacks a portable way to carry a principal's purpose and limits across several independently operated services.

This creates room for identity incumbents, policy infrastructure and new agent-specific control products. Our view is that agent identity will become a feature of existing identity platforms, while cross-platform authority, revocation and accountability develop as a separate integration problem.

Where we see the market going

Agent identity will become a distinct workload category inside existing identity systems, not a replacement for them. Cloud and SaaS platforms will issue more agent-specific identities and credentials, while enterprise policy systems retain the principal, purpose, budget and revocation decision.

The hard interoperability problem is authority, not authentication. Portable identifiers will spread faster than portable mandates; the winners will preserve narrowing authority and effective revocation across agent, tool and organisational boundaries.

Three questions remain open:

1. Will agent-specific identities become portable standards or remain control-plane objects inside large cloud and SaaS platforms?
2. Can authority narrow consistently through a chain of independently operated agents and tools without flattening principal, actor and purpose?
3. Which revocation designs can stop both new and in-flight effects across organisational boundaries within a stated time?

The chapter's conclusion would change if deployments showed that ordinary workload identities and existing policy systems consistently preserve the full principal-to-action chain without agent-specific objects. It would also change if a portable authority standard achieved observed cross-provider enforcement and revocation.

About the author and editorial record

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking or proof that every listed product has been independently tested.

Previous: agent-to-agent coordination · Next: evaluation, observability and security.