How Do You Actually Revoke a Bot's Access to a Tool It No Longer Uses?

What an OAuth revoke request actually does

A bot may hold an OAuth access token for a tool and a refresh token for obtaining later access tokens. RFC 7009 defines an HTTPS revocation endpoint where a client can submit either kind of token. It requires support for revoking refresh tokens and recommends support for access tokens, so the provider’s actual behavior matters.

For a valid request, the authorization server invalidates the submitted token immediately. The RFC also warns of a practical propagation delay while different servers learn about that invalidation. A successful response does not, by itself, prove that every resource server has stopped accepting the token at that instant. The client must stop using the token after a successful response.

Related tokens have their own policy. If a refresh token is revoked and the server supports access-token revocation, the RFC says the server should also invalidate access tokens from the same grant. If an access token is submitted, the server may revoke its related refresh token. Neither direction is an unconditional guarantee about every credential tied to the connection.

Sources: RFC 7009: OAuth 2.0 Token Revocation.

Token format and validation both affect the delay

RFC 7009 describes self-contained access tokens that a resource server can check without contacting the issuer, and reference tokens that require a lookup. A self-contained JWT is a common example of the first design, but its format alone does not decide whether a server can enforce early revocation. The validation method matters.

If a server checks only a token’s signature and expiry, it may continue accepting an already-issued token until expiry unless it also checks a revocation list or receives another invalidation signal. This is a conditional risk, not a rule that every JWT remains valid until expiry. Ask how the specific provider validates tokens and whether it can stop an active token early.

Reference tokens can provide fresher status when the resource server queries the issuer, but a lookup is not automatically live on every request. RFC 7662 permits caching introspection responses and notes that a cached active result may leave a window in which a revoked token is still accepted. The cache lifetime and provider implementation matter as much as the token label.

Sources: RFC 7009: OAuth 2.0 Token Revocation, RFC 7662: OAuth 2.0 Token Introspection.

Worked example: a fictional calendar bot

Illustrative example: a personal bot has calendar-write permission, a refresh token and an access token that expires in 60 minutes. The owner removes the connection in the calendar provider console. First, the builder checks whether that action revokes the grant, the refresh token, the current access token or some combination. A button label alone does not specify the provider’s policy.

Suppose the provider confirms the refresh token is revoked. The bot should no longer be able to exchange that token for a new access token. Whether the current access token also becomes unusable depends on the provider’s related-token policy and the calendar server’s validation. A locally validated token with no early-revocation check might still be accepted for the remainder of its lifetime. A server with an effective invalidation check could reject it sooner.

The builder removes the bot’s stored credentials and disables new calendar calls in its own system. For a controlled verification, it asks the provider or an authorized test client to attempt a harmless read with the old access token and records the response and time. Rejection supports the claim that this route has stopped working; a successful read means access is not yet fully cut off. Do not change a real event merely to prove the revoke button worked.

Sources: RFC 7009: OAuth 2.0 Token Revocation.

What to check for an authorized MCP connection

For an HTTP MCP connection using authorization, the MCP specification treats the MCP server as an OAuth resource server. It requires the server to validate each request’s access token, including that the token was issued for that server as its intended audience. Invalid or expired tokens must receive HTTP 401. The specification does not prescribe one token format or one revocation propagation method for every MCP server.

An MCP server may also call a downstream API with a separate token. The MCP specification prohibits passing the incoming MCP client token straight through to that API. Revoking the MCP-side grant and revoking a downstream grant can therefore be distinct operations. A builder should list both connections, identify which party issued each credential and revoke the credential that grants the unwanted action.

For a BotBento-style tool connection, the practical question is which credential can still reach which resource after revocation. Check the MCP server’s token validation and the downstream provider’s status independently. BotBento is pre-release; this is a design checklist, not a claim that it currently provides a completed revocation audit feature.

Sources: Authorization - Model Context Protocol.

A short checklist before trusting a revoke button

Revocation is a useful control, but an operator should distinguish the submitted token, related tokens and observed resource access. RFC 7009 says the submitted token is invalidated; it also permits differences in related-token policy and notes propagation delay. Verify the provider’s behavior before treating a console action as an emergency stop for a bot.

• Record the issuer, audience, scopes and expiry for each access token; identify whether the server validates locally or checks live status.
• Ask the provider whether revoking a refresh token also invalidates related access tokens, and whether revoking an access token affects its refresh token.
• Check for cached introspection results or other propagation delays. Short token lifetime limits one possible window but is not a complete revocation mechanism.
• Remove stored credentials and stop the bot’s own tool calls, then verify that an authorized old-token request is rejected by the resource server.
• For an MCP server that calls another API, inspect both the MCP authorization and any separate downstream credential before declaring access removed.

Sources: RFC 7009: OAuth 2.0 Token Revocation, RFC 7662: OAuth 2.0 Token Introspection, Authorization - Model Context Protocol.