What Is AI Agent Identity? A Model for Authorizing Real Actions

Main claim: An AI agent identity becomes enforceable when the executing system verifies both which agent is acting and whether that identity may authorize the exact requested action.

An agent can present valid credentials and still request the wrong action. Authentication identifies the caller. Action authorization determines whether a production deployment, payment, or database change matches the authority granted to that caller. This distinction matters when agents can create effects. This article defines AI agent identity, shows where identity controls stop, and gives a model for enforceable action authorization.

What is an AI agent identity?

An AI agent identity is a stable, verifiable representation of an agent that other systems use to authenticate requests and attribute actions. The identity may be linked to a workload, an application, an owner, a tenant, or a delegation from a human.

Standards for AI agent identity remain fragmented. NIST's 2026 concept paper asks how organizations should identify agents, authorize them, audit their actions, and support non-repudiation. These open questions show that the architecture is still developing.

This model gives an AI agent identity four parts:

1. An identifier that distinguishes the agent from other actors.
2. A credential or key that lets the agent prove control of that identity.
3. An owner or authority chain that explains who created or delegated the identity.
4. A lifecycle that supports creation, rotation, suspension, and retirement.

These parts establish who the agent is and who is responsible for it. A separate authority definition governs what the agent may do in one specific request.

What does a cryptographic identity prove?

A cryptographic identity proves control of a key and binds that key to signed data. Signature verification identifies the signing key and detects changes to the covered bytes.

A valid signature establishes that a key signed specific bytes. Business validity, intent, freshness, and policy compliance come from verifier checks over those bytes and their context.

Consider an agent that signs this request:

{
  "action": "deploy",
  "service": "billing",
  "environment": "production",
  "artifactDigest": "sha256:...",
  "expiresAt": "2026-07-28T15:00:00Z"
}

The signature can protect every field from modification. The deployment backend must still check the expected agent key, the production environment, the artifact digest, the expiry, and the policy that permits this identity to deploy that service.

Where does authentication stop?

Authentication establishes the caller's identity. Exact-effect authority requires a separate decision over the request.

Assume a deployment agent receives an OAuth token with a broad deploy:write scope. An attacker uses indirect prompt injection to change the agent's target from staging to production. The token remains valid, and the agent calls an allowed deployment API. Authentication succeeds even though the requested effect no longer matches the operator's intent.

OWASP classifies this pattern as a tool-use and privilege problem. Its Agentic Applications Top 10 separates goal hijacking, tool misuse, and identity or privilege abuse because an agent can cause harm through legitimate credentials and legitimate tools.

The control must evaluate both the session and the action. For the deployment request, policy should check the service, environment, artifact, requester, approval state, and expiry before producing authorization that the backend requires.

How is agent identity different from workload identity?

Workload identity identifies running software so services can authenticate it without long-lived shared secrets. SPIFFE, for example, defines workload identities and SPIRE issues verifiable identity documents after workload and node attestation.

Agent identity adds governance questions created by delegated and partly autonomous behavior. The system may need to record an owner, a user delegation, an agent version, available tools, and the authority granted for a task.

Governed cryptographic identity adds one more boundary: which exact actions the identity may authorize and which proof the executing system must verify.

These models can work together. A workload identity can authenticate the process hosting an agent, while a governed key identity authorizes a specific payment, deployment, certificate, or command.

What must action authorization contain?

Action authorization must cover every field that can change the effect. A policy check over one payload and a signature over another creates a gap an attacker can exploit.

A practical authorization object should bind:

• the agent or machine identity
• the action type
• the target resource and environment
• every effect-changing parameter
• the policy or authority version
• required human or external approvals
• an expiry, nonce, sequence, or idempotency key
• the cryptographic proof

The exact fields depend on the action. A payment needs an asset, amount, destination, network, and expiry. A deployment needs an artifact digest, service, environment, and release constraints. A certificate request needs the subject, public key, validity period, extensions, and issuance policy.

Google's Agent Payments Protocol applies this principle to commerce. AP2 uses cryptographically verifiable mandates to show what a user authorized an agent to do, then requires a verifier to check that a presented mandate permits the requested transaction. AP2 covers payments, but the same cause-and-effect rule applies to other machine actions: the proof must cover the effect that will occur.

Where must the proof be verified?

The system that creates the effect must verify the proof before execution. Verification elsewhere is advisory if the executing backend can bypass or ignore it.

For the deployment example, the deployment backend should:

1. Reconstruct or validate the exact deployment intent.
2. Verify the signature against the expected identity.
3. Check that policy and approvals cover the same intent.
4. Reject expired or replayed requests.
5. Deploy the approved artifact to the approved environment.

This placement creates an enforceable path:

agent proposes action
-> authority evaluates exact intent
-> authority returns proof
-> backend verifies proof
-> backend executes the same intent

A second route without proof turns the control into an advisory check. The identity may still improve attribution while the bypass path remains able to execute.

How does this relate to MCP authorization?

MCP authorization protects access to an MCP server through OAuth-based flows. The specification covers token acquisition, audience binding, token validation, and scopes for protected resources.

An OAuth token can authorize access to a server or tool without proving that one set of tool arguments passed a separate business policy. The MCP server must still validate the requested operation and enforce any action-level rules.

For a read-only inventory tool, a scoped token may provide enough control. For a tool that transfers funds or changes production state, the backend should also require authorization bound to the exact arguments and effect.

What should an implementation do?

Start with one action whose failure has a clear consequence. Mapping one complete execution path exposes gaps faster than designing a universal agent identity model.

Use this checklist:

1. Give each agent or governed workflow a distinct identity.
2. Assign an owner and document the identity's purpose.
3. Keep long-lived private keys and credentials outside the model context.
4. Define a typed intent that includes every effect-changing field.
5. Evaluate policy in deterministic code outside the model.
6. Require explicit approval for actions that policy cannot safely automate.
7. Bind the accepted intent, policy state, and approvals to cryptographic proof.
8. Verify that proof in the backend before execution.
9. Enforce expiry, replay protection, and idempotency where needed.
10. Record the decision and result for incident response and audit.

Use stronger controls when an action can move funds, change production, issue credentials, export protected data, or create an irreversible external effect. A low-risk read operation may need only workload authentication and narrow access scopes.

What are the common implementation errors?

Shared credentials erase attribution. If five agents use one API key, the receiving system sees one caller and cannot reliably distinguish their authority or lifecycle.

Broad scopes combine access with approval. Treat API access and effect approval as separate decisions for each destination, amount, artifact, or environment.

Arbitrary signing hides action meaning. A signing service cannot enforce semantic policy when it receives opaque bytes with no trusted interpretation.

Detached approvals create substitution risk. Bind the approval and payload to the same canonical intent.

Audit-only controls act after execution. Logs help investigators reconstruct an event; the backend still needs a preventive check for unapproved requests.

Signature-only verification trusts too little context. A verifier must require the expected identity and validate the signed action.

Where does agent identity stop?

Model correctness sits outside the identity boundary. A signed action can reflect a bad policy, a compromised quorum, an unsafe approval, or a verifier bug.

Sandboxing, host security, network controls, credential protection, fraud detection, and prompt-injection defenses reduce other parts of the attack surface.

Cryptographic authorization protects only paths that require its proof. If the same effect can occur through an ungoverned credential, administrator route, or alternate backend, that path remains outside the boundary.

What should you do next?

Choose one action an agent can make real, then write down the exact fields the executing backend must verify. If the team cannot identify those fields or the backend can execute without checking them, the system has an agent identity but no enforceable authority boundary.

Read Governed Cryptographic Identity for the TKeeper model, For AI Agents for the integration contract, and the Threat Model for the security boundary.