Agent Governance Foundation

Why Autonomous Agents Need Their Own Identity Infrastructure

Agent Governance Foundation
identitystandardsarchitecture

When an autonomous agent calls an external API, a fundamental question arises: who is this request from?

Today, the honest answer is: "whoever owns the API key that was loaded into the agent at startup." That answer is inadequate for the kinds of systems we're building.

The problem with API keys for agents

API keys were designed for services — long-running, stable, human-administered processes. They work acceptably for that context because:

  1. The service has a stable operational identity
  2. A human operator is accountable for key rotation and scope
  3. The scope of the key is relatively bounded and well-understood

Agents violate all three assumptions.

Agents are ephemeral. A modern agent might be spawned dozens of times per minute, each instance independent. There's no "the agent" — there are many instantiations of an agent definition, each with a lifecycle measured in seconds to minutes.

Agents spawn other agents. An orchestrator agent might delegate subtasks to specialized agents, each needing some subset of the orchestrator's authority. API keys don't have a delegation model. You can't give a sub-agent "only the write access to the calendar, not the email."

Agents act under instruction. Unlike a service, an agent's actions are shaped in real-time by its instruction context. A prompt-injected agent can be directed to act outside its intended scope. The identity layer needs to constrain what's possible, not just authenticate who is asking.

What agent identity actually needs

A proper identity framework for agents needs to provide:

Persistent root identity. An agent definition — the combination of its model, system prompt, tools, and deployment configuration — should have a stable, verifiable identifier. This is the agent's "birth certificate": it doesn't change between invocations.

Session-scoped credentials. Each invocation gets a short-lived credential derived from the root identity. These expire. They can be revoked. They carry explicit scope.

Cryptographic binding. Both the root identity and session credentials need to be backed by public-key cryptography so that any receiving system can verify them without calling back to a central authority.

Delegation support. When an agent delegates to a sub-agent, the sub-agent should receive a credential that is:

  • Cryptographically bound to the parent agent's identity
  • Narrower in scope than the parent's credential
  • Separately revocable

This is closer to the OAuth 2.0 token exchange model than to an API key. The IETF's RFC 8693 is a useful starting point, though it wasn't designed with agents in mind.

The W3C DID parallel

Decentralized Identifiers (DIDs) offer an interesting model. A DID is a globally unique identifier backed by a DID document that contains public keys and service endpoints. The DID owner controls the document; no central registry is required.

For agent identity, a DID-like structure makes sense at the agent definition level. An agent's root identity document would contain:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:agent:example:billing-automation-v2",
  "verificationMethod": [{
    "id": "#key-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z6Mkf..."
  }],
  "agentMetadata": {
    "modelFamily": "claude-3",
    "toolset": ["calendar-read", "email-send"],
    "deployedBy": "did:org:example:corp"
  }
}

The receiving API can verify that the request came from the agent identified by this document, without trusting an intermediary.

Where we are today

No widely-adopted standard for agent identity exists. Several projects are experimenting with pieces of this:

  • Anthropic's MCP (Model Context Protocol) includes tool authorization primitives
  • Several agent frameworks have internal session management
  • Some enterprise deployments use service account mapping as a workaround

None of these constitute an interoperable standard. An agent that uses Anthropic's tooling today can't be verified by a system built on a different framework tomorrow.

This is the gap the Agent Identity Standard (AIS) is designed to fill. The current draft is available for comment in our GitHub repository. We welcome input from security practitioners, identity standards experts, and agent framework developers.

This post describes work in progress. The AIS specification is in early draft; nothing here should be treated as a finalized standard.

All posts