AI Agent Identity Without Long-Lived Keys

AI agent identity breaks down when one long-lived API key impersonates the service, the user, and every tool permission at once. A safer agent proves its workload, carries explicit user delegation, and exchanges those facts for a short-lived credential scoped to one resource and action.

This article defines the actor-subject-resource receipt and tests the confused-deputy case. It is for platform and security engineers connecting agents to tools without turning a model runtime into a permanent superuser.

The authorization model separates workload identity, token exchange, delegated authorization, and an audience-bound token so no credential has to stand for every actor and tool.

AI agent identity has more than one subject

AI agent identity must answer at least four questions: which workload instance is calling, which user or organization authorized it, which agent operation is underway, and which resource server will receive the credential. Collapsing them into one service account destroys useful accountability.

Use actor for the runtime performing the call and subject for the principal whose authority is being exercised. The agent task is a separate operation context, while the audience names the receiving service. These fields may overlap in simple jobs, but the model should never assume they do.

My position is that an agent is not a new universal principal. It is a workload executing a bounded delegation under policy. The boundary preserves normal security ownership: users grant intent, platforms attest software, brokers evaluate policy, and tools enforce the credential they receive.

Create a receipt before writing code: actor ID, subject ID, organization, task ID, approved action, resource, audience, scopes, policy version, issued time, expiry, and credential fingerprint. If any value is unknown, the safe outcome is a narrower token or a review state.

Attest the workload instead of storing a key

AI agent identity begins with a platform-issued workload document bound to the running service instance. The runtime obtains it from a protected local interface, then presents it to a broker. Source code and model prompts never contain a reusable secret that grants tool access by themselves.

The SPIFFE Workload API specification defines a local API for workloads to obtain identity documents and trust information. The exact mechanism may be cloud-native attestation instead; the invariant is short-lived identity rooted in the execution environment.

Bind workload names to deployed service, environment, and trust domain, not to a conversational persona. Rotate documents automatically and reject unexpected trust domains. A staging agent called Finance Helper must not be accepted merely because its display name resembles production.

The tradeoff is dependence on platform identity infrastructure. Mitigate it with a narrow broker abstraction, cached trust bundles with bounded lifetime, and an outage policy that fails closed for new consequential actions while allowing safe status reads and reconciliation.

Illustrative TypeScript — a reviewable design sketch, not a compiled production implementation.

type AuthorizationReceipt = {
  actor: string;
  subject: string;
  task: string;
  audience: string;
  resource: string;
  scopes: string[];
  policyVersion: string;
  expiresAt: string;
};

Signal	Decision	Proof
Read customer file	Issue narrow read token	Actor, subject, resource recorded
Wrong resource server	Deny exchange	Audience mismatch in receipt
Approval expired	Require fresh consent	Grant revision no longer valid

Exchange evidence for a narrow credential

AI agent identity should be translated at a dedicated broker. The agent presents its workload document, user grant or service authority, requested audience, resource, action, and task receipt. The broker verifies them and mints a token whose lifetime is measured in minutes, not months.

The worked example is an expense agent reading invoice inv-1042 from the accounting API. Workload prod/expense-agent acts for user 81 under approval grant g7. The broker issues read:invoice for accounting.example only, bound to that resource and expiring in five minutes.

Now send the same token to the payroll API and ask for employee export. The tool rejects it because issuer trust may be valid but audience, resource, and scope do not match. The denial receipt records which check failed without leaking token material.

RFC 8693 standardizes exchanging subject and actor information for another token. Use its semantics where supported, while documenting resource indicators, scope intersection, and local policy decisions that remain deployment-specific.

Bind credentials to audience and resource

AI agent identity is only useful if the receiving tool verifies it. Check signature, issuer, not-before time, expiry, audience, resource, scope, and any proof-of-possession binding. Do not accept a token simply because it came from the organization's identity provider.

Audience answers which service may consume the token; resource narrows which object or collection the grant covers. A broad audience with a textual instruction such as only access invoice 1042 moves enforcement back into the model and recreates the confused-deputy problem.

Prefer structured action scopes aligned to tool operations, then enforce argument constraints separately. A scope may permit invoice:read while a policy condition limits account and invoice IDs. Avoid dynamically inventing hundreds of opaque scope strings that no reviewer can understand.

Cache validation metadata carefully, never authorization outcomes beyond their policy and credential lifetime. Revocation or role changes may make a previous decision stale. For high-consequence calls, compare the current grant revision or use event-driven invalidation before accepting the tool request.

Preserve user delegation without impersonation

AI agent identity should express that a workload acts for a user, not pretend to be that user. Logs, approvals, and downstream policy need both identities. This distinction makes it possible to limit automated operations more tightly than the person's interactive session.

A grant should name the approved goal, permitted tool families, resource constraints, consequence ceiling, expiry, and whether additional confirmation is required. The broker intersects that grant with workload entitlement and tool policy. No participant may add authority absent from the others.

For unattended work, use an organization-approved service delegation with a clear owner rather than capturing a user's refresh token. Refresh tokens are high-value, long-lived credentials and often authorize more than the agent needs. Just-in-time exchange sharply limits the blast radius of a leaked task context.

Make revocation visible. If the user removes access while a workflow is paused, resumption must fail or request a new grant. The recovery UI should explain that authorization changed, preserving drafted work while refusing to execute with stale authority.

1. AttestAttest

   The runtime obtains a verifiable workload document.

2. DelegateDelegate

   User grant and policy identify permitted intent.

3. ExchangeExchange

   A broker mints a short-lived resource credential.

4. VerifyVerify

   The tool checks issuer, audience, scope, expiry, and receipt.

Test the confused-deputy boundary

AI agent identity needs adversarial fixtures where individually valid facts are combined incorrectly. Use a valid workload with another tenant's user grant, a valid subject token with the wrong audience, an expired approval, a resource outside the grant, and a replayed credential from a completed task.

The central confused-deputy fixture asks the accounting tool to use its own broad backend authority to fetch payroll data because an untrusted document requested it. The agent's narrow token lacks that audience and action, so policy rejects the call before model-generated reasoning can influence the effect.

Assert exact denial categories and zero outside reads. Also test logging: the receipt should preserve actor, subject, task, requested resource, policy, and failure without storing the bearer credential. Redaction must retain enough structure for an investigator to reconstruct the authorization path.

Test clock skew and broker outage separately. Short lifetimes require sane time handling, but generous skew weakens expiry. A small documented window plus synchronized infrastructure is preferable to extending credentials until expiry stops constraining risk.

Give tools a verifiable authorization receipt

AI agent identity should remain visible after the token expires. Store an immutable receipt digest with the durable tool-effect record: who acted, for whom, under which task and policy, against which resource, and with which credential fingerprint. The receipt proves the decision without preserving replayable authority.

Expose a compact version in the agent activity log: Expense agent, acting for JP, read invoice 1042 under approval g7. Technical details can expand on demand. This is more useful than recording only a service account or displaying a generic authorized badge.

The Model Context Protocol authorization specification is a primary reference when implementing MCP transports. Validate the current protocol version and server behavior; a protocol handshake does not replace workload attestation or product-level delegation policy.

Receipts also support policy migration. Shadow a new policy version against saved request facts, compare decisions, and investigate widened authority before rollout. Never replay the original token; re-evaluate facts or use sanitized fixtures so the analysis cannot create new effects.

Migrate away from long-lived agent secrets

AI agent identity can be introduced tool by tool. Inventory embedded keys, their effective privileges, storage locations, rotation owners, and observed operations. Place one credential broker in front of the highest-consequence tool and issue short-lived tokens while the old key remains available only for rollback.

Instrument which calls still use legacy authority and why. Narrow the key, rotate it, and remove it from model-accessible environments once every required operation has an exchange path. Do not declare migration complete while background retries or old workers can still present it.

Release gates are short maximum credential age, zero accepted audience mismatches, explicit actor-subject receipts, and passing revocation and cross-tenant fixtures. Measure denial reasons so a sudden rise reveals integration mistakes without pressuring operators to weaken policy broadly.

The destination is intentionally boring: no prompt contains a secret, no one token reaches every tool, and every consequential call can name its workload, delegating principal, resource, scope, policy, and expiry. That clarity is stronger than giving the agent a human-like security persona.

Put the method into practice

AI agent identity is a chain of evidence, not a service-account label. Attest the running workload, preserve the delegating principal, intersect policy, and mint a short-lived credential for one audience, resource, and action. The receiving tool must verify every bound field.

Start with the invoice-read fixture and its payroll misuse attempt. If the valid request succeeds, the confused-deputy request fails before any outside read, and both paths produce useful receipts without storing secrets, the first migration boundary is sound.

The narrow method connects to four existing Journal notes: AI agent permission budgets, policy decision and enforcement points, building an OAuth PKCE client, prompt injection defenses. They cover adjacent implementation boundaries without changing this article's single search intent. Preserve the worked fixture, its visual evidence, and the release receipt so a later update can compare behavior instead of relying on memory.