Version: v0.1
Status: Specification suite complete; pending Zenodo deposit
Spec home: aegis-governance.com/identity/
RFC: RFC-0019 — Draft
License: CC-BY-SA-4.0
What it is
AIAM-1 is the AEGIS Initiative’s specification for identity and access management at the AI-agent layer. It introduces:
- aIAM — AI agent IAM as a distinct identity category, parallel to but separate from human IAM and service-account IAM. Agents are first-class principals, not service-account proxies for the humans who deployed them.
- IBAC — Intent-Bound Access Control, an authorization model that adds an explicit intent dimension to the standard identity-and-action authorization predicate. Authorization becomes
f(identity, action, intent context)— distinct from RBAC’sf(role, action), ABAC’sf(attributes, action), or PBAC’s purpose-based access control.
Why it exists
Existing IAM frameworks were designed for humans (with persistent identities and stable purposes) and for services (with narrow, declared functional scopes). Autonomous agents fit neither. They have ephemeral session-scoped identities, broad capability sets, and intent that varies per action — and the consequences of a misauthorized action can extend through delegation chains across multiple principals.
AIAM-1 names the structural primitives needed to govern this: composite identity (agent + session + principal chain), intent claims (structured purpose assertions at moment of action), authority (capability scope under IBAC), delegation (multi-step principal chains with depth limits), attestation (action-level governance decision proofs), and revocation (mid-session capability invalidation).
What’s in v0.1
| Chapter | Topic |
|---|---|
| 1 | Identity Model — composite identity, sessions, principals |
| 2 | Intent Claims — structured purpose assertions |
| 3 | Authority (IBAC) — Intent-Bound Access Control |
| 4 | Capabilities — capability schema and lifecycle |
| 5 | Delegation — multi-step principal chains |
| 6 | Sessions — session structure and scope |
| 7 | Attestation — action-level governance decision proofs |
| 8 | Revocation — mid-session capability invalidation |
| 9 | Interoperability — relationship to RBAC, ABAC, PBAC, OAuth, OIDC |
| 10 | Threat Model — AIAM-1 specific failure modes |
| 11 | Conformance — how to claim AIAM-1 conformance |
| 12 | Open Questions — items deferred to v0.2 |
Five JSON Schemas accompany the chapters: identity, intent claim, authority, capability, attestation. All schemas are committed to aegis-core/schemas/aiam/ and validated by the runtime test suite.
Distinctions worth noting
- Principal vs Actor. AIAM-1’s Principal is the human, organization, or legal entity accountable for agent actions. AGP-1 / ATM-1’s Actor is any entity submitting an action proposal. They are different abstractions; do not conflate.
- Intent claim vs ACTION_PROPOSE parameters. AIAM-1 §3.2’s intent claim is an explicit assertion of purpose. AGP-1’s
ACTION_PROPOSEparameters carry implicit intent through their structure but are not the same construct. - Attestation, scoped two ways. AIAM-1 §3.7 attestation is action-level (proof of one decision). GFN-1 governance attestation is node-level (proof of an entire AEGIS node’s posture). Same word, different scope.
Status and next steps
- v0.1 specification suite is complete.
- RFC-0019 is the reference document.
- Zenodo deposit is queued — DOI will be minted once the deposit lands.
- AIAM-1 v0.1 — position paper at aegis-governance.com/foundation/ (forthcoming as a published artifact).
Closest prior art
PBAC (Purpose-Based Access Control), Byun et al. (2005) — the closest prior art to IBAC. PBAC binds authorization to declared purpose at policy-write time; IBAC adds intent context at action-evaluation time. Differences are documented in AIAM-1 §9 (Interoperability).