> ## Content Index > Fetch the complete content index at: https://research.controlarch.org/llms.txt > Use this file to discover other available public pages before exploring further. # AI Agent Identity and Access - URL: https://research.controlarch.org/ai-agent-identity-and-access/ - Published: 2026-09-13T20:28:39.000Z - Updated: 2026-09-23T14:07:01.000Z - Description: Agent authorization has converged on mechanism and remains unsettled on decision. What must be built is an agent access control plane — more of it can be bought now, but the composition stays the enterprise's accountability. - Author: Homan Farahmand - Tags: Capability Report, AI Agent, Identity, Access [AI Agent Identity and AccessIdentity is the root; access is the objective.AI Agent Identity and Access.pdf950 KBdownload-circle](https://research.controlarch.org/content/files/2026/09/AI-Agent-Identity-and-Access-1.pdf "Download") ## Observations - **Agent authorization has converged on mechanism and remains unsettled on decision.** The specification layer now names the credential to present, the exchange at each boundary, the cross-domain chain, and the contents of an audit record. Two things the leading draft puts explicitly out of its own scope: how a task becomes authorization requirements, and the policy model that expresses them. Two more it leaves open: how a human confirms mid-execution, where the callback protocol it cites only covers initiation, and how scope inherits when an agent spawns another, which is still missing.[1](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn1) - **The consequential incidents are access failures, not identity failures.** Agents are workload identities carrying agentic attributes: an operating mode, a delegation chain, a tool and data reach, an accountable owner. That framing earns its place only through what follows it. In CAI's reading of the incidents worth studying, not a frequency claim, they turn on an agent exercising authority it was never scoped for: a stale or over-broad token, a tool call that should have been denied, an instruction relayed down a delegation chain without re-checking the original intent. - **Letting an agent inherit a human's credential is the most consequential anti-pattern.** It obscures who acted, and it gives the agent whatever that credential reaches, which for a broad user session is most of that human's standing access. It persists because it is the fastest path to a working agent, and because the systems an agent reaches still expect a human user. What it costs varies by type: an endpoint assistant, a coding agent, an autonomous cloud service, and a privileged-operations agent share neither a trust boundary nor a blast radius. ## Position - **Give every agent its own identity, an accountable owner, and a bounded envelope.** Record type at the same moment, because type selects the control bundle, the enforcement point, and the telemetry source. The owner is accountable for the agent; the owner's own entitlements do not define its authority. - **Enforce authority at runtime as a computed intersection, deny by default.** On every consequential call, authorize against the intersection of registered scope, operating mode, delegation chain, the resource's policy, the action's context, and data sensitivity. Express that envelope as structured, versioned resource permissions that a non-reasoning system evaluates, never as instructions in a prompt: an agent that is misled still cannot exceed the permissions underneath it. Require human approval for high-risk actions. - **Eliminate credential inheritance and impersonation on a dated plan.** Replace inherited credentials with distinct workload identities and short-lived credentials exchanged for the task and the call chain. Treat any remaining human-user impersonation as a documented exception with an expiry, not a default. When an agent delegates to another agent, scope may only narrow, and each hop records what it conveyed. ## What Changed in This Version This second iteration of IAM-CAP-AI-01 (originally published on 06 July 2026) covers the interval to 10 September 2026 and aligns to the Foundation Reports. - The opening claim is narrowed to where agent authorization now actually stands. - Runtime policy and tool-boundary authorization are treated as available. - The operating system enters the architecture as an enforcement point and identity root. - The maturity model uses the operability vocabulary in the Foundation Reports. ## Scope and Context This report treats one capability: governing, authorizing, and observing the access that AI agents exercise across enterprise systems. Its subject is access (the authority an agent holds and uses) rooted in, but not satisfied by, identity. An AI agent here is a software system that pursues a goal by interpreting context, deciding, and acting through tools, with or without a human in the loop. The capability is not model safety, alignment, or prompt-injection defense; those bear on this report only where they change what an access control must enforce. AI agents are a constituency of Machine IAM (the umbrella term for identity and access management applied to devices, workloads, AI agents, and other machine subjects), which replaces the looser market phrase “non-human identity.” Machine IAM parallels workforce IAM and customer IAM as a subject population. An AI agent is best understood within it as a workload identity that carries additional agentic attributes: a declared operating mode, a delegation chain, a tool and data reach, and an accountable owner. Currency and alignment. Statements about specification status in this report are verified as of 10 September 2026 and are dated wherever the status is load-bearing. Band vocabulary follows the Foundation Reports: attribution confidence A0 to A4, binding confidence S0 to S4, and the shared operability vocabulary behind the governance, runtime, and observability bands. The maturity model in Table 6 uses that vocabulary at levels 1 to 5 and states its own agent-specific entry conditions; it is read alongside the Foundation profiles through the crosswalk stated there, not as a substitute for them. > **CAI View** — Identity is necessary but not sufficient. An agent rooted in a flawless identity, with no authorization enforced at the moment it acts, is ungoverned. The control object is access. In the IAM control architecture, agent access control spans the three control categories: governance (deciding who should have what access), runtime (enforcing access in the moment), and observability (knowing what happened, with the capacity to interrogate, detect, and respond). Agent access control is distinctive because the runtime category carries unusually heavy weight (an agent’s authority is exercised programmatically, at machine speed, across many calls) so admin-time governance alone leaves most of the risk untouched. The boundary of this report is drawn as follows. **Table 1.** *The report's scope: what is treated in full, what is referenced as adjacent, and what is out of scope.* | **Boundary** | **Coverage** | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **In scope** | Agent registration and classification; distinct identity, ownership, and lifecycle; access-envelope definition; runtime authorization; gateway and tool-boundary enforcement; short-lived credentials and token exchange; human-in-the-loop approval; attribution and observability; and cross-domain and multiagent trust considerations. | | **Adjacent (referenced)** | Workload-identity foundations; authorization management platforms; privileged access management; API security; identity governance; and security event monitoring and identity threat detection. These are integrated, not duplicated. | | **Out of scope** | Model alignment and safety; prompt-injection and content-safety defenses except where they change access enforcement; full customer-IAM treatment of agentic customers; product ranking; and legal or regulatory analysis beyond its IAM-control implications. | ## Agent Types and Control Selection Because risk varies by type, type is the first registration decision and the one that selects the control bundle. The map below states, for each type, the identity root and the strength of the binding behind it, the enforcement point, the telemetry source, the primary risk, and the controls that follow. Binding strength is stated on the substrate scale used across the Foundation Reports, because an identity root named without a strength is a mechanism rather than a control. An eighth type, the commerce or payment agent, is added in this iteration: it is separated from the SaaS connector because its consequential action is a transaction authorized by a signed mandate rather than an API call authorized by a token. **Table 2.** *The eight agent types and, for each, its identity root, enforcement point, telemetry source, primary risk, and control bundle, the basis for type-first control selection; binding strength is stated where the evidence supports it.* | **Agent type** | **Identity root** | **Enforcement point** | **Telemetry source** | **Primary risk** | **Control bundle** | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Endpoint assistant** | Operating-system agent account, distinct from the signed-in user; directory-backed, with binding confidence set by the verification evidence retained, not by placement | Agent session boundary; the app's API gateway | Endpoint and SaaS audit logs; local model execution is not visible in the SaaS log | Over-broad delegated scope; data exfiltration | Device posture; delegated short-lived tokens; per-action scope; data-loss controls | | **Coding / CI-CD agent** | Workload identity in the pipeline platform | Repository and pipeline permissions; secrets broker | Pipeline and source-control logs | Secret exposure; supply-chain and destructive actions | Ephemeral pipeline credentials; scoped repo and deploy rights; approval for production; signed provenance | | **SaaS-embedded connector** | Federated tenant agent identity | Identity provider via cross-app access; SaaS APIs | Identity-provider and SaaS audit | Token sprawl; cross-app over-reach; confused deputy | Provider-mediated cross-app access; scoped grants; token vaulting; universal logout | | **Cloud-hosted autonomous agent** | Cloud workload identity | The IAM-aware runtime and its tool gateway | Runtime traces; cloud audit | Unattended over-reach; lateral movement | Runtime identity injection; tool-boundary authorization; instance isolation; conditional access | | **Self-hosted agent** | SPIFFE/WIMSE workload identity in the trust domain | Service-mesh or sidecar enforcement; internal gateway | Mesh and host telemetry | Flat internal trust; credential theft | Mutual-TLS workload identity; sidecar authorization; segmentation; short-lived credentials | | **Privileged-operations agent** | Workload identity under privileged-access management | Privileged-access broker; just-in-time elevation | Session recording; privileged-access logs | Catastrophic blast radius | Zero standing privilege; just-in-time access; mandatory human approval; full session attribution | | **Multiagent orchestrator** | Agent identity plus signed delegation | Agent-to-agent trust verification; gateway at each hop | Trace context propagated across hops | Scope-attenuation failure across the chain; impersonation | Signed agent cards; holder-attenuable delegation; per-hop authorization; end-to-end attribution | | Commerce or payment agent | Workload identity plus a signed mandate binding the authorizing human to the specific transaction | Payment or commerce protocol endpoint, and the merchant's authorization server | Mandate records and settlement logs | Transacting outside the authorized intent, amount, or instrument; disputed attribution after settlement | Signed intent and transaction mandates; per-transaction limits; non-repudiable evidence retained to the dispute window | ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/09/figure-1.png) **Figure 1.** *The eight agent types ordered by risk in CAI's judgment, each mapped to where its calls are enforced, its dominant risk, and its control bundle; gold marks privileged-operations, the type to govern first.* Two reading rules follow from the map: - **Place enforcement where the type’s calls actually pass**: A gateway for SaaS and cloud, a sidecar in a self-hosted mesh, the runtime for cloud-hosted autonomous agents, and a privileged-access broker for privileged operations. - **Sequence by risk**: coding, data-access, commerce, infrastructure, and privileged-operations agents earn controls before low-risk assistants, because their failure modes are the ones that end up in an incident review. The eight types are described below. Each entry says what the type is, what makes its control problem different from the others, and one worked example of the difference in practice. ### Endpoint assistant Runs beside a person on their device and acts inside the applications that person already uses. Its authority is delegated, its blast radius is whatever the person can reach, and its distinguishing problem is that its actions look like theirs. Example: an assistant asked to clear a mailbox backlog drafts replies, files messages, and declines two meetings. With its own account on the device and its own client identity at the mail service, the declines are attributable to the agent and its grant is revocable without touching the person's mail access; running as the person, neither is possible. The local account alone gives only local attribution; the application-side identity is what carries it to the service. ### Coding and CI/CD agent Operates inside a source repository and a build pipeline, where its authority is the pipeline's authority and its output is merged code or a deployed artifact. Its distinguishing problem is that the pipeline's credentials are usually broader than any single task needs. Example: an agent asked to fix a failing test edits one module, but the token it holds can also publish a release. Scoping the credential to the repository and the job, and requiring approval on the publish path, is the difference between a contained fix and a supply-chain event. ### SaaS-embedded connector Lives inside a vendor's application and reaches the enterprise's other applications on a user's behalf. Its identity is federated from the tenant, so the enterprise governs it at the identity provider rather than in the product. Example: a connector in a productivity suite is asked to assemble a briefing from documents, chat history, and a CRM record. Cross-application access carrying a per-user identity keeps the CRM's own authorization in force; a shared connector credential silently replaces it. ### Cloud-hosted autonomous agent Runs continuously on a provider's agent runtime, pursuing goals without a person in the loop for each step. Its authority is its own rather than a user's, and its distinguishing problem is that nobody is watching any individual call. Example: an agent monitoring cost anomalies is asked to remediate one, and its remediation path includes terminating resources. Per-call authorization at the tool boundary, with termination classed as high risk and gated, keeps autonomy useful without making it unbounded. ### Self-hosted agent Runs on infrastructure the enterprise controls, usually inside a service mesh, with a workload identity issued by the enterprise's own authority. Its distinguishing advantage is that the enterprise owns every layer; its distinguishing risk is that the same team often owns the policy and the enforcement. Example: an agent querying a data platform is issued a short-lived credential at start and a sidecar intercepts each outbound call. Separating who writes the policy from who runs the workload is what keeps the arrangement a control. ### Privileged-operations agent Acts on the systems that govern other systems: directories, key stores, infrastructure control planes. Its distinguishing problem is that its ordinary work is indistinguishable from the most damaging action available in the estate. Example: an agent asked to rotate a set of expiring certificates holds, for the duration, the ability to issue new ones. Just-in-time elevation through a privileged-access broker, scoped to the certificates named in the task and expiring with it, is the only form in which this type should exist. ### Multiagent orchestrator Decomposes a task and hands parts of it to other agents, which may belong to other teams or other organizations. Its distinguishing problem is that authority is conveyed at a moment when no human is present. Example: a planning agent asks a finance agent for transaction data. The finance agent should receive a delegation that is narrower than the planner's own authority, verify it, and record what it conveyed, so that the chain can be read afterward by someone who trusts neither agent. ### Commerce or payment agent Transacts on a person's behalf, so its consequential action settles money rather than returning data. Its distinguishing problem is that the authorization must survive a dispute months later. Example: an agent asked to reorder supplies within a budget presents a mandate signed by the authorizing human, naming the limit and the permitted merchant. A token proves the agent was permitted to call the merchant's API; a signed mandate, or an equivalent consent record, is what carries the human's authorization of this purchase to the point of settlement. ## The Capability Model Agent access control decomposes into ten sub-capabilities, grouped by the three control categories. This Capability Model and the Reference Architecture that follows describe the same plane through two lenses: - **Capabilities**, meaning what the plane must be able to do - **Components**, meaning what an enterprise builds or buys to do it The model is rooted in identity but weighted toward runtime: issuing an identity is necessary, and deciding and enforcing what that identity may do on each call is where the control actually lives. That weighting matters because the word identity is now used for two different things in agent tooling, and only one of them is a control. > **Watch-Out** — An agent operating system calls its purpose-and-constraints file an identity layer. It is not one. Identity is a representation of a subject, bound by verification, carrying an identifier and a credential that can be challenged. A file describing what an agent is for binds nothing to anyone, proves nothing, and survives no dispute. An enterprise that believes agent identity is solved because each agent has such a file has satisfied no auditor and will discover this at the first incident. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/09/figure-2.png) **Figure 2.** *The ten capabilities as a dependency model: governance sets the envelope, the runtime acts per call, observability closes the loop: each marked actionable-now or plan-for; gold marks authorization, the objective the other nine serve.* ### Governance These are the admin-time controls. Four capabilities administer access before the agent acts. - **Registration and classification.** Discover every agent, sanctioned or shadow, and record its type, owner, operating mode, and access envelope: the precondition for governing it at all. - **Identity issuance and credentialing.** Mint a distinct workload identity for each agent and exchange it for short-lived, audience-bound credentials at each boundary: never a shared, inherited, or long-lived secret. - **Policy administration.** Author, version, and store the access envelope and the authorization policy that bind what an agent may ever reach, separately from the point that evaluates them. - **Lifecycle.** Provision, rotate, suspend, and retire agents and their credentials on owner change, risk change, or task completion, so authority does not outlive its purpose. ### Runtime This is the per-call core. Three capabilities decide and apply authority on every consequential call, in order: authenticate, authorize, enforce. - **Authentication and credential verification.** Verify the credential the agent presents on every consequential call and resolve the principal (the agent and, in delegated mode, the delegated human and the chain) before any decision is made. - **Authorization.** Compute the per-call decision as the deny-by-default intersection of the access envelope, operating mode, delegation chain, resource and action policy, context, and data sensitivity, returning a decision and its obligations. - **Enforcement.** Apply the decision where the agent invokes a tool or reaches a resource, denying the call before it lands rather than reporting it afterward. As of this iteration this is a now capability rather than a plan-for one: enforcement at the tool boundary is available from protocol gateways, and runtime policy for agents is available from the platform. ### Observability This is the detective layer. Three capabilities watch what happens and feed the result back to governance and to the runtime decision. - **Discovery and posture management.** Continuously discover agents, including shadow ones, and assess the posture of the agent, its runtime, and its credentials, feeding both the registry and the runtime decision. - **Telemetry and attribution.** Record every decision and action and resolve each to the agent, its accountable owner, the runtime, the instance, the delegated principal, the resource, the tool, and the action. - **Threat detection and response.** Detect behavioral drift and anomalies in agent action and drive the response: suspend, revoke, or contain. > **Watch-Out** — Authenticating an agent once at startup is not control. Authority is exercised per call; between authentications a compromised or drifting agent operates unchecked, and the registered envelope is advisory until something enforces it at the moment of action. ## Reference Architecture The capability is delivered by an agent access control plane of eleven components, grouped by the three control categories. The count is components, not capabilities: the capability model above stays at ten, and the eleventh component realizes enforcement at the tool boundary rather than adding a capability. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/09/figure-3.png) **Figure 3.** *Eleven components mapped to the IAM controls that realize them, with the decision and enforcement split, the attributes the decision point reads, and feedback edges; gold marks the authorization decision, the objective the plane serves.* ### Governance Four components do the admin-time controls work: - **Registry and classification.** The authoritative inventory of agents, known and discovered, recording type, owner, operating mode, and access envelope. It is also the attribute source of record that the runtime decision reads. Integrates with identity governance and posture management. - **Identity issuance and credentialing.** Mints distinct workload identities and issues short-lived credentials for them, exchanged for scoped, audience-bound credentials at each boundary. Integrates with workload identity, the OAuth authorization server, and secrets and privileged-access vaults. - **Policy administration.** Where access envelopes and authorization policy are authored, versioned, and stored. This is kept separate from the point that evaluates them, so policy can change without redeploying enforcement. It is typically provided in (or integrates with) the authorization management platform. - **Lifecycle.** Provisioning, rotation, suspension, and retirement for agents and their credentials, tied to the accountable owner (the joiner, mover, and leaver-equivalent events for agents), so authority does not outlive its purpose. Integrates with identity governance. ### Runtime Four components do the work on every consequential call, implementing three functions in order: authenticate, authorize, enforce. Naming the functions separately is the point. They are distinct and often sit in different places; the gateway can host the enforcement point rather than adding a second one. Collapsing them into one gate is how startup-only authentication happens by accident. - **Authentication and credential verification.** Verifies the credential the agent presents and resolves the principal before any authorization decision is made (detailed below). Integrates with workload identity and the authorization server. - **Authorization.** Computes the per-call decision as a deny-by-default intersection and returns a decision with obligations. The request-and-decision interface between this component and the enforcement point is standardized, and two profiles now extend it for agents: one for a denial that is requestable, routing it through approval, consent, or attestation before re-evaluation, and one that maps a tool protocol's own information model into the decision request so that a call can be authorized at parameter level. Where the call crosses an organizational boundary, authority travels by identity chaining rather than by passing the original credential through. - **Enforcement.** Applies the decision where the agent invokes a tool or reaches a resource, denying the call before it lands when the decision is deny and applying any obligations when it is allow. The enforcement point is realized at the locus the agent type dictates (an API gateway, a sidecar in a mesh, the IAM-aware runtime, or a privileged-access broker) as the agent type-to-control map sets out. Integrates with API security and the runtime. - **Tool gateway.** Fronts the tool servers an agent may call. The requirement CAI sets for it: run or mediate each tool server in its own isolated unit with no locally stored credential, authenticate the caller against the enterprise identity provider, and authorize each invocation so that the call carries a verified identity rather than a shared service credential. It also narrows what the agent can see: a role is shown the tools its work requires rather than everything a server exposes. Isolation strength and credential custody depend on the implementation and must be stated for the boundary tested. **Authentication** On every consequential call the agent presents a credential, and the enforcement point verifies it before any authorization decision is made. The credential takes one of three forms: a workload-identity certificate presented over mutual TLS, a signed token bound to the agent’s workload identity, or an OAuth access token that is audience-bound and sender-constrained (proof-of-possession or mutual-TLS binding) so a token stolen in transit cannot be replayed by another caller.[2](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn2) Verification resolves the principal: the agent identity and, in delegated mode, the delegated human and the delegation chain. Three rules make authentication a control rather than a formality: - Credentials are short-lived and exchanged at each boundary, never long-lived and never shared. - A credential is never passed through to an upstream service, because the calling component must obtain its own downstream credential, the rule that mitigates token-audience and confused-deputy risks. - Authentication is performed on every call, not once at startup, so the registered identity is reverified each time authority is exercised. **Authorization** Authentication establishes who is calling; authorization decides whether this call is allowed, and it is the objective the rest of the plane serves. The decision is computed deny-by-default as the intersection of inputs such as: - The registered access envelope - The operating mode (delegated mode bounds authority to the user’s intersected scope, autonomous mode bounds it to the agent’s own envelope and never a human’s standing entitlements) - The delegation chain (attenuated so each hop carries no more authority than the task needs) - The resource’s policy - The action’s policy - The runtime context (such as device and workload posture and anomaly signals) - The sensitivity of the data in reach. The result is not a bare allow or deny but a decision plus obligations (step up to human approval for high-risk classes, scope down to a narrower grant, log, or redact) that the enforcement point must apply. The standard decision API carries an optional context object for this; the obligation identifiers, their schemas, and the rule that an enforcement point fails closed when it cannot satisfy a mandatory obligation are CAI's deployment profile on top of the API, not semantics the API defines. The decision point and the enforcement point are deliberately separate. A policy decision point evaluates the intersection against the policy that policy administration authored; it answers a standard request-and-decision interface that any enforcement point can call; and it reads its attributes from the registry, posture management, and the request itself. Separating the two lets one decision service serve every enforcement locus so the same authority is computed identically wherever the agent acts. ### Observability Three components watch what happens and close the loop back to governance and to the runtime decision. - **Discovery and posture management.** Continuously discovers agents, including shadow ones, and assesses the posture of the agent, its runtime, and its credentials. It feeds two things: the registry, so governance reflects reality, and the runtime decision, so a failed-posture agent is denied. Integrates with posture management and the registry. - **Telemetry and attribution.** The spine: it collects every decision and action and resolves each to the responsible parties. Integrates with the observability function. - **Threat detection and response.** Detects behavioral drift and anomalies in agent action and drives the response (suspend, revoke, or contain) feeding identity threat detection and security event monitoring. The Shared Signals Framework and its Continuous Access Evaluation Profile (CAEP) are the standardized carrier for this response: a transmitter emits session-revocation, credential-change, and device-posture events that receivers consume to revoke or re-evaluate an agent’s access in near-real-time, across systems the enterprise does not own.[3](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn3) The telemetry and attribution layer is the plane’s spine, not an afterthought. It resolves every consequential action to the agent, its accountable owner, the runtime, the instance, the delegated principal, the resource, the tool, and the action. Transaction-token and trace-context propagation carry identity and authorization context across the call chain, so a single agent action correlates from host through gateway to downstream resource.[4](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn4) ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/09/figure-4.png) **Figure 4.** *Every consequential action binds eight facts and propagates them across the call chain by trace context; gold marks the accountable owner, the anchor that makes the action answerable to a person. Trace context correlates the records; it does not authenticate them. An action reaches A3 on the attribution confidence scale only when the record verifies the authorizing party and its link to the actor, not merely when the fields are present.* These categories are a loop, not a pipeline. Discovery and posture feed the registry, so what observability finds becomes what governance manages; threat detection triggers lifecycle suspension and credential revocation, so what observability detects becomes what governance acts on; and posture feeds the runtime authorization decision as context, so what observability measures shapes what the runtime allows. A plane without that feedback governs only what it knew at registration time, which, for software that changes behavior at runtime, is most of the risk left on the table. The plane resolves to one sequence repeated on every consequential call. The agent presents its credential and the enforcement point authenticates it; the decision point gathers attributes from the registry, posture, and the request and computes the deny-by-default intersection; the enforcement point applies the decision and its obligations at the tool or resource boundary; and the telemetry layer records the outcome and resolves it to the responsible parties. Authenticate, decide, enforce, attribute: every call, not once at startup. The registered envelope is the outer bound; the runtime decision is where authority is actually granted or denied. > **CAI View** — Buy the components; own the composition. Most of the plane is bought (a registry, a decision service, a gateway, a runtime, workload identity) but what the enterprise must own is the requirement and the integration: define the capability set you need, then source best-fit products and existing controls against it and integrate them. No single product is the whole plane today, because agents span endpoints, pipelines, SaaS, and multiple clouds, each with its own enforcement point. Waiting for a perfect, do-it-all platform cedes the ground while agents are already arriving. Don’t hold out for a perfect solution; hold out for a clear specification and an open integration surface. ## The IAM-Aware Agent Runtime For cloud-hosted and self-hosted agents, the most effective place to enforce access is the runtime itself. An IAM-aware agent runtime embeds identity and access control into the execution layer: it injects identity context when the agent starts, authorizes at the tool-invocation boundary, isolates each agent instance, and emits comprehensive observability signals. It collapses four controls that are otherwise bolted on (identity, authorization, isolation, and telemetry) into the layer where the agent actually runs. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/09/figure-5.png) **Figure 5.** *On every call, an isolated agent instance presents injected identity; the tool-invocation boundary computes the deny-by-default decision and allows or denies before the call lands; attribution is emitted. Gold marks the tool-boundary decision. The tool protocol's core became stateless in its July 2026 revision, so no protocol session carries authority between calls; authorizing each protected request, with any cached decision bounded by policy, is CAI's design choice on top of that.* - **Identity injection.** The runtime obtains and injects a short-lived workload identity and, where the agent acts for a user, an exchanged delegated credential, so the agent never holds a long-lived secret. - **Tool-boundary authorization.** Every tool call passes through a decision point that evaluates the computed intersection before the call reaches the tool or resource. - **Instance isolation.** Each session runs in an isolated unit, designed so that one agent (or one compromised session) cannot reach another's context, memory, or credentials; the boundary actually enforced depends on the runtime and its configuration. - **Observability emission.** The runtime emits a trace of every invocation and decision, tagged for attribution and exported to the enterprise’s monitoring stack. This pattern is visible in production cloud agent runtimes that pair session isolation with an identity service and a tool gateway, and it is reinforced protocol-side as agent-tool protocols standardize distributed trace propagation.[5](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn5)CAI’s position is to treat the runtime as a first-class enforcement point and telemetry source selected by agent type, rather than as one cloud provider’s feature. > **CAI View** — Treat the IAM-aware runtime as a first-class enforcement point and telemetry source, chosen by agent type. For cloud-hosted and self-hosted agents it is usually the right place to enforce the per-call decision and to source attribution, because it sees both the injected identity and the tool call. > **Standards Note** — Over HTTP transports, a Model Context Protocol server can act as an OAuth 2.1 resource server, validating tokens an authorization server issues; authorization is optional in the protocol, OAuth 2.1 itself remains a draft, and the authorization server may be co-hosted or separate. A server must obtain its own downstream credentials and must not pass an inbound token through, which mitigates token-audience and confused-deputy risks without removing the need for downstream grant validation. The 28 July 2026 revision adds issuer validation and issuer-bound client credentials.[6](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn6) ### Plan-for: agent-aware operating environments The migration described in the first iteration as a horizon has begun. The desktop operating system now provisions an agent with its own account, separate from the signed-in user and non-interactive, runs it in a contained session with its own desktop area, assigns it a local or directory-provisioned identity, and attributes every action from that container to it. A declarative containment layer applies process and session isolation, with hardware-backed containment named as a future option. The platform states least privilege as a rule, holds that an agent must not carry permissions exceeding the human who initiated it, and requires granted privileges to be granular, specific, and time bound. Cloud agent platforms take the same direction, organizing governance around an agent identity and a gateway that mediates the agent's traffic.[7](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn7)[8](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn8) Two qualifications travel with that, and both matter to an architect. The containment is explicitly not yet a security boundary; its own publishers say the profiles should not be treated as one. And the identity separation, which is the part that is real today, is an operating-system account rather than a portable credential, so it establishes attribution locally and does nothing on its own for a call that leaves the device. For access control the consequence is that the enforcement point multiplies rather than moves. The session boundary joins the gateway, the sidecar, and the runtime, and an architect now chooses among four rather than three. The three contracts an enterprise should hold open are unchanged and are now more achievable: identity as a standards-based workload credential rather than a platform token, authorization as an externalized decision against a standard request-and-decision interface, and attribution as standards-based trace and event propagation rather than a proprietary ledger. Plan for attestation next. The remaining ceiling on endpoint agent attribution is that a privileged administrator can alter the record that would implicate them. Remote attestation, whose architecture was published as Informational RFC 9334 in January 2023, supplies one part of the answer: evidence about the state of the environment an agent runs in, produced by the platform and evaluated by a party that does not have to trust the operator. It works alongside independently held log custody, protected signing keys, and complete capture, not instead of them. Work binding attestation evidence into workload credentials is at draft stage and moving. An enterprise does not act on this now. It avoids buying anything that would prevent acting on it later. > **Watch-Out** — An agent-aware operating environment that bundles its own identity, policy, and attribution model is a re-lock-in risk wearing a convenience label. Before delegating enforcement to the substrate, require it to speak the open identity, decision, and trace standards, so the substrate becomes one more enforcement point in the plane, not a private plane of its own. ## Standards and Specifications The protocols an agent access control plane relies on are building blocks, not governance models. They cluster into three groups: - Workload-identity and credential foundations - Authorization - Agent-to-agent and tool-access protocols The status column is the practical fact that decides what to depend on now, and it is stated as of 10 September 2026 because it moves faster than anything else in this report. Since the first iteration the composing specification has advanced three revisions and reframed itself from a proposed model to a set of best practices, the authorization profiles have been approved as working group drafts and acquired names, the tool protocol has been through its largest revision since launch, and the transaction token and workload identity drafts have all moved. **Table 3.** *The standards underpinning agent identity and access, what each provides, and status as of 10 September 2026; the status column decides what to depend on now.* | **Standard** | **What it provides** | Status (10 September 2026) | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **OAuth 2.0 / OpenID Connect** | Delegated authorization and authentication for the human and the client | Final; ubiquitous | | **OAuth 2.0 Token Exchange (RFC 8693)** | Exchange one credential for a scoped, audience-bound credential at a boundary | Final | | **Resource Indicators (RFC 8707)** | Bind a token to its intended audience to prevent misuse | Final | | **OAuth Transaction Tokens** | Propagate identity and authorization context across a call chain | IETF working group draft, revision 11, 30 July 2026, Standards Track intent, awaiting write-up | | **SPIFFE / SPIRE** | Workload identity within a trust domain (X.509 or JWT credentials) | De facto standard; production | | **WIMSE** | IETF workload-identity architecture; positions agents as workload identities | IETF working group drafts: architecture 08 and identifier 03, 6 July 2026; credentials 02, 2 July; HTTP signature 05, 20 July; proof token revised August | | **AuthZEN Authorization API 1.0** | Standard request-and-decision API between policy decision and enforcement points | Final; approved January 2026 | | **AuthZEN approval and tool-authorization profiles** | Human-in-the-loop approval; tool-call authorization for agents | Approved as official working group drafts, June 2026 | | **Model Context Protocol (authorization)** | Agent-to-tool access on an OAuth 2.1 resource-server model | Revision 2026-07-28; stateless core, issuer validation, issuer-bound client credentials, enterprise-managed authorization as a stable extension | | **Agent2Agent (A2A)** | Agent-to-agent discovery and delegation; signed agent cards | Linux Foundation; v1.0, with reported enterprise production use and 150-plus supporting organizations | | **Cross-app access / identity-assertion grant** | Provider-mediated agent app-to-app access | Shipping commercially since August 2026 on the identity-assertion grant, which is at working group draft | | **Shared Signals Framework / CAEP (OpenID)** | Event-driven sharing of session-revocation, credential-change, and device-posture signals so receivers re-evaluate or revoke agent access in near-real-time | Final 1.0 (2025); the interoperability profile is in public review to 25 September 2026, with the membership vote from 26 September to 10 October 2026 | | OAuth identity and authorization chaining | Preserve identity and authorization context across trust domains | Final 1.0 (2025); the interoperability profile is in public review to 25 September 2026, with the membership vote from 26 September to 10 October 2026IETF working group draft, revision 17, 19 July 2026, in the RFC Editor queue | > **Standards Note** — The authorization API reached Final Specification status in January 2026 and is not subject to further revision. Its two agent-era profiles were approved as official working group drafts in June 2026\. The first defines what happens when a decision is denied but requestable, giving a denial a structured path through approval, consent, attestation, or additional justification before the decision point re-evaluates. The second maps an arbitrary protocol's information model into the authorization request, with a published binding for the tool protocol so that a gateway can authorize a tool call at parameter level. Together they are the closest thing available to a standard answer for the tool boundary.[9](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn9) > **Standards Note** — WIMSE and SPIFFE supply the workload-identity root, and OAuth Token Exchange carries it across boundaries; the leading agent-authentication draft composes these into a complete identity model and, at revision 03, gives authorization guidance built on existing protocols while leaving policy expression and deployment integration to the enterprise. Identity standardized ahead of access, and the gap that remains is decision rather than mechanism. The sequencing rule is unchanged: adopt the finalized building blocks now, treat the drafts as the direction of travel, and keep the interfaces open. What has changed is where the unsettled part sits. It is no longer that agent authorization lacks a specification. The composing draft puts two things out of scope, translating a task into authorization requirements and the policy model that expresses them, and this report identifies two more that it leaves open: mid-execution confirmation and scope inheritance across delegating agents. An enterprise answers all four locally, and should expect to keep answering them for at least another cycle. ## Implementation Patterns Four patterns dominate. Each carries a trade-off and a placement rule; deeper treatment of each belongs to forthcoming CAI pattern reports rather than this capability overview. **Gateway-mediated tool access** Place a gateway between the agent and its tools that authenticates the agent, authorizes each tool call, and brokers downstream credentials. The trade-off is a clean choke point and uniform attribution against the cost of a component every call traverses. Placement rule: at the tool boundary, best for SaaS connectors and cloud-hosted agents. **Sidecar or proxy authorization** Co-locate a policy enforcement point with the agent that intercepts outbound calls and consults a policy decision point. The trade-off is enforcement close to the workload with mutual-TLS identity against the cost of mesh complexity. Placement rule: in the service mesh, best for self-hosted agents. **Short-lived credential exchange** Issue no long-lived secret. Exchange the agent's workload credential, and in delegated mode the user's context, for a short-lived, audience-bound credential at each boundary, using token exchange with resource indicators. Where the boundary is organizational, use identity chaining so the receiving domain issues its own credential rather than accepting a foreign one. Bind the credential to the sender where the resource warrants it, so a stolen token is not a usable token. **Signed-delegation chains** For delegated and multiagent action, carry a signed delegation that binds user, agent, and scope, verifiable at each hop, with attenuation so each downstream agent receives no more authority than the task needs. The trade-off is real accountability across hops against the cost of standards that are still maturing. Placement rule: at every hop of a multiagent chain.[10](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn10) ## Design Decisions **What is the agent’s identity root?** Options: inherit a human user’s credential; use a shared service account; or issue a distinct workload identity. CAI recommends a distinct workload identity per agent, with delegated user context only where a system requires it and only through short-lived exchange. **Where does the enforcement point sit?** Options: in the resource, at a gateway, in a sidecar, or in the runtime. CAI recommends choosing by type: gateway for SaaS and cloud, sidecar for a self-hosted mesh, the runtime for cloud-hosted autonomous agents, and a privileged-access broker for privileged operations. **Delegated or autonomous authority?** Options: the agent always acts as the user; the agent acts as itself; or a mix. CAI recommends declaring the operating mode at registration and authorizing each differently: delegated mode carries the user’s intersected scope, while autonomous mode carries only the agent’s own envelope and never a human’s standing entitlements. **How is the access envelope bounded?** Options: implicit, whatever the credential happens to allow; or explicit, an allow-list of tools, data, and actions. CAI recommends an explicit envelope declared at registration and enforced at runtime as the outer bound of the computed intersection. **When is human approval required?** Options: never; on every action; or on high-risk actions by policy. CAI recommends policy-gated approval for high-risk actions (financial, destructive, privileged, and bulk-data) delivered asynchronously. **Where is the delegation signed, and by whom?** Options: the platform asserts the delegation; the agent asserts it; or the delegating human signs it. CAI recommends the third. A delegation the agent asserts about itself is not independent evidence, and a delegation the platform asserts is only as good as the platform's own record. A credential signed by the delegating human, referencing both the human's identity and the agent's, carrying scope, expiry, and a revocation endpoint, is verifiable by a party that trusts the issuer's key binding and consent capture rather than the agent or its operator. That is the difference between relying on apparent authority and being able to demonstrate actual authority afterward; it is not automatic legal non-repudiation, which depends on the trust model around the key. **Can the model see the agent's credential?** Options: the credential is available in the model's context; or it is held outside the model and attached by the runtime at call time. CAI recommends the second without exception. A credential inside the context window is a credential one prompt injection away from exfiltration, and the specification effort now states the same rule. This is the single cheapest control decision in the report and, in CAI's experience, the one most often got wrong in early builds. > **Watch-Out** — Per-action human consent at machine speed collapses into consent fatigue: reviewers approve reflexively, and the control becomes theater. Gate high-risk actions by policy and route approvals asynchronously, for example through a backchannel approval flow, rather than prompting a human on every call. ## Market Context The market has resolved into a shape a buyer can act on, which it had not when this report was first written. Two routes are now distinguishable. The platform-native route suits an estate already committed to one vendor's directory and device management, and delivers agent identity, conditional policy for agents, and governance as extensions of controls the enterprise already operates. The identity-layer route suits a multi-vendor estate, and delivers agent registration, discovery of unregistered agents, named human owners, and short-lived governed tokens at the identity provider rather than inside any one application.[11](file:///Users/hofarahm/Library/CloudStorage/OneDrive-ControlArchitectureInstitute/Documents/5-Products/BodyOfKnowledge/1-Production/2-Ghost%20version/1.1-AI%20Agent%20Identity%20and%20Access/ai-agent-identity-and-access.html#fn11) Both routes shipped material capability during 2026, most of it before this edition's interval, and the direction is the same in each: the authorization side of the agent problem is being productized, not merely described. Cloud providers continue to bundle identity, a tool gateway, and observability into agent runtimes, and one has added a hosted consent portal for approving access on a user's behalf. This edition covers a sub-segment the first did not, though it predates it: agentic commerce, whose leading protocol was announced in September 2025 and where card networks now run pilots. Where an agent transacts, the authorization artifact carries the human's intent forward to the point of settlement rather than carrying permission forward to the point of access; signed mandates are one form of that evidence, alongside grants, consent records, and payment network records. The structural point survives the protocol contest: settlement needs evidence of what was authorized, which is the same property this report's attribution model demands, arrived at from the opposite direction. Widely circulated figures on the ratio of machine to human identities, on over-permissioned agents, and on the share of organizations applying equivalent controls to agents come from vendor-commissioned surveys. They are directionally consistent and none is used here as sole support for a claim. The honest read for an enterprise is unchanged and now better evidenced. These are capabilities to integrate, not a replacement for the plane. No vendor supplies the composition, and the enterprise remains the accountable integrator of whatever it assembles. ## Metrics and Success Criteria Six metrics measure whether the plane is working. They are deliberately about access and attribution, not about how many agents exist. **Table 4.** *Six operating metrics for the access control plane: what each measures and the target signal that shows it is working.* | **Metric** | **What it measures** | **Target signal** | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Registered-and-attributed coverage** | Share of active agents with a distinct identity, a named owner, and a recorded type, and the attribution confidence level their actions reach | Approaching all, with no shadow agents on critical systems and high-impact actions reaching the delegation-context level of attribution | | **Short-lived credential share** | Share of agent credentials that are short-lived and exchanged, not static | Rising to all; static secrets retired | | **Runtime-authorized call share** | Share of consequential calls authorized at runtime, not only at startup | Rising; high-risk types first | | **Inherited-credential debt** | Count of agents still using inherited user credentials | Declining to zero on a dated plan | | **High-risk actions gated** | Share of defined high-risk actions requiring policy-gated approval | All defined high-risk classes | | **Mean time to revoke** | Time to suspend an agent and its credentials on owner or risk change | Minutes, not days | ## Common Anti-Patterns > **Watch-Out** — User-credential inheritance and human impersonation collapse attribution and hand the agent the union of a human’s standing entitlements. After the fact, no one can tell whether the human or the agent acted, and the agent could reach everything the human could. This is the single highest-yield anti-pattern to eliminate. **Table 5.** *Common anti-patterns, the symptom that surfaces each, and the corrective control.* | **Anti-pattern** | **Symptom** | **Correction** | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Inherited user credentials** | Agents authenticate with a person’s token or service account; logs show the human, not the agent | Distinct workload identity per agent; delegated mode only through short-lived exchange | | **One control stack for all agents** | A single policy applied to assistants and privileged-operations agents alike | Type-aware control selection; prioritize high-risk types | | **Authenticate-once** | The agent authenticates at startup and acts freely thereafter | Runtime authorization on every consequential call | | **Owner entitlements as agent authority** | The agent can do whatever its owner can do | Bound the agent by its declared envelope and the computed intersection, not the owner’s standing access | | **Unattributable action** | An agent action cannot be resolved to agent, owner, runtime, instance, principal, resource, tool, and action | Attribution as a first-class requirement, carried by transaction-token and trace-context propagation | | **Static long-lived secrets** | API keys and tokens that outlive the task | Short-lived, audience-bound, exchanged credentials, with vaulting and rotation | | Prompt-level constraint treated as a control | The scope of an agent's authority exists only in its instructions, and a successful injection widens it | Express the envelope as structured resource permissions enforced outside the model; treat natural-language scoping as an input to be translated and reviewed | | Agent running as the signed-in user | Agent activity is indistinguishable from the person's own activity in endpoint and application logs | Run the agent under its own account with its own identity, so that every action is separable and revocable without touching the person's access | ## Maturity Progression Maturity is stated across four dimensions using the operability vocabulary the Foundation Reports share, so that an agent program can be placed beside the governance, runtime, and observability profiles an enterprise already holds. The crosswalk is direct: columns 1 to 5 correspond to bands 1 to 5 of the G, R, and O scales. Band 0, absent, is omitted because it has no entry condition to state. The entry conditions themselves are specific to agent programs and are CAI's; they are not the Foundation Reports' conditions restated. A program sits at the level whose condition it currently meets in production, not the level its tooling would permit. **Table 6.** *The maturity model across four dimensions, stated as entry conditions on the shared operability vocabulary and read as a self-assessment.* | **Dimension** | 1 Ad hoc | 2 Repeatable | 3 Managed | 4 Measured | **5 Adaptive** | | ------------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **Discovery & classification** | No inventory. Shadow agents are discovered by accident, if at all. | A list of sanctioned agents exists and is updated by hand. | Type and a named human owner are mandatory at registration, and registration is enforced rather than requested. | Coverage and shadow-agent counts are measured against a target and reported. | Discovery drives control automatically: a newly found agent is tiered, scoped, and either registered or blocked without a ticket. | | **Identity & credentials** | Agents authenticate with inherited or shared credentials. | Each agent has a distinct identity; some static secrets remain. | Distinct workload identities, short-lived and exchanged at each boundary. | Standing secrets are counted and trending to zero against a dated plan. | Credentials adapt to risk: audience, lifetime, and binding tighten on posture or anomaly signals without human action. | | **Runtime enforcement** | Authentication happens once at startup and authority is not re-checked. | A gateway authenticates agents for some applications. | High-risk types are authorized per call against a computed intersection. | Per-call authorization coverage is measured by type and reported. | The intersection tightens itself: policy responds to drift and posture, and high-risk actions escalate to a human automatically. | | **Attribution & observability** | Logs are per application and agent action is indistinguishable from human action. | Agent actions are logged and separable. | High-impact actions carry the eight facts and a stated attribution confidence level. | Attribution confidence is scored per action class and tracked as a metric. | Attribution feeds enforcement: drift detection changes what the agent is allowed to do next, not just what is reported. | ## Audience Callouts - **IAM leader.** Fund the plane as an orchestration program, not a product purchase. Set the dated plan to retire inherited credentials and to gate high-risk actions, and hold the metrics above as the measure of progress. - **Identity or security architect.** Place enforcement by agent type; make type, owner, and access envelope mandatory at registration; and design attribution in from the start rather than bolting it on after an incident. - **Platform engineering and DevOps.** Wire short-lived credential exchange and the IAM-aware runtime. Treat the coding agent’s pipeline credentials as ephemeral and its production actions as approval-gated. - **Security operations.** Instrument attribution end to end, build detection on agent behavioral drift, and revoke on owner or risk change in minutes, not days, propagated as shared signals (SSF/CAEP) to every integrated receiver, with end-to-end revocation latency measured and unsupported resources documented. ## Conclusion The agentic enterprise has solved the easier half of the problem first. Who an agent is has converged on a shared workload-identity foundation, and in the interval since this report was first written the mechanism for what an agent may do has converged too: tokens, exchanges, chaining, and audit obligations are all specified now. What remains unsettled is the decision rather than the mechanism; the draft that composes everything else puts two of those questions out of scope itself, and this report identifies two more. That is a better position than the field was in, and it is not the same as being finished. The capability the enterprise must build is therefore an agent access control plane: registry, identity issuance, policy administration, lifecycle, per-call authorization, enforcement, and attribution, composed from controls the enterprise mostly already operates. What changed in this interval is that more of that plane can now be bought rather than built, and that the enforcement point has multiplied rather than settled. Neither change removes the composition work, and the composition is what the enterprise remains accountable for. ## Acronym Key and Glossary | **Term / Acronym** | **Expansion or definition** | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **A2A** | Agent2Agent protocol, an open standard for agent-to-agent discovery and delegation | | **Access envelope** | The declared maximum scope of tools, data, and actions an agent may ever reach | | **Agent access control plane** | The orchestrated set of registry, issuance, decision-and-enforcement, lifecycle, and attribution controls that govern agent access | | **Attribution** | Resolving an agent action to the agent, owner, runtime, instance, delegated principal, resource, tool, and action | | **Autonomous / delegated mode** | Whether an agent acts as itself or on behalf of a specific user | | **CI/CD** | Continuous integration and continuous delivery | | **IAM** | Identity and access management | | **IAM-aware runtime** | An execution environment that injects identity, authorizes at the tool boundary, isolates instances, and emits observability | | **IdP** | Identity provider | | **Machine IAM** | CAI’s umbrella term for IAM applied to devices, workloads, AI agents, and other machine subjects | | **MCP** | Model Context Protocol, a standard for agent-to-tool access | | **OAuth / OIDC** | Open standards for delegated authorization and for authentication | | **PAM** | Privileged access management | | **PDP / PEP** | Policy decision point and policy enforcement point | | **Runtime authorization** | Authorizing each consequential call in the moment, rather than once at startup | | **SaaS** | Software as a service | | **SIEM** | Security information and event management | | **SPIFFE** | Secure Production Identity Framework for Everyone, a workload-identity standard | | **WIMSE** | Workload Identity in Multi-System Environments, an IETF workload-identity effort | | **Workload identity** | A machine identity representing a software workload, authenticated with credentials that should be short-lived and automatically rotated | ## Evidence ### Standards and specifications referenced OAuth 2.0 Token Exchange (RFC 8693); Resource Indicators for OAuth 2.0 (RFC 8707); mutual-TLS and proof-of-possession token binding (RFC 8705, RFC 9449); OAuth Transaction Tokens and identity chaining, both current IETF drafts; the WIMSE architecture, identifier, credential, and proof-token drafts; SPIFFE; the AuthZEN Authorization API 1.0 Final Specification and its two agent-era working group profiles; the Model Context Protocol authorization specification at its 28 July 2026 revision; the Agent2Agent protocol; the Shared Signals Framework and CAEP 1.0; the Remote Attestation Procedures architecture (RFC 9334); and NIST SP 800-207. ### Selected research and practitioner sources South et al., authenticated delegation for AI agents (2025), cited as an unrefereed preprint; the OWASP Top 10 for Agentic Applications and the OWASP Non-Human Identity Top 10; Cloud Security Alliance threat-modeling and agentic trust material; the NIST AI Agent Standards Initiative and the associated concept paper on agent identity and authorization, both at pre-guidance stage; and vendor platform documentation read for capability rather than adoption. ### Methodology This report pairs CAI's control-architecture frame with a comprehensive scan across academic, standards, vendor, practitioner, and market sources. For this iteration, citations carried forward from the first edition were re-checked at their issuing bodies where reachable, specification revisions and dates are stated as of 10 September 2026, and vendor claims are attributed to vendor documentation. Claims that could not be reached at a primary source were removed rather than carried forward, including two widely repeated statements about forthcoming national guidance. Vendor material is read as evidence of what has been built and claimed, never as evidence of adoption. Survey figures are used as attributed directional ranges and never as sole support. One research source is a preprint and is identified as such. A claim-to-source register accompanies the internal edition. ## Related Reading - [IAM-RD-01](https://research.controlarch.org/identity-and-access-management/) for the Identity and Access Management Root Document, whose control categories this report inherits. - [IAM-F-GOV-01](https://research.controlarch.org/identity-and-access-governance-controls/) for the Identity and Access Governance Controls Foundation Report. - [IAM-F-RTM-01](https://research.controlarch.org/identity-and-access-runtime-controls/) for the Identity and Access Runtime Controls Foundation Report. - [IAM-F-OBS-01](https://research.controlarch.org/identity-and-access-observability-controls/) for the Identity and Access Observability Controls Foundation Report, whose attribution confidence scale is the instrument behind the attribution model in Figure 4 and the observability dimension in Table 6. - [IAM-F-SUB-01](https://research.controlarch.org/identity-and-access-substrate/) for the Identity and Access Substrate Foundation Report, whose binding confidence scale states the strength behind each identity root in Table 2. ## Notes 1. AI Agent Authentication and Authorization, IETF Internet-Draft draft-klrc-aiagent-auth-03, 6 July 2026, intended status Informational, expires 7 January 2027\. Composes WIMSE, SPIFFE, and the OAuth 2.0 family rather than defining new protocols. Revision 03 carries a complete authorization treatment and a MUST-level audit minimum, and declines to standardize the policy model. 2. Sender-constrained, proof-of-possession access tokens bind a token to the client that holds it: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (RFC 8705) and OAuth 2.0 Demonstrating Proof of Possession, DPoP (RFC 9449). datatracker.ietf.org. 3. OpenID Shared Signals Framework (SSF) 1.0 and Continuous Access Evaluation Profile (CAEP) 1.0 were approved as Final Specifications in 2025; events are carried as Security Event Tokens (RFC 8417), and CAEP explicitly scopes robotic as well as human subjects. The CAEP Interoperability Profile remains a draft. Okta’s Universal Logout and Microsoft Entra’s continuous access evaluation build on this framework. openid.net. 4. Transaction Tokens, IETF Internet-Draft draft-ietf-oauth-transaction-tokens-11, 30 July 2026, propagate user identity, workload identity, and authorization context across a call chain within a trust domain; OAuth Identity and Authorization Chaining, draft-ietf-oauth-identity-chaining-17, 19 July 2026, carries it across trust domains. The Model Context Protocol revision of 28 July 2026 documents W3C Trace Context propagation for distributed tracing. datatracker.ietf.org; modelcontextprotocol.io. 5. Amazon Bedrock AgentCore (generally available October 2025) pairs a session-isolated runtime with an identity service performing token exchange, a tool gateway enforcing authorization, and OpenTelemetry observability; read for capability, not adoption. aws.amazon.com/bedrock/agentcore. 6. Model Context Protocol, Authorization specification, revision 2026-07-28, superseding 2025-06-18 and 2025-11-25: over HTTP transports an MCP server may act as an OAuth 2.1 resource server; RFC 9728 Protected Resource Metadata and RFC 8707 Resource Indicators apply; issuer validation and issuer-bound client credentials are added; token pass-through to upstream services is prohibited. modelcontextprotocol.io. 7. At Build 2026 (June 2026) Microsoft positioned Windows as an operating system for AI agents: the Microsoft Execution Containers (MXC) SDK provides an OS-level, policy-driven execution and containment layer that enforces agent access at runtime (early preview); Windows 365 for Agents (generally available) runs any agent in an isolated, policy-governed Cloud PC; and the Agent 365 registry surfaces unmanaged local agents discovered by Microsoft Defender, Entra, and Intune. Microsoft Security Blog and Windows Developer Blog. Read for capability and direction, not adoption. 8. Google’s Gemini Enterprise Agent Platform provides a managed Agent Runtime in which agents run in an isolated sandbox, with Agent Identity for granular agent permissions, an Agent Gateway that enforces runtime policy and threat protection, and OpenTelemetry-based tracing; Android has been positioned as an agent-orchestration layer above installed apps. Google Cloud documentation, 2026\. Read for capability and direction, not adoption. 9. OpenID Foundation, AuthZEN Authorization API 1.0, Final Specification dated 11 January 2026 with approval announced 12 January 2026, separating policy decision and enforcement points for per-request decisions and aligned with NIST SP 800-207\. The Access Request and Approval Profile and the COAZ framework with its Model Context Protocol binding were approved as Working Group Drafts in June 2026\. openid.net. 10. T. South et al., “Authenticated Delegation and Authorized AI Agents,” arXiv:2501.09674 (2025), extends OAuth 2.0 and OpenID Connect with user-identity, agent-identity, and signed delegation tokens that bind user, agent, and scope to address confused-deputy and accountability. 11. Microsoft Entra Agent ID reached general availability in April 2026 with agent blueprints, per-instance agent identities, and accountable sponsors; Conditional Access for agents is generally available for delegated-access agents, with own-access agents in preview at the cutoff, and entitlement features carry their own status (Microsoft Learn). Okta for AI Agents reached general availability on 30 April 2026, and Agent SSO on 24 August 2026 (Okta). Platform availability does not establish the availability of every listed feature. ## Disclaimer © 2026 Control Architecture Institute Inc. All rights reserved. Control Architecture Institute Inc. (Control Architecture Institute or CAI) is a research institute. The Library, of which this report is a part, consists of the opinions of CAI's research team, which should not be construed as statements of fact. While the information contained in this publication has been obtained from sources believed to be reliable, CAI disclaims all warranties as to the accuracy, completeness, or adequacy of such information. Although CAI research may address legal and financial issues, CAI does not provide legal or financial advice and its research should not be construed or used as such. Your access and use of this publication are governed by CAI's terms of use. CAI prides itself on its independence and objectivity. Its research is produced independently by its research team without input or influence from any third party. This publication may not be reproduced or distributed in any form without CAI's prior written permission. CAI research may not be used as input into, or for the training or development of, generative artificial intelligence, machine learning, algorithms, software, or related technologies.