THE IDENTITY THAT OUTLIVED ITS PURPOSE

VSR-01 through VSR-03 all treat an agent's access as a fixed thing to be measured, bound, or mapped at a point in time. This report adds the axis the other three deliberately hold constant: time itself. A grant that was correctly scoped (VSR-01), correctly runtime-bound (VSR-02), and correctly matched to an access-shaped failure category (VSR-03) can still be wrong six months later, if the agent's purpose, owner, or connected tools have changed and nothing re-evaluated the grant against the new reality. The Agent Lifecycle Register applies standard identity-management discipline (joiner, mover, leaver) to agent identities specifically, closing the loop VSR-01's audit opens.

Human identity management established a mature discipline for this problem decades ago, even if implementation remains imperfect: when someone joins an organization, they're provisioned; when their role changes, their access is supposed to change with it; when they leave, access is revoked. In practice even human identity lifecycle management is imperfect, but the discipline exists, is named, and is audited against.

Agent identities mostly don't have an equivalent lifecycle discipline yet, because "agent" as a governed identity category is new enough that most organizations are still at the provisioning stage (VSR-01's problem) rather than the ongoing-maintenance stage. An agent gets created for a purpose, granted access matched to that purpose, and then, unlike a human employee whose role changes trigger an access review through an HR process, nothing structurally forces a re-check when the agent's purpose, owning team, or connected tool stack changes. The agent doesn't quit, get promoted, or move departments in a way that trips an existing process. It just keeps running, with access that was correct once.

The Akto/nhimg practitioner guidance surfacing this window states the fix plainly: "extend lifecycle control to AI systems: apply joiner-mover-leaver style thinking to AI agents by reviewing ownership, purpose, connected tools, and revocation events whenever the work changes." That is a direct, actionable recommendation, and this report operationalizes it into a maintainable register rather than leaving it as a principle.

It also closes a real gap the rest of this issue's VSR stack leaves open. VSR-01 finds unused access at a point in time. VSR-02 checks whether a grant is enforced at runtime. VSR-03 checks whether a grant addresses the right failure category. None of the three, run once, stays true indefinitely. An agent whose purpose narrows six months after a clean VSR-01 audit will have new unused scope that audit never anticipated. Lifecycle discipline is what makes the other three tools' findings durable rather than a one-time snapshot.

Does this agent's access still match a purpose that's still true?

The question has two parts, and both have to hold. "Still true" checks whether the original purpose still exists at all: has the task been retired, absorbed into a different system, or handed to a different owner? "Still match" checks whether, assuming the purpose is still true, the access still fits it, or has drifted wider or narrower than what the current version of the purpose actually requires.

5.1 Joiner, agent creation

The point at which an agent identity is created and access is first provisioned. This is where VSR-01's grant-vs-use discipline should start, and where ownership and purpose should be recorded as first-class, queryable fields, not left implicit in a deployment ticket that becomes unfindable within a quarter.

5.2 Mover, purpose or ownership change

Any point at which the agent's task, the team responsible for it, or its connected tool stack changes materially. Movers are the highest-risk, lowest-visibility events in an agent's lifecycle, because, unlike a human's promotion or transfer, nothing in most organizations' existing processes automatically flags an agent mover event.

5.3 Leaver, retirement or replacement

The point at which an agent's task is retired, absorbed elsewhere, or the agent is replaced by a newer version. Leaver events are where access most commonly outlives purpose: the old agent identity's credentials and grants are frequently left active because deleting them feels riskier than leaving them, which is precisely backward.

Silent mover events

An agent's purpose narrows or shifts: a task it originally handled end-to-end gets split across two more specialized agents, and the original agent's broader access is never revisited, because no process exists to flag the change as a lifecycle event requiring review.

Zombie leavers

An agent is functionally replaced by a newer version, but the old identity's credentials remain active "in case something still depends on it," and nobody ever confirms whether anything actually does, or comes back to check.

Ownerless drift

An agent identity's original owner leaves the organization or changes roles, and the agent's ownership is never formally transferred, leaving a governed identity with no accountable human able to answer for its current access when a review or incident requires one.

For every agent identity in production:

Purpose

Maintain a living record of every agent identity's owner, purpose, connected tools, and review status, so lifecycle events (mover, leaver) trigger a review instead of passing unnoticed.

Use when

• Standing up agent governance for the first time: the register is the foundation VSR-01/02/03's point-in-time audits should log their findings against.
• On a recurring cadence (recommended quarterly, or triggered by known organizational changes).
• Whenever an agent's owning team, tool stack, or task definition changes for any reason.

What it creates

A single queryable record per agent identity, with a status flag (current / needs-review / stale) that can be checked without re-running a full audit from scratch.

Technical version

agent_lifecycle_register:
  agent_id:
  created_at:
  owner:
  purpose:
  connected_tools: []
  last_reviewed:
  next_review_due:
  lifecycle_status: joiner | mover_pending_review | current | leaver_pending_revocation | retired
  revocation_trigger:   # what event should retire this agent

Manual / no-code alternative

A single spreadsheet, one row per agent, with owner/purpose/tools/last-reviewed columns and conditional formatting that flags any row past its review-due date: the minimum viable version of the register, buildable without any new tooling.

Output

A standing, current answer to "which of our agents have gone stale," rather than discovering the answer only when an incident forces the question.

Failure prevented

An agent identity that was correctly scoped and correctly bound at creation, and was never revisited as its purpose, owner, or connected tools changed.

A permission is only as current as its last review. Treat an unreviewed grant as an expired one.

An agent originally built to triage a single support queue is, six months later, quietly handling three queues after an internal reorg folded two teams together. Nobody updated its governance record, because the expansion happened gradually through configuration changes rather than a single redeployment event. Run the lifecycle register check. Step 1: owner on record left the company two months ago; ownership was never transferred: ownerless drift, first finding. Step 2: recorded purpose ("Queue A triage") no longer matches actual behavior (three queues): an unflagged mover event. The agent's access was never audited against its new, wider actual purpose, meaning a VSR-01 grant-vs-use audit run today would be comparing current access against a stale, narrower baseline. The lifecycle register doesn't fix the access itself. It's what surfaces that VSR-01 and VSR-02 need to be re-run against the agent's actual current purpose before their findings can be trusted.

This report establishes that lifecycle review needs to happen and gives a structure for tracking it; it does not itself determine correct access levels. That's VSR-01's and VSR-02's work, re-applied at each lifecycle checkpoint. It also assumes an organization can name an owner for each agent identity in the first place; where agent creation is decentralized enough that no single accountable owner exists, establishing that accountability is a prerequisite this report cannot substitute for. Review cadence (quarterly, as recommended) is a starting default, not a finding. Higher-risk agent classes likely warrant tighter cycles, and this report does not attempt to set that threshold generically.

VSR-01 through VSR-03 all answer questions about an agent's access as it stands right now. This report is the reminder that "right now" has an expiration date nobody schedules by default. An agent whose owner has left, whose purpose has quietly expanded, and whose access was never re-checked against either fact is not a hypothetical risk. It is the median outcome of not building lifecycle discipline in from the start. The fix is not more sophisticated access control. It is the unglamorous, already-known practice of human identity management, applied to a population of identities that don't hand in a resignation letter when their purpose changes.

DFEI.010 :: VSR-04 :: The Identity That Outlived Its Purpose Dispatches From Emerging Intelligence