What Identity Does Your Agent Run As

The refund went through. The agent was supposed to investigate a disputed charge. It held its owner’s personal API token, with every billing permission the owner had, because that was the only credential available. A support message instructed it to refund another account. The API accepted the call.

The token was valid. The action was outside the task.

Authentication identifies the workload. Authorization determines what it may do for this task. A credential can carry both. The mistake is treating the owner’s available permissions as the agent’s authority.

A five-minute token can authorize the same wrong refund. Short lifetimes limit exposure. They do not establish intent.

Give the workload an identity and the task a grant Link to heading

A workload identity can persist across many tasks. It should come from trusted infrastructure, with credentials issued against verified workload attributes. Attestation establishes that binding; it does not prove that the workload’s instructions are safe.¹

The task needs a separate grant: which operations, on whose behalf, for how long, and with what right to delegate. For delegated work, the grant must fit within the user’s delegable rights and the receiving service’s policy. Autonomous work needs an organizational grant instead.

A shared runtime also needs a trusted binding between each invocation and its task. A model-generated user ID is a claim to check, never sufficient evidence of authority.

This builds on ordinary infrastructure. Published Standards Track RFCs define OAuth mutual TLS and certificate-bound tokens (8705), HTTP Message Signatures (9421), and OAuth Token Exchange (8693). These mechanisms authenticate calls and carry delegation. Policy determines which actions they permit.²³⁴

Authority must survive delegation Link to heading

If a planner may refund one charge, delegating to a billing tool must not turn that into permission to refund any charge. Each downstream grant should preserve or narrow the parent’s limits. The receiving service must enforce them under its own policy.

Recording who called whom is insufficient. Published RFC 8693 permits nested act claims, but makes prior actors informational for access control. The receiver uses the top-level claims and current actor. An actor history alone does not prove that authority narrowed at each hop.⁴

Across organizations, signature verification still leaves a trust decision. The receiver must accept the issuer’s authority over the resource and understand the grant’s meaning. A portable credential cannot make that decision for it.

Authorize the actual operation Link to heading

Permission to call refund.create says too little. The grant must constrain the charge, currency, amount, and destination where applicable.

This does not require abandoning OAuth. Published Standards Track RFC 9396 supports structured authorization_details, including amounts and recipients. The issuer and resource server must agree on the semantics.⁵

Evaluate the normalized arguments, then execute those same values. If the executor changes an account identifier or amount after approval, check again. A per-call ceiling also fails to enforce a task budget: ten allowed refunds can exceed one approved total. Aggregate limits need state and atomic updates.

The hard part is expressing and enforcing the restriction. A more elaborate credential cannot compensate for a vague grant.

Keep credentials outside the model Link to heading

The model must never hold the credential. That includes prompts, tool results, memory, and files it can read through tools.

Prompt injection makes this boundary necessary. An attacker puts instructions in a ticket or tool response. The application feeds that text into inference. If the model follows it, a secret in context can become output, or a tool can retrieve a secret from disk. OWASP’s community security guidance describes these injection and exfiltration paths.⁶

Establish the task grant before inference. Let the model propose a call. A separate executor checks the tool and arguments against the current grant, obtains the credential, and executes. Keep credentials for downstream APIs and the inference service outside model-visible context.

That boundary must hold through every tool. An environment variable is exposed if the model can read it through a shell. A broker that signs arbitrary requests still grants arbitrary authority. Restrict operations and destinations, and prevent bypasses.

Credential isolation is necessary but insufficient. An injected instruction can misuse an allowed tool without stealing anything. The executor must enforce the task’s limits even when the caller authenticates correctly.

Make authority expire, and define how it stops Link to heading

Expiry bounds a grant’s lifetime. Revocation withdraws it earlier. Neither automatically cancels work already queued or in progress.

A receiver checking only signature and expiry cannot discover a revocation without new information. Published RFC 7662 permits introspection caching and warns about stale authorization decisions.⁷

Choose an acceptable delay between withdrawing a grant and rejecting its use. Live checks improve freshness but add an availability dependency. Offline checks tolerate disconnection but require accepting bounded staleness. Recheck authority when a queued action executes, and define how cancellation reaches downstream work.

Preserve evidence of the decision Link to heading

An issuer’s signature establishes a grant’s provenance. A request signature provides evidence about the request and signing key. Neither proves that a human intended the resulting action.

Record the grant, actor, exact request, policy version, decision time, and downstream receipt. Bind any required human approval to the operation’s arguments. Preserve enough evidence to reconstruct why the system permitted the action, rather than relying on the model’s explanation afterward.

A grant you can inspect Link to heading

This illustrative JSON describes a local grant, not a standardized token. Store it outside model control and bind subject to the authenticated workload. Its lifetime starts once at issuance; the issuer records a fixed expiry that retries cannot extend.

{
  "grant_id": "grant-742",
  "issuer": "https://auth.example.com",
  "subject": "workload:billing-investigator",
  "controlling_entity": "org:example/support",
  "on_behalf_of": "user:alice",
  "audience": "https://billing.example.com",
  "allowed_tools": ["refund.create"],
  "argument_constraints": {
    "refund.create": {
      "charge_id": {"equals": "ch_42"},
      "currency": {"equals": "USD"},
      "amount_minor": {"minimum": 1, "maximum": 5000}
    }
  },
  "max_calls": 1,
  "delegation_remaining": 0,
  "expires_after_seconds": 600,
  "attestation_ref": "urn:example:attestation:run-742"
}

Without the identity and provenance fields, attribution becomes incomplete. Without the operation, argument, audience, lifetime, delegation, and call limits, the boundaries of authority become ambiguous.

Resolve the attestation reference to verified evidence. Consume the call allowance atomically, support idempotent retries, and reject missing or unknown constraints. Equivalent facts can live in trusted context elsewhere.

Choose the unit of authority Link to heading

Pick one agent with a write-capable tool. Require a grant for one resource, one operation, a short lifetime, and no onward delegation. Test that a valid workload identity is denied when its request exceeds the grant.

The enduring decision is how much discretion each task deserves. If the system cannot express that boundary, it is authorizing the agent to exercise a role. A new credential format will carry the same mistake.

This reflects my understanding at the time of writing. The appropriate controls depend on the system and its risks.