Revoking an AI Agent’s Access in One Place

Choose what the revoke action stops

A laptop disappears while a coding agent is connected to the issue tracker, a database and an internal API. The useful emergency control is a server-side decision that rejects the laptop’s credential without requiring access to the laptop. Deleting its local MCP configuration cannot provide that control when someone else possesses a copy of the credential.

Define the target before choosing the button. Revoking one agent credential should stop that agent’s access through the endpoint while another agent continues working. Disconnecting the issue tracker should stop every agent using that connection. Offboarding a person requires finding all credentials and grants associated with that person; one revoked key does not stand for the whole identity.

Give each agent a distinct credential and record its owner, environment and intended sources. A label such as reviewer-ci-production is more useful during an incident than team-key. The companion guide to one scoped key per agent explains how to keep that revocation target small.

Remove routes around the endpoint

Draw the actual access paths from the affected machine. Include remote MCP connections, local server environment variables, shell-accessible service tokens, mounted credentials and CI secrets. If an agent can call the database directly with a password, blocking its gateway key leaves that route open. Network restrictions can help enforce the intended route, but they do not replace removing unnecessary credentials.

Use the inventory to distinguish the credential the agent presents from the credentials the intermediary presents upstream. The agent should receive authorization for the intermediary’s resources. Upstream credentials should remain with the component making upstream requests. MCP’s security guidance explicitly forbids accepting a token intended for another resource and passing it through unchanged; that pattern also muddles which boundary an operator is revoking.

Before relying on centralized revocation, retire obsolete direct connections and revoke their old credentials at the issuers. Removing a secret from a configuration file does not invalidate copies already made. Record any remaining exceptions beside the emergency procedure. For handling those machine-level copies, see credentials in agent sandboxes and VMs.

Make every call consult current authorization

A central URL only helps if the request path enforces the current decision. In a custom gateway, check that the presented credential is active and authorized for the requested workspace, source and operation before dispatch. Do not let an earlier successful connection become indefinite permission to invoke tools. MCP’s authorization specification requires authorization on every HTTP request and validation of tokens for the intended MCP resource.

OAuth token introspection provides one mechanism for consulting current token state. RFC 7662 defines the active response field and explicitly describes the risk of cached decisions: a resource can continue accepting a revoked token while relying on an earlier response. Its inactive-token response can be:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": false
}

That is a response from an authorized introspection endpoint, not a successful tool call. For an immediate-stop design, avoid stale positive authorization decisions or invalidate them across every serving instance. Recommend rejecting new tool dispatches when current authorization cannot be established. State any propagation window explicitly instead of describing a delayed stop as immediate revocation.

Handle OAuth access and refresh tokens together

When the credential is OAuth-based, identify both the access token and any refresh capability. RFC 7009 defines revocation using an HTTPS POST with a form-encoded body. This illustrative request uses dummy confidential-client credentials; the endpoint and authentication method must come from the issuer’s documentation. It is not a SPYN3 API example.

curl --request POST 'https://auth.example.com/revoke' \
  --user 'demo-client:demo-secret' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'token=demo-refresh-token' \
  --data-urlencode 'token_type_hint=refresh_token'

Do not substitute production secrets into a command retained in shell history. Use the issuer’s administrative control or a protected credential-handling process.

RFC 7009 allows HTTP 200 for both successful revocation and an already-invalid token. Cascading revocation depends on server policy, and existing access tokens may survive refresh-token revocation in some deployments. Verify both that existing access is rejected and that refresh cannot restore it. A 503 means the client must assume the token still exists. For a custom API key, use its issuer’s revocation mechanism; the OAuth request above is not a universal key-deletion API.

Prove denial with a controlled drill

Before an incident, rehearse with a disposable credential against harmless data. Keep the process using that credential running during the test: restarting the client can conceal a server that only checks permissions during connection setup. Use this sequence as an acceptance test for the emergency control:

1. Make an authorized read through the endpoint and record the credential identifier, source, tool and time. Confirm that an independent agent can read its own allowed source.
2. Revoke the test credential from a separate administrator session and record when the change is acknowledged.
3. Immediately repeat the read from the existing process, then from a fresh process holding the same credential. Check every serving instance or region your deployment uses.
4. For OAuth, test refresh through the issuer’s supported process. Confirm that the denied client cannot silently acquire replacement access through a surviving grant.
5. Verify that no new upstream request was dispatched for either denied call and that the independent agent still works.

For OAuth-protected MCP, the authorization specification assigns HTTP 401 to an invalid token and 403 to insufficient permissions. A timeout or upstream outage proves neither condition. Compare gateway and upstream records using timestamps and request identifiers, without retaining raw credentials.

Separate newly dispatched work from work accepted before revocation. A write already sent to an upstream system can complete after the key is disabled; a background job may require cancellation at that system. Record those operations for review. Revocation also cannot retract data already returned to the agent.

One dashboard action with SPYN3

SPYN3 provides one MCP endpoint per workspace at https://api.spyn3.com/agent/mcp. Upstream credentials stay envelope-encrypted in the workspace; the agent holds only a SPYN3 API key or OAuth token. Revoking a key or disconnecting a source is one dashboard action, effective on the next call. Choose key revocation to stop that credential, or source disconnection to stop access through that workspace connection. Every proxied tool call is audit-logged with source, tool, outcome and duration.

Restore access without restoring the incident

During a real laptop-loss event, revoke the affected credentials immediately; do not postpone containment until the inventory is perfect. Then follow the documented exceptions, check for refresh grants and inspect the last successful upstream operations. If an upstream credential reached the machine, revoke or rotate it at its issuer as well. The central endpoint cannot invalidate an independently usable secret held elsewhere.

Before issuing replacement access, establish why the old credential was exposed or misused and whether the replacement environment still has that condition. Give the replacement agent a fresh, narrowly scoped credential. Retain the old credential’s non-secret identifier and incident timestamps so later log review can distinguish old activity from recovery.

Close the incident with evidence: the last authorized dispatch, the revoke acknowledgement, the first denied attempt and any operation that continued upstream. If the drill revealed a second revocation console or a surviving direct token, update the access design and repeat it. The operational goal is a known stopping point for the affected agent, with the limits of that stop measured.