From Service Accounts to Agent Identities: Governing AI Access at Enterprise Scale

Five key takeaways

1. Every production agent needs its own identity. Shared service accounts and borrowed user credentials destroy attribution, weaken revocation and create excessive privilege.

2. Agent identity and human delegation are separate facts. A secure transaction should establish both which agent acted and on whose authority it acted.

3. Authentication is not authorisation. Proving an agent’s identity does not prove that the requested action is appropriate for the current task, user, data and risk context.

4. Permissions should be issued just in time and constrained to a specific purpose. Short-lived, audience-restricted and sender-constrained tokens are safer than long-lived credentials.

5. Human accountability cannot be delegated to software. The audit trail must identify the initiating user, approver, agent, policy decision, tool call, affected resource and accountable business owner.

Introduction

Enterprise AI is moving from assistants that answer questions to agents that perform work. An agent may search records, update applications, create purchase orders, reconcile transactions, communicate with suppliers or coordinate other agents.

That ability creates a new category of identity problem.

Traditional identity and access management, or IAM, has generally distinguished between human users and software workloads. AI agents sit between those categories. They are software workloads, but they may interpret goals, select tools, plan intermediate steps and act under authority delegated by a person or business process.

An agent therefore needs at least two identity dimensions:

• Its own identity as a software actor
• The authority under which it is acting

Treating the agent as merely another application client is sometimes technically possible, but usually insufficient. Treating it as the human user is worse. It conceals the agent’s involvement precisely when the organisation needs to reconstruct what happened.

This concern is not hypothetical. The OWASP Top 10 for Agentic Applications 2026 identifies risks including identity and privilege abuse, tool misuse, insecure inter-agent communication, cascading failures and rogue-agent behaviour.

Meanwhile, zero-trust guidance has already moved enterprise security away from trust based on network location and toward continuous decisions based on user, workload, resource and environmental identity. NIST SP 800-207A specifically calls for application and service identities alongside user identities in cloud-native systems.

AI agents make that principle unavoidable.

Business context and problem definition

From information access to delegated action

A chatbot that retrieves a policy document poses a manageable information-access problem. An agent that modifies an employee record, orders equipment or releases a payment creates a transaction-authorisation problem.

The enterprise must answer questions such as:

• Which agent performed the action?
• Which user, role or process delegated the authority?
• Was the user entitled to delegate that authority?
• Was the agent permitted to use that tool?
• Was the action consistent with the assigned task?
• Did the transaction exceed a financial or risk threshold?
• Was human approval required?
• Which policy version authorised the action?
• Can the authority be revoked before the next tool call?
• Which human remains accountable for the outcome?

A conventional service account rarely answers these questions. It normally establishes only that a process possessed a password, certificate or API key. When twenty agents share that account, the audit trail records twenty autonomous actors as one apparently industrious piece of software.

Why shared service accounts fail

Shared service accounts introduce several architectural defects:

Shared accounts may be tolerated temporarily for a low-risk proof of concept, but they should not become the production identity model.

Why borrowed user credentials are worse

Allowing an agent to reuse a user session, password, browser cookie or broadly scoped bearer token creates impersonation rather than transparent delegation.

OAuth token exchange formally distinguishes the two concepts. With impersonation, the actor effectively becomes the subject within the authorised context. With delegation, the actor retains its own identity while acting on behalf of another principal. RFC 8693 also defines an act claim that can identify the delegated actor.

For enterprise agents, delegation should normally be preferred because it preserves both identities:

Agent A performed action X on behalf of user B under policy P for task T.

That is far more useful than:

User B apparently performed action X, although user B may have been eating lunch while an agent reorganised the procurement system.

Core concepts and terminology

Human identity

The verified identity of an employee, contractor, customer, supplier or citizen. Human authentication may involve federation, multifactor authentication and assurance levels such as those described by NIST SP 800-63-4, which became final in July 2025.

Workload identity

A cryptographically verifiable identity assigned to software executing in a particular environment. It may represent a container, virtual machine, serverless function or process.

SPIFFE provides a mature, vendor-neutral model for workload identity using short-lived X.509 or JWT-based SPIFFE Verifiable Identity Documents, known as SVIDs. Identities can be issued through workload attestation rather than embedded secrets.

Agent identity

A dedicated identity representing the logical AI agent.

The agent identity should be linked to, but not necessarily identical to, its runtime workload identity. One logical agent might run across several ephemeral workloads. Conversely, one orchestration runtime might host multiple separately governed agents.

Useful agent identity attributes include:

• Agent identifier and version
• Business owner and technical owner
• Approved purpose
• Risk classification
• Permitted tools and data domains
• Deployment environment
• Model and orchestration configuration
• Maximum autonomy level
• Required approval thresholds
• Expiry and review dates

Delegation

A principal grants limited authority to another actor while both identities remain visible. Delegation may originate from a user, business role, workflow, scheduled mandate or another agent.

Impersonation

One principal acts as another principal within a defined context. Because downstream systems may see only the impersonated identity, impersonation should be restricted to legacy integrations that cannot understand delegation and surrounded by compensating audit controls.

Authentication and authorisation

Authentication establishes who or what is making a request.

Authorisation determines whether that actor may perform a particular action on a particular resource under the current conditions.

An authenticated payroll agent is not automatically authorised to change every employee’s bank account. Authentication is the badge; authorisation is the locked door, the access schedule and the increasingly suspicious security guard.

Consent

Consent records a user’s approval for an agent to exercise defined permissions. Consent should describe meaningful business actions rather than vague technical scopes.

“Allow access to ERP” is poor consent.

“Allow the procurement agent to create draft purchase requisitions up to $5,000 for cost centre 410, excluding new suppliers, for the next eight hours” is considerably better.

OAuth Rich Authorization Requests, RFC 9396, supports structured authorization_details for expressing fine-grained rights beyond simple scope strings.

Token exchange

A security token service exchanges one credential for another credential targeted to a specific downstream resource. In an agent workflow, token exchange can combine:

• The user’s delegated authority
• The agent’s identity
• The target tool or API
• The approved scopes or transaction details
• The permitted delegation depth
• The token lifetime

Short-lived and sender-constrained credentials

Short-lived credentials reduce the time available to abuse a stolen token. Sender-constrained tokens go further by requiring the caller to prove possession of a cryptographic key.

RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, recommends sender-constraining access tokens where appropriate, using mechanisms such as mutual TLS or Demonstrating Proof of Possession, known as DPoP.

Secrets management

A secrets vault stores credentials, keys and refresh tokens and releases them only to authorised workloads. Agents should never receive raw long-lived secrets in prompts, memory, configuration files or tool responses.

Where possible, replace secrets with workload federation and ephemeral credentials. A vault remains necessary for legacy API keys and third-party refresh tokens, but it should mediate their use rather than casually handing them to the agent runtime like a receptionist distributing master keys.

Architecture principles

A defensible agent IAM architecture should apply the following principles.

Give every agent a unique, lifecycle-managed identity

The identity should have an owner, sponsor, purpose, status, environment, risk rating and review schedule. It should be disabled automatically when the agent is retired or its sponsor leaves.

Separate agent identity from runtime identity

The runtime identity proves where the agent is executing. The agent identity proves which governed agent is operating. Policies should normally evaluate both.

Preserve delegation rather than hiding it

Downstream services should be able to distinguish the subject, actor and delegating chain. Avoid flattening the chain into a borrowed user credential.

Authorise each consequential action

Do not authorise the entire conversation or workflow with one broad initial decision. Re-evaluate access before sensitive tool calls and transactions.

Bind authority to purpose

A token issued to read supplier records should not authorise supplier creation. A token issued for one purchase request should not become a general procurement credential.

Use least privilege and separation of duties

NIST SP 800-53 identifies least privilege and separation of duties as core access-control practices. An agent that proposes a payment should not also approve and release it unless the organisation has explicitly accepted that concentration of power.

Prefer ephemeral, audience-restricted credentials

Tokens should be valid only for the intended API, action and time window. Avoid reusable bearer tokens spanning unrelated tools.

Deny safely

If policy information, user context, agent status, data classification or approval evidence is unavailable, the system should fail closed for consequential actions.

Make every decision reconstructable

The organisation should be able to reproduce the identity context, policy decision, approval, credential issuance and tool response associated with an action.

Detailed reference architecture

Textual reference architecture

The reference architecture contains the following layers:

1. Users and channels: Employees, customers, operators, APIs, portals, collaboration tools and scheduled business processes.
2. Business applications and processes: HR, procurement, finance, CRM, service management, manufacturing and custom workflows.
3. Agent and orchestration layer: Agent runtime, planner, task manager, memory, model gateway and multi-agent coordinator.
4. Identity and access services: Human identity provider, agent identity registry, workload identity service, token service and consent records.
5. Policy and control layer: Policy decision point, policy enforcement points, approval service, risk engine and data-classification service.
6. Tool and integration layer: Tool gateway, API gateway, event broker, workflow engine and protocol adapters.
7. Data and knowledge services: Operational databases, document repositories, vector indexes, master data and metadata catalogues.
8. Security and observability: Secrets vault, security monitoring, distributed tracing, tamper-evident audit ledger and incident response.
9. Infrastructure: Cloud platforms, on-premises infrastructure, containers, serverless runtimes and trusted execution environments.
10. External services: SaaS applications, supplier platforms, banks, government services and partner APIs.
11. Governance and operations: Business owners, IAM team, security operations, AI governance, privacy, risk, internal audit and platform engineering.

The critical design point is that the agent does not connect directly to arbitrary tools using whatever credential happens to be available. Requests pass through enforcement and gateway controls that establish identity, obtain a narrowly scoped credential, apply policy and create a durable audit record.

Explanation of the architecture components

Identity provider

The identity provider authenticates human users and issues assertions containing relevant identity and session context. Higher-risk actions may require step-up authentication.

The human identity should not become the agent’s identity. It becomes one input into the delegation decision.

Agent identity registry

The registry is the authoritative inventory of agents. It should record ownership, purpose, deployment, capabilities, risk, approved tools, data domains and lifecycle state.

The registry should also support emergency disablement, periodic certification and linkage to source code, models, prompts, evaluations and architecture decisions.

Workload identity service

The workload identity service attests the executing runtime and issues short-lived cryptographic credentials.

SPIFFE and cloud-native workload federation are mature implementation approaches. The IETF Workload Identity in Multi-System Environments working group is developing additional architecture and credential specifications, but its 2026 documents remain Internet-Drafts and should be treated as emerging rather than final standards.

Security token service

The token service validates the human delegation, agent identity, runtime identity and requested target. It then issues a short-lived token for the specific tool.

The token should carry or reference:

• Human subject
• Agent actor
• Runtime or client identity
• Audience
• Approved actions
• Task or transaction identifier
• Delegation depth
• Authentication context
• Expiry
• Policy and consent references

Policy decision point

The policy decision point, or PDP, evaluates whether the action should be allowed, denied or escalated.

OpenID AuthZEN Authorization API 1.0 became a final specification in January 2026. It standardises communication between policy enforcement points and policy decision points without prescribing the internal policy language or engine.

Policy enforcement point

A policy enforcement point, or PEP, intercepts the requested action and enforces the PDP’s decision. PEPs may exist in the agent runtime, tool gateway, API gateway and individual high-value applications.

Defence in depth matters. An agent-side check alone can be bypassed by a compromised runtime.

Secrets vault

The vault stores third-party refresh tokens, API keys and signing keys. Access should be tied to the workload identity and mediated by policy.

The preferred pattern is for the gateway or token service to use the secret without exposing it to the model or agent memory.

Tool gateway

The tool gateway provides a controlled boundary between agents and enterprise capabilities. It can:

• Maintain an approved tool catalogue
• Validate input and output schemas
• Enforce rate and transaction limits
• Remove dangerous or unnecessary parameters
• Inject identity and audit metadata
• Obtain downstream credentials
• Prevent direct network access to unapproved services
• Apply content, data-loss and prompt-injection controls

The gateway should be protocol-neutral. REST, events, gRPC, database procedures, browser automation and emerging agent protocols can all be governed through the same architectural boundary.

Approval service

The approval service supports human-in-the-loop decisions for high-risk actions. Approval must bind to the actual transaction details, not merely to a vague workflow stage.

Approving “a supplier payment” should not silently approve a different amount, bank account or supplier substituted after approval.

Audit ledger

The audit ledger records identity, delegation, policy and transaction evidence. It should be append-only or tamper-evident, retained according to legal and business obligations, and linked to operational traces.

A blockchain is not inherently required. Most enterprises need controlled immutability, cryptographic integrity, time synchronisation, restricted administration and independent retention. Adding distributed consensus to an internal audit log merely because the word “ledger” appeared in a diagram would be an expensive act of theatre.

End-to-end delegation and transaction flow

The user first authenticates normally. The agent then requests an action as itself, carrying the user’s delegated context. The PDP assesses the request. If the action exceeds a threshold, an approval service obtains explicit human approval.

Only after policy approval does the token service issue a short-lived credential targeted to the required application. The gateway validates the request and records the outcome.

This keeps planning separate from execution. The model may propose an action, but deterministic security components decide whether the action is permitted.

Constraining permissions by context

Agent authorisation should evaluate more than roles and scopes.

The policy engine should return obligations as well as a decision. Obligations might require masking fields, recording additional evidence, limiting output, obtaining approval or forcing a particular secure execution environment.

RBAC, ABAC, policy-based and capability-based security

No single authorisation model is sufficient for every agentic workflow.

NIST defines ABAC as evaluating attributes of the subject, object, requested operation and environment against policy.

For most enterprises, the practical answer is a hybrid:

1. RBAC establishes the outer entitlement boundary.
2. ABAC applies contextual constraints.
3. Policy-based control centralises decisions and obligations.
4. Capability-like tokens convey narrowly scoped, time-limited authority to a tool or sub-agent.

OAuth Rich Authorization Requests can represent structured rights, while token exchange can issue credentials for a particular target and delegation chain.

Nested delegation and multi-agent chains

An orchestration agent may delegate part of a task to a specialist agent, which may call another service. Each hop expands the opportunity for privilege escalation or loss of accountability.

A nested delegation chain should therefore carry:

• The original human or process principal
• Every intermediate agent identity
• The current acting agent
• The original purpose
• The remaining permitted actions
• Delegation depth and expiry
• Prohibition against privilege amplification
• A common task and trace identifier

Each delegation must produce equal or narrower authority. A sub-agent must never gain permissions that the parent agent did not possess.

For example:

Human requester
  → Procurement coordinator agent
    → Supplier analysis agent
      → Sanctions-screening service

The supplier analysis agent may receive permission to read supplier data, but not the procurement coordinator’s permission to create a purchase order. The sanctions service may receive only the supplier identifiers required for screening.

Delegation depth

Policies should define a maximum depth. High-risk financial or administrative actions may permit no agent-to-agent redelegation at all.

Chain validation

Every receiving service should validate the chain or rely on a trusted token service that has done so. A string in a prompt claiming “the CFO approved this” is not delegation evidence. It is text, a medium famously vulnerable to both error and confident nonsense.

Revocation and continuous access evaluation

Short token lifetimes reduce exposure but do not provide immediate revocation. Enterprises need several complementary mechanisms:

• Disable the agent identity
• Revoke refresh tokens and grants
• Revoke user consent
• Terminate active sessions
• Invalidate workload credentials
• Change policy centrally
• Block the tool at the gateway
• Publish risk or account-status events
• Quarantine affected runtimes

OAuth Token Revocation, RFC 7009, provides client-initiated revocation, while token introspection allows protected resources to query token state.

The OpenID Shared Signals Framework and Continuous Access Evaluation Profile became final specifications in September 2025. They support real-time communication of identity and session changes across systems, providing a foundation for faster revocation and continuous evaluation.

For critical actions, the gateway should evaluate current policy and risk even when the presented token remains cryptographically valid.

Non-repudiation and human accountability

What non-repudiation should mean here

Non-repudiation is not achieved simply by writing the agent’s output to a log. It requires evidence that can credibly establish:

• Which identities participated
• Which credentials were used
• Which policy decision was made
• Which transaction was approved
• What data was submitted
• What system accepted the action
• Whether the record has been altered
• Which human or organisational role held decision authority

Digital signatures, trusted timestamps, immutable storage, protected signing keys and independently controlled audit retention strengthen this evidence.

Determining the accountable human

The agent itself is not the accountable organisational actor. Accountability should be resolved using the operating mandate.

These responsibilities coexist. Assigning the user as accountable does not remove the platform owner’s responsibility for defective controls, nor does assigning a business sponsor excuse an approver who authorised a specific transaction.

NIST AI RMF calls for documented accountability structures, clear roles, executive responsibility and differentiated human-AI oversight responsibilities.

The audit record should therefore capture an accountability tuple:

Business owner
+ initiating principal
+ approving principal
+ agent identity
+ runtime identity
+ task and purpose
+ policy decision
+ affected resource
+ transaction result

Security, privacy and governance considerations

Prompt injection and goal manipulation

An agent may interpret untrusted content as instructions. IAM cannot prevent every prompt-injection attack, but it can limit the resulting damage by ensuring that content alone cannot grant authority.

Tool execution must remain behind deterministic policy checks.

Excessive agency

An agent with broad permissions, unrestricted tools and persistent credentials can turn a minor reasoning error into a major operational event. Limit autonomy by action type, data sensitivity and transaction impact.

Data minimisation

Pass only the data required by the receiving tool or sub-agent. Avoid copying entire documents or customer records into agent memory merely because storage is inexpensive and future investigations apparently need additional misery.

Segregation of agent memory

Memory must be partitioned by tenant, user, task and classification. Authorisation to use a tool does not automatically authorise the agent to retrieve every historical memory entry.

Human oversight

High-risk actions need effective intervention, override and stop mechanisms. The EU AI Act includes requirements for human oversight and logging for relevant high-risk systems, while its wider application timetable reaches a significant milestone on 2 August 2026. Applicability depends on the use case and legal classification, not on whether a vendor labels the product an “agent.”

Governance management system

ISO/IEC 42001:2023 establishes requirements for an AI management system covering risk, accountability, transparency and continual improvement. Agent identity controls should be integrated into that governance system rather than operated as an isolated security project.

Architecture options and trade-offs

The recommended enterprise pattern is dedicated agent identity combined with workload identity, token exchange, policy enforcement and gateway-mediated tool access.

Not every use case needs the most elaborate implementation. A knowledge-search agent with read-only access to public documents can use a simpler model than a financial operations agent. Architecture should follow impact, not fashion.

Build versus buy

As of July 2026, vendor agent-identity capabilities are becoming more mature but remain uneven.

Microsoft lists the core Entra Agent ID platform as generally available from April 2026, although some related experiences and integrations remain in preview. AWS made Amazon Bedrock AgentCore generally available in October 2025 and added on-behalf-of token exchange in June 2026. Google Cloud documentation now describes agent identities tied to an agent’s lifecycle as distinct from conventional service accounts.

These are useful implementation options, not substitutes for vendor-neutral identity and policy principles.

Enterprise use cases

HR agent

Business objective: Reduce administrative effort for employee onboarding and routine HR enquiries.

Architecture: The HR agent receives a dedicated identity and can read policy documents and create draft onboarding tasks. Employee-record access is limited by the requesting manager’s organisational scope. Changes to salary, bank details, employment status or sensitive health information require specialised tools and additional approval.

Governance: HR owns the business mandate; IAM manages entitlements; privacy defines data-minimisation requirements; security monitors unusual record access. The agent may propose changes but cannot approve its own changes.

Expected result: Faster onboarding and consistent responses without granting the agent unrestricted HR administrator access.

Procurement agent

Business objective: Prepare purchase requisitions, compare approved suppliers and obtain quotations.

Architecture: RBAC permits procurement functions, while ABAC restricts business unit, category and cost centre. Transaction-bound authorisation limits each token to a named requisition. Purchases above $5,000 require an approver. New suppliers, bank-account changes and sanctioned-country indicators require specialist workflows.

Governance: The procurement process owner sponsors the agent. Finance defines value thresholds. Supplier-risk and legal teams define due-diligence controls. The requesting manager remains accountable for the business need; the approver remains accountable for the expenditure decision.

Expected result: Reduced cycle time with maintained purchasing controls and traceable delegation.

Financial operations agent

Business objective: Reconcile invoices and prepare payments.

Architecture: The agent can read invoices, purchase orders and receipt data, then propose matches. A separate payment agent can create a draft payment batch. Neither agent can release funds. A human approver uses step-up authentication, and the approval is cryptographically bound to the payee, account, amount and batch.

Governance: Separation of duties is enforced technically. Treasury owns payment authority; finance owns reconciliation rules; security monitors abnormal values and destinations; internal audit reviews the full delegation and approval evidence.

Expected result: Higher straight-through processing for low-risk matches while preserving human control over fund release.

Organisational roles and responsibilities

No agent should enter production without a named business owner and a named technical owner.

Phased implementation roadmap

Warning signs that the organisation is not ready

• Agents are not centrally inventoried.
• Business owners cannot explain what authority an agent has.
• Tools are exposed directly to models.
• Shared service accounts remain the default.
• There is no reliable data classification.
• Approval processes cannot bind approval to transaction details.
• Logs cannot correlate a user, agent, policy decision and tool call.
• Security teams cannot disable an agent rapidly.
• The organisation lacks an incident response process for autonomous actions.

Suggested architecture artefacts

Architects should produce and maintain:

• Agent context and scope diagram
• Identity and trust-boundary model
• Delegation and token-flow sequence
• Tool and data-access matrix
• Policy decision model
• Agent threat model
• Data-classification mapping
• Approval and separation-of-duties design
• Audit and evidence model
• Credential lifecycle design
• Failure-mode and emergency-stop design
• Responsibility assignment matrix
• Architecture decision records
• Operational readiness checklist

Relevant non-functional requirements

Success measures and operational metrics

Metrics should be segmented by risk tier. Averaging a harmless document-search agent with a payment agent produces the kind of reassuring dashboard that executives enjoy until someone asks a meaningful question.

Procurement and vendor evaluation considerations

Evaluate potential platforms against:

• Dedicated agent identity support
• Separation of logical agent and runtime identities
• Workload federation and attestation
• Delegated and on-behalf-of access
• Standards-based token exchange
• Sender-constrained token support
• Fine-grained authorisation and external PDP integration
• Tool-gateway enforcement
• Consent and approval workflows
• Agent and credential lifecycle management
• Nested-delegation representation
• Real-time revocation and risk events
• Tamper-evident audit evidence
• Cross-cloud and third-party integration
• Data residency and key management
• Exportability of logs, policies and identity records
• Availability, latency and recovery commitments
• Independent assurance and regulatory evidence
• Feature maturity: generally available, preview or roadmap

A product demonstration is not evidence that a control works under failure, compromise or multi-agent delegation. Require architecture documentation, API specifications, security testing evidence and operational procedures.

Common mistakes and anti-patterns

Treating an agent as a normal service account

An agent may act under different users, tasks and risk contexts. A static service account cannot express those distinctions.

Giving the model direct access to credentials

Credentials should be handled by trusted runtime components, token services or gateways, not placed in prompts or model-visible memory.

Authorising at login and never again

A user’s authentication at 9:00 a.m. does not authorise every action an agent invents at 4:55 p.m.

Using broad scopes as the complete policy model

Scopes such as finance.write or hr.admin are too coarse for transaction-level controls.

Logging only prompts and responses

Prompt logs do not prove identity, policy, consent, credential issuance or downstream execution.

Allowing privilege amplification through sub-agents

Each delegation hop must narrow or preserve authority, never expand it.

Approving a plan rather than the transaction

Approval must be bound to the final resource, value and action. Material changes should invalidate the approval.

Confusing visibility with control

An agent registry provides inventory. It does not enforce runtime permissions unless connected to the policy, token and gateway layers.

Architecture decision checklist

An Architecture Review Board should ask:

1. Does every production agent have a unique identity, sponsor and owner?
2. Can the organisation distinguish the agent, runtime and delegating human?
3. Is delegation preserved across every system and sub-agent hop?
4. Can any component impersonate a user, and is that genuinely necessary?
5. How are tools discovered, approved and restricted?
6. Are permissions constrained by task, data, transaction value, time and risk?
7. Are credentials short-lived, audience-restricted and sender-constrained?
8. Can a compromised agent be revoked immediately?
9. What happens when the PDP, gateway, vault or identity provider is unavailable?
10. Which actions require step-up authentication or independent approval?
11. How is separation of duties enforced?
12. Can the organisation reconstruct and prove each consequential action?
13. Which human or business role is accountable in every operating mode?
14. Are agent-specific controls generally available, or dependent on preview features?
15. Can identities, policies and logs be migrated if the agent platform changes?

Conclusion

AI agents should not be governed as anonymous automation, shared applications or invisible extensions of human users. They are distinct non-human actors operating within delegated authority.

A secure enterprise architecture therefore needs to establish three facts for every consequential action:

1. Who requested or authorised the work
2. Which agent and workload performed it
3. Why the specific action was permitted

The strongest pattern combines dedicated agent identities, workload attestation, explicit delegation, token exchange, short-lived credentials, runtime policy decisions, controlled tool gateways, transaction-bound approvals and tamper-evident audit records.

RBAC remains useful for baseline entitlements, but agentic systems require contextual ABAC, central policy evaluation and narrowly scoped capabilities. Multi-agent chains must preserve the original principal and prevent privilege amplification. Revocation must operate continuously rather than waiting for credentials to expire.

Most importantly, accountability must remain human and organisational. An agent may execute an action, but a named person or role must own its mandate, approve its authority and answer for its operation.

The non-human workforce should be fast, scalable and useful. It should not be anonymous.

Frequently asked questions

Does every AI agent need a separate identity?

Every production agent with distinct ownership, purpose, permissions or lifecycle should have a separate logical identity. Ephemeral runtime instances can use separate workload credentials linked to that logical agent.

Can an agent use the user’s OAuth token?

It may use delegated authority derived from the user’s session, but it should normally exchange that authority for a new, narrowly scoped token identifying the agent as the actor. Passing the original user token through multiple systems weakens attribution and audience restriction.

Is a managed identity enough?

A managed workload identity is an important foundation, but it may identify only the runtime. Enterprises also need the logical agent identity, delegated human context, task purpose and runtime authorisation.

Should agents ever impersonate users?

Only when a legacy target cannot process delegation and the business need justifies the reduced transparency. Impersonation should be narrowly scoped, short-lived and accompanied by independent records identifying the real agent.

How long should agent credentials remain valid?

As briefly as operationally practical. High-risk, one-time actions may use credentials valid for minutes or a single transaction. Renewal should require fresh policy evaluation.

Can a policy engine stop prompt injection?

It cannot prevent every injection or reasoning failure. It can prevent untrusted content from becoming authority by enforcing deterministic rules before tools and data are accessed.

Who is accountable when one agent delegates to another?

The original business mandate and human accountability remain in force. The audit trail must also identify each intermediate agent. The receiving agent is operationally responsible for its execution, but software does not replace the accountable human or organisational role.

Is capability-based security better than ABAC?

They solve different problems. ABAC is useful for evaluating context. Capabilities are useful for conveying specific, limited authority after a decision. Many high-assurance architectures should use both.

Do we need a blockchain audit ledger?

Usually not. A protected append-only log with cryptographic integrity, controlled access, reliable timestamps and independent retention is normally sufficient.

Are agent identity standards mature?

Workload identity, OAuth, token exchange and proof-of-possession mechanisms are mature. AuthZEN and Shared Signals now have final specifications. Agent-specific identity products are becoming available, while cross-platform agent and workload identity conventions such as IETF WIMSE remain under development.

References

1. Zero Trust Architecture, National Institute of Standards and Technology, August 2020. https://csrc.nist.gov/pubs/sp/800/207/final

2. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, NIST SP 800-207A, September 2023. https://csrc.nist.gov/pubs/sp/800/207/a/final

3. Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Revision 5, September 2020, subsequently updated. https://csrc.nist.gov/pubs/sp/800/53/r5/final

4. Guide to Attribute Based Access Control Definition and Considerations, NIST SP 800-162, updated August 2019. https://csrc.nist.gov/pubs/sp/800/162/upd2/final

5. Digital Identity Guidelines, NIST SP 800-63-4, July 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final

6. Artificial Intelligence Risk Management Framework 1.0, National Institute of Standards and Technology, January 2023. https://airc.nist.gov/airmf-resources/

7. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024, updated April 2026. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

8. OAuth 2.0 Token Exchange, RFC 8693, Internet Engineering Task Force, January 2020. https://www.rfc-editor.org/rfc/rfc8693.html

9. OAuth 2.0 Rich Authorization Requests, RFC 9396, Internet Engineering Task Force, May 2023. https://www.rfc-editor.org/rfc/rfc9396.html

10. OAuth 2.0 Demonstrating Proof of Possession, RFC 9449, Internet Engineering Task Force, September 2023. https://www.rfc-editor.org/rfc/rfc9449.html

11. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, RFC 8705, Internet Engineering Task Force, February 2020. https://www.rfc-editor.org/rfc/rfc8705.html

12. Best Current Practice for OAuth 2.0 Security, RFC 9700 and BCP 240, Internet Engineering Task Force, January 2025. https://www.rfc-editor.org/rfc/rfc9700.html

13. OAuth 2.0 Token Revocation, RFC 7009, Internet Engineering Task Force, August 2013. https://www.rfc-editor.org/rfc/rfc7009.html

14. SPIFFE Overview and Specifications, SPIFFE and Cloud Native Computing Foundation, continuously maintained. https://spiffe.io/docs/latest/spiffe-about/overview/ https://spiffe.io/docs/latest/spiffe-specs/

15. Workload Identity in Multi-System Environments Working Group, Internet Engineering Task Force, chartered March 2024; specifications remain under development. https://datatracker.ietf.org/wg/wimse/

16. Authorization API 1.0 Final Specification, OpenID Foundation AuthZEN Working Group, approved January 2026. https://openid.net/wg/authzen/specifications/

17. Shared Signals Framework and Continuous Access Evaluation Profile Final Specifications, OpenID Foundation, approved September 2025. https://openid.net/three-shared-signals-final-specifications-approved/

18. ISO/IEC 42001:2023, Information Technology — Artificial Intelligence — Management System, International Organization for Standardization, December 2023. https://www.iso.org/standard/42001

19. OWASP Top 10 for Agentic Applications for 2026, OWASP GenAI Security Project, December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

20. Regulation (EU) 2024/1689, Artificial Intelligence Act, European Union, June 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/

21. AI Act Regulatory Framework and Application Timeline, European Commission, updated July 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

22. Microsoft Entra Releases and Announcements: Agent ID General Availability, Microsoft, April 2026. https://learn.microsoft.com/en-us/entra/fundamentals/whats-new

23. Amazon Bedrock AgentCore Generally Available, Amazon Web Services, October 2025. https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available/

24. Amazon Bedrock AgentCore Release Notes, Amazon Web Services, updated June 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html

25. Identities for Workloads, Google Cloud Documentation, updated July 2026. https://docs.cloud.google.com/iam/docs/workload-identities