How should teams revoke AI agent access after decommissioning?

What decommissioning should actually remove from an AI agent

Decommissioning is not complete until the agent can no longer authenticate, be authorised, or act through any inherited path. That means removing the agent account itself, any connected service accounts, all credentials and certificates, OAuth consent, API grants, and tool registrations. It also means closing the authority path in the human-owned records that still describe what the agent is allowed to do.

For teams that want a practical control baseline, the AI Agent Authorisation Guide is the clearest reference for treating agent access as delegated, bounded authority rather than a permanent entitlement.

When the agent has used shared secrets or cached sessions, revocation has to extend beyond the account object. If a token, key, or certificate can still be replayed, the decommissioning process is incomplete even if the agent is “disabled” in one console.

Why revocation must cover credentials, grants, and tooling together

AI agent access is usually distributed across several control planes, so one missed dependency can keep the agent alive. A deactivated principal may still retain an OAuth grant, a tool connector, a platform-issued token, or a service account with permissions that outlive the agent’s visible lifecycle. That is why the revocation job has to address identity, access, and integration layers together.

The same pattern is why identity and privilege should be planned as an operating model, not an afterthought. NHIMG’s Agentic AI Identity Guide covers the lifecycle side, including how agent identities are registered, used, and retired, while the Zero Trust for AI Agents guide explains why standing privilege should be removed at the end of that lifecycle.

Revoke the broadest authority first, then the narrower leftovers. In practice, that means disabling the agent, expiring its credentials, and then removing the approvals that allow the agent to be silently reconstituted through another tool or connector.

What teams should verify after shutdown

After revocation, teams should verify that no valid authentication path remains, no token can still be exchanged, and no tool or API path still trusts the agent’s old identity. They should also confirm that any human owner, admin, or approver has removed the agent from IAM or PAM records, because stale ownership records are often the reason dormant authority comes back during rebuilds or incident response.

If the agent was allowed to use delegated cloud or platform permissions, it is worth checking the surrounding control layer as well. NHIMG’s Shadow AI and AI Agent Discovery Guide is useful here because discovery and decommissioning are linked: you cannot be confident an agent is gone until the grants and registrations that expose it are gone too.

For organisations that rely on central policy enforcement, the practical test is simple: if the old agent identity can still be observed in logs, trusted by a gateway, or accepted by a downstream tool, the shutdown is not finished.

Risk and Threat Considerations

Residual agent access creates a real exposure window because decommissioned agents often retain the exact permissions they had while active. That can leave behind a dormant but still-authorised path for misuse, replay, or accidental reuse, especially when secrets, sessions, or third-party connectors were never rotated or removed.

Failure mechanism: The agent is “disabled” in one system, but an OAuth grant, service account, cached session, or API key still authenticates elsewhere, so the decommissioned identity remains actionable.

Impact: Attackers or internal users can continue to invoke tools, access data, or trigger automated actions under an abandoned authority path, which expands blast radius and delays detection.

Practitioner Guidance

What to verify: Confirm that the agent has no remaining authentication method, no active grant, and no tool registration that can recreate its access. If any one of those survives, treat the decommissioning as incomplete.

Decision rule: If the agent ever held shared secrets, long-lived tokens, or cross-system permissions, rotate the adjacent secrets first and then validate that all dependent integrations fail closed, rather than assuming account disablement is enough.

What good looks like: A decommissioned agent should fail every login, token exchange, connector call, and tool invocation, while the owning team can show the record of closure in IAM or PAM and the evidence of removed grants.

Practitioner takeaway: Decommissioning is only real when the agent cannot be resurrected through another control plane, another token, or another inherited permission path.

Related resources from NHI Mgmt Group

• What breaks when AI agent access is reviewed only after the fact?
• What should teams do when an AI agent keeps access after a project ends?
• Should organisations revoke agent access after detection or redesign it up front?
• Who is accountable when a service account or AI agent keeps access after offboarding?