Ephemeral Agent Identity

Problem

An agent that authenticates as a static service account holds a credential that persists long after its task is done, is scoped far wider than the one run required, and is shared across every run that reuses it. A compromised session token then surfaces on the network as a fully legitimate identity with valid access, indistinguishable from a real agent, and there is no clean task boundary at which to revoke it. Treating the agent's own identity as either a human user or a permanent integration account leaves no identity class that is born with the run, bounded to it, and gone when it ends.

Solution

Treat the agent's own identity as a first-class non-human identity class, distinct from human users and from static service accounts, with a lifecycle tied to the task rather than to a deployment. When the orchestrator spawns a run, it requests a fresh identity from the identity provider: a short-lived credential or workload token scoped to exactly the resources this task needs, stamped with the spawning run's lineage so later audit can group it. The agent authenticates every step under that identity. When the task returns, the orchestrator revokes the identity or lets its short lifetime expire, so nothing remains to be reused, leaked, or escalated. Scoping, issuance, and revocation run at machine speed inside the spawn and teardown path, not through a human approval queue, so identity governance keeps pace with the rate at which agents are created.

When to use

• Agents and sub-agents are spawned frequently for bounded tasks, so a per-task identity lifecycle is feasible and worthwhile.
• The identity provider can issue and revoke scoped, short-lived credentials at machine speed without a human approval step.
• Blast radius matters: a leaked credential must not grant standing access beyond the task it was minted for.