A companion article to this piece will compare the security guidance published by the five major LLM frontier model suppliers against the governance frameworks evaluated here. Model-layer content safety and deployment-layer identity governance answer genuinely different questions. That analysis is in preparation.
Five governance frameworks converge on authentication and stop short of structural enforcement
Five governance specifications for AIgentic systems reached operational maturity in the first quarter of 2026. Each was produced independently, by different organizations, against different institutional mandates. CSA’s Agentic Trust Framework arrived in February, targeting enterprise security practitioners. The IETF’s AIGA draft followed, targeting protocol engineers. NIST’s NCCoE concept paper spoke to federal and regulated-industry CISOs. CoSAI’s Agentic IAM specification addressed the multi-organizational AI deployment community. NHI governance emerged not from a single standards body but from the regulatory obligations and credential architecture research that the other four frameworks implicitly require. Five organizations, five mandates, five starting points.
They arrived at the same posture.
Each framework, treated independently, says a version of the following: provision a unique identity for every AIgentic Actor, grant minimum permissions for the specific task, monitor behavior continuously, and enforce policy at every access decision. That is the verification posture. It is not wrong. It is necessary. The question this article addresses is whether it is sufficient.
The convergence finding, stated plainly, is that all four peer frameworks share this posture and none prescribes an enforcement substrate that constrains an Actor’s action space before any policy check runs. It is an Attribit-ID original synthesis. It is the field’s current frontier. It is the security architect’s immediate assignment. The five evaluations in this article test each framework against that finding, identify where each one stops and why, and map what the security leader must supply to close the gap no single framework has yet specified.
What does four frameworks sharing the same posture actually mean?
Convergence across independently produced specifications is the strongest available signal of field consensus. When CSA, IETF, NIST, and CoSAI independently arrive at the same architecture, that architecture is settled. Organizations deploying AIgentic Actors that have not implemented the verification posture are behind the field consensus. This is not an emerging or contested question: it is closed.
The absence that the convergence also reveals is a different kind of finding. Four organizations working independently against different mandates produce four frameworks. The absence of a topology-first enforcement substrate in all four is not an oversight in any individual framework. It is a collective description of where the field currently stops. That is what makes it the security architect’s responsibility: the field has defined the floor but not the ceiling, and the distance between them is where production AIgentic deployments actually operate.
The urgency gap is concrete. Gartner predicts that 40 percent of enterprise applications will include task-specific AIgentic Actors by the end of 2026, up from less than five percent in 2025.1 A CSA and Oasis Security survey of 383 IT and security professionals conducted in January 2026 found that 78 percent of organizations lack documented policies for creating or removing AI identities, 92 percent lack confidence their legacy IAM solutions can manage NHI risks, and only 21 percent maintain real-time registries of active agents.2 A CSA Labs analysis published in Q1 2026 found that 88 percent of organizations experienced confirmed or suspected AI agent security incidents in the prior year, 97 percent of non-human identities carry excessive privileges, 90 percent of deployed AIgentic Actors exceed their actual task scope in permission grants, and only 28 percent of organizations can trace agent actions to a named human sponsor across all environments.3
The verification posture is the governance answer to these numbers. It is where this field consensus landed. Understanding precisely what each of the five frameworks establishes within that posture, and where each stops, is the analytical foundation for everything a security leader must decide next.
The deployment pace has already outrun governance framework maturity
Governance frameworks arrived into an environment that was already in motion. Organizations did not wait for CSA, IETF, NIST, or CoSAI to finalize guidance before deploying AIgentic Actors. The NIST and UK AI Security Institute joint research quantified the operational consequence of that gap: optimized attack strategies against AI agents achieved an 81 percent success rate compared to an 11 percent success rate for baseline defenses, with prompt optimization alone producing a sevenfold improvement in attacker success.4 The attack surface that five governance frameworks are attempting to govern was already being exploited before any of those frameworks was published.
The Palo Alto Networks Unit 42 research published in March 2026 disclosed that the Vertex AI P4SA service account associated with deployed Google Cloud agents received excessive default permissions: broad read access to Cloud Storage buckets, Artifact Registry repositories, and deployment files, by platform design rather than operator misconfiguration.5 The authorization gap is not an edge case in poorly-governed deployments. It is a platform-level default that organizations inherit at provisioning. Governance frameworks cannot fix platform defaults. They can specify what the platform’s operator is responsible for configuring, which is precisely what all four peer frameworks do in their authorization requirements.
The regulatory environment compounds the deployment pace problem. The EU AI Act’s enforcement of Annex III obligations for high-risk AI systems begins August 2, 2026; Attribit-ID interprets enterprise agentic pipeline deployments in Annex III-covered sectors as meeting the high-risk classification threshold where those pipelines make consequential decisions in the Act’s enumerated domains. DORA’s Article 9 least-privilege requirements for ICT access controls in financial entities have been effective since January 17, 2025; Attribit-ID interprets Article 9’s ICT access control requirements as covering NHI credentials at runtime. These deadlines were not set by standards committees. The frameworks arrived on a timeline determined by regulators who did not wait for the governance specifications to mature.
The five evaluations that follow are comparative, not sequential. Each framework is tested against the same criteria: what it establishes within the verification posture, where it stops, and why that stopping point is a property of the paradigm rather than a correctable design gap.
CSA’s Agentic Trust Framework ties agent capability to organizational governance readiness
Identity element: Unique verified identity for every AIgentic Actor, with machine-readable credentials persisting across the Actor Identity Lifecycle. Behavior element: Behavioral anomaly detection and intent analysis applied continuously, covering the Actor’s actions after provisioning. Data Governance element: End-to-end encryption, data classification, provenance tracking, and cross-boundary data controls covering all data the Actor accesses or produces. Segmentation element: Network microsegmentation and logical isolation to contain the blast radius from a compromised Actor. Incident Response element: Isolation, forensic investigation, and root cause analysis triggered by behavioral anomaly detection.
ATF’s five elements compose an integrated governance posture in which each element depends on the others: identity makes attribution possible, behavior monitoring makes detection possible, and segmentation makes containment possible when detection triggers a response. The four-tier maturity model (Intern through Principal) determines which elements apply at which capability level and which governance controls are required to elevate an Actor’s autonomous authority.
How does ATF’s four-tier maturity model translate to governance practice?
The ATF four-tier maturity model is the framework’s most operationally useful original contribution. The full ATF evaluation traces all five governance elements in detail. Intern-tier Actors observe and report only: they access read-only systems, their outputs are reviewed by humans before any action is taken, and no autonomous action is permitted under any circumstance. Junior-tier Actors recommend with human approval required for execution. The recommendation is the Actor’s output; the human makes the decision and executes it. Senior-tier Actors act independently with post-hoc notification: they execute, then report. Principal-tier Actors operate autonomously within a defined domain with no per-action human approval required at any step.
The tiers are not a classification system for AI models. They are a governance readiness scale for organizations. A Junior-tier designation means the organization has implemented the controls required to grant an AIgentic Actor supervised autonomy. It does not mean the Actor itself is inherently less capable than a Senior-tier Actor. An organization that has not implemented continuous behavioral monitoring cannot safely operate Senior-tier Actors regardless of the model’s capability. An organization without functional incident response cannot justify Principal-tier autonomy regardless of the business case for it. ATF is explicit on this point: autonomy is earned through governance readiness, not capability demonstration.
This is ATF’s original contribution to the field. No other framework published in this series ties agent capability directly to the organization’s capacity to govern it. That linkage has practical consequences for organizations evaluating their deployment posture: ATF provides a diagnostic for whether the current governance infrastructure can support the autonomy level the business wants to deploy, and it names specific controls required to justify each tier elevation.
The ATF Verified certification program, in open enrollment as of June 2026, provides a third-party audit path for organizations seeking to validate their governance readiness before elevating Actor autonomy. The program’s existence signals CSA’s intent to make ATF’s maturity tiers auditable against an external standard rather than self-assessed against the framework’s own language.
The practical starting point for any ATF implementation is the Identity element: provision a unique verified identity for every AIgentic Actor before any other governance work begins. This is also CoSAI’s Phase 1 starting point and NIST NCCoE’s first focus area. The convergence on identity as the prerequisite for all other governance controls is not coincidental. You cannot govern what you cannot identify. Every other ATF element (behavioral monitoring, data governance, segmentation, and incident response) requires knowing which Actor performed which action, and that knowledge requires a unique persistent identity that survives re-instantiation.
Where does behavioral verification reach its structural limit?
ATF’s Behavior element relies on anomaly detection and intent analysis applied after the Actor has acted. This architecture has a specific failure mode that ATF inherits from the verification paradigm rather than introduces through any design choice. An AIgentic Actor that has been compromised via indirect prompt injection presents a valid credential to the identity infrastructure, passes all behavioral baseline checks, and satisfies every policy constraint ATF defines. It does this while executing attacker instructions, because the attacker’s instructions are semantically indistinguishable from legitimate instructions at the access decision layer. The Actor’s behavior is consistent with its approved scope. What has changed is the source of the instructions driving that behavior.
This is not a correctable problem within the verification paradigm. It is a property of the paradigm. A governance layer that authenticates the Actor, checks its permissions, and monitors its behavior cannot detect that the Actor’s context window has been compromised. All three checks operate on what the Actor is and what it has permission to do, not on whether the Actor’s current intent matches its designated purpose. A prompt-injected Actor retains its valid identity, its authorized permissions, and its historically normal behavior profile right up to the moment it performs the attacker’s requested action, which may itself be within its authorized scope.
ATF’s Segmentation element provides partial mitigation. If an Actor’s network access is constrained to the systems required for its designated function, the damage from a compromised Actor is bounded by the segmentation perimeter. However, segmentation limits the blast radius of a compromise; it does not prevent the compromise or detect it before it occurs. The governance architecture that addresses the detection gap requires something outside the verification paradigm: an enforcement layer positioned between the Actor and the systems it attempts to reach, one that evaluates the Actor’s request against the current task’s authorized scope before the request is executed, not before the Actor is authenticated.
IETF AIGA publishes the most precisely worded governance requirements in any current specification
T0 tier: Read-only information retrieval with no external actions. Standard authentication. No special security requirements beyond the baseline. T1 tier: Limited tool use on approved systems with user confirmation required at each consequential action. Standard authentication and scoped credentials. T2 tier: Broad tool use with persistent state and multi-step planning. Requires audit logging, anomaly detection, and minimum-scope credential issuance. T3 tier: Cross-system orchestration managing Agentlets, capable of triggering real-world consequences. Requires Immutable Kernel Architecture with TEE/HSM attestation and Constitutional Constraint enforcement. T4 tier: Critical infrastructure control with financial, safety, or national security consequences. Requires Hardware Security Module binding and continuous Constitutional Constraint verification at every action.
The five tiers compose a risk-stratified governance architecture in which each tier adds proportionally stronger identity attestation and behavioral constraint. The Immutable Kernel Architecture and Constitutional Constraints are mandatory from T3 upward, where multi-Actor orchestration and non-human-supervised autonomy create material risk that audit logging alone cannot address.
What do Constitutional Constraints actually require?
The full AIGA evaluation covers the complete five-tier risk architecture and the AIGA-ID liveness token mechanism. AIGA’s Constitutional Constraints use CANNOT and MUST language applied to four kernel properties. Kernel code cannot be modified at runtime. Logging cannot be disabled under any operational condition. Action approval requirements cannot be bypassed regardless of operator instruction. A kill switch must be implemented and operational at all times. These four requirements are stated without qualification: they are invariant across all deployment contexts for Actors at T3 and above, regardless of the business case for any individual exception.6
The precision is AIGA’s most significant contribution to the field. Attribit-ID finds every other framework in this series uses conditional or implementation-flexible language: organizations should implement minimum-scope credentials, organizations may adopt structured delegation chains, organizations are encouraged to consider anomaly detection. AIGA’s Constitutional Constraints are binary: they apply, and they are non-negotiable, for Actors at the specified tier. An Actor at T3 that does not satisfy all four Constitutional Constraints is not a T3 Actor under AIGA’s classification. This makes AIGA uniquely auditable across the five frameworks: Constitutional Constraint compliance is binary and verifiable by inspection, not a matter of organizational interpretation or stated intent.
AIGA also specifies that Actors at T3 and above must run in Trusted Execution Environments with Hardware Security Module attestation, and that AIGA-IDs must be cryptographically bound to specific hardware configurations rather than software identifiers that can be migrated or cloned.6 The liveness token mechanism requires periodic cryptographic renewal of the Actor’s credential: a compromised Actor cannot operate indefinitely on a stale credential, because the credential’s liveness is verified continuously rather than only at provisioning.
The AIGA-ID architecture is the most specific identity specification published by any framework in this series. A unique persistent identifier cryptographically bound to hardware attestation, combined with a continuously renewed liveness token, provides a stronger assurance of Actor authenticity than any identifier scheme the other four frameworks specify. The identity architecture is not the gap. The gap lies elsewhere, and it is architectural.
Note on standing: draft-aylward-aiga-2-00 is an individual Internet-Draft with no formal IETF working group endorsement or standards-track standing. It carries Intended Status: Informational. It expires July 30, 2026, with no renewal draft filed as of this article’s publication date.
Why does in-process enforcement fail to detect semantic compromise?
AIGA’s Immutable Kernel Architecture runs inside the Agent’s execution environment. The kernel enforces Constitutional Constraints by monitoring the Agent’s own code, verifying that logging cannot be disabled, and requiring action approval flows to complete before consequential actions execute. What the kernel cannot monitor is the Agent’s context window: the stream of input from users, upstream Agents, tool outputs, and retrieved documents that forms the basis for the Agent’s next action.
An AIgentic Actor that has been compromised via indirect prompt injection holds a valid AIGA-ID, a current liveness token, and an intact kernel. The kernel permits every action the Actor requests because all requested actions fall within approved policy, regardless of why the Actor is requesting them. The semantic compromise lives in the context window, not in the code the kernel monitors. In-process enforcement is, by design, blind to this failure mode. It is not that AIGA’s designers failed to anticipate the problem. It is that the problem requires a solution at a different architectural layer than the one the kernel occupies.
This architectural boundary is the same boundary that ATF’s behavioral anomaly detection reaches from the other side. ATF detects deviations from behavioral baselines after the Actor has acted. AIGA prevents the Actor from acting outside approved policy. Both approaches operate on identity and code integrity. Neither operates on the semantic content of the Actor’s context at the moment of decision. A prompt-injected Actor that requests an action within its approved policy passes both AIGA’s kernel checks and ATF’s behavioral checks while executing an attacker’s instruction.
Addressing the semantic layer requires an external architectural position: something that intercepts and evaluates the Actor’s action requests before execution, positioned outside the Actor’s own execution environment, without reliance on what the Actor reports about its own intentions. The Semantic Proxy Pattern describes this enforcement layer in detail. It is the topology-first addition that AIGA’s Immutable Kernel Architecture, despite being the most architecturally specific specification in this series, does not prescribe.
NIST NCCoE maps four stages of the Actor Identity Lifecycle but leaves revocation undefined
Identification focus area: Unique persistent identifiers for every AIgentic Actor, with identity propagation maintained across multi-hop delegation chains. SPIFFE/SPIRE proposed as the implementation mechanism for cryptographic workload attestation. Authorization focus area: Minimum necessary permissions scoped to specific tasks. Attribute-based access control and zero-trust policy enforcement at every access decision. Access Delegation focus area: Structured delegation with integrity maintained across multi-agent workflows. OAuth 2.0 Token Exchange proposed as the operative protocol. Logging and Transparency focus area: Immutable, tamper-evident audit trails covering all Actor actions, access decisions, and delegation events. Tracking Data Flows focus area: End-to-end monitoring of data accessed, modified, and produced by AIgentic Actors, enabling retrospective investigation of data lineage.
NCCoE’s five focus areas map to four of the five stages of the Actor Identity Lifecycle. The stage absent from the mapping is revocation, which is the operationally most consequential gap in the current draft.
Which stage of the Actor Identity Lifecycle does NCCoE leave unspecified?
The full NCCoE evaluation covers the demonstration project proposal and all five focus areas in detail. The NCCoE concept paper maps directly onto four Actor Identity Lifecycle stages: provisioning (Identification), scoping (Authorization), delegation (Access Delegation), and audit (Logging and Transparency combined with Tracking Data Flows). The fifth stage, revocation, does not appear as a defined focus area. No mechanism is specified for triggering credential invalidation when an Actor completes its task, when an Agentlet is destroyed at the end of its pipeline step, or when a compromised Actor must be removed from operation before its credential’s natural expiry.
The absence is operationally significant. Without a revocation mechanism with defined triggers, credentials issued for a task continue to be valid after the task ends. In a human identity context, this is a stale credential risk that audit cycles can surface and remediation can address over time. In an AIgentic context, where Agentlets are dynamically spawned and destroyed at machine pace, it is a standing privilege problem at scale: every credential issued to a short-lived Actor that is not explicitly revoked is a potential attack surface for the duration of its validity period, accumulating across every Actor provisioned since the last audit cycle.
The Actor Identity Lifecycle’s revocation stage requires three capabilities that the NCCoE concept paper does not specify: a defined revocation trigger for each Actor class, a propagation mechanism that invalidates derived credentials when a parent credential is revoked, and a verification mechanism that confirms revocation has propagated before a downstream system accepts a new delegation from the revoked Actor’s lineage. None of the four peer frameworks in this series specifies all three. Attribit-ID concludes the revocation gap is a shared gap across the field’s current governance consensus, not an NCCoE-specific omission.
NCCoE’s status shapes how the gap should be interpreted. The concept paper is an Initial Public Draft with a public comment period that closed April 2, 2026. No revised draft has been issued as of this article’s publication date. It is not a NIST Special Publication, a mandatory control set, or normative guidance. It is a proposal for a demonstration project that, when executed, will produce reference implementations for the five focus areas using OAuth 2.0, SPIFFE/SPIRE, and Zero Trust architecture. The revocation gap is not a permanent deficit; it is a gap in the current public draft that the demonstration project may address. Organizations implementing the NCCoE guidance now must add explicit revocation to the five focus areas independently.
NCCoE’s concept paper names SPIFFE/SPIRE among the workload identity technologies under consideration for the Identification focus area, representing the framework’s most immediately actionable contribution for organizations operating cloud-native infrastructure.7 SPIFFE/SPIRE’s cryptographic workload attestation provides the identity binding NCCoE’s Identification focus area requires without dependency on a shared directory that may not be accessible across multi-cloud or multi-organization deployment boundaries. The X.509-SVID credential SPIFFE/SPIRE issues binds a workload’s identity to a short-lived certificate rather than a long-lived secret, providing a native path toward the zero standing privilege posture that NHI governance requires at machine pace.
The NCCoE concept paper’s proposal for a demonstration project is also the implicit acknowledgment that governance specifications alone are insufficient. The demonstration project will produce reference implementations, not just requirements. When published, those implementations will provide the most concrete implementation guidance NIST has produced for AIgentic Actor identity and authorization. Until then, the five focus areas are requirements with a defined implementation direction but no reference implementation to validate against.
NCCoE’s guidance also maps directly to the NIST AI Agent Standards Initiative, launched February 17, 2026, which will ultimately produce COSAiS: SP 800-53 control overlays for single-agent and multi-agent AI systems. No timeline for the agent-specific overlays has been published as of June 2026. When COSAiS is published, it will translate NCCoE’s focus areas into specific SP 800-53 control overlays, providing a compliance mapping that federal agencies and regulated enterprises operating under FISMA or similar frameworks can apply directly. COSAiS is forthcoming; it is not a currently available resource.
CoSAI identifies five threat vectors that classical IAM cannot detect or contain
First-Class Identity Principle: Every AIgentic Actor receives a unique persistent identity that survives its full operational lifecycle, including re-instantiation after task completion and migration across execution environments. Standalone deployment pattern: Single-purpose Actors with direct user authorization. The user grants explicit permission; the Actor scopes its credentials to the authorized operation. User-delegated deployment pattern: Actors operating on behalf of a human principal. OBO authorization chains required. Permissions cannot exceed the delegating principal’s own effective permissions. Crew deployment pattern: Multi-Actor orchestration with hierarchical delegation chains that may cross organizational domain boundaries. The strictest delegation chain governance requirements in the framework apply at this pattern level. OBO delegation chain requirement: Delegated permissions MUST NOT expand beyond the delegating principal’s effective permissions at any hop in the chain. Enforced via RFC 8693 Token Exchange and RFC 9396 Rich Authorization Requests.
CoSAI’s three deployment patterns compose a risk-stratified architecture. The Crew pattern governs the highest-risk configuration: multi-Actor orchestration across organizational boundaries with Agentlet spawning. The OBO delegation chain requirement is the structural constraint that prevents permission accumulation as complexity increases.
What are the five threat vectors classical IAM cannot see?
The full CoSAI evaluation covers the First-Class Identity Principle, three deployment patterns, and the three-phase adoption roadmap in detail. CoSAI’s Agentic IAM framework identifies five threat categories absent from classical IAM threat models. Each emerges from properties unique to AIgentic execution: non-determinism, ephemerality, multi-hop delegation, and the capacity to spawn Agentlets dynamically across domain boundaries.
Standing privilege is the first. In classical IAM, standing privilege is a configuration problem: an account with overly broad permissions that an audit cycle can surface and remediation can address. In AIgentic execution, standing privilege is a rate problem. Agentlets are provisioned and destroyed faster than audit cycles can identify excess permissions. Every credential that is not explicitly revoked at task end becomes standing privilege for the duration of its validity period. The problem is not the individual credential. It is the accumulation across every Agentlet provisioned since the last audit cycle in a system where Agentlets are spawned hundreds or thousands of times per hour.
Loss of Actor clarity is the second. When an orchestrator Actor passes its own credentials to an Agentlet rather than issuing derived credentials scoped to the Agentlet’s specific sub-task, the downstream system receiving the Agentlet’s access request cannot determine which Actor actually made it. The orchestrator’s identity is on the credential. The Agentlet made the request. Audit trails record the orchestrator. Incident response investigations begin with the wrong Actor. The chain of accountability (who authorized what, when, and for what purpose) dissolves at the first delegation hop that does not produce a derived credential.
Unsigned or swapped models are the third. An attacker who can substitute the model backing an AIgentic Actor changes the Actor’s behavior without altering its credential. The identity infrastructure identifies the Actor correctly. The AIGA-ID is valid. The liveness token is current. The model running inside the Actor is different from the model that was originally provisioned. Constitutional Constraints that enforce code integrity cannot detect a swap at the model layer if the model is treated as a runtime parameter rather than an immutable component of the Actor’s attested identity.
Indirect prompt injection is the fourth. An attacker delivers instructions to an AIgentic Actor through the Actor’s context window rather than through direct user input. The instructions arrive embedded in a retrieved document, a tool output, or a message from an upstream Actor in the pipeline. The compromised Actor authenticates correctly, satisfies all policy checks, and executes the attacker’s instruction while appearing compliant to every monitoring layer that operates on identity and permissions. The attack surface is the context window, which no identity-based governance layer inspects before the Actor acts on its contents.
Agent collusion is the fifth. Two or more Actors coordinate to achieve an outcome that neither could achieve independently within its individual permission scope. Each Actor’s individual action is within its authorized bounds. The aggregate effect of coordinated actions violates the security policy. No single-Actor monitoring system, whether behavioral anomaly detection, audit logging, or policy enforcement, can detect an emergent coordination pattern across multiple independently operating Actors without a cross-Actor visibility layer that none of the five frameworks in this series specifies.
Attribit-ID finds these five threat vectors are not addressed by any of the four peer frameworks. CSA ATF’s behavioral anomaly detection may surface some collusion patterns retrospectively. AIGA’s Constitutional Constraints prevent the compromised Actor from disabling logging after the fact. Neither provides a structural response to the threat class at the point where it actually operates: the context window, the credential lineage, and the cross-Actor coordination layer.
How does the OBO delegation chain prevent permission escalation?
CoSAI’s OBO delegation chain requirement is the most precisely specified identity constraint published by any framework in this series. Delegated permissions MUST NOT expand beyond the delegating principal’s effective permissions at any hop. The mechanism is RFC 8693 Token Exchange combined with RFC 9396 Rich Authorization Requests.8
Token Exchange enables a downstream Actor to obtain a credential scoped to its specific sub-task without embedding the upstream Actor’s full credentials in the request. The downstream Actor presents the upstream token as evidence of delegation authority and receives a new token scoped to its authorized sub-operation. The upstream credentials are not passed through. Rich Authorization Requests enable the resulting token to carry structured authorization_details covering specific resources, specific operations, and specific time bounds, rather than broad OAuth scopes that express authorization in terms of resource categories rather than specific permitted actions. Together, these two mechanisms implement the OBO chain: every Agentlet in a multi-hop workflow receives a credential provably derived from the orchestrator’s credential and provably scoped to the Agentlet’s assigned task, with no expansion of permissions at any delegation hop.
The practical enforcement challenge is that this requires every system in the delegation chain to implement Token Exchange and Rich Authorization Requests. Most enterprise systems do not. This is why CoSAI’s three-phase adoption roadmap begins where it does. Phase 1 focuses on visibility: agent discovery, registration, elimination of shared accounts, and immutable logging. Phase 1 requires no new token infrastructure and no new authorization protocol implementation. It requires only that the organization know which Actors exist, that each one has a unique identity, and that their actions are logged. Phase 1 is the prerequisite for everything else: without discovery and registration, the OBO delegation chain cannot be implemented because the chain’s components are not known.
Phase 2 introduces short-lived tokens and attribute-based access control for higher-risk Actors. Phase 3 implements the full OBO delegation chain with cross-domain governance and continuous evaluation. The three-phase roadmap is CoSAI’s most immediately useful contribution to practitioners, not because it accelerates the path to Phase 3, but because it provides a structured implementation sequence that acknowledges where enterprises actually are. No other framework in this series provides a comparable implementation roadmap with explicitly defined infrastructure prerequisites at each phase.
NHI governance is the credential architecture the four frameworks point toward but do not specify
Why is NHI governance a direction rather than a framework?
Non-human identity governance is not a peer of CSA ATF, IETF AIGA, NIST NCCoE, and CoSAI. The full NHI governance analysis covers the rate problem, zero standing privilege architecture, and regulatory mapping in detail. Those four are governance specifications published by identifiable organizations against defined institutional mandates. NHI governance is the credential architecture answer that emerges when the governance intentions of those four frameworks are applied to the velocity at which AIgentic systems actually generate, consume, and invalidate credentials. It is what the four frameworks require at the identity layer, operationalized at machine pace rather than human pace.
The scale problem defines what machine pace means in practice. Non-human identities already outnumber human identities in enterprise environments by between 45-to-1 and 144-to-1.9 An enterprise deploying AIgentic Actors into that environment does not face a governance problem of the kind human IAM was designed to address. Human IAM was designed for a population of identities that grows slowly, where each identity corresponds to a named accountable person, and where credential provisioning and revocation events are infrequent enough for manual review. AIgentic deployment creates identities at a rate and with a lifecycle pattern that breaks every assumption human IAM governance makes.
Agentlets spawned by an orchestrator Actor in a production pipeline may have a lifecycle measured in seconds or minutes. Each one requires a credential. Each credential should be scoped to the Agentlet’s specific sub-task. Each should be revoked when the sub-task ends. In a system running at machine pace, the provisioning, scoping, and revocation events that governance requires happen thousands of times per hour, automated, without human review at any individual event. The four peer frameworks define what the controls should be. NHI governance defines what those controls must look like when they operate at this pace.
The OWASP Non-Human Identities Top 10 (2025) includes overprivileged NHIs (NHI5:2025) and long-lived secrets (NHI7:2025) among its ten risk categories.10 Both risk categories emerge directly from the absence of zero standing privilege: credentials that are not revoked at task end accumulate privilege, and credentials with no time bound become secrets with no natural expiry. These are not new risks. They are the oldest risks in IAM governance, applied to a population of identities that classical IAM governance was not designed to manage at this scale or pace.
What does zero standing privilege solve that the four frameworks do not?
Zero standing privilege means no AIgentic Actor holds persistent credentials between tasks. Each operation requests minimum access for the exact duration required. When the task ends, the credential expires. There is no cleanup step, no revocation workflow initiated by a human reviewer, no audit finding for a stale credential that accumulated privileges across six months of task executions. The credential cannot be reused because it no longer exists.
The four peer frameworks all specify minimum permissions. CSA ATF specifies minimum permissions in its Behavior element. NIST NCCoE specifies minimum necessary permissions in its Authorization focus area. CoSAI’s Phase 2 introduces short-lived tokens. AIGA requires scoped credential issuance from T2 upward. None of them specifies zero standing privilege as the architecture: a posture in which the absence of a credential is the default state for every Actor and the presence of a credential is the exception, valid only for the duration of a specific transaction.
Attribit-ID interprets zero standing privilege as the architectural implementation of DORA Article 9’s least-privilege requirement for ICT access controls as applied to NHIs at runtime. It simultaneously satisfies CoSAI’s Phase 2 short-lived token requirement, NIST NCCoE’s Authorization focus area minimum-scope mandate, and AIGA’s T2 scoped credential requirement. Four frameworks’ governance intentions, converging at the credential architecture layer, implemented as a single architectural decision.
The IETF WIMSE working group draft (draft-ni-wimse-ai-agent-identity-02, active as of this article’s publication date) proposes dual-identity credential binding as the complementary mechanism: the access token cryptographically encodes both the Actor’s identity and the human sponsor’s identity in the credential itself. Every access decision carries an auditable authorization chain: not a directory reference that may have drifted from operational state, but a cryptographic assertion embedded in the token. The audit trail is in the credential. The attribution is resolved at the point of access, not reconstructed retrospectively.
The regulatory consequence of dual-identity credential binding is direct. Attribit-ID interprets EU AI Act Article 14’s human oversight requirement for high-risk AI systems as requiring that every agent action be attributable to a named human sponsor who can effectively oversee, interpret, and where necessary halt the agent’s operation. A pipeline in which Agentlets operate on inherited credentials without an auditable delegation chain back to a named human sponsor does not satisfy Article 14’s attribution requirement. Dual-identity credential binding satisfies it at the credential layer, making attribution structural rather than retrospective.
This is NHI governance’s position in the synthesis: not a fifth peer framework competing with ATF, AIGA, NCCoE, and CoSAI, but the specific architectural answer to the specific question all four ask without fully answering: how does governance actually work at the pace AIgentic systems generate and consume identity?
The convergence matrix shows exactly where security architect decisions begin
What exactly do the four frameworks share, and where does each stop?
The convergence matrix is the synthesis payload. Four organizations working independently produced four frameworks that share four governance capabilities and omit two.
All four specify unique Actor identity as a first-class requirement. The implementations differ: AIGA uses AIGA-ID with X.509 hardware binding, CoSAI uses the First-Class Identity Principle with lifecycle persistence, CSA ATF treats identity as one of five governance elements, and NCCoE proposes SPIFFE/SPIRE for workload attestation. The requirement is shared. Organizations that are sharing service accounts across Actors or operating with inherited credentials from upstream systems are below the floor that all four frameworks define.
All four specify minimum-scope permissions. The terminology varies across the four: ATF specifies minimum permissions in its Behavior element, NCCoE specifies minimum necessary permissions in its Authorization focus area, CoSAI’s OBO delegation chain requirement prevents permission expansion beyond the delegating principal’s scope, and AIGA’s tier system scopes credentials by risk level with proportional permission constraints. The requirement is shared. The minimum-scope mandate is the field consensus on authorization.
All four specify behavioral monitoring. ATF’s Behavior element is built around behavioral anomaly detection and intent analysis. AIGA requires anomaly detection at T2 and above. NCCoE’s Logging and Transparency focus area is behavioral monitoring with a transparency and auditability obligation. CoSAI identifies behavioral anomaly detection as a standard control in its implementation guidance. The requirement is shared and is the strongest area of inter-framework convergence.
Multi-hop delegation chain governance is specified in three of four frameworks. AIGA’s T3 requirements govern Agentlet orchestration. NCCoE’s Access Delegation focus area governs structured delegation across multi-agent workflows. CoSAI’s OBO delegation chain requirement with the MUST NOT expand constraint is the most specific delegation governance specification in the series. Attribit-ID finds ATF does not specify delegation chain mechanics, leaving multi-hop governance as an implementation decision outside the framework’s defined governance elements. This is a partial gap in ATF relative to the other three, not a full absence.
Attribit-ID finds revocation is absent from all four as a defined mechanism with specified triggers. No framework defines when a credential must be invalidated, what event triggers revocation, how revocation propagates down a delegation chain to invalidate derived credentials, or how systems that have cached a revoked credential are notified. The revocation gap is the single most consequential shared absence in the field’s current governance consensus. CoSAI’s Phase 1 agent discovery and registration is the prerequisite that must exist before revocation becomes mechanically possible: you cannot revoke credentials for Actors you have not registered. However, Phase 1’s completion does not produce a revocation mechanism; it produces the inventory that a revocation mechanism would operate against.
Topology-first enforcement, a structural layer that constrains an Actor’s action space before any identity or policy check runs, is absent from all four frameworks. This is the convergence finding’s second component: all four share the verification posture as their governance architecture, and all four stop at the same architectural boundary. The boundary is not where the frameworks were designed to stop. It is where the verification paradigm reaches its structural limit.
The matrix reveals the field’s current state with precision. The floor is well-defined and shared across four independently produced frameworks. The ceiling, the complete operational security posture that includes topology-first enforcement, explicit revocation, and Agentlet governance at the class level, requires three additions that the security architect must supply without framework precedent. The Governing AIgentic Actors: Identity, Trust and Control whitepaper establishes the Actor Identity Lifecycle and topology-first enforcement as the governance disciplines that complete what the frameworks started.
Three architectural additions separate operational security from framework compliance
What is a topology-first enforcement substrate and why does it matter?
A topology-first enforcement substrate is an architectural layer that constrains an AIgentic Actor’s action space before any identity credential is checked or any policy rule is applied. It operates out of band: the Actor cannot detect it, cannot interact with it, and cannot be instructed to bypass it. Its enforcement is structural rather than behavioral: the Actor cannot reach systems it is not authorized to reach because the network topology does not route its traffic to those systems, regardless of what the Actor’s context window contains.
The Semantic Proxy Pattern is the Attribit-ID implementation of this substrate. It interposes a semantic-aware proxy between every AIgentic Actor and every system the Actor might access. The proxy evaluates the Actor’s request against the policy defined for the Actor’s current task, and blocks requests that exceed the task’s authorized scope before they reach the target system. The evaluation is against the task policy, not the Actor’s identity or historical behavior. An Actor that has been prompt-injected cannot exfiltrate data it is not authorized to access because the proxy does not route exfiltration requests to the target system, regardless of whether the Actor presents a valid credential and regardless of whether the exfiltration request falls within the Actor’s general permission scope.
The proxy’s enforcement position, between the Actor and the target system and outside the Actor’s execution environment, is what makes it effective against the failure mode that the verification posture cannot reach. A compromised Actor with valid credentials requesting authorized actions in service of attacker instructions cannot be detected by a governance layer that checks identity and permissions. The proxy does not check identity or permissions. It checks whether the specific request is within the current task’s authorized scope. If it is not, the request is blocked. The audit trail records the block with the Actor’s identity, the target system, the request, and the policy rule triggered. The Actor proceeds to its next action, unaware that the attacker’s instruction was not executed.
This is not a replacement for the verification posture. It is the layer the verification posture’s structural limits make necessary. AIGA’s Immutable Kernel Architecture enforces that an Actor’s code cannot be modified and that logging cannot be disabled. The Semantic Proxy enforces that the Actor’s actions cannot reach systems outside its current task scope. Both enforcements are necessary. Neither can substitute for the other. Together they address the two principal failure modes that prompt injection and indirect context compromise create: in-process integrity (AIGA’s contribution) and external action scope (the Semantic Proxy’s contribution).
How does the Actor Identity Lifecycle complete what the frameworks started?
The Actor Identity Lifecycle is the governance discipline that makes the verification posture operational: a defined sequence of provisioning, scoping, delegation, audit, and revocation applied to every AIgentic Actor, at every deployment, across every environment. The Attribit-ID series anchor whitepaper Governing AIgentic Actors: Identity, Trust and Control establishes the lifecycle as the primary governance instrument.
The four peer frameworks collectively cover four of five lifecycle stages. All four address provisioning in their identity requirements. All four address scoping in their minimum-permission requirements. Three of four address delegation in their authorization chain specifications. All four address audit in their logging and monitoring requirements. None addresses revocation as a defined mechanism with specified triggers and propagation rules. The lifecycle is almost complete in the field’s current governance consensus. The missing stage is also the one that prevents standing privilege from accumulating: without revocation, every governance gain at provisioning and scoping is undone by credentials that persist beyond their authorized task.
Completing the lifecycle requires three capabilities not specified by any framework. The first is a revocation trigger: a defined event (task completion, Agentlet destruction, detected compromise, or time-bound expiry) that initiates the revocation process for a specific credential. The second is a propagation mechanism: an automated process that invalidates credentials derived from the revoked parent credential, so that a revoked orchestrator’s credential does not leave active Agentlet credentials in its delegation tree. The third is a verification gate: a mechanism that downstream systems use to confirm that a credential presented for access has not been revoked by checking the current revocation status rather than relying on the credential’s stated validity period.
CoSAI’s Phase 1 agent discovery and registration is the prerequisite for all three capabilities. A revocation trigger cannot be implemented for Actors that are not registered. Propagation cannot reach derived credentials in a delegation tree that has not been recorded. The verification gate cannot query a revocation status for credentials that are not in a registry. Phase 1 is therefore not the beginning of the governance journey; it is the foundation without which the journey’s remaining steps are structurally impossible.
The Agentlet governance problem requires one addition to the standard lifecycle: governance at the class level before any instance is spawned. Agentlets are not provisioned individually in production pipelines. They are provisioned as a class, with parameters defined at the class level, and instantiated on demand. Governance at the class level means defining the permitted action space, permission scope, delegation authority, and revocation trigger for every Agentlet class before the orchestrator that will spawn them is deployed. This is governance before deployment, not governance applied as a remediation after a deployment decision has already created an operational exposure.
What is the minimum viable implementation for an enterprise deploying agents today?
The minimum viable governance posture for an enterprise deploying AIgentic Actors in 2026 has four components, each derivable directly from the frameworks this article evaluates.
First: every AIgentic Actor requires a unique persistent identity. This is the universal first-class requirement across all four peer frameworks and NHI governance. It is CoSAI’s Phase 1 starting point, NIST NCCoE’s first focus area, ATF’s Identity element prerequisite, and AIGA’s AIGA-ID requirement. Organizations sharing service accounts across Actors or operating with credentials inherited from upstream systems are below the floor that every published governance specification defines. This is the only governance starting point. Nothing else is possible without it.
Second: credentials must be task-scoped and short-lived, approaching zero standing privilege as the operational standard. Each credential is valid for one task at minimum-necessary scope for the duration of that task. When the task ends, the credential expires or is revoked. This single architectural decision eliminates standing privilege as an accumulating risk, satisfies CoSAI’s Phase 2 short-lived token requirement, addresses two of the OWASP NHI Top 10’s risk categories (NHI5:2025 Overprivileged NHI and NHI7:2025 Long-Lived Secrets) simultaneously, and provides the attribution baseline that, in Attribit-ID’s interpretation, DORA Article 10’s anomalous activity detection obligation and EU AI Act Article 14’s human oversight requirement each demand.
Third: the delegation chain must be governed with derived credentials at every hop. Every Agentlet spawned by an orchestrator Actor receives a credential provably derived from the orchestrator’s credential, with permissions provably narrower than the orchestrator’s own authorized scope. RFC 8693 Token Exchange is the implementation path.8 This satisfies CoSAI’s OBO delegation chain requirement, AIGA’s T3 multi-Actor orchestration requirements, and NCCoE’s Access Delegation focus area simultaneously. It also satisfies the loss of Actor clarity threat vector: every access decision in the system carries a credential that names the specific Agentlet that made the request, derived from a chain that ultimately names the human sponsor who authorized the orchestration.
Fourth: immutable audit logs must cover every access decision, every delegation event, and every Actor provisioning and deprovision event. This is the prerequisite for every other governance function: detection, investigation, compliance demonstration, revocation verification, and cross-Actor coordination analysis all depend on a complete audit record that cannot be altered after the fact. AIGA’s Constitutional Constraint that logging cannot be disabled is the most unambiguous statement of this requirement in any published framework. ATF, NCCoE, and CoSAI state equivalent requirements with different language. The requirement is universal.
The topology-first enforcement substrate is not in this minimum viable posture. It is the next layer. The four components above align with what the field’s governance frameworks jointly specify. The topology-first layer is what the security architect adds after the minimum viable posture is operational and production experience reveals that the verification posture alone is not surfacing every compromise before consequential actions are executed. The evidence that this moment arrives is already in the literature. The NIST and UK AISI joint research quantifying a 81 percent attacker success rate against AI agents is that evidence. The minimum viable posture is necessary. It is not sufficient.
Frequently asked questions
What is the difference between the verification posture and topology-first enforcement?
The verification posture is the governance architecture shared across all four peer frameworks: authenticate the Actor, grant minimum permissions, monitor behavior, enforce policy at access decisions. It operates by checking the Actor’s identity and permissions at the moment of access. Topology-first enforcement is an architectural layer that constrains the Actor’s action space before any identity or permission check runs. The verification posture asks whether the Actor has permission to do a specific thing. The topology-first layer asks whether the Actor can physically reach the system it is attempting to access. They address different failure modes and are complementary: the verification posture is necessary for attribution and compliance; the topology-first layer is necessary for structural defense against a compromised Actor with valid credentials.
How should a security leader prioritize across five frameworks simultaneously?
No organization needs to implement all five frameworks simultaneously. The implementation sequence follows the Actor Identity Lifecycle. Start with CoSAI’s Phase 1: agent discovery, registration, elimination of shared accounts, and immutable logging. This requires no new infrastructure and satisfies the first-class identity requirement that all four peer frameworks share. Phase 1 also creates the audit foundation that every subsequent governance function requires. Once Phase 1 is operational, the four framework evaluations in this article provide the specific controls to implement at each subsequent phase, in the sequence the CoSAI roadmap defines.
Does the convergence of four frameworks mean the governance problem is solved?
The convergence confirms that the field has reached consensus on the verification posture. The governance problem is not solved. The convergence finding reveals where the consensus stops, and the gap between the consensus boundary and operational security is where security architect decisions live. Four organizations independently defining the same architecture confirms that the architecture is correct and necessary. It does not confirm that the architecture is sufficient. The convergence finding is a precise diagnostic of field maturity at a specific moment. It is not a declaration of field completion.
Is NHI governance a framework a security leader should implement alongside CSA ATF, IETF AIGA, NIST NCCoE, and CoSAI?
NHI governance is not a peer of the four frameworks. It is the credential architecture that emerges when any one of the four frameworks’ governance intentions is applied to machine-pace credential management. Zero standing privilege and dual-identity credential binding are NHI governance’s core controls. They satisfy requirements that all four peer frameworks impose at the identity and authorization layer. A security leader implementing CoSAI’s OBO delegation chain with short-lived tokens is implementing NHI governance. A security leader implementing AIGA’s T2 scoped credential requirement is implementing NHI governance. The label matters less than the architectural decision: credentials must be ephemeral, scoped, and carry an auditable delegation chain back to a named human sponsor.
What happens when the IETF AIGA draft expires in July 2026?
Draft-aylward-aiga-2-00 expires July 30, 2026 as an individual Internet-Draft. Expiry means the draft has not been renewed or advanced in its current form; it does not invalidate AIGA’s governance architecture. No renewal draft had been filed as of this article’s publication date. The Constitutional Constraints and Immutable Kernel Architecture that AIGA defines are sound architectural specifications regardless of the draft’s IETF standing. If the draft is not renewed, organizations should treat AIGA’s guidance as informational reference rather than standards-track specification. The governance requirements it articulates: non-modifiable kernel code, always-on logging, enforced approval flows, and an operational kill switch, remain best-practice requirements for high-autonomy AIgentic Actors regardless of AIGA’s eventual publication status.
The five frameworks evaluated in this article collectively define the governance floor for AIgentic Actor deployments in 2026. The Actor Identity Lifecycle provides the governance discipline to make that floor operational. The topology-first enforcement substrate provides the architectural layer that closes the gap the floor cannot reach. The security architect’s assignment is to determine which layer to address first, with evidence now available from five independent sources to inform the sequencing. That evidence is clear on one point: the verification posture is the prerequisite. Everything else is built on it.
Footnotes
-
Gartner, cited in CSA Labs, “AI Agent Identity Crisis: Standards Emerge as Enterprises Lag,” Q1 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-okta-ai-agent-iam-framework-enterprise-gap/ Primary Gartner research report is client-access only. ↩
-
CSA and Oasis Security, “The State of Non-Human Identity and AI Security,” January 2026. https://cloudsecurityalliance.org/artifacts/state-of-nhi-and-ai-security-survey-report ↩
-
CSA Labs, “AI Agent Identity Crisis: Standards Emerge as Enterprises Lag,” Q1 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-okta-ai-agent-iam-framework-enterprise-gap/ ↩
-
NIST, “Technical Blog: Strengthening AI Agent Hijacking Evaluations,” January 2025. https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations ↩
-
Palo Alto Networks Unit 42, “Double Agents: Exposing Security Blind Spots in GCP Vertex AI,” March 2026. https://unit42.paloaltonetworks.com/double-agents-vertex-ai/ ↩
-
Aylward et al., “AI Governance Architecture (AIGA),” Individual Internet-Draft, draft-aylward-aiga-2-00, January 2026. https://datatracker.ietf.org/doc/draft-aylward-aiga-2/ Individual submission; not endorsed by IETF; Intended Status: Informational. ↩ ↩2
-
NIST NCCoE, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization,” Concept Paper (Initial Public Draft), February 2026. https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf ↩
-
CoSAI, “Agentic Identity and Access Management,” March 2026. https://www.coalitionforsecureai.org/wp-content/uploads/2026/04/agentic-identity-and-access-control.pdf ↩ ↩2
-
Cloud Security Alliance, “Securing Non-Human Identities in the Age of AI Agents,” RSAC 2025. https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025 (45-to-1 lower bound). Entro Labs, “NHI & Secrets Risk Report H1 2025,” enterprise data collected January–June 2025. https://23579664.fs1.hubspotusercontent-na1.net/hubfs/23579664/Assets/EL-The-NHI-Secrets-Risk-Report-H1-2025.pdf (144-to-1 upper bound, up from 92:1 in H1 2024). ↩
-
OWASP, “Non-Human Identities Top 10, 2025.” https://owasp.org/www-project-non-human-identities-top-10/2025/top-10-2025/ ↩