AI Agent IAM Reference Architecture: Identity and Access

Separate the seven control boundaries¶

A successful network connection proves reachability. Authentication verifies an identity. Authorization resolves what that identity may access. Runtime policy evaluates this action and context. Approval gives an eligible person a bounded decision. Execution creates the side effect. Evidence records the complete unit for review.

Keep each boundary explicit in the architecture and the event model. A valid credential can still lack authority for the requested purpose, amount, data, environment, or time. A successful policy evaluation can still require an independent reviewer. An approval can release only the exact request and context it covered.

System context and identity classes¶

Treat the agent identity as the durable business object and the workload identity as the running software instance. A service identity represents a non-human dependency or gateway. The tool or resource server authenticates the caller and enforces its own authorization. A reviewer uses a human identity with current decision authority.

Text alternative. A human user delegates a bounded purpose to an agent and workload. Identity and token services authenticate the parties. Authorization and policy evaluate the request. A reviewer decides held actions. The tool executes an allowed action. Every stage sends records to the evidence store inside the tenant and organization trust boundary.

Scroll horizontally to inspect the diagram.

Choose dedicated, delegated, or hybrid identity¶

A dedicated identity gives the agent its own enterprise-owned authority. A delegated identity carries one user’s current authority into the task. A hybrid records both parties: the agent remains the actor and the human remains the subject or sponsor. This separation supports accurate policy, revocation, and audit.

Shared service accounts weaken attribution and often carry wide standing access. Keep them behind a service-mediated gateway when a target system cannot issue narrow agent credentials. Record the originating agent, human subject, policy decision, and downstream receipt for every mediated call.

Request and delegated-authority sequence¶

Bind the human subject, agent actor, workload, delegation, purpose, target, and expiry before token issuance. Use an audience-bound short-lived credential for the target resource. Resolve current authority again at the action boundary because roles, assignments, risk facts, and policy can change during a session.

Text alternative. The user assigns a purpose to the agent. The agent starts an attested workload. The workload requests a token. The token service validates the actor and delegated subject, then issues a short-lived audience-bound credential. The workload sends the complete context to policy. The tool receives only an allowed or validly approved request and returns an execution receipt.

Scroll horizontally to inspect the diagram.

Own every entitlement dimension¶

Least privilege becomes testable when every dimension has an owner, decision point, review path, revocation path, and evidence field. Evaluate the complete tuple for each consequential request. A role can supply a baseline, while purpose, value, data, environment, and time keep the effective grant narrow.

Combine authorization patterns deliberately¶

Role-based access control supplies a stable job or service baseline. Attribute-based access control evaluates subject, resource, action, and environment facts. Relationship-based access control resolves graph relationships such as assignment, ownership, or case membership. Capability-based access carries a narrow transferable authority object that should remain target-bound, time-bound, and revocable.

Use the smallest combination that expresses the real decision. Record the resolved inputs and final effective grant so reviewers can reproduce the result after groups, attributes, relationships, or capability state changes.

Entitlement and approval decision flow¶

Evaluate identity, tenant, delegation, audience, and expiry before resolving entitlements. Invalid or missing authority stops the request. Runtime policy then selects allow, warn, require_approval, or block. A required approval holds the exact request and releases it only after an eligible independent reviewer decides before expiry.

Text alternative. The flow verifies identity and token context, then all nine entitlement dimensions. Invalid context blocks. Policy selects one of four outcomes. Block stops. Require approval sends the bound request to an independent reviewer. Rejection or expiry stops. Allow, warn, or valid approval executes once and records the receipt and evidence.

Scroll horizontally to inspect the diagram.

Issue short-lived credentials and control impersonation¶

Issue credentials after workload authentication and current authority resolution. Bind each credential to one audience, trust domain, environment, subject or actor relationship, purpose, scope, and short lifetime. Keep refresh and exchange privileges narrower than the original authority.

OAuth 2.0 Token Exchange defines separate subject and actor tokens for delegation. The act claim can express the current actor. Resource Indicators bind a token request to the target resource. Rich Authorization Requests can carry structured action and resource details. Each protocol still relies on the authorization server and resource server to enforce local policy and revocation.

• Just in time: issue access when the task starts, after approval or assignment, and expire it with the task.
• Rotation: automate key and credential replacement, retain generation and overlap evidence, and test the old credential after cutover.
• Impersonation boundary: reserve impersonation for explicit cases where the actor becomes indistinguishable at the target; preserve the original actor in a separate protected record.
• Delegation boundary: keep both subject and actor visible and reduce the delegated authority for the task.
• Token handling: exclude raw secrets from logs; retain issuer, token identifier or digest, audience, scopes, effective time, expiry, and revocation result.

Reusable least-privilege policy¶

The policy below is a vendor-neutral design example for a credit-review document reader. It covers all nine entitlement dimensions and links missing or expired context to a block. Download the JSON file for workshops and tests. Replace every synthetic identifier and threshold with an approved local contract.

{
  "schema_version": "1.0",
  "policy_id": "credit-review-document-reader",
  "status": "example",
  "subject": {
    "agent_id": "credit-review-agent",
    "workload_id": "spiffe://bank.example/prod/credit-review",
    "delegated_user_required": true
  },
  "entitlements": {
    "tools": [
      "credit_application.read",
      "credit_memo.draft",
      "credit_decision.propose"
    ],
    "resources": [
      "credit-application:{case_id}"
    ],
    "data": {
      "fields": [
        "declared_income",
        "verified_income",
        "existing_exposure",
        "requested_amount"
      ],
      "denied_fields": [
        "special_category_data",
        "unrelated_household_records"
      ]
    },
    "actions": [
      "read",
      "draft",
      "propose_credit_decision"
    ],
    "purposes": [
      "credit_application_review"
    ],
    "amount": {
      "currency": "EUR",
      "approval_threshold": 25000,
      "authorization_ceiling": 100000
    },
    "environments": [
      "production"
    ],
    "time": {
      "maximum_token_lifetime_seconds": 900,
      "access_window": "case_assignment"
    }
  },
  "decision": {
    "allow_when": [
      "case_id matches the assigned case",
      "delegated user remains assigned and active",
      "all requested fields are allowed",
      "purpose equals credit_application_review",
      "requested amount is at or below EUR 25000",
      "token audience matches the target resource"
    ],
    "require_approval_when": [
      "the agent proposes a credit decision",
      "the requested amount exceeds EUR 25000 and is at or below EUR 100000"
    ],
    "block_when": [
      "identity, delegation, tenant, purpose, or audience is missing",
      "the credential, assignment, entitlement, or policy is expired",
      "the request targets an unassigned case or forbidden field",
      "the requested amount exceeds EUR 100000",
      "the destination or purpose differs from the authorized values",
      "the policy decision service cannot produce the required verdict"
    ]
  },
  "evidence": [
    "principal_id",
    "agent_identity_id",
    "workload_identity_id",
    "delegation_id",
    "tenant_id",
    "tool_id",
    "resource_id",
    "data_boundary_ref",
    "action",
    "purpose",
    "amount",
    "environment",
    "requested_at",
    "expires_at",
    "policy_id",
    "policy_version",
    "authentication_event_id",
    "authorization_decision_id",
    "policy_decision_id",
    "approval_decision_id",
    "reason_codes",
    "approval_id",
    "reviewer_id",
    "execution_receipt"
  ]
}

Run the entitlement review as a control¶

A review starts with a reconciled identity and access population, then tests effective authority and observed use. Download the IAM architecture workbook for the full checklist, decision tables, and review record.

• Reconcile the population. Compare registered agents and service accounts with token issuers, cloud principals, secret stores, gateways, MCP discovery, CI/CD identities, package spend, and observed tool calls.
• Resolve effective access. Include direct grants, roles, attributes, relationships, capabilities, groups, delegations, temporary access, policy rules, and downstream permissions.
• Find control exceptions. Record orphaned, shared, dormant, duplicate, expired, unobserved, cross-tenant, self-approvable, and over-broad authority.
• Test enforcement. Exercise allowed, approval, blocked, expired, missing-context, revoked, and stale-relationship requests.
• Reconcile outcomes. Join each sample to the policy result, reviewer decision, tool receipt, business state, and evidence record.
• Certify the scoped result. Record criteria, population, period, reviewer, exceptions, decision, expiry, next review, and evidence references.

Discover and audit service accounts¶

Build the non-human identity population from several independent sources. Identity directories alone miss credentials created in cloud projects, CI/CD systems, secret stores, local MCP clients, schedulers, browser automation, and downstream applications. Gateway and network observations reveal identities that bypass the expected catalog.

For each service account, record the owning Process, accountable person, agents and workloads that can use it, credential location, allowed targets, effective grants, last use, expiry, rotation, revocation method, and evidence source. Quarantine or revoke accounts with no current owner or approved use after the defined safety review.

Revoke, stop, roll back, and recover¶

Revocation closes authority for future use. Emergency stop contains active and queued work. Rollback restores a known-good Release or configuration. Incident recovery reconciles downstream effects, issues fresh credentials, tests the safe state, and uses a separate restart decision.

Text alternative. The incident owner records the affected scope and activates a deny state. Workflow controls cancel active and queued work. Identity controls disable the agent and workload, revoke tokens, and rotate credentials. Gateways deny new requests. Tool owners reconcile accepted and committed effects. Evidence records acknowledgements and residual access. Recovery uses a known-good Release, fresh credentials, a narrow allowlist, and restart approval.

Scroll horizontally to inspect the diagram.

Enforce tenant and organization boundaries¶

Treat tenant, organization, trust domain, environment, and region as authorization facts with authoritative issuers. Validate them at every external boundary and use them in datastore queries, token audiences, policy context, approval lookup, tool routing, and evidence selection.

Keep production and non-production identities in separate trust domains or equivalent namespaces. Qualify foreign attributes and roles by their issuing authority. Federation establishes which credentials can be authenticated across domains; local authorization still decides which action and resource each foreign identity may use.

• Reject a tenant or organization selector that conflicts with the authenticated token.
• Bind resource identifiers, relationship edges, capabilities, and approvals to one tenant.
• Use target-specific token audiences and avoid bearer tokens accepted by several unrelated resources.
• Test cross-tenant reads, writes, approvals, delegation, cache keys, queues, and evidence exports.
• Record the authoritative tenant and trust domain in every identity, policy, execution, and evidence event.

Assign responsibility across the lifecycle¶

Name one accountable role for each identity, entitlement, decision, effect, and evidence boundary. Advisory groups can review the design. Operating authority remains assigned to a person or role with a defined delegate, effective period, and escalation path.

Select a deployment pattern¶

Choose the pattern from the authority owner, target-system capability, action consequence, identity volume, and required attribution. A single organization can use several patterns across Processes while preserving one evidence model.

Worked example: regulated credit review¶

A bank assigns a credit-review agent to case CR-1842. The agent has a dedicated identity and runs under an attested production workload. A named underwriter is the delegated subject for this case. The token service issues a 15-minute credential whose audience is the document service.

Authorization permits four approved fields, three actions, and amounts up to EUR 100,000 for the purpose credit_application_review while the assignment remains active. Policy allows reading those fields and drafting a memo. A proposed credit decision or a request above EUR 25,000 creates a Decision Request. A new purpose, a forbidden field, an amount above the authorization ceiling, or missing identity, delegation, tenant, audience, or current policy blocks. Approval operates inside the authorization ceiling.

The requesting underwriter cannot decide the held request. A qualified second reviewer sees the exact action, source evidence, policy reasons, authority requirement, expiry, and expected effect. Approval releases the same bound request once. The downstream receipt and case state join the identity, delegation, entitlement, policy, reviewer, and execution records.

How the architecture maps to current KLA contracts¶

The KLA Control Plane governs instrumented agent actions. The current implementation supplies a runtime policy, approval, execution, lineage, and evidence layer. Enterprise identity providers, resource servers, and credential systems remain the authority for their identities and grants.

The mapping below reflects code present in repository source at commit a4e8087f. Deployment and production behavior remain unverified. Source links are pinned to that commit. Status distinguishes a current contract from a partial mapping or a conceptual abstraction.

Current KLA gaps and conceptual abstractions¶

KLA evaluates and records authority at the governed action boundary. It is outside several enterprise IAM responsibilities in this reference. Treat the fields and flows below as integration requirements until the stated gap has a current implemented contract.

• Delegated subject. Execution creation currently sets onBehalfOfSubject to the initiating subject and records the caller client. The complete public execution contract currently lacks a separately attested end-user subject and delegation chain.
• Identity lifecycle. Enterprise identity providers, workload attestation authorities, HR directories, and universal service-account discovery systems remain external dependencies.
• Credential lifecycle. Connectors and target systems own downstream tool credential issuance, rotation, revocation, brokering, and incident actuation.
• Entitlement normalization. Current contracts support principal, resource, action, attributes, tool arguments, environment, and flexible context. Each path can represent purpose, amount, data, and relationship facts through flexible fields; the contract leaves their normalization to the producer.
• Authorization models. RBAC, ABAC, relationship, and capability patterns in this reference are architecture choices. The current KLA policy contract is model-agnostic.
• Certification. The current product records controls and evidence. Universal certification of an agent identity or entitlement population remains outside the current contract.
• Revocation fan-out. Runtime cancellation is implemented. End-to-end identity disablement, token revocation, network isolation, downstream cancellation, and compensation remain coordinated external actions.
• Portable record. The AI Agent Audit Log Schema normalizes several KLA producers into one vendor-neutral event. Current producers emit their authoritative native records, which the reference maps into the public envelope.

Primary sources and freshness¶

This architecture was checked on 28 July 2026. Identity standards, protocol specifications, draft guidance, and implementation profiles can change. Recheck the live source and local deployment before using a status in an audit, procurement, or security decision.

• NIST NCCoE software and AI agent identity and authorization concept paper (draft, published 5 February 2026)
• NIST SP 800-162, Guide to Attribute Based Access Control
• NIST Role Based Access Control project and current standard reference
• NIST SP 800-207, Zero Trust Architecture
• RFC 8693, OAuth 2.0 Token Exchange
• RFC 8707, Resource Indicators for OAuth 2.0
• RFC 9396, OAuth 2.0 Rich Authorization Requests
• SPIFFE standard 1.15.2 and workload identity specifications
• Model Context Protocol authorization specification, 25 November 2025
• Model Context Protocol security best practices