Agent Identity Framework

An AI agent is not a user. It is not a service. It is not a traditional machine identity. It is a new kind of principal — one that acts with autonomy, makes decisions, delegates authority to other agents, and operates across organizational boundaries. Standard identity frameworks do not have a model for this.

Agent identity is the set of verifiable attributes that uniquely identify an agent, describe its provenance, and allow any system it interacts with to understand who created it, who owns it, what it is authorized to do, and what trust to extend to it. Identity is not the same as authentication — authentication proves the agent is who it claims to be, but identity includes all of the context around that claim.

The AGF Agent Identity Framework establishes a formal model for agent identity that is persistent, portable, cryptographically verifiable, and independent of the model, runtime, or organization that created the agent.

Every agent that operates in a governed environment must have a globally unique, persistent identifier: an Agent ID. Unlike a session token, an API key, or a user ID, the Agent ID is not scoped to a single system or credential store. It identifies the agent as a conceptual entity — a 'thing' that persists across sessions, system upgrades, and organizational transfers.

The Agent ID format is based on Decentralized Identifiers (DIDs) — a W3C standard that enables identifiers to be self-sovereign, cryptographically verifiable, and resolvable without a central registry. An AGF Agent ID takes the form: did:agent:<namespace>:<agent-name>-<version>. For example: did:agent:acme:billing-processor-v3.

The Agent ID is the anchor for all other identity attributes. The Agent Passport is bound to it. Delegation tokens reference it. Audit artifacts include it. Revocation acts on it. The Agent ID is the persistent root — everything else is derived from or associated with it.

The Agent Passport is a cryptographically signed credential bundle that an agent carries across system interactions. It is analogous to a national passport — it doesn't prove you're the right person for every task, but it proves who you are and provides trusted context about you, in a form that any receiving system can verify without calling back to the issuer.

A valid Agent Passport contains: the agent's Agent ID; the owner's identifier (the human or organization responsible); a trust score at time of issuance; a delegation scope statement (what the agent is authorized to do); an expiry; and a chain of signatures from the issuing authority.

Passports are short-lived by design. A passport issued for a session expires with the session. A passport issued for a long-running agent has a maximum validity period — configurable in policy, defaulting to 24 hours — and must be renewed with a fresh trust evaluation. This expiry discipline creates natural checkpoints for re-evaluating whether the agent's identity context is still valid.

Every agent must have an owner: a responsible principal — a human, team, or organization — who is accountable for the agent's actions and lifecycle. Ownership is not the same as the deploying system or the runtime; it is the legal and operational accountability attribution.

Ownership is recorded in the agent's identity record and included in every Agent Passport. It is the anchor for accountability: when an agent causes harm, when a delegation chain must be investigated, or when a compliance report must be produced, ownership is the attribute that connects the agent's actions to a responsible human entity.

Ownership can be transferred — when an agent is acquired by another organization, reassigned to another team, or migrated to a new principal. Transfers are cryptographically attested and recorded in the agent's identity history. The complete ownership provenance of an agent must be reconstructable at any point in its lifetime.

Identity does not imply authorization. Knowing who an agent is does not tell a system what the agent is allowed to do. Authorization is a separate layer — but it is closely bound to identity because authorization is issued against a specific agent identity and cannot be transferred.

The AGF Authorization model uses bounded delegation tokens: short-lived, cryptographically signed assertions that encode not just 'this agent is permitted' but 'this agent is permitted to perform these specific actions on these specific resources, subject to these constraints, until this expiry, under this policy version.'

Scope constraints are enforced at the token level, not just at the PDP. A Finance Agent cannot delegate payment authority to an Invoice Agent if the Finance Agent's own delegation token doesn't include that authority — the sub-delegation is bounded by the parent's scope. This is the principle of least privilege, applied to agent delegation chains.

AGF uses the W3C Decentralized Identifier (DID) specification as the foundation for Agent IDs. DIDs provide several properties that are essential for agent identity: global uniqueness without a central registry; cryptographic verifiability (the DID document contains public keys that can be used to verify signatures); resolvability (any system with the DID can resolve it to the DID document to retrieve identity attributes); and self-sovereignty (the identity is not dependent on any single service remaining operational).

AGF defines the did:agent DID method, which extends the base DID specification with agent-specific attributes: namespace (the organization or domain that manages the agent), name, version, and an optional parent agent reference for sub-agents. The DID document for an agent includes its public keys, service endpoints (PDP endpoints, delegation authorities), and metadata.

DID-based identity enables cross-organizational agent governance: an agent from Organization A can present its Agent Passport to a system in Organization B, and Organization B can verify the identity and trust score without calling back to Organization A's internal systems — a critical requirement for the federated agent economy that is emerging.

Agent ID generation: When provisioning a new agent, generate a keypair and derive the Agent ID using the did:agent method. The private key never leaves the secure enclave where the agent runs. The Agent ID and corresponding DID document are registered with the Domain Authority.

Passport issuance: Issue Agent Passports at session start (or on first interaction with a new system), not at agent creation. Use short expiries (1–24 hours) and require renewal. Include the current trust score at time of issuance — trust scores degrade over time and must be recomputed on renewal.

Ownership records: Maintain ownership records in an append-only log — never delete or overwrite. Each transfer creates a new record referencing the previous owner. The full ownership history must be auditable for the lifetime of the agent plus a retention period defined by your compliance requirements.