Attribit-ID framework
AIgentic Actor Identity: The Enterprise Control Framework
Trust in AI agents starts with identity. AIgentic actors — AI agents and their subordinate Agentlets — are becoming operational participants in enterprise environments, executing tasks, calling APIs, spawning other agents, and accessing sensitive data. Without explicit identity governance, every AIgentic actor in your environment is running on inherited permissions, with no lifecycle, no audit trail, and no clear accountability. This framework defines the model enterprises need to provision, delegate, audit, and revoke the identities of every AIgentic actor they deploy.
The Actor ontology
From humans and applications to Actors
Traditional IAM was built for two entity types: humans and applications. The application was the gatekeeper — mediating all downstream access, enforcing authorization logic, and providing a natural audit point. AI agents dissolve that model. They call APIs directly, bypass the application layer entirely, and spawn hierarchies of subordinate actors that each require their own identity.
This requires a new ontology. Attribit-ID organizes all enterprise entities under a single superset — the Actor — with identity defining the subcategories.
A person with an identity governed through HR workflows, lifecycle management, and biometric-grade authentication. HR is the issuing authority.
A system or workload with a provisioned identity, governed by IT and DevOps through certificates and service accounts. The development and operations function is the issuing authority.
An autonomous agent operating on behalf of a human or application principal, requiring explicitly provisioned identity, delegated scope, runtime constraints, and a governed lifecycle. Most organizations have not yet established an issuing authority for this class.
Agentlet
A specific subtype of AIgentic actor: a spawned sub-agent, purpose-specific and subordinate — analogous to a thread or daemon in traditional computing. An orchestrator agent spawning three Agentlets to complete a task creates four distinct principals, each requiring their own identity. Without explicit governance, all four run on inherited permissions from the original human principal, creating a delegation chain with no natural limits.
The four-layer architecture
The identity infrastructure AIgentic systems require
A coherent response to AIgentic identity pressure is taking shape across the industry, built on four complementary layers that each address a distinct aspect of the problem. These layers compose into a complete control stack for both human and AIgentic actors.
- 01
Directories — onboarding and type classification
LDAP/Active Directory retains its role, narrowed to onboarding and type classification. The critical discipline is structural separation: AIgentic actors and humans must occupy distinct organizational units with different object schemas, different lifecycle owners, and different issuing processes. The moment these processes share infrastructure, the human/non-human identity distinction becomes unenforceable downstream.
- 02
Workload PKI — cryptographic identity at runtime
SPIFFE/SPIRE provides AIgentic actors with cryptographic identities that encode what a workload is rather than who a person is. Short-lived certificates enforce rotation and limit the blast radius of compromise. The CA hierarchy for AIgentic actors is physically separate from the CA hierarchy for humans — a relying party can inspect the issuing chain and immediately determine principal class.
- 03
Verifiable Credentials — delegation semantics
Verifiable Credentials carry the delegation semantics that PKI cannot express natively. A VC issued to an AIgentic actor encodes the full principal chain — who authorized this actor, under what constraints, and for how long — as a cryptographically signed, self-proving document. Chained VCs make the Actor Identity Lifecycle auditable end-to-end without requiring a shared directory or bilateral federation agreement between organizations.
- 04
Decentralized Identifiers — cross-organizational trust
DIDs and the DIF Universal Resolver complete the picture for cross-organizational trust. A DID resolves to a DID Document containing the entity's public keys and authentication methods, with no CA required. For cross-organizational AIgentic interactions, this eliminates the need for shared CA roots or bilateral federation agreements — the VC carries the trust, the resolver provides the key material.
The default failure mode
The Identity Inheritance Model
By default, AI agents operate as extensions of their human principal — inheriting both identity and permissions, acting as a proxy for the human rather than as a distinct actor. No explicit provisioning required; no explicit revocation required either. The agent simply inherits what the human has, and acts within it.
This creates an inheritance chain risk: human → agent → Agentlet, with rights flowing down the delegation chain unrestricted unless explicitly governed. Everyone defaults to the inheritance model because it requires no work. The risk is not yet widely understood — but the control gap is real and growing with every AIgentic deployment.
Identity Inheritance Model
- Agent runs on human principal's credentials
- Rights flow down unconstrained
- No lifecycle separate from the human's
- No audit trail specific to agent actions
- Revocation requires revoking the human's access
Explicit Actor Identity
- Agent provisioned with its own identity
- Delegation scope explicitly defined and bounded
- Actor Identity Lifecycle: provisioning → audit → revocation
- Audit trail tied to the actor, not the human
- Revocation is targeted and independent
The governance question for every AIgentic actor in your environment is always the same: was this identity and its rights explicitly designed, or implicitly inherited?