![](\"/assets/CSA-logo-RGB-a0a3855889ad836fa585d60f6caf8d619f241d43904c304c2f64284127fe9bf3.svg\"){kind=logo}
![](\"/assets/social-share/li-icon-09fa81c48d4329077ed9608610eb94677c1598373b57333973e931874e641c30.svg\"){kind=icon}
![](\"/assets/social-share/x-icon-d5737d8484c6d1c6b2c18ad43c18037db1925464c40f14899cdfdb82fe33a861.svg\"){kind=icon}
![](\"/assets/social-share/fb-icon-c0307da13019b8e4ef32e5f2e7039eac01c272bcbc2c3a7aad4ba033c0a27153.svg\"){kind=icon}
![](\"/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NjE5MzMsInB1ciI6ImJsb2JfaWQifX0=--7c54f8357770cfda3158913cb5cd655e1689dee7/Tuhin%20Headshot.jpg\")
![](\"/assets/social-share/yt-icon-ade320bf2b6ffeae084895dac740b736c7dda9f181a871260f83da2462465ab3.svg\"){kind=icon}
![](\"https://cloudsecurityalliance.org/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NjU3MTQsInB1ciI6ImJsb2JfaWQifX0=--9d4c1be0bdad13586265c81a967a4d7abd584d98/CSAI%20-%20Latest%20News%20(3)%20(1).jpg\")
![](\"https://cloudsecurityalliance.org/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NjY4MTMsInB1ciI6ImJsb2JfaWQifX0=--be1514d1ceff85e8ef76733df3072f919e4351d4/AISMM%20Bundle%20-%20Latest%20News.png\")
![](\"https://cloudsecurityalliance.org/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NjY4MTEsInB1ciI6ImJsb2JfaWQifX0=--c0910e6aac845ea0db480cde21e4cb07adb646cb/TAISE%20Certificate%20Launch%20-%20Latest%20News.png\")
![](\"https://cloudsecurityalliance.org/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6Njc2MzAsInB1ciI6ImJsb2JfaWQifX0=--b52ef7096980e87b5ffd19f7fb02e35f36930dda/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJwbmciLCJyZXNpemVfdG9fbGltaXQiOlsxMzIsOTldfSwicHVyIjoidmFyaWF0aW9uIn19--1c3631b2c4e5d2a9f120d3fbdaa1517964193ad5/ZT%20Program%20Guidance%20-%20Latest%20News.png\")
![](\"https://cloudsecurityalliance.org/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6Njc2MDcsInB1ciI6ImJsb2JfaWQifX0=--af5184f16012f5adbca38e45144703fdee6caa9c/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJwbmciLCJyZXNpemVfdG9fbGltaXQiOlsxMzIsOTldfSwicHVyIjoidmFyaWF0aW9uIn19--1c3631b2c4e5d2a9f120d3fbdaa1517964193ad5/Pitchapalooza%20generic%20Latest%20News.png\")
![](\"https://cloudsecurityalliance.org/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6Njc0NjgsInB1ciI6ImJsb2JfaWQifX0=--dbd26c121d0dc29eb77f0c4feb91635cdeebd75f/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJwbmciLCJyZXNpemVfdG9fbGltaXQiOlsxMzIsOTldfSwicHVyIjoidmFyaWF0aW9uIn19--1c3631b2c4e5d2a9f120d3fbdaa1517964193ad5/Webinar%20-%20CloudBytes%20800x600.png\")
![](\"/assets/arrows/arrow-white-right-53b5245d5c2df81c153080d64b7cbaeddc14e5b9e8f582d1400b7be8edda4db2.svg\"){kind=icon}
![](\"/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NDgwODMsInB1ciI6ImJsb2JfaWQifX0=--857fe61be6b1ca089416e89ecfe802da0b03a066/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJqcGVnIiwiYXV0b19vcmllbnQiOnRydWUsInJvdGF0ZSI6MCwiZ3Jhdml0eSI6ImNlbnRlciIsInJlc2l6ZSI6IjQwMHg2MDBeIiwiYmFja2dyb3VuZCI6Im5vbmUifSwicHVyIjoidmFyaWF0aW9uIn19--f4d2a3313fd645de5a58f33b6728c40f4d1c31a6/Untitled%20(2).jpeg\")
![](\"/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NTY3NzEsInB1ciI6ImJsb2JfaWQifX0=--61e5d276d1abd2cb9f1be9329b98a9aea4b2ea74/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJqcGVnIiwiYXV0b19vcmllbnQiOnRydWUsInJvdGF0ZSI6MCwiZ3Jhdml0eSI6ImNlbnRlciIsInJlc2l6ZSI6IjQwMHg2MDBeIiwiYmFja2dyb3VuZCI6Im5vbmUifSwicHVyIjoidmFyaWF0aW9uIn19--f4d2a3313fd645de5a58f33b6728c40f4d1c31a6/Untitled%20(39).jpeg\")
![](\"/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NTI5NSwicHVyIjoiYmxvYl9pZCJ9fQ==--393265c5b94b6c994ed3b25433cbb6809b7ef575/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJqcGciLCJhdXRvX29yaWVudCI6dHJ1ZSwicm90YXRlIjowLCJncmF2aXR5IjoiY2VudGVyIiwicmVzaXplIjoiNDAweDYwMF4iLCJiYWNrZ3JvdW5kIjoibm9uZSJ9LCJwdXIiOiJ2YXJpYXRpb24ifX0=--310876cbbca9fc5c5307dd52ccf006503fd7e296/How-to-Fix-Vulnerabilities-Regularly-and-Block-DDoS-Attacks.jpg\")
![](\"/rails/active_storage/representations/redirect/eyJfcmFpbHMiOnsiZGF0YSI6NjI5NzUsInB1ciI6ImJsb2JfaWQifX0=--51e582be3c3a4775b93a5961a83769e24b680b7a/eyJfcmFpbHMiOnsiZGF0YSI6eyJmb3JtYXQiOiJqcGVnIiwiYXV0b19vcmllbnQiOnRydWUsInJvdGF0ZSI6MCwiZ3Jhdml0eSI6ImNlbnRlciIsInJlc2l6ZSI6IjQwMHg2MDBeIiwiYmFja2dyb3VuZCI6Im5vbmUifSwicHVyIjoidmFyaWF0aW9uIn19--f4d2a3313fd645de5a58f33b6728c40f4d1c31a6/Untitled%20-%202026-04-21T160343.576.jpeg\")
![\"csa-labs-logo\"](\"https://i0.wp.com/labs.cloudsecurityalliance.org/wp-content/uploads/2025/09/ioHKw52c_ry9fIMSLVURfg88hkEceIuhTlyzzPQ7Zus.png?fit=800%2C176&ssl=1\")
White Paper | 2026-03-27 | Status: draft
\nAgent Identity Governance Framework
\nExecutive Summary
\nEnterprise adoption of AI agents has introduced a class of identity that does not fit neatly within the assumptions of traditional identity and access management. Human users authenticate interactively, exercise judgment, hold organizational accountability, and can be terminated or suspended with a single administrative action. AI agents do none of these things in the same way. They authenticate programmatically, execute instructions at machine speed, operate across trust boundaries that span organizational perimeters, spawn child agents dynamically, and persist long after the business context that originally justified their privileges has changed. The gap between what legacy IAM systems were designed to govern and what enterprise AI deployments actually require has become one of the most consequential security challenges of 2026.
\nThe scale of this challenge is no longer theoretical. Research from the Cloud Security Alliance’s “State of Non-Human Identity and AI Security” survey found that non-human identities — a category that includes AI agents, service accounts, API keys, OAuth tokens, and workload identities — outnumber human identities by more than 90 to 1 in many organizations, with some enterprises reporting ratios as high as 144 to 1 [1]. In the year from 2024 to 2025 alone, NHIs grew by 44 percent across measured enterprise environments [2]. Meanwhile, 92 percent of survey respondents reported that their legacy IAM solutions cannot effectively manage the risks associated with AI and NHIs, and 78 percent acknowledged the absence of formally documented policies for creating or removing AI agent identities [1]. The most troubling finding may be the accountability gap: only 28 percent of organizations can trace AI agent actions back to a human sponsor across all environments [3].
\nThis whitepaper presents the Agent Identity Governance Framework (AIGF), a structured approach to lifecycle management for non-human AI identities in enterprise agent ecosystems. The AIGF addresses five distinct categories of AI agent identity, each with its own credential management requirements, privilege model, monitoring obligations, and decommissioning process. It evaluates how existing open standards — OAuth 2.0 and OpenID Connect, SPIFFE/SPIRE, and SCIM — can be applied to agent identity governance, identifies the gaps these standards exhibit in agentic contexts, and specifies extensions or compensating controls required to close those gaps. The framework’s centerpiece is a just-in-time access model that replaces standing agent privileges with intent-declared, time-bound, scope-limited grants, fundamentally changing the relationship between agent execution and privilege.
\nThe AIGF is designed to be immediately actionable. A tiered implementation roadmap addresses organizations at three distinct maturity levels — those still conducting basic inventory, those with partial automation but inconsistent lifecycle controls, and those ready to implement full just-in-time orchestration. Control objectives are mapped to the CSA AI Controls Matrix (AICM) IAM domain, OWASP Agentic Security Initiative ASI03 (Identity and Privilege Abuse), the CSA MAESTRO threat modeling framework’s relevant layers, and the NIST AI Risk Management Framework’s Govern and Manage functions. The goal throughout is to enable organizations to derive the operational benefits of AI agents without accepting the identity governance risks that current deployment patterns entail.
\n\n
1. Introduction: The Agent Identity Crisis
\nThe history of enterprise identity management has been shaped by a consistent architectural assumption: that the primary subject of access control is a human being. This assumption drove the design of directory services, LDAP schemas, SAML assertions, OAuth flows, and role-based access control models. Even service accounts — long recognized as a governance challenge — were designed with human oversight in mind: they existed to enable a known piece of software to authenticate to a known set of resources, on behalf of an owner who could be identified in the directory and held accountable. The human-centric model bent to accommodate non-human actors, but it never abandoned its foundational premise.
\nThe emergence of autonomous AI agents has broken that premise entirely. An AI agent is not a piece of software executing a deterministic script. It is a goal-directed system that plans, selects tools, invokes external services, generates sub-tasks, and delegates authority to other agents — all in real time, without step-by-step human direction. When an orchestrating agent spawns five ephemeral sub-agents to perform parallel research tasks, each of those sub-agents requires authenticated access to tools, data sources, and APIs. They need credentials. They need scope definitions. They need to be tracked. And when their task completes, they need to be terminated and their access revoked. None of this happens automatically under legacy IAM architectures, and most organizations have no systematic process to make it happen at all.
\nThe consequences of this governance vacuum are already visible in incident data. Oasis Security’s research found that nearly 50 percent of organizations had experienced NHI-related compromises, with successful cyberattacks resulting from those compromises in 66 percent of cases [2]. The NHIMG’s 2025 State of Non-Human Identities and Secrets report documented that 73 percent of secrets held by NHIs carry excessive permissions, and 1 in 20 AWS machine identities has full administrative privileges [4]. When an AI agent inherits or acquires such a credential, the potential blast radius of a compromise extends far beyond what the agent’s original purpose justified. OWASP’s Agentic Security Initiative formally classifies this threat as ASI03: Identity and Privilege Abuse, recognizing that an agent’s operational identity is in practice an aggregation point for every credential, token, and delegated permission it has been granted [5].
\nThe urgency of the problem is compounded by the speed at which it is growing. Gartner had previously estimated the human-to-NHI ratio at approximately 45:1; more recent measurement from Oasis Security’s 2025 research placed the ratio at 144:1, up from 92:1 in the first half of 2024 [2]. NIST, in a significant signal of regulatory intent, issued a Request for Information on AI Agent Security in early 2026 and published a concept paper on AI Agent Identity and Authorization, indicating that federal frameworks are beginning to close the gap between policy intent and agentic deployment reality [6]. The window for voluntary, proactive governance is narrowing. Organizations that establish structured agent identity governance now will be substantially better positioned than those that wait for regulatory mandates, incident-driven response, or both.
\nThe Agent Identity Governance Framework presented in this document takes the position that AI agents must be treated as first-class identity subjects: provisioned with intention, authenticated cryptographically, authorized just-in-time, continuously monitored, and decommissioned completely. This is not a philosophical stance about AI personhood — it is a practical security requirement. Agents that hold credentials are attack surfaces. Agents that lack lifecycle governance are standing risks. The framework that follows is designed to address both.
\n\n
2. The Current State of Agent Identity Governance
\nUnderstanding the current state of agent identity governance requires confronting an uncomfortable paradox: the organizations most aggressively adopting AI agent technology are precisely the organizations whose IAM infrastructure is least prepared to govern the identities those agents require. This is not primarily a technology failure. The underlying cryptographic primitives, token formats, and protocol specifications needed to manage agent identities either already exist or are close to completion. The failure is one of process, policy, and organizational prioritization — a governance deficit that has allowed agent deployment to run far ahead of agent oversight.
\nThe Cloud Security Alliance’s survey on non-human identity and AI security, conducted across 383 IT and security professionals in August and September 2025, provides the most comprehensive empirical picture of this deficit available [1]. Its findings document a consistent pattern of unmanaged growth combined with inadequate visibility. The 78 percent of organizations without documented policies for creating or removing AI identities are not simply being careless — they are operating in an environment where the volume and velocity of agent provisioning has outpaced any governance framework they might have attempted to apply. When a development team can instantiate a new AI agent in minutes using a cloud provider’s API, and when that agent can begin accumulating credentials and permissions immediately, the traditional change-control processes that govern human identity provisioning simply do not scale.
\nThe ownership problem compounds the policy gap. Fifty-one percent of the organizations surveyed reported no clear ownership or accountability for their AI and NHI populations [1]. This creates a situation where no one is responsible for reviewing or revoking an agent’s privileges when its purpose changes, and no one is notified when it begins behaving outside its original scope. The accountability chain that makes human IAM governable — where every account has an owner who can be contacted, questioned, or terminated — does not exist for most AI agents in production today. The CSA’s “Securing Autonomous AI Agents” survey, conducted in collaboration with Strata Identity and published in early 2026, found that only 28 percent of organizations can trace agent actions back to a human sponsor across all environments, meaning that in nearly three-quarters of enterprises, AI agents are effectively operating without an accountable principal [3].
\nThe credential practices underlying most agent deployments reflect this governance vacuum directly. Forty-four percent of organizations in the CSA NHI survey reported relying on static API keys as the primary credential mechanism for their NHI populations [1]. Static API keys are problematic for human-managed services; they are far more dangerous for AI agents, because agents can autonomously use those keys to invoke additional APIs, spawn additional agents, and accumulate additional context in ways that a static service account cannot. An API key granted to a research agent may be legitimately used to query a knowledge base and then, through a chain of tool invocations prompted by retrieved content, used to access a file system, send an email, or make an external API call — all with the same credential and without any human visibility into the escalating scope of the original access grant.
\nThe legacy IAM confidence gap confirms that practitioners recognize these limitations. The finding that 92 percent of security professionals lack confidence in their existing IAM solutions’ ability to manage NHI risks is not a condemnation of those solutions on their own terms [1]. Active Directory, Okta, and similar platforms were not designed for the agent use case. They were designed to manage human users and relatively static service accounts at volumes measured in the thousands, not to govern dynamically spawning AI agent populations at volumes measured in the hundreds of thousands or millions. The current state of agent identity governance is therefore best described as an improvised extension of human-centric systems into a domain those systems were never designed to address — with the predictable result that critical governance functions remain unperformed.
\n\n
3. Five Agent Identity Types
\nThe absence of a coherent taxonomy for AI agent identities is itself a root cause of governance failures. When an organization cannot articulate the differences between a copilot assistant that a human supervises in real time and an autonomous background agent running scheduled tasks, it cannot design appropriate credential lifecycles, access controls, or monitoring policies for either. The Agent Identity Governance Framework defines five distinct agent identity types based on their autonomy level, operational persistence, trust relationship scope, and multi-tenancy characteristics. Each type requires a distinct governance profile.
\n3.1 Copilot Identities
\nCopilot identities represent the class of AI agent that operates as an interactive assistant under continuous human supervision. A copilot agent executes within a user’s authenticated session: it reads from context that the user has explicitly provided, invokes tools that the user has pre-authorized, and returns results that the user reviews before any consequential action is taken. The canonical examples are coding assistants, document editing copilots, and customer service augmentation tools — systems designed to accelerate human work rather than replace human judgment.
\nBecause the copilot’s operational context is anchored to an active human session, credential management can leverage that session directly. The preferred model is session-bound credential delegation: the copilot receives a downscoped token derived from the user’s authenticated identity at session initiation, valid only for the duration of the session and constrained to the specific tool permissions the user has pre-authorized. This token should not persist beyond the session boundary; when the user’s session terminates, the copilot’s credential should be revoked automatically. The key governance requirement is that the copilot must never be provisioned with standing credentials that survive its user’s session. If a copilot is given a persistent API key “for convenience,” it has effectively been promoted to an autonomous identity without the governance controls that classification requires.
\nThe lifecycle events for copilot identities are relatively simple because they are structurally coupled to human lifecycle events. A copilot identity is created when an authorized user authenticates and invokes the copilot capability; it is active for the duration of that session; it is suspended when the session is inactive; and it is terminated when the session ends. The monitoring obligation for copilot identities is primarily anomaly detection within session scope: watching for tool invocations that deviate from the user’s stated intent, access to resources outside the session’s established scope, and unusual data volumes or exfiltration patterns. Decommissioning a copilot is operationally equivalent to decommissioning the user’s access to the copilot capability — it requires no separate credential revocation process if session-bound delegation has been correctly implemented.
\n3.2 Autonomous Agent Identities
\nAutonomous agent identities represent the most demanding governance challenge in the AIGF taxonomy. These are agents that operate independently of any active human session: they run scheduled tasks, respond to events, manage workflows, or conduct research on behalf of a human or organizational principal who may not be actively engaged with the agent at the time of execution. The autonomous agent’s execution is temporally decoupled from its human sponsor — the person who authorized it may have done so days or weeks earlier, through a policy document or a configuration file, and may not know what the agent is doing at any given moment.
\nThis temporal decoupling means that autonomous agents cannot rely on session-bound delegation for their credentials. They require durable, independently provisioned identities that survive across multiple execution cycles. However, durable does not mean static. The governance requirement for autonomous agent identities is that durable credentials must be short-lived and automatically rotated on a schedule that is aggressive relative to the sensitivity of the resources they access. An autonomous agent performing low-risk data aggregation might hold credentials valid for 24 hours; an autonomous agent with write access to production databases or the ability to invoke external payment APIs should hold credentials valid for no more than the duration of a single planned execution window, with re-attestation required before each new window. The specific rotation interval is a function of the agent’s access scope and the criticality of the systems it touches, but the principle is absolute: autonomous agent credentials must expire.
\nThe lifecycle governance for autonomous agents requires particular attention to three events that are poorly managed under legacy IAM. The first is scope creep during operation: as an autonomous agent encounters new tasks or invokes capabilities that retrieve new context, it may develop a rationale for accessing resources outside its original scope. The governance control is strict tooling perimeters — the agent’s identity should be associated with a capability declaration specifying the complete set of tools, APIs, and data sources it is authorized to access, and any attempt to access resources outside that declaration should fail and generate an alert. The second is human sponsor departure: when the person who authorized an autonomous agent leaves the organization or changes roles, the agent’s authorization should not persist indefinitely. Ownership records for every autonomous agent must be kept current, and a workflow must exist to transfer or terminate agent authorization when its sponsor’s organizational relationship changes. The third is purpose obsolescence: agents authorized for a specific project or workflow that has concluded must be decommissioned, including revocation of all associated credentials and removal from all access control lists.
\n3.3 Orchestrator Identities
\nOrchestrator identities belong to AI agents whose primary function is coordinating the activities of other agents. An orchestrator receives a high-level goal, decomposes it into sub-tasks, dispatches sub-agents to execute those tasks, aggregates their outputs, and makes decisions about subsequent steps based on those outputs. The orchestrator is architecturally analogous to a privileged management plane: it must be able to instantiate, direct, and terminate the sub-agents under its control, and it may hold elevated permissions that allow it to provision credentials for those sub-agents.
\nThis management-plane role creates a concentrated risk profile. An orchestrator identity, if compromised, provides an attacker with the ability to redirect the behavior of every agent the orchestrator controls. The governance requirement is that orchestrator identities must be subject to more stringent authentication and authorization controls than the sub-agents they manage. Orchestrator credentials should use mutual TLS or SPIFFE SVIDs (Secure Verifiable Identity Documents) rather than API tokens alone, ensuring cryptographic binding to a specific infrastructure context that cannot be easily replicated by an attacker who has obtained a copy of the credential. Orchestrator actions — specifically the instantiation of sub-agents and the delegation of credentials to those sub-agents — must be logged with sufficient fidelity to reconstruct a complete audit trail of what was authorized, by whom, and under what operational context.
\nThe delegation model for orchestrators deserves special treatment. An orchestrator should only be permitted to delegate to sub-agents permissions that are explicitly contained within its own authorization grant — this is the principle of constrained delegation, and it is the primary defense against privilege escalation through delegation chains. If an orchestrator is authorized to read from a specific data store, it may delegate read access to its sub-agents; it may not delegate write access, even if the sub-agent has been instructed to write. Enforcing constrained delegation requires that the authorization system understand the parentage of each credential grant and can verify that the delegating identity itself holds the privileges it is delegating.
\n3.4 Ephemeral Sub-Agent Identities
\nEphemeral sub-agent identities are created dynamically at the direction of an orchestrator or an autonomous agent to perform a specific, bounded delegated task. They have the shortest lifecycle of any identity type in the AIGF taxonomy — typically measured in seconds to minutes — and the most constrained privilege profile, since they are created to execute a single well-defined function. The canonical examples include web browsing agents instantiated to retrieve a specific document, code execution agents instantiated to run a single script, and data transformation agents instantiated to apply a specific operation to a dataset.
\nThe governance requirements for ephemeral sub-agent identities center on instantiation integrity and automatic termination. Instantiation integrity means that when an orchestrator creates a sub-agent, the sub-agent’s identity and permission set must be derived directly from the orchestrator’s own authorization grant — not expanded, not supplemented with external credentials, and not persisted beyond the task’s completion. The sub-agent’s identity document should include a reference to the orchestrator that created it, the specific task scope it was authorized to perform, and a maximum duration beyond which its credentials automatically expire. This parentage record is essential for audit trail reconstruction and for enforcing constrained delegation at the system level.
\nAutomatic termination is not merely a best practice for ephemeral sub-agents — it is a hard governance requirement. A sub-agent that completes its task but retains active credentials is, from the identity governance perspective, an abandoned account with standing access. The AIGF requires that ephemeral sub-agent credentials carry a built-in time-to-live that cannot be extended by the sub-agent itself. If a task requires more time than the initial TTL allowed, the sub-agent should request re-authorization from its orchestrator rather than autonomously extending its own credential lifetime. This requirement closes a subtle but important attack vector: an adversary who has compromised a sub-agent cannot extend the duration of its access simply by keeping the task alive.
\n3.5 Agent-as-a-Service Identities
\nAgent-as-a-Service (AaaS) identities represent a distinct class of organizational and technical challenge: AI agents that are deployed to serve multiple tenants, customers, or organizational units, each of which has distinct data access rights, compliance obligations, and operational contexts. A shared AI assistant embedded in a multi-tenant SaaS platform is an AaaS identity; so is an internal shared research agent that serves multiple business units with different data classification levels, and so is a vendor-managed AI agent that a third party operates on behalf of an enterprise customer.
\nThe defining governance requirement for AaaS identities is tenant isolation: the agent must never allow data, credentials, or behavioral context from one tenant’s session to influence or contaminate another tenant’s session. This is architecturally distinct from the single-tenant agent governance challenges discussed above, because the failure mode is not simply privilege escalation within a single identity’s scope — it is cross-tenant data leakage that may not be detectable through standard monitoring unless specifically instrumented. Tenant isolation controls for AaaS agents must be enforced at the identity layer, not just at the application layer. Each tenant’s access context should be represented as a separate, independently scoped credential or session token that cannot be combined with or substituted for another tenant’s context.
\nThe monitoring requirements for AaaS identities reflect this multi-tenant risk profile. In addition to the anomaly detection that applies to all agent identities, AaaS agents require cross-tenant behavioral analysis: monitoring that can detect when an agent’s behavior in one tenant’s context is being influenced by patterns from another tenant, when the agent is attempting to access data stores from a context that does not match its current tenant assignment, or when tool invocations from one tenant session are generating results that appear to reference another tenant’s data. Decommissioning an AaaS agent requires not only revoking the agent’s master identity but also ensuring that all tenant-specific session records, cached credentials, and context representations are purged completely — a more complex operation than single-tenant decommissioning and one that requires explicit verification rather than assumption.
\n\n
4. Standards Reuse Assessment
\nBefore specifying new controls, a disciplined governance framework must assess what existing standards can accomplish and where they fall short. Three protocol families are directly relevant to AI agent identity governance: OAuth 2.0 and OpenID Connect, the SPIFFE/SPIRE workload identity stack, and the System for Cross-domain Identity Management (SCIM). Each was developed for a different original purpose and exhibits both genuine strengths and meaningful gaps when applied to the agent identity problem.
\n4.1 OAuth 2.0 and OpenID Connect
\nOAuth 2.0 and OpenID Connect together constitute the dominant framework for authorization and authentication in modern web services, and they are the natural starting point for agent identity credential management. OAuth 2.0’s token-based model — in which an authorization server issues scoped, time-limited tokens to authenticated clients — aligns well with the AIGF’s principle that agent credentials should be short-lived and scope-constrained. OpenID Connect’s identity layer provides a standardized mechanism for attaching claims about the authenticated subject to a token, which is valuable for attaching agent metadata such as type classification, capability declarations, and sponsoring principal references.
\nHowever, the standard OAuth 2.0 flows exhibit fundamental limitations in agentic contexts that stem from their design for human-interactive authorization. The Authorization Code flow, which is OAuth’s primary mechanism for granting delegated access, assumes a human user who can read and consent to an authorization request presented in a browser. Autonomous agents, ephemeral sub-agents, and orchestrators acting without human supervision cannot execute this flow. The Client Credentials flow, which allows non-interactive clients to obtain tokens using a client ID and secret, is more applicable to agent-to-agent contexts but was designed for server-to-server communication between relatively static, pre-registered services — not for the dynamic instantiation of novel agent identities at runtime.
\nThe IETF is actively developing extensions that close these gaps. The “OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents” Internet Draft introduces a requested_actor parameter that allows an agent to be identified as the specific entity requiring delegated access and an actor_token parameter to authenticate the agent during token exchange [7]. The AAuth (Agentic Authorization) OAuth 2.1 extension draft proposes an Agent Authorization Grant specifically for AI agents acting on behalf of users [8]. These extensions represent the standards community’s recognition that the agentic use case requires modifications to OAuth’s core flows rather than workarounds. Organizations implementing agent identity governance today should implement OAuth 2.1 as a baseline and monitor the AAuth and On-Behalf-Of drafts for standardization progress, designing their authorization servers to accommodate these extensions when they reach RFC status.
The most critical gap that no current OAuth extension fully closes is the delegation chain audit trail. When an orchestrator delegates credentials to a sub-agent, and that sub-agent further delegates to a transitive sub-agent, standard OAuth token introspection provides no mechanism to reconstruct the full delegation ancestry. The AIGF requires that authorization servers maintain delegation parentage records and that token introspection responses for agent credentials include the full delegation chain up to the human-principal anchor. This is a custom extension that organizations must implement in their authorization server infrastructure until a standardized delegation graph specification matures.
\n4.2 SPIFFE and SPIRE
\nThe Secure Production Identity Framework for Everyone (SPIFFE) and its reference implementation, the SPIFFE Runtime Environment (SPIRE), are CNCF-graduated projects that address workload identity in a way that is architecturally well-suited to several of the AIGF’s requirements [9]. SPIFFE’s core construct is the SPIFFE Verifiable Identity Document (SVID): a short-lived, cryptographically signed credential that attests both the identity of a workload and the infrastructure context (node, cluster, cloud account) in which it is running. SVIDs are issued by a SPIRE server based on attestation: before a workload can receive an SVID, it must prove something about its execution environment that matches a pre-configured attestation policy. This proof-before-credential model is fundamentally different from the secret-based model of static API keys and is directly aligned with the AIGF’s requirements for orchestrator identity assurance.
\nHashiCorp’s 2025 analysis of SPIFFE for agentic AI workloads identified several properties that make it well-suited to the agent identity problem [10]. The short-lived nature of SVIDs (default rotation interval is configurable but typically set to one hour or less) addresses the static credential risk that makes legacy API keys dangerous. The infrastructure-binding of attestation means that an SVID issued to an agent running in a specific Kubernetes pod cannot be used by an attacker who extracts it and attempts to use it in a different execution context — the SPIRE agent on the target node will refuse to issue a new SVID to a workload that does not match the attestation policy. The uniform identity namespace (SPIFFE URIs of the form spiffe://trust-domain/path) provides a consistent, cross-platform way to reference agent identities regardless of the orchestration framework they run in.
The principal limitation of SPIFFE/SPIRE for agent identity governance is that the framework was designed for relatively stable workload populations in well-defined infrastructure environments. AI agents — particularly ephemeral sub-agents dynamically instantiated by orchestrators — may appear and disappear too rapidly for SPIRE’s node attestation and workload registration processes to keep pace in their default configurations. An orchestrator instantiating dozens of sub-agents per second cannot afford the latency of individual SPIRE workload attestation for each. The AIGF recommendation is to use SPIFFE SVIDs as the preferred credential format for orchestrator identities and persistent autonomous agents, where the attestation overhead is acceptable and the security benefits are substantial. For ephemeral sub-agents operating at high instantiation velocity, a lightweight delegation token derived from the orchestrator’s SVID — with the orchestrator’s trust domain and parentage recorded in the token claims — is a pragmatic alternative that preserves the audit trail while reducing attestation latency.
\n4.3 SCIM
\nThe System for Cross-domain Identity Management, defined in RFC 7643 (Core Schema) and RFC 7644 (Protocol), provides a standardized HTTP-based protocol for provisioning and managing identity records across organizational boundaries [11][12]. SCIM’s primary use case has historically been synchronizing human user accounts between enterprise identity providers and SaaS applications: when an employee joins or leaves an organization, SCIM propagates the change to every connected application automatically. Its relevance to agent identity governance lies in its potential as an authoritative registry for agent identity records — a mechanism for creating, updating, and decommissioning agent identities in a consistent, auditable way across the heterogeneous systems an enterprise uses.
\nThe challenge is that SCIM’s core schema was designed for human users and groups, not for the attributes that characterize AI agent identities. A SCIM User object has fields for a person’s name, email, phone number, organizational unit, and manager — none of which map naturally to the governance attributes that agents require. The IETF community has recognized this gap and produced a working draft, “SCIM Agents and Agentic Applications Extension,” that defines new schema elements specifically for agent provisioning [13]. The draft introduces an Agent resource type with attributes including a structured representation of the agent’s capability declarations, protocol bindings (with values such as “A2A,” “OpenAPI,” or “MCP-Server”), trust profile metadata, and X.509 certificate associations. This extension, if adopted, would allow SCIM to serve as the authoritative provisioning mechanism for agent identities in the same way it currently serves for human identities.
Beyond the schema extension, three additional SCIM customizations are required for complete agent lifecycle management. First, the agent registry must capture behavioral attestation: a machine-readable declaration of the agent’s expected behaviors, tool invocations, and access patterns that can serve as a baseline for anomaly detection. Second, the registry must record the full sponsoring principal chain — not just the immediate human owner, but the organizational role that authorized the agent’s creation and the governance policy under which it was provisioned. Third, the registry must support real-time lifecycle event triggers: when an agent’s SCIM record is updated (capability change), suspended (owner departed), or deleted (decommission), those events must automatically propagate to all associated authorization servers, token issuers, and monitoring systems. The AIGF treats a SCIM agent registry with these extensions as the authoritative system of record for all five agent identity types.
\n\n
5. Just-In-Time Access Model for Agents
\nThe most consequential structural change the Agent Identity Governance Framework introduces relative to current practice is the replacement of standing agent privileges with a just-in-time (JIT) access model. In the standing-privilege model — which describes the vast majority of agent deployments today — an agent is provisioned with a set of credentials at creation time, and those credentials remain valid until someone explicitly revokes them. The agent can invoke any tool, access any resource, and exercise any permission within its standing grant at any time, whether or not it is actively performing a task that requires those privileges. The standing-privilege model is operationally convenient and technically simple, but it maximizes the blast radius of every credential compromise and makes it essentially impossible to construct a meaningful audit trail linking specific agent actions to specific authorized purposes.
\nThe JIT model inverts this relationship. Instead of receiving a standing grant at provisioning time, an agent receives a minimal baseline identity — sufficient for it to identify itself to the authorization infrastructure and declare its intent — but no operational privileges. When the agent is assigned a task that requires privileged access, it submits an intent declaration to the authorization system before requesting any privilege elevation. The intent declaration is a structured, machine-readable statement of the task to be performed, the specific resources to be accessed, the tools to be invoked, and the maximum duration of the required access window. The authorization system evaluates the intent declaration against policy — checking that the requested scope is consistent with the agent’s authorized capability profile, that the declared task is consistent with the agent’s purpose, and if the request exceeds a defined risk threshold, routing it to a human-in-the-loop approval workflow — and, if the evaluation succeeds, issues a time-limited, scope-constrained grant.
\nThe intent declaration mechanism provides a governance artifact that standing-privilege models completely lack: a pre-execution record of what the agent intended to do, against which post-execution behavior can be compared. If an agent’s declared intent was to retrieve three documents from a specific knowledge base, and the audit log shows it instead read from a different data store and invoked a network egress tool, the deviation is immediately detectable. This comparison between declared intent and actual behavior is the foundation of behavioral anomaly detection in the AIGF, and it depends entirely on the intent declaration existing in the first place. Without the JIT structure that creates intent declarations, anomaly detection is reduced to pattern-matching against historical baselines — a weaker signal with a higher false-positive rate.
\nThe human-in-the-loop escalation criteria within the JIT model require careful calibration. An overly aggressive escalation threshold — routing every privilege request for human review — negates the operational value of AI agents by introducing approval latency for routine tasks. An insufficiently aggressive threshold — routing only the most extreme requests for human review — fails to catch the gradual privilege escalation through incremental requests that is one of the most common patterns in agent-related incidents. The AIGF specifies four conditions that should unconditionally trigger human-in-the-loop review, regardless of other policy parameters: any request to expand an agent’s capability profile beyond its provisioned declaration; any request to create or modify the identity or credentials of another agent; any request to access resources classified above the tier for which the agent was originally authorized; and any request that would grant the agent the ability to persist data outside its designated scope across task boundaries. Outside these hard escalation triggers, organizations should calibrate their escalation thresholds based on the sensitivity classification of the resources involved, with lower-sensitivity tasks able to proceed under automated authorization and higher-sensitivity tasks requiring human approval.
\nThe prevention of delegation chain privilege escalation deserves treatment as a first-class design requirement rather than a secondary control. In multi-agent systems, the delegation chain can be long: a human principal authorizes an orchestrator, which delegates to sub-agents, which may further delegate to tools or other agents. At each step in this chain, there is a temptation — and sometimes a technical capability — to request slightly broader access than was delegated from the step above, rationalizing the expansion as necessary for the current task. Over multiple steps, these small expansions compound into an agent operating with privileges far beyond what the originating human principal intended to authorize. The AIGF’s constrained delegation requirement — that no identity may delegate more privilege than it has been granted — must be enforced by the authorization infrastructure itself, not merely by policy. Authorization servers must track the privilege ceiling of each delegation step and refuse to issue grants that exceed it, even if the requesting agent provides a compelling operational rationale.
\nAudit trail construction under the JIT model becomes substantially more complete than under standing-privilege architectures. Because every privilege grant is preceded by an intent declaration and followed by a token issuance event, the audit trail contains three anchoring records for every significant agent action: the intent declared, the privilege granted, and the privilege exercised. These three records, linked by the agent’s identity and the task’s unique identifier, provide the material needed to reconstruct the full context of any agent action and to trace it back through the delegation chain to the authorizing human principal. The CSA’s finding that only 28 percent of organizations can currently trace agent actions to a human sponsor [3] is, in the AIGF model, a consequence of architecture rather than effort: without intent declarations and constrained delegation records, traceability is structurally impossible regardless of the monitoring investment an organization makes.
\n\n
6. OWASP ASI03 and AICM IAM Alignment
\nThe AIGF does not exist in a standards vacuum. Its controls are designed to be directly responsive to the risk categories identified by the OWASP Agentic Security Initiative and mappable to the IAM domain of the CSA AI Controls Matrix, ensuring that organizations implementing the AIGF can demonstrate compliance with both frameworks as a direct byproduct of implementation rather than through a separate mapping exercise.
\nOWASP ASI03, Identity and Privilege Abuse, addresses the class of threats that arise when AI agents accumulate, inherit, or exploit credentials and permissions beyond their intended operational scope [5]. The core insight of ASI03 is that an AI agent’s identity is effectively an aggregation point: it encompasses not only the agent’s own provisioned credentials but also any credentials, tokens, or delegated sessions it acquires through tool invocations, API responses, or context injection. When a research agent retrieves a document that contains embedded credentials, those credentials become part of the agent’s effective identity surface, even if they were never intentionally provisioned to it. ASI03 risk therefore cannot be fully mitigated through provisioning controls alone — it requires runtime containment of credentials that agents encounter during execution, in addition to lifecycle governance of credentials intentionally granted.
\nThe AIGF addresses ASI03’s runtime credential exposure risk through two complementary controls. The first is credential scrubbing at tool output boundaries: a processing layer that inspects agent-accessible outputs for credential-like patterns (API keys, tokens, passwords, certificates) and either redacts them or routes them to a secure vault rather than surfacing them directly in the agent’s context. The second is a tooling perimeter that prevents agents from acting on credentials encountered in retrieved content without explicit re-authorization. If an agent encounters a credential during a retrieval task, using that credential should be classified as a new intent-declaration event requiring explicit authorization, not a continuation of the original task’s privilege grant.
\nThe CSA AI Controls Matrix was released in July 2025 as a framework of 243 control objectives across 18 security domains, including a dedicated Identity and Access Management domain [14]. The AICM IAM domain addresses authentication, authorization, credential management, access governance, and audit for AI systems. The AIGF’s five identity type definitions, JIT access model, and standards-based credential architecture map to AICM IAM controls across four categories: identity provisioning and lifecycle (ensuring agents are created, modified, and decommissioned through formal processes with documented ownership), authentication assurance (ensuring agents use cryptographically strong credentials that are regularly rotated), authorization governance (ensuring agent access is constrained by the principle of least privilege and reviewed periodically), and audit and accountability (ensuring agent actions are logged with sufficient fidelity to reconstruct the full identity and delegation context of each action). The AIGF’s requirement that every agent identity be anchored to a human sponsor in the organizational directory directly addresses the AICM’s accountability requirements and closes the traceability gap identified in the CSA’s autonomous agents survey [3].
\nThe NIST AI Risk Management Framework provides additional alignment context. NIST’s AI RMF 1.0 Govern function requires that organizations establish roles, responsibilities, and accountability for AI system oversight. The AIGF’s ownership registry, which requires that every agent identity be associated with a named human sponsor and a governing organizational policy, directly satisfies the AI RMF’s accountability requirements. NIST’s recent RFI on AI Agent Security and its concept paper on AI Agent Identity and Authorization signal that future NIST guidance will incorporate the lifecycle governance concepts that the AIGF formalizes [6]. Organizations that implement the AIGF now are positioning themselves to align with forthcoming NIST agent-specific guidance without requiring a separate implementation effort.
\n\n
7. Implementation Roadmap
\nImplementing the Agent Identity Governance Framework is a multi-phase effort that varies significantly in complexity depending on an organization’s current NHI governance maturity. Rather than presenting a single prescriptive timeline, the AIGF defines three maturity levels and an appropriate implementation path for each. Organizations should honestly assess their current state and begin at the appropriate level — attempting to skip phases is likely to produce incomplete implementations that provide the appearance of governance without its substance.
\nFoundation Level organizations are those that lack a complete inventory of their existing AI agents and NHI population and have no formal lifecycle governance processes in place. The first and most important action for these organizations is comprehensive inventory: deploying discovery tooling that identifies all active agent identities, service accounts, API keys, and workload credentials across the environment, and recording for each the associated human owner, provisioning date, access scope, and last activity timestamp. This inventory exercise almost always reveals a significant population of orphaned identities — credentials associated with departed employees, decommissioned projects, or applications that no longer exist — and remediating these orphans should be prioritized immediately, as they represent standing risk with no operational justification. Once the inventory is established, Foundation Level organizations should implement an ownership assignment process that requires every agent identity to be associated with a named sponsor and reviewed for continued need on a quarterly cycle. Static API keys identified during the inventory should be migrated to short-lived tokens as a parallel workstream, with the goal of eliminating static keys for all agents accessing sensitive resources within six months.
\nIntermediate Level organizations have an established inventory and some lifecycle governance processes, but operate with largely manual controls, inconsistent enforcement, and no JIT access capability. The primary development at this level is automation: building the workflow integrations that enforce policy consistently without requiring human action for every identity event. This means connecting the SCIM agent registry to the authorization infrastructure so that changes to an agent’s registry record automatically propagate to its token issuance permissions; implementing automated credential rotation for all agent identities on a schedule calibrated to their access scope; and deploying behavioral monitoring with alerting on deviations from each agent’s registered capability profile. Intermediate Level organizations should also begin piloting the intent declaration mechanism for their highest-risk autonomous agents — this does not require a full JIT implementation initially, but establishing the pattern of pre-execution intent logging creates the audit trail foundation that the full JIT model requires.
\nAdvanced Level organizations have automated lifecycle governance and behavioral monitoring in place and are ready to implement full just-in-time access orchestration. The priority at this level is deploying the JIT authorization service as the control plane for all agent privilege grants, migrating agents from standing-privilege credentials to baseline-plus-JIT architectures, and implementing constrained delegation enforcement in the authorization infrastructure. Advanced Level organizations should also implement the delegation chain audit trail described in Section 5, ensuring that every token issued to an agent includes its full parentage record and that those records are queryable by the security operations team. The final capability at the Advanced Level is cross-agent behavioral correlation: detection systems that can identify when a multi-agent workflow is exhibiting collective behavior that deviates from the declared intent of the orchestrating agent, even if each individual agent appears to be behaving within its own authorized scope in isolation.
\n\n
8. Framework Alignment Table
\nThe following table maps the AIGF’s primary control domains to corresponding controls in the CSA AI Controls Matrix IAM domain, the OWASP Agentic Security Initiative, the CSA MAESTRO threat modeling framework’s relevant layers, and the NIST AI Risk Management Framework. Organizations using this table should note that the AICM, OWASP ASI, and NIST AI RMF are all living documents that are updated as agentic AI security guidance matures; the mappings below reflect the state of each framework as of Q1 2026 and should be reviewed annually.
\n| AIGF Control Domain | \nAICM IAM Control | \nOWASP ASI Risk | \nMAESTRO Layer | \nNIST AI RMF Function | \n
|---|---|---|---|---|
| Agent Identity Registry (SCIM) | \nIAM-01: Identity Provisioning | \nASI03: Identity & Privilege Abuse | \nL5: Deployment Infrastructure | \nGovern 1.1: Accountability | \n
| Credential Lifecycle Management | \nIAM-02: Credential Management | \nASI03: Identity & Privilege Abuse | \nL5: Deployment Infrastructure | \nManage 2.2: Risk Treatment | \n
| Session-Bound Delegation (Copilot) | \nIAM-03: Access Delegation | \nASI02: Excessive Permissions | \nL6: Security & Compliance | \nGovern 4.1: Human Oversight | \n
| Autonomous Agent Credential Rotation | \nIAM-02: Credential Management | \nASI03: Identity & Privilege Abuse | \nL5: Deployment Infrastructure | \nManage 1.3: Risk Monitoring | \n
| Orchestrator Constrained Delegation | \nIAM-04: Privilege Management | \nASI03: Identity & Privilege Abuse | \nL4: Agent Frameworks | \nGovern 1.1: Accountability | \n
| Ephemeral Agent TTL Enforcement | \nIAM-02: Credential Management | \nASI04: Resource & Service Abuse | \nL5: Deployment Infrastructure | \nManage 2.2: Risk Treatment | \n
| AaaS Tenant Isolation | \nIAM-05: Tenant Separation | \nASI06: Data & Model Poisoning | \nL6: Security & Compliance | \nGovern 3.2: Risk Tolerance | \n
| OAuth 2.1 / AAuth Extension | \nIAM-03: Access Delegation | \nASI03: Identity & Privilege Abuse | \nL5: Deployment Infrastructure | \nMap 1.5: Risk Identification | \n
| SPIFFE SVID for Orchestrators | \nIAM-01: Identity Provisioning | \nASI03: Identity & Privilege Abuse | \nL5: Deployment Infrastructure | \nManage 1.1: Risk Mitigation | \n
| Intent Declaration (JIT) | \nIAM-04: Privilege Management | \nASI01: Agent Goal Hijack | \nL6: Security & Compliance | \nGovern 4.1: Human Oversight | \n
| Delegation Chain Audit Trail | \nIAM-06: Audit & Accountability | \nASI03: Identity & Privilege Abuse | \nL7: Agent Ecosystem | \nGovern 1.1: Accountability | \n
| Human Sponsor Traceability | \nIAM-06: Audit & Accountability | \nASI03: Identity & Privilege Abuse | \nL7: Agent Ecosystem | \nGovern 1.1: Accountability | \n
| Behavioral Anomaly Detection | \nIAM-06: Audit & Accountability | \nASI05: Unintended Consequences | \nL6: Security & Compliance | \nManage 1.3: Risk Monitoring | \n
| Credential Scrubbing at Tool Output | \nIAM-02: Credential Management | \nASI03: Identity & Privilege Abuse | \nL4: Agent Frameworks | \nManage 2.2: Risk Treatment | \n
The MAESTRO layer assignments in this table reflect the architectural location at which each control is most naturally enforced. Controls assigned to Layer 5 (Deployment Infrastructure) require implementation at the Kubernetes, cloud, or container orchestration layer — at the level of node attestation, network policy, and secrets management infrastructure. Controls assigned to Layer 4 (Agent Frameworks) require implementation within the agent development frameworks themselves — in the SDK code, middleware, or agent runtime that developers use to build agents. Controls assigned to Layer 6 (Security and Compliance) are cross-cutting monitoring and policy enforcement controls that operate across multiple layers. Controls assigned to Layer 7 (Agent Ecosystem) address governance artifacts — audit trails, ownership records, and accountability chains — that exist at the organizational and operational level above the technical infrastructure.
\n\n
References
\n[1] Cloud Security Alliance. The State of Non-Human Identity and AI Security Survey Report. Cloud Security Alliance, 2025. https://cloudsecurityalliance.org/artifacts/state-of-nhi-and-ai-security-survey-report
\n[2] NHIMG / Oasis Security. 2025 State of Non-Human Identities and Secrets in Cybersecurity. Non-Human Identity Management Group, 2025. https://nhimg.org/2025-state-of-non-human-identities-and-secrets-in-cybersecurity
\n[3] Cloud Security Alliance / Strata Identity. Securing Autonomous AI Agents Survey Report. Cloud Security Alliance, 2026. https://cloudsecurityalliance.org/artifacts/securing-autonomous-ai-agents
\n[4] NHIMG. 2025 State of Non-Human Identities and Secrets in Cybersecurity: Key Findings. Non-Human Identity Management Group, 2025. https://nhimg.org/2025-state-of-non-human-identities-and-secrets-in-cybersecurity
\n[5] OWASP Agentic Security Initiative. OWASP Top 10 for Agentic Applications. OWASP Gen AI Security Project, 2026. https://genai.owasp.org/initiatives/agentic-security-initiative/
\n[6] NIST. Request for Information: AI Agent Security and AI Agent Identity and Authorization Concept Paper. National Institute of Standards and Technology, 2026. https://digital.nemko.com/news/ai-agent-standards-navigating-new-nist-governance
\n[7] IETF. OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents (draft-oauth-ai-agents-on-behalf-of-user). Internet Engineering Task Force, 2025. https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/
\n[8] Rosenberg, J. AAuth — Agentic Authorization OAuth 2.1 Extension (draft-rosenberg-oauth-aauth-00). Internet Engineering Task Force, 2025. https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html
\n[9] SPIFFE / SPIRE Project. SPIRE Concepts. Cloud Native Computing Foundation, 2025. https://spiffe.io/docs/latest/spire-about/spire-concepts/
\n[10] HashiCorp. SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors. HashiCorp Engineering Blog, 2025. https://www.hashicorp.com/en/blog/spiffe-securing-the-identity-of-agentic-ai-and-non-human-actors
\n[11] IETF. RFC 7643: System for Cross-domain Identity Management: Core Schema. Internet Engineering Task Force, 2015. https://datatracker.ietf.org/doc/html/rfc7643
\n[12] IETF. RFC 7644: System for Cross-domain Identity Management: Protocol. Internet Engineering Task Force, 2015. https://datatracker.ietf.org/doc/html/rfc7644
\n[13] Abbey, M. et al. SCIM Agents and Agentic Applications Extension (draft-abbey-scim-agent-extension-00). Internet Engineering Task Force, 2025. https://www.ietf.org/archive/id/draft-abbey-scim-agent-extension-00.html
\n[14] Cloud Security Alliance. AI Controls Matrix: A Framework for Trustworthy AI. Cloud Security Alliance, 2025. https://cloudsecurityalliance.org/artifacts/ai-controls-matrix
\n[15] Cloud Security Alliance. Agentic AI Threat Modeling Framework: MAESTRO. Cloud Security Alliance, 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
\n[16] CSA. 79% of IT Pros Feel Ill-Equipped to Prevent Attacks Via Non-Human Identities — CSA/Oasis Survey. Cloud Security Alliance Press Release, 2026. https://cloudsecurityalliance.org/press-releases/2026/01/27/79-of-it-pros-feel-ill-equipped-to-prevent-attacks-via-nhi-csa-oasis-survey-finds
\n[17] Cloud Security Alliance. More Than Two-Thirds of Organizations Cannot Clearly Distinguish AI Agent from Human Actions. Cloud Security Alliance Press Release, 2026. https://cloudsecurityalliance.org/press-releases/2026/03/24/more-than-two-thirds-of-organizations-cannot-clearly-distinguish-ai-agent-from-human-actions
\n[18] CSA. Why Just-in-Time Access Is the Future of PAM. Cloud Security Alliance Blog, 2025. https://cloudsecurityalliance.org/blog/2025/12/04/killing-standing-privileges-why-just-in-time-access-is-the-future-of-pam
\n[19] Aembit. Just-in-Time Access for Workloads: Eliminating Standing Privileges. Aembit Engineering Blog, 2025. https://aembit.io/blog/jit-access-workloads-eliminating-standing-privileges/
\n[20] WorkOS. SCIM for AI: Inside the New IETF Draft for Agent and Agentic Application Provisioning. WorkOS Engineering Blog, 2025. https://workos.com/blog/scim-agents-agentic-applications
\n