AI agent access control gives a named agent the minimum current authority required for one approved purpose, evaluates each proposed action against that authority, routes consequential exceptions to an eligible human, and records the result. A complete design covers identity creation through emergency revocation. It resolves effective entitlements at runtime because roles, assignments, data sensitivity, transaction values, and policy can change between login and execution.
This pillar answers how to design and operate the control system. The AI agent permissions guide covers periodic access audit and certification. The AI agent IAM reference architecture supplies the deeper component and deployment model. The guidance here is vendor-neutral and was checked against primary sources on 28 July 2026.
Use one lifecycle from identity to revocation
Assign every agent a durable owner, purpose, risk class, environment, and identity record before granting access. Bind that business identity to an attested workload or client. Grant narrow entitlements with an expiry and review date. Evaluate them at each action. Record approval and execution under the same correlation identifiers. Revoke authority when the purpose, owner, assignment, risk, or environment changes.
Text alternative. The lifecycle starts with registration and identity binding, moves through grant, runtime evaluation, human approval, execution, evidence, and periodic review, then ends with revoke, reconcile, and recover. A change in purpose, ownership, risk, or environment sends the agent back to review before later execution.
Scroll horizontally to inspect the diagram.
Treat access as a governed lifecycle with an owner, expiry, review, and tested revocation path.
Open full-size diagram| Stage | Decision | Owner | Evidence |
|---|---|---|---|
| Register | Agent purpose, risk, sponsor, tenant, environment | Business owner | Registry record and approval |
| Bind identity | Agent, workload, service, and delegated subject | IAM and platform owners | Issuer, subject, actor, audience, attestation |
| Grant | Effective tool, resource, data, action, and context limits | Resource and policy owners | Grant, policy, expiry, exception |
| Evaluate | Current request against current authority | Authorization and policy owners | Inputs, result, reason codes, versions |
| Approve | Eligible person releases the exact held request | Reviewer authority owner | Role snapshot, rationale, digest, expiry |
| Execute | Bound request creates one side effect | Tool and Process owners | Receipt, before and after state, downstream effect |
| Review | Access remains necessary and proportionate | Owner and independent reviewer | Population, exceptions, certification boundary |
| Revoke | Stop authority and reconcile residual access | Incident, IAM, and tool owners | Commands, denials, residual sessions, recovery |
Choose the identity pattern before assigning rights
Use a dedicated agent identity for repeatable enterprise authority. Add a delegated human subject when that person’s current assignment constrains the action. Bind the agent to a workload identity so the running software instance is attributable. Reserve shared service accounts for legacy targets behind a mandatory gateway that resolves the agent and request before each call.
| Pattern | Use when | Required control | Primary risk |
|---|---|---|---|
| Dedicated agent | The organization owns repeatable operational authority | Named owner, narrow grants, workload binding, lifecycle | Standing or orphaned access |
| Delegated user | One person remains the authority owner | Actor-subject binding, reduced scope, purpose, expiry | Ambient user privilege |
| Hybrid | Both agent actor and human subject affect the decision | Token exchange or equivalent dual identity, audience, evidence | Actor-subject confusion |
| Brokered service account | A legacy target accepts one technical credential | Mandatory gateway, per-call policy, bypass detection, receipt | Shared credential and weak attribution |
Combine RBAC, ABAC, and capabilities deliberately
Role-based access control (RBAC) supplies understandable baseline duties. Attribute-based access control (ABAC) narrows a request using subject, resource, action, and environment attributes. A capability grants a specific holder a narrow, transferable-by-rule authority to a resource or action. Most production agent systems use roles for baseline assignment, attributes for live context, and short-lived capabilities or tokens for the final call.
| Model | Best use | Example | Control requirement |
|---|---|---|---|
| RBAC | Stable job or service baselines | claims_reader can read assigned claim summaries | Small roles, separation, periodic review |
| ABAC | Context-sensitive decisions | Tenant, assignment, sensitivity, purpose, amount, location, and time all match | Trusted attributes, freshness, reason codes |
| Capability | Narrow call authority | One short-lived grant for claim:1842 and settlement.propose | Audience, expiry, attenuation, replay defense, revocation |
| Combined | Consequential production actions | Role grants eligibility; attributes constrain context; capability binds the call | One precedence rule and one evidence record |
Own all seven least-privilege boundaries
A tool allowlist is one boundary. The policy must also constrain the records, fields, operation, value, business purpose, deployment, and time. Assign a source of truth, enforcement point, review owner, and evidence field to every boundary.
| Boundary | Policy question | Example control | Evidence |
|---|---|---|---|
| Tool | Which connector, API, or MCP server may receive a call? | Allowlisted tool identity and destination | Tool ID, endpoint, server version |
| Data | Which tenant, record, field, region, and sensitivity? | Assigned case and approved fields | Resource IDs, field set, classification |
| Action | Which read, draft, propose, approve, or execute operation? | Separate propose and execute permissions | Operation and parameters |
| Amount | What value or risk threshold applies? | Approval at EUR 25,000; ceiling at EUR 100,000 | Currency, amount, thresholds |
| Purpose | Which declared business use authorizes access? | Purpose equals claim_settlement | Purpose, legal or policy basis, case |
| Environment | Which tenant, account, region, network, and deployment? | Production identity accepted only in production | Tenant, environment, workload |
| Time | When and for how long? | 15-minute token within active assignment | Issued, effective, expiry, decision time |
Return one of four policy outcomes
Define precedence and failure behavior before rollout. A block condition wins. A missing required input or unavailable mandatory policy dependency enters the documented safe state. Approval releases only the same request, parameters, evidence, policy, and context that the reviewer saw.
| Outcome | Meaning | Execution behavior | Evidence |
|---|---|---|---|
| allow | Request is within current authority and policy | Execute the bound request | Decision, versions, reasons, receipt |
| warn | Request may proceed with a recorded advisory | Surface warning and execute under defined policy | Warning, acknowledgement rule, receipt |
| require_approval | A qualified person must decide before expiry | Hold; approve, reject, request changes, or escalate | Decision Request, reviewer authority, rationale |
| block | Request exceeds authority or violates policy | Stop before the side effect | Deny reason, request digest, attempted target |
Place human approval at consequential boundaries
Require approval for rights-affecting decisions, irreversible effects, policy exceptions, high values, sensitive external communications, access expansion, and unusual uncertainty. Resolve the reviewer’s current role, value limit, delegation, training, conflicts, and maker relationship at decision time.
The human oversight decision guide covers trigger design, maker-checker separation, expiry, override, appeal, and failure handling. The Human Oversight architecture shows KLA Decision Requests and Decision Desk in the product.
- Show the exact proposed action, target, values, affected party, and expected effect.
- Show the policy outcome, matched rules, reason codes, source facts, uncertainty, and missing facts.
- Bind the approval to the request digest, policy version, evidence snapshot, reviewer, and expiry.
- Re-evaluate authority and policy immediately before release.
- Keep reject, request-changes, escalate, timeout, and appeal paths available.
Run entitlement review as a control test
Start from the complete agent and service-account population. Compare requested, approved, configured, and observed authority. Inspect direct grants, inherited roles, group membership, delegated access, MCP servers, connector secrets, emergency exceptions, dormant identities, token lifetimes, and target-system permissions.
Download the AI agent entitlement review checklist for the evidence request, service-account discovery, sample tests, exception log, and reviewer sign-off.
| Field | Required value | Test |
|---|---|---|
| Population | Every production agent, workload, service identity, gateway, and delegated path | Reconcile registry, identity provider, secrets, gateways, tools, and runtime logs |
| Authority | Effective tool, data, action, amount, purpose, environment, and time | Compare approved policy to configured and observed access |
| Owner and need | Named accountable owner and current business purpose | Confirm with an independent reviewer |
| Exceptions | Reason, compensating control, approver, expiry | Reject expired or ownerless exceptions |
| Revocation | Actuators, dependencies, last test, residual access | Exercise a representative disablement |
| Conclusion | Scope, criteria, period, samples, findings, limitations, next review | Record the certification boundary |
Discover service accounts across every control plane
Service accounts often sit outside the agent registry. Reconcile cloud IAM, identity-provider applications, workload identities, Kubernetes service accounts, CI identities, vault and secret-manager entries, API gateways, MCP server registrations, connector installations, target-system audit logs, and network egress records.
- Flag credentials with no owner, no last-used signal, no expiry, broad wildcard scopes, or use from several environments.
- Trace each shared credential through the gateway to the agent, tenant, request, and downstream receipt.
- Compare observed destinations and operations with approved tool and action boundaries.
- Rotate or retire dormant credentials under the organization’s change and recovery procedure.
Make emergency revocation executable
Predefine who can declare the incident, which scope they can stop, and how responders verify containment. Preserve evidence during the response. Reconcile downstream effects before restoring authority.
| Step | Action | Proof |
|---|---|---|
| 1. Scope | Identify tenant, agent, workload, credentials, sessions, tools, requests, and downstream jobs | Incident and correlation identifiers |
| 2. Stop | Cancel active executions and hold queued or approval-gated work | Cancellation results and denied transitions |
| 3. Revoke | Disable identity; revoke tokens, secrets, capabilities, sessions, and delegated grants | Actuator responses and later denials |
| 4. Isolate | Block network paths, connectors, or target accounts when credential revocation is incomplete | Network and target-system decisions |
| 5. Reconcile | Find completed and partial side effects; compensate where authorized | Receipts, before and after state, compensation |
| 6. Recover | Repair root cause, issue fresh authority, test safe state, approve restart | Change, test, reviewer, restart time |
Capture evidence at the decision boundary
The evidence record should let a reviewer reconstruct the identity chain, effective authority, evaluated context, outcome, human decision, side effect, and later revocation. Use stable identifiers to join authoritative native records. The public AI Agent Audit Log Schema provides a portable event envelope.
| Boundary | Required fields |
|---|---|
| Identity | tenant, principal, agent, workload, delegated subject, issuer, audience, authentication event |
| Entitlement | effective roles, attributes, capabilities, tool, resource, data, action, amount, purpose, environment, time |
| Policy | policy and rule versions, evaluated fields, outcome, reason codes, exception |
| Approval | request ID and digest, eligible reviewer, role snapshot, decision, rationale, expiry |
| Execution | idempotency key, tool call, receipt, before and after state, downstream effect |
| Lifecycle | owner, review, change, revoke, deny, residual access, compensation, recovery |
Worked example: regulated insurance settlement
An insurer assigns a claims agent to claim CL-1842. A dedicated agent identity runs under an attested production workload. The policy permits the assigned claim, approved claim fields, document reading, settlement drafting, and settlement proposals up to EUR 100,000 for claim_settlement during the active assignment.
A proposal at EUR 32,000 returns require_approval because it exceeds the EUR 25,000 approval threshold. A qualified claims manager independent of the requester reviews the source facts, policy reasons, proposed payee, amount, and expected ledger effect. Approval binds those values for ten minutes. The system re-evaluates policy, executes once, and joins the downstream receipt to the request and decision.
A different payee, forbidden medical field, expired assignment, new purpose, changed evidence, amount above EUR 100,000, or missing mandatory policy result returns block. Emergency revocation cancels active work, disables the agent and workload credentials, blocks the connector, reconciles partial effects, and records recovery approval.
| Stage | Result | Evidence |
|---|---|---|
| Identity | Agent, workload, tenant, claim assignment, and purpose valid | Issuer, subjects, attestation, assignment, expiry |
| Entitlement | Claim, fields, tools, action, value ceiling, environment, and time match | Effective grants and attributes |
| Policy | require_approval at EUR 32,000 | Policy version, threshold, reasons, request digest |
| Approval | Independent manager approves exact request for ten minutes | Eligibility, role, rationale, expiry |
| Execution | Policy rechecked; approved transfer instruction issued once | Receipt, idempotency key, ledger effect |
| Review | Reviewer samples request, decision, execution, and revocation readiness | Workpaper, exception, conclusion |
Treat MCP authorization as one integration boundary
Model Context Protocol (MCP) defines authorization interactions for HTTP transports and points implementations to OAuth security practices. Enterprise access control still owns agent identity, tenant binding, target-system grants, tool allowlists, data and action limits, approval, evidence, and incident revocation.
Review the MCP audit and security guide for transport and server risks. Record the server identity, advertised tools, authorization server, audiences, scopes, consent or approval, token lifetime, tool arguments, result, and downstream effect.
Map the model to current KLA contracts precisely
The KLA Control Plane governs instrumented actions at runtime. This mapping reflects code present at commit 8fd582a6. Deployment and production behavior remain unverified. Enterprise identity providers, credential issuers, directories, tool authorizers, and source-system entitlement inventories remain external authorities.
| Function | Current KLA mapping | Source | Status |
|---|---|---|---|
| Authentication and tenant binding | Execution API verifies allowed JWT issuer and audience and derives tenant binding. | auth middleware and execution route | Code present |
| Action context and four outcomes | Policy requests carry principal, resource, action, actor, environment, tool, destination, data sensitivity, and business context. Outcomes are allow, warn, require_approval, or block. | policy contracts | Code present; producer-specific fields |
| Control-plane authorization | permissionProcedure authenticates the caller and fails closed when its named permission is absent. protectedProcedure authenticates only; integrations.list, llmProviders.list, and usage.getQuotaStatus use it without an explicit permission check. Authorization coverage is procedure-specific. | procedure definitions, integrations, providers, and usage | Code present; verify each procedure |
| Tenant data isolation | Tenant context scopes requests. Tenant-owned API tables use forced row-level security under the migration contract; coverage remains table-specific and service-specific. | tenant middleware and RLS migration | Code present; verify each service and table |
| Fail-closed workflow gate | The transition gate blocks missing work-item context, unresolved pack contracts, failed output validation, evaluation errors, and block outcomes before advancing. | transition gate | Code present |
| Human approval | Decision Desk checks decision permission, required role, pending state, maker identity, and due time for Decision Requests. | approvals router | Code present; producer-dependent fields |
| Runtime cancellation | A tenant-scoped route signals active or gated workflows. Identity-provider and downstream token revocation remain external actuators. | execution cancellation | Code present; partial revocation fan-out |
| Audit and evidence | Worker records carry identity, policy, approval, execution, hashes, and trace correlation. Evidence Room bundles selected records under a manifest and integrity proofs. | audit events and evidence contract | Code present across authoritative records |
Keep the KLA scope boundary explicit
KLA evaluates and records the governed action paths integrated with the KLA Control Plane. Universal visibility into every identity, credential, service account, connector, and target-system permission remains outside that scope.
- Identity lifecycle. Enterprise identity providers, HR directories, workload attestation authorities, and service-account inventories own identity creation, status, and discovery.
- Credential lifecycle. Issuers, vaults, connectors, and target systems own downstream credential issue, rotation, brokering, and revocation.
- Entitlement normalization. KLA contracts accept flexible action and business context. Producers remain responsible for normalized purpose, amount, data, relationship, and time facts.
- Authorization model. RBAC, ABAC, and capability patterns are architecture choices. The KLA policy contract is model-agnostic.
- Certification. KLA records controls and evidence. The organization defines review criteria, complete population, samples, conclusion, and any certification boundary.
- Revocation fan-out. Runtime cancellation exists. End-to-end identity disablement, token revocation, network isolation, downstream cancellation, compensation, and recovery require coordinated external actions.
Primary sources and freshness
This guide was checked on 28 July 2026. Standards, specifications, draft guidance, and local implementations change. Recheck the primary source and deployed behavior before an audit, procurement, legal, or security decision.
- NIST SP 800-53 Rev. 5, AC-6 Least Privilege
- NIST SP 800-162, Guide to Attribute Based Access Control
- NIST Role Based Access Control project and standard reference
- NIST NCCoE software and AI agent identity and authorization concept paper (draft, published 5 February 2026)
- RFC 8693, OAuth 2.0 Token Exchange
- RFC 8707, Resource Indicators for OAuth 2.0
- RFC 9396, OAuth 2.0 Rich Authorization Requests
- Model Context Protocol authorization specification, 25 November 2025 (latest published version available during this review)
- Model Context Protocol 2026-07-28 release candidate (locked 21 May 2026; final publication was scheduled for 28 July and was not yet available during this review)
Frequently Asked Questions
What is AI agent access control?
AI agent access control identifies the agent and workload, resolves current entitlements, evaluates the proposed action and context, routes consequential requests to an eligible human, and records the decision and effect.
How does least privilege apply to AI agents?
Grant only the tool, data, action, amount, purpose, environment, and time needed for the approved task. Re-evaluate those boundaries before each consequential action.
Should an AI agent use RBAC or ABAC?
Use RBAC for understandable baseline duties and ABAC for request-specific context. A short-lived capability or token can bind the final resource, action, audience, and expiry.
When should an AI agent require human approval?
Require approval for rights-affecting decisions, irreversible effects, policy exceptions, high values, sensitive communications, access expansion, and unusual uncertainty. Bind the decision to the exact request and expiry.
How often should AI agent entitlements be reviewed?
Set a risk-based cadence and trigger a review when the owner, purpose, risk, tools, data, policy, environment, or target system changes. High-impact and standing production access needs shorter intervals.
How do I find AI agent service accounts?
Reconcile the agent registry with cloud IAM, identity-provider applications, workload platforms, CI, vaults, secrets, API gateways, MCP servers, connectors, target-system logs, and network egress.
What should emergency revocation stop?
Stop active and queued work, revoke identities, tokens, secrets, sessions, delegated grants, and capabilities, isolate remaining paths, reconcile side effects, repair the cause, and approve recovery.
What evidence proves AI agent access control worked?
Join identity and authentication, effective entitlements, policy inputs and outcome, human decision, execution receipt, lifecycle changes, revocation, residual-access checks, and recovery under stable identifiers.
Key Takeaways
Effective AI agent access control starts with a complete identity population, narrow and reviewable entitlements, four explicit runtime outcomes, eligible human approval, tested emergency revocation, and joined evidence. Use the entitlement review checklist, deepen the architecture with the IAM reference, audit rights with the permissions guide, and implement the portable event fields in the AI Agent Audit Log Schema.