The agent identity lifecycle: a ring of six stages around a credential card.

The agent identity lifecycle

Most failures of agent identity are not cryptographic. They are lifecycle failures: an agent that was never properly onboarded, a credential that was never rotated, an identity that was never revoked when the project ended. Know Your Agent is therefore not a one-time checkpoint but a lifecycle — issue → onboard → run → rotate → revoke → offboard — with an owner at every stage. This guide describes the stages, what “good” looks like at each, and the two chronic problems that lifecycle discipline is meant to prevent: orphaned agents and credential sprawl.

It assumes the framing in What is Know Your Agent? and the controls in How to scope an agent’s permissions and Audit trails for agents.

The six stages

StageGoalTypical controlsCommon failure
IssueCreate a unique, verifiable identity for the agentOne identity per agent; attested identifier; named ownerShared service account reused for many agents
OnboardRegister the agent and bind it to a principal and purposeInventory/registry entry; principal; declared scope; reviewAgent in production with no registry entry
RunLet it act within a scoped, observable mandateShort-lived credentials; per-request policy; loggingLong-lived static secret; no decision log
RotateReplace credentials before they age outAutomatic rotation; no manual keysStatic key that never changes
RevokeWithdraw authority immediatelyRevocation endpoint; short lifetimes; identity disablementRevocation that is assumed, never tested
OffboardRemove the identity and its grants when the purpose endsDecommission; delete grants; archive audit trailIdentity left enabled “just in case”

Two properties make this a lifecycle rather than a checklist. First, the stages repeat: an agent may rotate credentials many times and be re-scoped between tasks. Second, the end matters as much as the start — OWASP’s Non-Human Identities Top 10 names Improper Offboarding as a headline risk, warning that NHIs left active when no longer needed “can be exploited by attackers to gain unauthorized access to sensitive systems and data.” The gateway to compromise is often an identity nobody remembers creating.

Identity proofing for non-human principals

For users, identity proofing establishes that a claimed identity is real and belongs to the claimant. NIST SP 800-63-4 defines assurance levels for identity proofing, authentication and federation — the vocabulary behind “how sure are you that this is who it says it is?”.

An agent is not a person, so the question shifts: proofing an agent means proving what it runs and who issued it, and proving who its principal is. In practice, three things are established at issue time:

  1. The principal — the accountable person or organisation, proofed as it would be for any delegated authority. Where the agent acts in regulated activity, the principal still needs KYC/KYB; an agent does not launder that requirement.
  2. The agent’s identity — a purpose-built, verifiable identifier, such as a SPIFFE Verifiable Identity Document (which is “proven as authentic” and “proven to belong to the presenter”), a platform agent identity, or an issuer-signed credential.
  3. The agent’s right to act — the declared scope and purpose, recorded at onboarding so that “what is this agent for?” has an answer later.

Workload identity platforms make this concrete by attesting the workload and provisioning a short-lived credential based on that attestation, so the agent holds no static secret.

Key rotation

Rotation is the discipline that stops a credential from becoming a permanent liability. Its purpose is to bound the window in which a leaked key is useful. SPIFFE’s design states the principle plainly: to minimise exposure from a leaked or compromised key, keys and certificates “are short lived, rotated frequently and automatically.”

Good rotation:

  • Is automatic — no human remembers to rotate, because humans forget, and forgotten keys become the Long-Lived Secrets OWASP flags.
  • Is overlapping — the new key is issued and trusted before the old one expires, so rotation does not cause an outage.
  • Is observable — the last rotation time is a monitored property; a key that has not rotated is an alert.
  • Survives compromise — because the agent can be re-issued a fresh identity from attestation rather than patching a stolen secret.

Short-lived, auto-rotated credentials are also what make revocation tractable. If every credential expires soon, “revoke” often means “stop re-issuing”, and the residual exposure is one token lifetime rather than an unbounded one.

Revocation propagation

Revoking an agent should stop the very next action — and the honest difficulty is propagation: how fast does the denial reach every service that might accept a credential minted for that agent?

The mechanisms:

  • Token revocation (RFC 7009) invalidates a token and, where applicable, other tokens from the same grant.
  • Token introspection (RFC 7662) lets a resource server ask whether a token is still active before acting — the natural check before a high-value action.
  • Identity disablement — the agent identity itself is disabled, so no new credentials can be minted.
  • Short lifetimes — bound the worst case when propagation is slow: the credential dies on its own.

Make revocation end to end and tested: revoke the identity or credential, then confirm the next action is refused. A revocation path that has never been exercised is an assumption, not a control. Design the check so that a slow or failed revocation is visible (an alert), rather than silently allowing.

Orphaned agents and credential sprawl

These are the two chronic diseases of an agent estate.

Orphaned agents are identities with no live owner or purpose — the contractor’s bot from a finished engagement, the experiment that graduated to production, the sub-agent spawned once and never retired. They persist precisely because nothing in their lifecycle forces a review. The defence is a registry: an authoritative inventory of agents, each with a named owner, a declared purpose, a scope, and a review date. If an agent is not in the registry, it should not be issuable; if its review date passes, it should be re-approved or retired.

Credential sprawl is the accumulation of keys, tokens and grants around one agent — several per integration, some long-lived, some shared. Each is an independent leak. The defence is the same discipline as scoping: one agent, one identity, credentials minted just-in-time and short-lived, per-integration scopes, and no sharing of tokens across servers. Inventory the credentials as belonging to an identity, so that retiring the identity retires them.

The two interact: sprawl is what makes an agent hard to offboard, and orphaned agents are what leave sprawl undiscovered.

Checklist

  • Every agent has its own identity — never a shared account
  • Every agent is in a registry with a named owner and review date
  • The principal is recorded and (where required) proofed
  • Declared purpose and scope are captured at onboarding
  • Credentials are short-lived and rotate automatically with overlap
  • Rotation recency is monitored; stale keys alert
  • Revocation is tested end to end, and the next action is refused
  • Revocation propagation delay is bounded by credential lifetime
  • Offboarding removes the identity, its grants and its credentials
  • A periodic review retires orphaned agents and prunes sprawl

FAQ

How is this different from employee or service-account offboarding?

The shape is similar — people and service accounts both need to be revoked — but the failure modes differ. Agents are ephemeral, can spawn sub-agents and cross trust boundaries, and often act without a human present, which is why traditional non-human identity models do not fully cover them. The registry and review discipline is what compensates for the fact that no HR process marks an agent as “left the company”.

Which stage do teams skip most often?

Offboarding, and rotation. Both are invisible when they work and only noticed when they fail. OWASP names improper offboarding and long-lived secrets as distinct risks for exactly this reason. Treat the last two stages as first-class rather than cleanup.

Do I need a full registry to start?

You can start with a spreadsheet, but the property that matters is authoritativeness: one inventory that new agents must be added to, not a document that drifts. A registry that is not consulted at issue time is a record of history, not a control.

Does an agent need a principal that has passed KYC?

If the activity is regulated, the principal’s own KYC/KYB obligations stand — an agent does not remove them. For unregulated activity, the principal still needs to be named and accountable; that is an identity-and-governance requirement, not necessarily a regulatory one.

Not legal advice. Identity-proofing levels, KYC/KYB obligations and the treatment of agent-initiated activity vary by jurisdiction and sector. Use this guide as an operational map and confirm your obligations with qualified counsel.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.