RFC-0019: AIAM-1 — Identity and Access Management for AI Agents

RFC: RFC-0019
Status: Draft
Version: 0.1.0
Created: 2026-04-10
Updated: 2026-04-10
Author: Kenneth Tannenbaum, AEGIS Initiative
Repository: aegis-governance
Target milestone: Q2 2026
Supersedes: None
Superseded by: None

Summary

This RFC introduces AIAM-1, a normative specification for identity and access management for AI agents (aIAM). AIAM-1 defines composite identity claims, structured intent assertions, Intent-Bound Access Control (IBAC), capability composition governance, delegation principal chains, session governance boundaries, tamper-evident attestation, and kill-switch revocation — the full set of IAM primitives required to govern autonomous AI agents as a distinct actor class. AIAM-1 is designed to be implemented independently of the AEGIS governance runtime while integrating cleanly with AGP-1, ATX-1, ATM-1, and GFN-1 when deployed within the AEGIS ecosystem.

Motivation

Existing identity and access management frameworks were built for two actor classes: humans and service accounts. AI agents are a third actor class that violates the assumptions underlying both — their identity is durable but their intent is not, their authorization cannot be static because their goals shift within a single session, and accountability cannot rest on the agent itself.

The AEGIS specification family currently has no normative definition for agent identity, intent, or delegation:

• AGP-1 uses actor.id as an opaque string with actor.type and actor.role. This is sufficient for governance decisions that do not require identity depth, but cannot answer: what model powers this agent? On whose behalf does it act? Why is it taking this action?
• ATM-1 defines threat actors and attack vectors but does not specify identity claims, intent validation, or delegation chains.
• GFN-1 defines DID-based identity for federation nodes, not for governed agents.
• RFC-0003 defines role-based capability scoping. Role-based authorization is insufficient for agents whose goals shift dynamically within a single operational session.
• RFC-0004 defines the two-layer trust model (threat detection + reputation) but does not specify how agent identity feeds into trust evaluation.

The Agents of Chaos study (Shapira et al., 2026) [12] documented production failures that AIAM-1 directly addresses:

• Case Study #8 (Owner Identity Spoofing): Cross-channel identity spoofing succeeded because the agent inferred identity from display names, not cryptographic claims.
• Case Study #10 (Agent Corruption): A non-owner manipulated an agent’s governance by editing an external document the agent treated as authoritative. The delegation was implicit, unattested, and unaccountable.
• Case Study #11 (Libelous Broadcast): An attacker’s instructions propagated through an invisible delegation chain (attacker → compromised agent → recipient agents → broadcast actions).

AIAM-1 makes these failure modes structurally addressable through composite identity, IBAC, and principal chains.

Guide-Level Explanation

AIAM-1 introduces three concepts that are new to the AEGIS specification family:

1. Composite Identity

An AIAM-1 identity claim is a four-dimensional composite: model provenance (what model?), orchestration layer (what framework?), goal context (what purpose?), and principal (whose accountability?). This is the rich backing record that an AGP-1 actor.id resolves to. AGP-1 doesn’t change — AIAM-1 gives it depth.

2. Intent-Bound Access Control (IBAC)

IBAC evaluates every authorization decision as a function of three inputs: identity, action, and intent context. This is a categorical extension of RBAC (which asks “what role?”) and ABAC (which asks “what attributes?”). IBAC asks “why are you doing this, right now, in this context?” — making intent a first-class input to every authorization decision.

IBAC generalizes prior models: an RBAC policy is an IBAC triple with wildcard intent. Organizations can adopt IBAC incrementally.

3. Principal Chains

When Agent A delegates to Agent B, the delegation creates an explicit, attested link in an accountability chain. Authority narrows monotonically down the chain. The principal at the top (always a human, organization, or legal entity) remains accountable for all actions taken anywhere in the chain. Principal chains are what make multi-agent delegation auditable.

What Changes for AEGIS Developers

• AGP-1 implementations that adopt AIAM-1 resolve actor.id to composite identity claims and add intent claims alongside ACTION_PROPOSE messages.
• AGP-1 implementations that do not adopt AIAM-1 continue to function unchanged.
• The governance gateway gains IBAC policy evaluation as an extension of existing policy evaluation.
• Attestation records gain identity, intent, and principal chain fields.
• All extensions are additive. Nothing in the existing spec family breaks.

Reference-Level Explanation

The full AIAM-1 specification is a 12-chapter document suite located at aiam/:

JSON schemas for AIAM-1 are currently located at aegis-core/schemas/aiam/. Shared cross-repository contracts are canonically owned by aegis/schemas/; AIAM-specific schemas in this repository should be treated as governance-owned extension artifacts until they are promoted into the canonical shared schema set.

• identity_claim.schema.json
• intent_claim.schema.json
• attestation_record.schema.json

The position paper is located at docs/position-papers/aiam/AIAM-1-position-paper-v0.1.md.

Drawbacks

1. Complexity. AIAM-1 adds 80+ normative requirements. Organizations with simple single-agent deployments may find the full specification disproportionate to their governance needs. Mitigation: future versions may define constrained conformance profiles.

2. Intent claim overhead. Every action must carry a structured intent claim. For high-frequency agents (thousands of actions per minute), intent claim generation and validation add latency and storage. The performance impact is not yet characterized.

3. Intent spoofing is an open problem. AIAM-1 provides detection mechanisms but cannot guarantee that intent claims correspond to actual reasoning. This is a fundamental limitation of governing opaque probabilistic systems, not a design flaw, but it bounds what IBAC can guarantee.

4. No existing implementations. AIAM-1 v0.1 is a specification without a reference implementation. Until implementations exist, conformance claims are theoretical.

5. Policy language not standardized. AIAM-1 does not mandate a specific IBAC policy language. This flexibility may create interoperability challenges across implementations. Candidate languages (Rego, Cedar, XACML) are identified for evaluation in v0.2.

Alternatives Considered

1. Extend AGP-1 directly. Rather than creating a new specification, identity and intent primitives could be added to AGP-1. Rejected because: AIAM-1 is designed to be standalone (implementable without AEGIS), which AGP-1 extensions could not be. Additionally, the scope of identity + intent + delegation + session + attestation + revocation would bloat AGP-1 beyond its governance-protocol focus.

2. Adopt an existing aIAM standard. No existing standard addresses AI agent IAM as a distinct problem. OAuth 2.1, OIDC, SCIM, and XACML were designed for humans and service accounts. AIAM-1 interoperates with all of them but addresses a fundamentally different actor class.

3. ABAC with agent-specific attributes. Extend ABAC to include agent-relevant attributes (model version, framework, etc.) without introducing intent as a first-class input. Rejected because: ABAC without intent cannot distinguish between two identical actions taken for different purposes — the exact failure mode that Agents of Chaos documented.

Compatibility

• Breaking changes: None. AIAM-1 is entirely additive to the existing specification family.
• Deprecations: None.
• Backwards compatibility: AGP-1 implementations without AIAM-1 continue to function unchanged. actor.id remains an opaque string. Capability grants remain role-based. All existing governance decisions remain valid.

AIAM-1 adoption is opt-in. The specification enriches AGP-1 when present but does not require it.

Open Questions

1. Intent claim verifiability (fundamental research question).
2. Policy language standardization (Rego, Cedar, XACML evaluation).
3. Cross-organization delegation (bilateral trust primitives).
4. AIAM-1 identity claim ↔ GFN-1 DID integration binding.
5. Constrained conformance profiles for edge/IoT deployments.
6. Reference implementation timeline and target language.

Implementation Notes

Implementation guidance is provided in the AIAM-1 Specification Suite. Reference implementation is deferred to the aegis-core runtime roadmap.

Success Criteria

1. Identity claims are verifiable at the governance gateway without external round-trips.
2. Intent-Bound Access Control decisions complete within the AGP-1 SLO budget.
3. Principal chain delegation is auditable end-to-end through the governance event log.

References

• AIAM-1 Specification Suite
• AIAM-1 Position Paper
• [12] N. Shapira et al., “Agents of Chaos,” arXiv:2602.20021, Feb. 2026.
• J.-W. Byun, E. Bertino, and N. Li, “Purpose Based Access Control of Complex Data for Privacy Protection,” ACM SACMAT, 2005.

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative — AEGIS Operations LLC