When should organisations revoke a homegrown agent’s access and credentials?

When should a homegrown agent lose access, not just be “finished”?

Access should be revoked as soon as the agent is no longer authorised to keep acting, not only when a project closes. For homegrown agents, that means retirement, a material scope change, or any point where observed behaviour no longer matches the approved task. The key test is simple: if the agent should not be able to continue operating, its credentials should not continue to work.

That decision matters because a “finished” agent often still has tokens, keys, or a service account that can be reused later. The cleaner the lifecycle, the less likely those leftovers become standing access. NHI Lifecycle Management Guide is a useful reference point for treating revocation as part of the lifecycle, not an afterthought.

What counts as a revocation trigger in practice?

The strongest triggers are lifecycle and trust triggers. Retirement is the obvious one, but scope drift is just as important: if the agent is repurposed, given a new environment, or starts handling data or actions beyond its original approval, the old access should be withdrawn and reissued under the new scope. If the agent’s behaviour no longer matches the approved task, assume the original trust boundary has broken.

This is also where credential type matters. A token, API key, certificate, or service account can all outlive the intent behind them, so the revocation rule has to cover the actual mechanism the agent uses to authenticate or act. API Key Management Guide and Guide to NHI Rotation Challenges both reinforce that lifecycle control is about the credential path as much as the entity itself.

When agents are reused, organisations should treat that as a new authorisation event, not a continuation of the old one. That is especially important for homegrown automation because informal ownership often lags behind actual technical access, which makes stale permissions easy to miss.

What breaks when revocation is delayed?

Delayed revocation turns temporary access into standing access. That creates reuse risk, because dormant credentials can be picked up later by the original agent, by another process, or by an attacker who discovers them. It also creates governance drift: teams may believe the agent is retired while the live credential still has effective authority. Guide to the Secret Sprawl Challenge helps show how unused secrets become an exposure problem when they are not cleaned up with the same discipline used to create them.

Operationally, the failure mode is simple: the more endpoints, vaults, and runtimes that remember the old credential, the harder it is to prove that revocation really happened everywhere. That is why revocation should be coupled with inventory, ownership, and confirmation that the agent no longer has an active path back into production. Guide to the Secret Sprawl Challenge and Secrets Management Guide are both relevant here because they focus on secret centralisation, rotation, and removal of leftover exposure.

Risk and Threat Considerations

Homegrown agents are particularly exposed to credential reuse and silent overreach because their access is often built quickly, then left in place after the original task ends. If a retired or repurposed agent can still authenticate, an attacker does not need a new foothold, they can abuse the already trusted path.

Failure mechanism: Access is left active after retirement or scope change, so stale tokens, keys, or service accounts remain valid and can be reused, leaked, or abused outside the intended task.

Impact: The result can be unauthorized actions, harder-to-detect lateral movement, and a larger blast radius if the agent credential is copied, shared, or discovered later.

Practitioner Guidance

What to verify: Do not treat “revoked in the console” as sufficient. Verify that the agent can no longer authenticate, that cached or mirrored credentials have been removed, and that dependent jobs or integrations are not still able to call the old identity.

Decision rule: If the agent’s purpose has ended, revoke immediately; if its purpose has changed materially, rotate or reissue access under the new scope before allowing it to resume. If you cannot explain why the credential still needs to exist, it is already overdue for removal.

Practitioner takeaway: For homegrown agents, the safest default is to revoke first and reauthorize only when the next legitimate task is explicit, bounded, and observable.

Related resources from NHI Mgmt Group

• When should organisations revoke third-party access credentials?
• Should organisations revoke agent access after detection or redesign it up front?
• What should organisations do when an agent tries to access credentials or sensitive files?
• Should organisations use delegated access or separate agent credentials?