What Is AI Agent Identity?

When a developer asks "who is this agent?", the usual answer is: an API key, a service account, or a process running on a server. None of these answers are agent identity. They are infrastructure identity — they identify a deployment environment, not the specific autonomous process making decisions.

AI agent identity is a different concept. It is the binding between a named, registered agent instance and every action that instance takes — provable without trusting the agent itself.

The Problem with API Keys as Agent Credentials#

Most production agents authenticate to downstream services the same way: environment variables containing API keys.

stripe.api_key = os.environ["STRIPE_SECRET_KEY"]
openai.api_key = os.environ["OPENAI_API_KEY"]

This authentication model has three fundamental flaws for autonomous agents:

Shared credentials. One API key typically authenticates multiple agents, multiple processes, and sometimes multiple services. When an incident occurs, you cannot determine which specific agent instance made which calls. The API key tells you "something with this key did this" — not which agent, not which task, not which prompt led to it.

No action-level scope. A Stripe API key either has access to the full API or it doesn't. There is no mechanism to say "this specific agent can only call charge with amounts under €200 and only for EUR-denominated transactions." The key grants access; it cannot restrict usage.

No revocation granularity. Revoking an API key breaks every agent and service using it. There is no way to revoke access for one compromised agent instance without disrupting the entire system. Rotating credentials is a blunt instrument.

What Cryptographic Agent Identity Provides#

True agent identity is built on asymmetric cryptography. Each agent gets an Ed25519 keypair at registration:

• ▸Private key: Stored by the agent, never transmitted. Used to sign every action request.
• ▸Public key: Registered server-side with the agent's ID, name, and policy bindings.

When the agent makes a request, it includes a cryptographic signature over the canonical JSON representation of the request. The verify gate checks this signature against the registered public key.

Request: {
  "agent_id": "agt_01JXMK9P2Q3R4S5T6U7V",
  "action": "create_charge",
  "payload": {"amount": 150, "currency": "EUR"},
  "timestamp": "2026-01-22T14:23:01.442Z",
  "nonce": "a7f3c9d2e1b4"
}

Signature (Ed25519): base64url(sign(private_key, canonical_json(request)))

This signature is unforgeable without the private key. It cryptographically proves:

1. ▸This specific registered agent (not just "something with this API key") made this request
2. ▸The request payload was not modified in transit
3. ▸The request was created at a specific timestamp (replay protection via nonce)

The Four Properties of Agent Identity#

Well-designed agent identity has four properties that distinguish it from infrastructure credentials:

1. Instance-level binding. Identity is bound to a specific agent instance — a named, registered entity with a declared purpose, policy set, and audit trail. Not to a role, not to a service account, not to a deployment environment.

2. Action-level scope. The identity carries policy information: what this agent is allowed to do, what it's explicitly denied, what limits apply. The identity and the authorization are unified.

3. Verifiable provenance. Every action signed with the agent's private key creates an unforgeable record of provenance. The audit log entry is not "user 12345 did X" but "agent checkout-assistant-v2, instance agt_01JXMK9P2Q3R4S5T6U7V, signed this action at this timestamp, and the signature verifies."

4. Independent revocability. The agent's identity can be revoked without touching the underlying infrastructure credentials. The verify gate returns DENY for all subsequent requests from that agent ID, regardless of what credentials the agent uses to connect to downstream services.

Agent Identity vs. Service Account Identity#

The closest existing concept is the service account — a non-human identity used by automated processes. Cloud providers offer them: AWS IAM roles, GCP service accounts, Azure managed identities. Why isn't this sufficient for AI agents?

Service accounts answer the question: What AWS APIs can this process call?

Agent identity answers the question: What specific actions can this specific autonomous decision-making process take, with what parameters, at what frequency, with what observable justification?

AWS IAM can grant an agent the s3:PutObject permission. It cannot enforce "this agent may only write objects with names matching the pattern reports/daily-*.csv and only between 01:00 and 03:00 UTC." Agent identity can.

More critically: AWS IAM has no concept of an audit log that chains every agent decision to a cryptographic proof of the policy version that authorized it. Service accounts don't generate tamper-evident evidence. Agent identity does.

Short-Lived Capability Tokens#

Agent identity is persistent — the Ed25519 keypair lives for the agent's lifetime. But the authorization to perform a specific action should be short-lived.

When the verify gate approves an action, it issues a capability token: a signed JWT scoped to that specific action, with a 5–30 minute TTL.

{
  "jti": "cap_01JXMK9P...",
  "agent_id": "agt_01JXMK9P2Q3R4S5T6U7V",
  "action": "create_charge",
  "constraints": {
    "max_amount": 150,
    "currency": "EUR"
  },
  "iat": 1737554581,
  "exp": 1737554881
}

This token is presented to the downstream service (Stripe, Salesforce, your internal API) when the action executes. The service validates the token signature against the KYA public key. If the token is expired, invalid, or has been revoked, the action is rejected — even if the agent has a valid Ed25519 identity.

This is the principle of least privilege applied to autonomous agents. The agent doesn't carry long-lived authorization. It requests capability tokens for specific actions, which expire after use.

Lifecycle of Agent Identity#

Agent identity has a defined lifecycle:

Registration → Active → Suspended → Revoked
                  ↕
            Policy Update

Registration: The agent's Ed25519 public key is registered with a name, environment tag, and initial policy. The agent receives its ID. No capability tokens can be issued until registration is complete.

Active: The agent can request capability tokens by presenting signed requests. The verify gate evaluates each request against the current policy version.

Suspended: The agent cannot initiate new actions, but in-flight capability tokens remain valid until expiry. Used for graceful shutdown during deployments.

Revoked: All verify calls for this agent ID return DENY immediately. In-flight capability tokens are added to a Redis blacklist. The agent is effectively dead — no new actions possible, no existing tokens honored.

Why This Matters for Compliance#

Compliance frameworks — SOC 2, ISO 27001, GDPR, HIPAA — require evidence of access control. For human users, this means login logs and session records. For AI agents acting in production, it means something more specific: a tamper-evident record of every decision, the policy version that authorized it, and the cryptographic proof that this specific agent made this specific call.

Agent identity is the foundation of that record. Without it, your audit log says "something happened." With it, your audit log says "agent checkout-assistant-v2 (agt_01JXMK...), operating under policy version pol_03, requested and was granted permission to charge €150 to customer cus_xyz at 14:23:01 UTC on 2026-01-22, under the daily limit of €10,000 (€2,340 used at time of decision)."

That's the difference between compliance-adjacent logging and actual audit evidence.

Related: AI Agents Are the New Root Users · Why LLM Agents Need Cryptographic Identity · Agent Authorization vs Human IAM