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 authority stack · market map · revocation · Authority Record · Next: evaluation, observability and security

The delegated standing problem

An autonomous software agent holds no independent legal standing, maintains no balance-sheet capital, and cannot be prosecuted in a court of law.

Every operational action an agent initiates—reading a database, signing a contract, committing code, or transferring funds—is executed on borrowed standing. That authority is lent to the software by an identifiable human employee or corporate principal who carries the statutory, financial, and legal liability when things go wrong.

An API key or mTLS certificate confirms which software process established a network connection. It does not answer the foundational governance questions: Who authorized this workload to act? What spending limits apply? Under what policy rules was the decision approved? And does that authority still hold at the exact moment the action commits?

In production architectures, commercial risk is determined by whether an enterprise maintains an unbroken chain linking the sponsoring principal to an active agent workload, a bounded policy evaluation, a cryptographic credential, and an auditable system receipt.

The operational benchmark of control is revocation. An organization does not control the authority it granted unless it can immediately extinguish an agent's effective ability to act across cached bearer tokens, active worker sessions, downstream cloud tools, and delegated third-party sub-agents.

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.

Agent identity as an enterprise product layer

Identity and access management (IAM) providers are extending traditional employee and machine directories to accommodate autonomous software actors. Microsoft is embedding agent identities, blueprints, and mandatory business sponsorship models directly into Entra ID. AWS and Auth0 are documenting delegated token exchange vaults for agent workloads. Policy vendors are adapting declarative authorization engines to evaluate non-deterministic machine actions in real time.

Microsoft’s enterprise architecture guidance establishes this trajectory: “Every agent should receive an Agent ID” (Microsoft, "How to Build Agents with Microsoft"). Hyperscalers are pulling software agents into the same governance directories, compliance boundaries, and access policies that enterprises have used for decades to govern employees and service accounts.

Managing autonomous agents requires separating technical authentication from delegated authority:

• An Agent Inventory registers software instances within an enterprise directory.
• A Business Sponsor designates the corporate executive who carries financial and operational accountability for the agent's actions.
• A Delegation Mandate defines what external resources the agent may access and establishes spending limits.
• A Revocation Pipeline ensures access can be terminated instantly across all downstream systems.

Cross-organizational authority federation—allowing an agent from Company A to transact autonomously against systems at Company B under verified enterprise mandates—remains one of the most significant open integration challenges in enterprise software.

The seven layers of enterprise authority

A complete authority architecture requires seven distinct components:

principal
  -> agent application identity
  -> workload instance session
  -> delegation mandate
  -> cryptographic credential
  -> policy decision point
  -> enforcement point and audit record

1. The Principal: The identifiable human individual or corporate entity whose balance sheet, legal standing, and contractual obligations sit behind the action.
2. The Agent Application: The specific software package, prompt configuration, and versioned codebase attempting the task.
3. The Workload Instance: The ephemeral compute process, container ID, or session token connecting across the network.
4. The Delegation Mandate: The explicit corporate record establishing the principal's intent, task scope, budget limits, and expiration rules.
5. The Access Credential: The technical proof (OAuth token, mTLS certificate, signed JWT) presented to authenticate the connection.
6. The Policy Decision: The real-time evaluation of principal, actor, resource, requested action, and environmental risk context against enterprise rules.
7. Enforcement and Evidence: The gateway, database, or API that permits or blocks the action and writes an immutable audit record to disk.

A standard OAuth bearer token proves that the caller holds a valid key; it does not tell the receiving system whether the underlying business task was authorized, what spend limits apply, or whether the user's consent was revoked two seconds ago. Autonomous execution requires policy enforcement at the exact point of action.

Authentication versus authorization

Authentication verifies identity assertion: Which machine or user account presented this credential? Authorization evaluates permission: Is this authenticated identity permitted to execute this specific write action on this database record right now?

In human workflows, authorization boundaries are relatively static: an employee is assigned a role (e.g., Accounts Payable Clerk) that persists for months. In autonomous workflows, authority is highly dynamic: an agent may select external tools at runtime, spawn sub-agents across third-party clouds, and initiate financial commitments while human supervisors are offline. Static, coarse-grained role-based access control (RBAC) cannot safely govern dynamic software agency.

The National Institute of Standards and Technology (NIST) highlights this architectural challenge, emphasizing that software-agent identity, continuous authorization, and immutable auditability represent an active standards boundary (NIST, "New Concept Paper on Identity and Authority of Software Agents").

Existing identity standards as architectural foundations

Enterprise agent governance builds directly upon established web and security standards:

Security standard	Supplied capability	Missing governance capability
OpenID Connect (OIDC)	Standardized authentication and identity assertion profiles	Task-specific spending limits and multi-hop delegation rules
OAuth 2.0	Scoped access tokens and delegated authorization flows	Semantic understanding of task intent, acceptance tests, or prompt safety
OAuth Token Exchange (RFC 8693)	Exchanging security tokens while preserving subject and actor identities	Universal policy rules determining whether a specific exchange is permissible
SPIFFE / SPIRE	Cryptographic workload attestation and mutual TLS across distributed compute	Human delegation tracking, corporate sponsorship, or application-level policy
OpenID AuthZEN 1.0	Standardized JSON API connecting Policy Enforcement Points to Policy Decision Points	Business policy definitions or verification that target APIs correctly enforce decisions
Open Policy Agent (OPA) / Rego	Declarative policy-as-code evaluation engine for cloud-native infrastructure	Credential issuance, key vaulting, or user consent lifecycles

RFC 8693 defines OAuth 2.0 Token Exchange, providing the critical technical primitive needed for multi-agent delegation: distinguishing between the original subject (the corporate principal) and the intermediate actor (the software agent acting on their behalf). However, production systems must preserve this lineage across every downstream API hop rather than flattening the chain into a single service account.

The SPIFFE Workload API provides stable, cryptographic identity to running containers, while SPIFFE Federation allows trust domains to verify identities across different cloud providers. SPIFFE confirms which container process executed the call; it does not confirm which human employee authorized the business transaction.

The OpenID Foundation approved the AuthZEN Authorization API 1.0 as a final specification in January 2026, standardizing how applications query external Policy Decision Points (PDPs). Open Policy Agent provides an open-source policy-as-code engine (OPA documentation). Both standards separate business policy logic from operational application code.

Who supplies identity, authority and policy infrastructure

The vendor ecosystem spans enterprise IAM providers, cloud hyperscalers, open-source policy engines, and specialized credential vaults:

Organization or platform	Target buyer	Documented capability	Commercial model	Current operational boundary
Microsoft Entra Agent ID	Enterprise IT and IAM security teams	Dedicated agent identities, blueprints, directory inventories, lifecycle management, and business sponsorship controls	Enterprise identity licensing (Entra P1/P2) and Microsoft 365 plans	Current documentation establishes agent identity governance within Azure and Microsoft 365 environments; cross-cloud federation remains emerging
Amazon Bedrock AgentCore Identity	AWS cloud architects and agent developers	Workload access tokens, OAuth credential vaults, user-delegated authentication, and machine-to-machine IAM roles	Managed AWS service consumption tied to AgentCore runtime	Documentation outlines token exchange flows; customers must independently configure least-privilege policies
Auth0 Token Vault	Application engineering teams	Centralized storage and automated refresh of third-party OAuth access tokens, calling APIs on user behalf	Tiered developer and enterprise platform subscriptions	Manages third-party SaaS token lifecycles; does not manage corporate budget mandates or task acceptance
SPIFFE / SPIRE	Infrastructure and platform security teams	Automated cryptographic workload attestation, SVID issuance, and multi-cloud trust federation	Open-source CNCF project; commercial support from enterprise vendors	Provides zero-trust workload identity; business delegation and user authorization sit in higher software layers
OpenID AuthZEN	Identity vendors and software architects	Standardized HTTP REST protocol connecting PEPs to centralized PDP authorization engines	Open industry standard implemented by commercial authorization products	Standardizes the request/response interface; does not determine the underlying corporate authorization rules
Open Policy Agent (OPA)	Platform, security, and DevOps engineers	High-performance declarative policy engine evaluating structured JSON inputs against Rego rules	Open-source CNCF graduated project; commercial SaaS control planes (Styra)	Evaluates context against rules; does not manage credential issuance or token revocation lifecycles
Payment Mandate Schemes	Fintechs, merchants, and card networks	Binds commercial spend transactions to specific merchants, dollar limits, and time windows (AP2, PayTo)	Transaction-based fees and scheme processing interchange	Specialised financial authority records; do not govern non-financial API tools or deliverable acceptance

Microsoft Entra Agent ID introduces an important organizational control: mandatory business sponsorship. Every agent blueprint requires a designated business owner alongside its technical creator (Microsoft, "Plan your agent identity architecture"; "Owners, sponsors, and managers"). This ensures that when an autonomous agent behaves unexpectedly, enterprise security teams can route alerts directly to the executive who holds budget accountability.

AWS AgentCore and Auth0 Token Vault represent an architectural pattern for securing API credentials: long-lived third-party secrets remain isolated inside a secure cloud vault, while ephemeral agent workloads receive only short-lived, scoped access tokens at runtime (AWS, "Supported authentication patterns").

Enforcing policy at the point of execution

System prompts and natural-language instructions provide guidance to a probabilistic model; they are not security enforcement controls. A prompt instructing an agent to "never transfer more than $500" is vulnerable to prompt injection, semantic jailbreaks, and hallucinations.

Consequential actions must be intercepted by deterministic policy enforcement points:

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 downstream resource (the database gateway, payment API, or ERP connector) must validate credentials independently. If an agent asserts that "the user approved this transaction," the receiving service must demand a verifiable, signed authorization digest before committing the change.

Human approvals must bind to canonical effects

Human-in-the-loop governance fails when approval requests are vague. Approving a request stating "allow agent to manage customer records" is too coarse to protect the enterprise. Similarly, approving a draft email is useless if the agent can alter the recipient address or file attachments prior to transmission.

Effective human approvals require binding to a canonical action digest:

• Explicit target resource (URL, database table, or recipient account).
• Specific operation (read, write, delete, fund transfer).
• Exact payload digest (cryptographic SHA-256 hash of proposed changes or message body).
• Defined financial value and currency.
• Strict expiration timestamp.

If an agent modifies any parameter between human review and network transmission, the authorization digest is invalidated, halting execution.

Context-aware authorization inputs

Role-based permissions are insufficient for autonomous workloads. Evaluating whether an agent action is permissible requires dynamic context:

• Sponsoring corporate tenant and client account identifier.
• Explicit business job ID and authorized scope of work.
• Data classification tags of accessed records (e.g., public, confidential, PII).
• Target external resource and requested write operation.
• Immediate transaction cost and cumulative historical spend on that task.
• Geographic network origin and hosting infrastructure domain.
• Sponsoring human user's presence (attended vs. unattended background run).
• Explicit sub-delegation permissions and current delegation depth.

A policy engine can evaluate these inputs only if the underlying orchestration harness captures and structures them reliably.

The mechanics of effective revocation

Revoking an agent's authority is substantially more complex than disabling a user account in an employee directory. Disabling an agent's top-level identity object often leaves active OAuth access tokens in cloud memory, valid refresh tokens in automated vaults, active headless browser containers, and delegated sub-agents running across external networks.

Effective revocation operates across an extended dependency graph:

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

Enterprise security requires two forms of revocation:

1. Prospective revocation: Halting the issuance of new credentials and blocking all subsequent task admissions within defined SLA targets.
2. In-flight revocation: Transmitting cancellation signals to active worker containers, terminating open database connections, revoking downstream tool tokens, and routing ambiguous intermediate actions to a reconciliation queue.

Revocation cannot reverse an external write operation that has already committed. If an agent transfers funds via an API before its credentials are wiped, the payment rail cannot undo the transaction. The runtime must log the committed effect, update the job record, and alert human operators to initiate commercial recovery.

Microsoft’s sponsor architecture allows business sponsors to disable or soft-delete agent identities directly, improving response time when business anomalies are detected without requiring full IT administrative escalation (Microsoft, "Owners, sponsors, and managers").

Evaluating identity and policy evidence

Enterprise security teams evaluate identity claims by testing enforcement boundaries directly:

Evidence source	What it establishes	Unresolved operational question
OIDC / OAuth standard	Token syntax, cryptographic signing, and grant exchange mechanics	Task-specific spending governance, data residency, or prompt security
Provider IAM documentation	Supported identity objects, directory features, and vault APIs	Production configuration correctness, least-privilege scoping, or multi-cloud portability
Authentication log	Proof that a specific credential was presented at an API gateway	Whether the underlying business transaction was authorized by a human principal
Policy decision log	Record of inputs, evaluated policy versions, and permit/deny verdicts	Verification that every downstream sub-agent enforced identical policy decisions
Human approval record	Documented sign-off by an authorized employee	Verification that the executed action matched the approved parameter digest
Revocation test result	Proof that designated credentials failed following an administrative disable	Guarantee that no untracked cached tokens or orphan processes survive
Job-level audit trail	Complete lineage linking principal, policy, execution, and acceptance	Portability of that authority architecture to unrelated business domains

Industry documentation confirms the rapid emergence of agent identity features, token vaults, and declarative policy engines. However, a universal cross-cloud authority standard does not exist. An Agent ID assigned inside a vendor's directory does not by itself satisfy external regulatory, privacy, or statutory compliance obligations.

The Agent Authority Record

Production systems require an explicit operational record governing each authority grant:

Record field	Operational governance requirement
Principal	The identifiable human individual or corporate entity carrying financial and legal liability
Actor	The specific agent software package, version identifier, and runtime workload instance
Business Sponsor	The designated corporate executive accountable for task purpose, ongoing lifecycle, and budget
Task Purpose	The explicit business job or deliverable class authorized for execution
Target Resource	Permitted cloud tenants, accounts, databases, and third-party API domains
Authorized Actions	Explicit allow-list of permitted read, write, execute, payment, and deletion operations
Operational Constraints	Maximum financial spend, transaction rate limits, data classification boundaries, and geography
Sub-delegation Rules	Whether downstream sub-agent delegation is permitted, and mandatory narrowing constraints
Human Approval Gates	Actions requiring human sign-off, authorized approver roles, and mandatory parameter digest binding
Credential Scoping	Cryptographic token type, target audience restriction, and hard session lifetime
Policy Enforcement	Designated Policy Decision Point (PDP), Policy Enforcement Point (PEP), and active policy version
Revocation Lifecycle	Natural expiration timestamp, emergency revocation endpoints, and propagation SLA targets
Audit Lineage	Cryptographic links to job IDs, policy decision logs, execution traces, and acceptance records
Remediation Path	Designated incident response contacts and procedures for notifying affected stakeholders of breaches

The three enforcement gates

1. Issuance gate: Reject authority grants missing an identifiable principal, business sponsor, bounded scope, or explicit expiration timestamp.
2. Execution gate: Evaluate context at the point of action; halt execution if parameter arguments deviate from approved policy digests.
3. Revocation gate: Upon administrative suspension, invalidate stored credentials, terminate active sessions, contain downstream sub-agents, and execute a negative access test confirming denied access.

The trajectory of agent identity and authority

Agent identity is integrating into existing enterprise IAM platforms (Entra, Okta, AWS IAM) as a distinct workload category rather than replacing them. Cloud providers will continue issuing agent-specific credentials, while centralized enterprise policy engines will govern spending mandates, data access, and instant revocation.

The primary architectural challenge is cross-organizational authority federation: passing an enterprise mandate from a buyer's agent to a supplier's agent across independent corporate networks while preserving policy boundaries. Standardized identity identifiers will spread quickly; portable commercial mandates and cross-cloud revocation pipelines will develop as a complex multi-vendor integration problem.

Authority governs what an agent is permitted to execute. It does not prove what the software actually did. Chapter 10 examines the observability and evaluation layer: pre-release testing, runtime execution tracing, containment of hostile inputs, and the immutable audit evidence required to confirm that a business job was completed and accepted.

Sources and method

• Primary sources: Technical specifications and architecture documentation from Microsoft (Entra Agent ID), AWS (Bedrock AgentCore), Auth0, SPIFFE/SPIRE, OpenID Foundation (AuthZEN 1.0, RFC 8693), and Open Policy Agent checked as of 13 September 2026.
• Analytical frameworks: The seven-part identity stack, the revocation dependency graph, and the Agent Authority Record are original analytical structures developed to evaluate delegated authority governance.
• Evidence boundaries: Provider documentation establishes declared feature sets, API parameters, and administrative controls. Production access control, token leakage containment, and revocation propagation speeds require empirical validation on customer infrastructure.
• Institutional references: Public concept papers from the National Institute of Standards and Technology (NIST) on software agent identity, authority, and auditability establish the governance context for delegated computing.
• Editorial record: Published by Agentic Economy, Perth, Western Australia. Updates and corrections are logged via the editorial record.

Back to the report hub · Next: evaluation, observability and security.