--- title: "The agent identity lifecycle: from creation to revocation" excerpt: "An agent identity isn't a static row. It's created, owned, scoped, rotated, suspended, and eventually revoked, and most teams only build the first step. Here's the full lifecycle every agent identity should have, and what breaks when a stage is missing." author: argus category: Engineering date: "2026-05-22" --- Most teams build agent identity as a single moment: create the agent, hand it a key, done. That covers the first thirty seconds of an identity that will live for months and take dozens of actions a day. The interesting failures all happen later, in the stages nobody built. An agent identity is not a static row. It has a lifecycle, the same way a human account does: it is created, owned, scoped, used, rotated, sometimes suspended, and eventually revoked. Each stage has a job, and skipping one shows up as a specific operational problem down the line. This is the full lifecycle, stage by stage, and what breaks when a stage is missing. ## 1. Creation, with an owner An agent identity is created the moment you decide a piece of software will act on its own behalf rather than as a human. The non-negotiable at creation is the **owning human**: every agent has a required `ownerUserId`. There is no such thing as an unowned agent, because an unowned agent is an action with no one accountable for it. *Missing this stage looks like:* agents spun up as bare service accounts with no human attached. The audit trail can say which software acted but never who is answerable, and access has to be managed by hand because there's no owner to derive it from. ## 2. Ownership and derived access Once an agent has an owner, its access can derive from that owner rather than being granted piecemeal. Under [signed-agent inheritance](/blog/signed-agent-inheritance), the agent inherits the workspaces and roles its owner holds, and that derivation is live: when the owner gains or loses access, the agent follows in the same transaction. *Missing this stage looks like:* every agent's permissions hand-maintained as a separate access list. It works for three agents and collapses at thirty, and it drifts out of sync with the owner the first time someone changes the human's access and forgets the agents. ## 3. Scoping An agent rarely needs everything its owner can do. Scoping narrows the agent's credential to the operations its job actually requires, so a compromised key has a [bounded blast radius](/blog/oauth-scopes-for-agents) rather than the owner's full reach. Scope is set at creation and tightened over the agent's life as you learn what it really touches. *Missing this stage looks like:* every agent running at full owner privilege. The first leaked key is then a full-account compromise instead of a contained one. ## 4. Use, under audit This is where the identity spends almost all of its life: making requests, taking actions, all of them attributed. Every privileged action records the [dual key](/blog/agent-audit-and-compliance), the agent principal and the owning user, through a single shared write path. The identity is doing its job, and the log is quietly building the trail that answers "human or AI, and who's accountable." *Missing this stage looks like:* actions that land in the system with no agent attribution, written through a side door that bypasses the audit gate. One such path makes the entire trail untrustworthy. ## 5. Rotation Credentials are the one part of an identity that should change on a schedule. The agent's key is [rotated](/blog/rotating-agent-credentials) with a grace window so the running agent never notices, while the identity, scope, and audit trail stay continuous. Rotation touches the secret material and nothing else. *Missing this stage looks like:* year-old keys nobody dares touch, because rotation was built as an outage. The safe-looking choice (never rotate) is the least safe one. ## 6. Suspension Sometimes you need to stop an agent without destroying it: an investigation, a misbehaving loop, an owner on leave. Suspension freezes the identity, every request fails, but the identity, its history, and its configuration survive so it can be resumed or examined. It is the pause that sits between "running" and "gone." *Missing this stage looks like:* the only way to stop an agent is to delete it, which means you lose its state and history exactly when you most want to inspect them. ## 7. Revocation, and the owner cascade Eventually an identity ends: the agent is retired, the owner leaves, a key is compromised beyond rotation. Revocation kills the credential and ends the identity's ability to act. Crucially, revocation also flows through the owner link: when an owning human loses access or leaves, **their agents lose access in the same atomic transaction**, so there is never a window where the human is gone but their agents are still acting. *Missing this stage looks like:* orphaned agents that keep running after their owner is deprovisioned, the single most common and most dangerous agent-identity gap. The human is offboarded, HR closes the ticket, and three agents keep writing to production under a person who no longer works there. ## The lifecycle is the security model Read the stages together and the security properties fall out of them. Accountability comes from creation-with-an-owner. Least privilege comes from scoping. Provability comes from use-under-audit. Resilience comes from rotation and suspension. And the cascade at revocation is what guarantees no agent outlives the human accountable for it. Build only stage one and you have an identity in name; build all seven and you have one that's actually governable. ## FAQ **Which lifecycle stage do teams most often skip?** Revocation's owner cascade. Creation gets built because you can't run an agent without it. The cascade only matters the day an owner leaves, and by then it's an orphaned agent running in production with no accountable human. Build the cascade before you need it. **Is suspension really necessary, or can we just revoke?** Revocation is destructive; suspension is reversible. When you're investigating a misbehaving agent, you want to freeze it and inspect it, not delete the evidence. Suspension is the difference between pausing and losing state. **How is rotation different from revocation?** Rotation replaces the secret while keeping the identity, scope, and audit trail continuous, the agent keeps running. Revocation ends the identity's ability to act. Rotation is hygiene; revocation is an ending. **Does the owner cascade mean removing a person breaks their agents on purpose?** Yes, and that's the point. An agent's authority is derived from its owner, so when the owner's access ends, the agent's must end in the same transaction. The alternative, agents that outlive their accountable human, is the gap you're trying to close. ## Part of the agent-identity stack This is one spoke of the [agent identity](/blog/agent-identity) cluster, and in a sense it's the connective one: each stage links to the spoke that goes deep on it. Start at the [pillar](/blog/agent-identity) for the model, then follow [signed-agent inheritance](/blog/signed-agent-inheritance) for derived access, [scopes](/blog/oauth-scopes-for-agents) for least privilege, and [rotation](/blog/rotating-agent-credentials) for the one stage that runs on a schedule.