Disabling a compromised or misbehaving AI agent does not remove the access it was delegated: the tokens it obtained, the grants users gave it and the credentials held by the tools and services it called can keep working after the agent itself is stopped. Agent architectures spread authority across a chain: a user consents to an agent platform, the agent holds a token for an MCP server or tool, that server holds its own token for the upstream API, and token exchange can mint further tokens for downstream services. Each link is revoked in a different place and many issued tokens survive revocation until they expire. This guide is for incident responders, identity engineers and platform owners who need to cut that chain quickly and prove it is cut. It concentrates on mapping the delegation graph, the revocation mechanics that reach issued tokens, the gaps they leave, the order of operations and verification. The broader stop procedure is in the AI Agent Kill Switch and Containment Guide, which this page does not repeat.
Key takeaways
- Revoke the graph, not the node. List every credential issued because of the agent, including those held by tools and downstream services, before you start revoking.
- Grant deletion is not token revocation. Microsoft documents that deleting a delegated permission grant leaves existing access tokens valid for their lifetime; some providers cascade, many do not.
- MCP servers hold their own upstream tokens. The MCP specification forbids token passthrough, so the upstream token is a separate credential that survives revocation of the token the agent presented to the server.
- Lifetime is your worst case. Where an access token cannot be revoked, its remaining life is how long the attacker keeps access, unless the resource enforces near-real-time signals such as Continuous Access Evaluation.
- Verify by watching use, not by trusting the API response. A 204 from a revocation call proves the request was accepted; only the absence of successful use after the revocation time proves the access is gone.
Why stopping the agent is not enough
An agent rarely holds one credential. A typical enterprise run involves several layers of borrowed authority, and the incident may have started in any of them: a prompt injection that drove the agent to misuse a legitimate grant, a compromised agent vendor whose token store was stolen, or a tool server whose upstream credential was exfiltrated.
- User to agent platform: an OAuth consent or delegated permission grant that lets the platform obtain tokens for the user, often with a refresh token that renews silently.
- Agent to tool or MCP server: an access token issued for the server's audience, as the MCP authorization specification requires.
- Tool to upstream API: the server acting as an OAuth client to the upstream service with a separate token, or a static API key in its configuration.
- Token exchange outputs: tokens minted under RFC 8693 for downstream services, which carry the actor chain in their
actclaims but are independent credentials once issued. - Agent's own identity: a workload identity, service principal or agent identity with client secrets, certificates or federated credentials.
- Copies: tokens written to agent memory, logs, scratch files or a vendor's database, which is where the Salesloft Drift breach tokens were stolen from.
For the design side of these chains, see the Agent Delegation Chains and Attenuation Guide.
Map the delegation graph first
Spend the first minutes of containment building this table. It tells you where to act and what will survive each action.
| Link | Who holds the credential | Where to revoke | What can survive |
|---|---|---|---|
| User consent to agent app | Agent platform or vendor | IdP grant store (Entra delegated permission grants, Google Workspace app tokens, GitHub app authorisation) | Access tokens already issued |
| Agent session for the user | Agent runtime | IdP user session and refresh token revocation | Access tokens at resources that do not evaluate revocation events |
| Agent to MCP server | Agent or MCP client | MCP server's authorisation server (refresh token revocation, client disable) | The server's own upstream tokens |
| MCP server or tool to upstream API | The tool server | Upstream provider, per user or for the whole client | Static keys in the server configuration |
| Token exchange output | Downstream service | Issuing authorisation server; downstream resource | Self-contained JWTs until expiry |
| Agent workload identity | Agent platform | IdP: disable service principal or agent identity, remove secrets and federated credentials | Tokens already issued to it |
| Copied tokens | Attacker | Every issuer of every copied token | Anything you did not inventory |
Use the agent registry, the IdP's enterprise application and grant listings, the MCP gateway configuration and the forensic timeline to populate it. The Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs covers how to find which credentials were actually used.
Revocation mechanics that reach issued tokens
Mechanisms differ in whether they stop new tokens only or also kill tokens already in circulation. Know which one you are pressing.
| Mechanism | Scope | Effect on issued tokens (as documented) |
|---|---|---|
Microsoft Graph DELETE /oAuth2PermissionGrants/{id} | One delegated permission grant | New tokens are not granted; existing access tokens stay valid for their lifetime. Needs DelegatedPermissionGrant.ReadWrite.All |
| Microsoft Entra revoke all refresh tokens for a user | All of a user's refresh tokens and sessions | Is a Continuous Access Evaluation critical event, so CAE-aware resources (Exchange Online, SharePoint Online, Teams) can reject current tokens; other resources honour tokens until expiry |
| Disable or delete an Entra service principal | The agent's workload identity | CAE for workload identities enforces disable, delete and high service principal risk, but only for Microsoft Graph, only for single-tenant line-of-business apps that declare the cp1 capability, and not for managed identities |
Google Workspace Directory API DELETE .../users/{userKey}/tokens/{clientId} | One user's tokens for one OAuth client | Deletes all access tokens issued by that user for the application; scope admin.directory.user.security |
GitHub DELETE /applications/{client_id}/grant | One user's authorisation of an OAuth app | Also deletes all OAuth tokens for the app for that user; /token revokes a single token |
| OAuth token revocation (RFC 7009) | One token at a compliant authorisation server | Servers must support refresh token revocation and should support access tokens; revoking a refresh token should invalidate access tokens from the same grant where supported |
| Disable the OAuth client or rotate its secret | Every user of that client | Stops refresh and new issuance; issued access tokens usually remain valid |
CAE-aware user sessions receive long-lived tokens of up to 28 hours, and CAE workload tokens up to 24 hours, because revocation is meant to be event driven. That is a benefit when the resource enforces CAE and a risk when it does not: a non-CAE resource will accept the token for its full life. Find out which of your agents' target resources are CAE-aware before you need to know.
Closing the gap for tokens that outlive revocation
- Shorten lifetimes in advance: the MCP specification says authorisation servers should issue short-lived access tokens and must rotate refresh tokens for public clients. Access token lifetime set to minutes for agent clients turns "until expiry" into a tolerable window. See the OAuth Refresh Token Rotation and Expiry Guide.
- Push signals to relying parties: the OpenID Shared Signals Framework and CAEP 1.0 (dated 29 August 2025) define events such as
session-revokedandcredential-changethat a transmitter can send to receivers, so a SaaS or tool server can end sessions it would otherwise trust. Coverage depends on which of your providers implement it. See the Shared Signals Framework Guide. - Enforce at the resource: where you own the API or the MCP server, keep a deny list of revoked token identifiers, client IDs or subjects, checked on every request, and reject tokens issued before the incident time for the affected identities.
- Cut the network path: if a token cannot be killed, block the agent runtime's egress or the tool server's route to the upstream API until the token expires.
- Remove the holder: shutting down the tool server that holds upstream tokens, or rotating the keys it uses to decrypt its token store, stops use from that location even if the tokens remain valid elsewhere.
Order of operations during an active incident
- Preserve evidence: export the grant listings, sign-in logs and token metadata for every identity in the graph, because some revocations remove the objects you need to examine.
- Stop new issuance at the root: disable the agent's client or service principal and its secrets and federated credentials, so it cannot mint anything new while you work down the graph.
- Cut the highest-impact downstream access: revoke the upstream tokens held by tools with write, delete, payment or data export capability first, at the upstream provider, for every affected user.
- Revoke user grants and sessions: delete the delegated grants users gave the agent platform and revoke refresh tokens for affected users. If a human account is suspected, also follow the user compromise path.
- Revoke token exchange outputs: ask each downstream authorisation server to revoke tokens issued with the agent as actor, or block them at the resource.
- Rotate copied and static secrets: API keys in tool configuration, secrets the agent could read from its workspace or vault paths, and anything in exported data. See the Credential Vaulting for AI Agents Guide.
- Cover the residual window: for tokens that cannot be revoked, apply resource-side denies or network blocks until the longest remaining lifetime has passed.
- Verify and record: run the checks below and record each action with its time, as part of the incident record.
Revoking an agent's grants for every user will break every legitimate workflow that depends on it. Agree in advance who can authorise a tenant-wide revocation and what message users receive.
Verifying that revocation worked
| Check | Evidence source | Pass condition |
|---|---|---|
| No new tokens issued | IdP sign-in logs for the agent's app ID and service principal | Only failures after the revocation time |
| No successful use of old tokens | Resource audit logs (cloud audit trail, SaaS audit, Microsoft Graph activity) filtered by app ID and identities | No successful calls after the longest remaining token lifetime |
| Grants gone | Grant listings (Entra delegated grants, Google user tokens, GitHub authorised apps) | No entries for the agent client for affected users |
| Upstream credentials dead | Test call with the old credential from an isolated host, if policy allows | 401 or equivalent from the upstream API |
| Signals delivered | Shared Signals transmitter and receiver logs | Acknowledged session-revoked events for each affected subject |
Decision guidance
- Targeted or broad: revoke per user when the incident is a prompt injection affecting a known set of sessions; revoke the whole client when the agent vendor or its token store is compromised, because you cannot know which tokens were taken.
- Revoke or block: revocation is permanent and forces re-consent; a resource-side block is reversible and faster to scope. Use blocks to buy time, then revoke once scope is clear.
- Smaller organisations: rely on provider console actions and short token lifetimes, and keep a written list of every agent app and its grants so you are not discovering them mid-incident.
- Larger organisations: script the graph build and revocation calls per provider, integrate them with the SOAR or incident tooling, and test them in exercises against a non-production tenant.
Measures
- Time from containment decision to last successful use of any agent-derived credential.
- Percentage of agent client applications with access token lifetimes below your target.
- Percentage of agent target resources that enforce CAE or receive Shared Signals events.
- Number of agents whose delegation graph is documented and current.
- Exercise result: credentials found active after a simulated revocation.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST CSF 2.0 | RS.MI-01, RS.MI-02, PR.AA-05 | Contain and eradicate the incident; manage and enforce authorisations |
| NIST SP 800-53 Rev. 5 | IR-4, AC-2(3), AC-3, AC-12, IA-5, SA-9 | Incident handling, disabling accounts, access enforcement, session termination, authenticator management, external services |
| MITRE ATT&CK | T1528 Steal Application Access Token, T1550.001 Application Access Token | The adversary behaviours that make surviving tokens dangerous |
| MCP specification | Authorization: token audience and passthrough | Explains why tool servers hold separate upstream credentials |
Common failure patterns
- Stopping at the agent: disabling the agent's identity while the tool servers' upstream tokens remain valid.
- Assuming grant deletion kills tokens: deleting consent and declaring the incident contained while issued access tokens run for another hour or more.
- Revoking one provider at a time: attackers move to the integration you have not reached yet.
- No inventory of downstream grants: discovering mid-incident which SaaS tenants the agent vendor was connected to.
- Containment at the vendor treated as containment for you: a vendor removing attacker access to its own environment does not invalidate tokens already copied.
- No verification window: closing the incident without checking resource logs past the longest token lifetime.
Lessons from incidents
- Revocation must span every integration: in the Salesloft Drift breach, Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application on 20 August 2025, but the Drift Email integration's Google Workspace tokens, already used on 9 August, were revoked by Google on 28 August. Google then advised all Drift customers to treat any token stored in or connected to Drift as compromised.
- A vendor's containment is not your revocation: in the Vercel Context.ai breach, Context.ai stopped unauthorised access to its AWS environment in March 2026, yet a stolen OAuth token for an AI app an employee had granted full access was used to take over a Google Workspace account before Vercel's 19 April disclosure. Customer-side grant revocation was the control that mattered.
Practitioner checklist
- Maintain a delegation graph for each production agent: grants, clients, tool servers, upstream credentials and token exchange targets.
- Script per-provider revocation calls (grant deletion, user token deletion, refresh token revocation, client disable) and test them.
- Set short access token lifetimes and refresh token rotation for agent clients.
- Record which agent target resources enforce CAE or consume Shared Signals events.
- Build resource-side deny lists for tokens, clients and subjects on APIs and MCP servers you own.
- Agree who can approve tenant-wide revocation of an agent app and how users are told.
- Preserve grant listings and sign-in logs before revoking.
- Verify revocation by checking resource logs until the longest token lifetime has passed.
Standards and references
- Model Context Protocol: Specification, Authorization
- IETF: RFC 7009 OAuth 2.0 Token Revocation
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- OpenID Foundation: Continuous Access Evaluation Profile 1.0
- Microsoft Learn: Continuous access evaluation
- Microsoft Learn: Continuous access evaluation for workload identities
- Microsoft Learn: Delete oAuth2PermissionGrant
- Google: Directory API tokens.delete
Related NHI Mgmt Group resources: Permission-Aware RAG Guide · AI Agent Kill Switch and Containment Guide · Agent Delegation Chains and Attenuation Guide · Consent Phishing and Illicit OAuth Grants Guide