This article is part of a series examining how the field’s leading governance frameworks address identity, trust, and control for AIgentic systems. The central thesis, established in Governing AIgentic Actors: Identity, Trust and Control, is that the governance problem in AIgentic systems is not solved by verifying Actors more carefully; it is dissolved by building environments where the scope of what an Actor can do is constrained before any verification occurs. Each article in this series evaluates one framework against that thesis: what it contributes, where its verification posture reaches a structural limit, and what a security leader must add to close it.
Our research shows the IETF’s AIGA draft is the most architecturally specific governance specification for AI agents published to date. Most governance frameworks organize around principles. AIGA specifies infrastructure: hardware isolation requirements by tier, approval latency targets, Constitutional Constraints with CANNOT and MUST language, and a proprietary identity format with X.509 certificate issuance. The architectural evaluation question is precise: does in-process kernel enforcement, even when cryptographically protected, address the right structural problem?
The answer requires understanding what the Immutable Kernel Architecture does, what it cannot do, and what four additions a security architect must make to close the remaining gaps.
Tiered Risk-Based Governance. Five tiers (T0 through T4) based on potential for harm, financial impact, data sensitivity, autonomy, self-modification capability, and irreversibility of actions. Each tier specifies hardware isolation requirements and approval latency targets.
Immutable Kernel Architecture. A Trusted Computing Base the agent cannot modify, containing four components: a Policy Enforcer, an Action Interceptor, an Audit Logger, and an Authority Client. The kernel intercepts code execution, network operations, file system modification, process creation, cryptographic operations, and resource allocation.
Constitutional Constraints. Four hard rules: kernel code CANNOT be modified, logging CANNOT be disabled, action approval for T2 and above CANNOT be bypassed, and a kill switch MUST be implemented. For T2 and above, the kernel MUST run inside a Trusted Execution Environment (TEE) or Hardware Security Module (HSM).
Action-Based Authorization. The kernel intercepts each action, checks its local policy cache, and requests approval from the central Authority for uncached actions. T3 and T4 operations block synchronously, with a 100-millisecond approval target. T1 and T2 operations use an asynchronous model, with the kernel returning “pending” while the Authority evaluates. The Authority responds ALLOW, DENY, or DEFER_TO_HUMAN.
AIGA-ID and Identity Chain. Each agent holds a unique identifier: aiga:1.0:<region>:<tier>:<uuid>:<fingerprint>. The central Authority issues an X.509 certificate binding the AIGA-ID, tier, and identity public key. For T2 and above, the private key must be non-exportable inside a TEE or HSM. At T3, peer-attested identity rotation requires supermajority consensus (greater than 75% of peers) to validate new keys.
The components are mutually reinforcing. The tier determines the hardware substrate. The Constitutional Constraints are enforced by the kernel on that substrate. The AIGA-ID and X.509 certificate make every action attributable to a specific tier-credentialed instance.
What does the IETF AIGA draft establish architecturally?
AIGA’s most precise contribution is the Constitutional Constraints. The CANNOT and MUST language is unusually specific for a governance specification. Most frameworks state principles; AIGA names four properties that admit no exceptions. A security architect reading the T2 requirement knows exactly what the deployment must include: a certified TEE or HSM, agent private key non-exportable, kernel enforcement non-bypassable, logging non-disableable. That specificity enables an audit.
The five tiers advance the state of the field. The CSA Agentic Trust Framework defines a four-tier maturity model (Intern through Principal) based on governance readiness and earned autonomy.1 AIGA’s five tiers classify by assessed potential for harm and required infrastructure. The approaches are complementary: ATF governs how much autonomy an organization grants an agent; AIGA governs what infrastructure is required to enforce that grant. The CSA Agentic Trust Framework: An Evaluation describes the ATF model in full.
The AIGA-ID format is the most concrete identity specification in any current AI agent governance draft. Each identifier encodes the tier, region, and cryptographic fingerprint directly. The central Authority issues X.509 certificates binding identifier to public key to tier, and liveness tokens on each check-in: T0 every 24 hours, T1 every hour, T2 every 5 minutes, T3 and T4 continuously. At T3, peer-attested identity rotation requires supermajority consensus to validate new keys. That mechanism addresses permanent identity theft without centralized key recovery.
AIGA draft-aylward-aiga-2-00 is an individual Internet-Draft, Intended Status: Informational, published January 26 2026, expiring July 30 2026.2 It has no formal IETF working group or standards-track standing. Security architects should treat it as a precise directional signal, not as normative guidance.
Where does in-process enforcement reach a structural limit?
The Immutable Kernel runs as a Trusted Computing Base inside the agent’s execution environment. That placement is the source of its strength and its limit. The kernel is tamper-resistant at the hardware layer: TEE isolation for T2 and above means kernel code cannot be modified by the agent’s model-layer processes. The Constitutional Constraints cannot be disabled from within the agent’s context.
The kernel enforces what the agent is permitted to do. It does not detect whether the agent’s semantic state has been compromised.
An agent that has been prompt-injected presents a valid AIGA-ID, holds a current liveness token, and satisfies the kernel’s policy checks while executing attacker instructions. The kernel permits the action because the action falls within approved policy. The credential is authentic. The behavior is not. This is not a design flaw in AIGA; it is a structural property of all in-process enforcement. An enforcement layer that operates inside the attack surface of the entity being controlled cannot detect that the entity’s intent has changed.
The topology-first architectural design pattern addresses this at the network layer. The Semantic Proxy Pattern describes the mechanism: an AIgentic Actor inside a subnet with deny-all egress traverses only the semantic proxy, which operates out-of-band and is invisible to the primary Actor. A prompt-injected Actor cannot disable the proxy because it cannot perceive the proxy’s existence. The security control operates entirely outside the attack surface of the entity being controlled. The Immutable Kernel enforces what the agent can do within its permitted action space. The topology constrains what action space is reachable before any kernel evaluation occurs.
These two mechanisms are not competing. They answer different structural questions. The kernel enforces policy at the agent layer. The topology enforces structural impossibility at the network layer. AIGA specifies a Network-level Quarantine for T4 agents; the draft does not specify deny-all egress routing with mandatory proxy traversal as a general enforcement substrate for T0 through T3.
What does a security architect need to add to make AIGA operational?
AIGA specifies what governed agent deployments look like. Making that specification operational requires four additions the draft does not prescribe.
The first is a topological enforcement substrate. Deny-all egress routing with mandatory semantic proxy traversal makes AIGA’s governance model hard at the network layer, not only at the kernel layer. An AIgentic Actor constrained by network topology cannot route around the proxy regardless of its credential state or kernel configuration. This is an infrastructure decision made at deployment time. Retrofitting deny-all egress into a production agentic environment (after agents are already running on service accounts with direct network access to internal systems) is a migration problem of the first order.
The second is per-Actor cryptographic delegation between agents. AIGA specifies AIGA-ID and X.509 certificates for per-instance identity and liveness. It does not specify how delegation relationships are encoded and verified when one AIgentic Actor acts on behalf of another. The IETF OAuth On-Behalf-Of draft introduces the act claim and requested_actor parameter to carry delegation semantics inside the token itself, making the authorization chain auditable at every hop.3 That mechanism fills the delegation gap AIGA leaves open in multi-agent architectures.
The third is the Actor Identity Lifecycle applied as an operational discipline. AIGA specifies agent registration, liveness check-in frequency, and credential rotation for T3 and above. The Actor Identity Lifecycle is the full governance sequence: provisioning, scoping, delegation, audit, and revocation, applied to every AIgentic Actor in the environment, including Agentlets. AIGA provides the registration and liveness components. The scoping and revocation components require explicit operational processes the draft does not prescribe.
The fourth is explicit governance of Agentlets. AIGA governs agents as discrete T0-T4 principals, each with its own AIGA-ID, X.509 certificate, and check-in schedule. An orchestrator at T2 may spawn dozens of short-lived Agentlets to complete a single task. None of them will be individually registered with the central Authority or assigned their own tier credentials. Governing the AIgentic Actor population requires governance at the Actor class level: what kind of Agentlet is permitted to spawn, with what inherited scope, what maximum lifetime, and what authorization requirements. AIGA’s per-instance model is a foundation, not a complete answer for multi-agent architectures.
The Governing AIgentic Actors whitepaper presents the full framework: Actor Identity Lifecycle, topological enforcement, per-Actor cryptographic delegation, and explicit Agentlet governance, as a complete operational answer to the governance problem AIGA defines.
Frequently asked questions
What is the difference between AIGA’s Tiered Risk-Based Governance and the CSA ATF maturity model?
The CSA ATF maturity model (Intern, Junior, Senior, Principal) classifies agents by governance maturity: autonomy is earned through demonstrated oversight readiness. AIGA’s five tiers classify by assessed potential for harm and required infrastructure capability: higher-risk agents require more isolated hardware and faster approval gates. ATF asks whether the agent has earned the trust its autonomy requires. AIGA asks whether the deployment has the hardware to enforce what that risk tier demands. Both questions are necessary; neither alone is sufficient.
Does the Immutable Kernel Architecture replace the need for a topology-first enforcement substrate?
No. The Immutable Kernel enforces what the agent is permitted to do within its configured action space, operating inside the agent’s execution environment. The topology-first architectural design pattern constrains what the agent can reach at the network layer, operating out-of-band and outside the agent’s attack surface. The kernel cannot prevent a prompt-injected AIgentic Actor from attempting a permitted action in service of attacker instructions. The topology constrains what actions are structurally reachable regardless of the agent’s semantic state. The two mechanisms are complementary, not substitutable.
How does AIGA’s AIGA-ID relate to SPIFFE SVIDs or OAuth OBO tokens?
They address different layers of the identity stack. A SPIFFE Verifiable Identity Document (SVID) provides a short-lived cryptographically verifiable workload identity, attesting that a given workload is running in a verified environment.4 An OAuth On-Behalf-Of token encodes the delegation relationship between principals: the act claim identifies the acting agent, and the sub claim identifies the delegating principal.3 An AIGA-ID encodes the agent’s governance tier and cryptographic fingerprint in the identifier itself, with the central Authority issuing X.509 certificates that bind identifier to public key to tier. These are complementary specifications: AIGA-ID for tier-bound governance identity, SPIFFE SVIDs for workload attestation, OAuth OBO for delegation chain encoding across agent hops.
Does AIGA governance cover Agentlets spawned by orchestrators?
Not directly. AIGA governs agents as discrete T0-T4 principals, each individually registered with the central Authority. Agentlets spawned by an orchestrator to complete subtasks are not individually assigned AIGA-IDs or tier credentials in the current draft. Security architects deploying multi-agent systems need governance at the Actor class level: what kind of Agentlet is permitted to spawn, what scope it inherits from the orchestrator, and what its maximum TTL is. Per-instance registration for every ephemeral Agentlet is not operationally tractable at production agentic scale.
Footnotes
-
Cloud Security Alliance / MassiveScale.AI. “The Agentic Trust Framework: Zero Trust Governance for AI Agents.” February 2026. https://cloudsecurityalliance.org/blog/2026/02/02/the-agentic-trust-framework-zero-trust-governance-for-ai-agents ↩
-
IETF. “AI Governance and Accountability Protocol (AIGA), draft-aylward-aiga-2-00.” Individual Internet-Draft, Intended Status: Informational. Published January 26 2026, expires July 30 2026. https://www.ietf.org/archive/id/draft-aylward-aiga-2-00.html ↩
-
IETF. “OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents, draft-oauth-ai-agents-on-behalf-of-user-01.” Individual Internet-Draft. https://www.ietf.org/archive/id/draft-oauth-ai-agents-on-behalf-of-user-01.html ↩ ↩2
-
SPIFFE. “The SPIFFE Standard.” https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ ↩