The order matters more than the detail work. If an MCP server you use might be compromised — the vendor disclosed a breach, a scan flagged a tool that changed overnight, something it did looks wrong — cut its access first, investigate second. Here’s the sequence: revoke, check what it actually did, rotate anything it could reach, re-scan before you reconnect anything, and only then decide whether it comes back.

How you’d even find out

There’s no single alert that fires. In practice, a suspicion usually comes from one of a few places: the vendor posts a security advisory or breach notice; a re-scan flags a tool description or schema that changed since you last approved it, which is exactly the mechanism behind an MCP rug pull; you notice a call in your log that you can’t explain; or someone in the community reports the same server behaving oddly. None of these are proof on their own — a changed tool description can be an innocent version bump, not an attack — but any of them is reason enough to treat the server as untrusted until you’ve looked closer.

Step 1: cut it off before you investigate

Revoke access before you spend time figuring out whether the suspicion is real. If you’re wrong, reconnecting later costs you a few minutes. If you’re right and you spend that time investigating first, the server keeps whatever access it had the entire time. A grant you approved once can live in three separate places — the vendor’s own OAuth settings, your AI client’s connection list, and a gateway’s record if you use one — and revoking in one doesn’t automatically revoke the others. We wrote up exactly where a grant lives and how to pull it from each place in how to revoke an MCP OAuth grant. Start at the vendor, since that’s the only place with the authority to invalidate the underlying token outright.

Step 2: check what it actually did

Once access is cut, the next question is what the server called while you were still connected to it. This is where a call log earns its keep — not a list of connections, but a record of individual tool calls, with arguments and timestamps, that you can actually read back in order. If you don’t have one, this step is mostly guesswork: you’re left checking the downstream systems the server touched (your email, your CRM, your repo, your bank) for anything that looks out of place, without knowing where to start looking. We went through what a useful audit log needs to capture and why in MCP observability and audit logs. If you can reconstruct the actual sequence of calls, you can tell the difference between “nothing happened” and “this needs a much bigger response.”

Step 3: rotate anything the token could reach

Revoking the MCP grant stops that specific token from working going forward. It doesn’t undo anything the server already did with it, and it doesn’t necessarily cover every place a copy of that access might still be valid. If the server forwards the caller’s own bearer token straight to its backend instead of issuing its own scoped one — the pattern we covered in MCP token passthrough — a cached copy downstream may outlive the revocation at the original identity provider, and you generally can’t verify this from the outside. When in doubt, rotate the underlying credential (API key, password, refresh token) rather than trusting that a single revoke button reached everywhere it needed to.

Step 4: re-scan before you reconnect anything

Don’t reconnect on a hunch that things are fine now. Run the server through a security scan again — gate’s free MCP security scanner or another tool-description scanner — and compare what comes back against what you approved before. A scan reads tool names, descriptions, and schemas for known manipulation patterns; it won’t tell you what a tool did at runtime, but it will tell you if the tool definitions themselves changed, which is worth knowing either way. We went through exactly what a scan does and doesn’t catch in what an MCP security scanner actually checks.

Deciding whether it comes back at all

A clean re-scan is necessary, not sufficient. Before reconnecting, look for the vendor’s own account of what happened — a real incident report explaining what was affected and what they fixed is a different situation from silence. Confirm you’re actually pointed at the vendor’s real server and not an impersonator that showed up while you were looking elsewhere; the checks in how to tell a real MCP server from a fake one (domain, vendor docs, OAuth redirect) apply here too. And reconsider the scope you grant on reconnection — this is a natural point to ask for less than you had before, rather than clicking through the same broad consent screen out of habit.

Where gate fits: the reason this sequence is fast rather than a scramble is mostly preparation, not response. A gateway that keeps one list of which clients hold a live grant for which server means step 1 is one click instead of hunting through individual laptops and vendor settings pages. A plain-language log of every tool call means step 2 is reading a list instead of guessing. And scanning on every re-sync, not just at connection time, means a changed tool can surface as a signal before you ever get to this checklist. See the full model on gate’s security page, or how the single-URL gateway pattern works more generally on the MCP gateway page.

The bottom line

Revoke first, investigate second — a suspicion you can’t confirm yet still costs you nothing to act on early, and costs you everything to act on late. Check what the server actually called, rotate anything its token could reach rather than trusting one revoke button, and re-scan before you let it back in. None of this is exotic; it’s the same incident-response shape you’d use for a compromised employee account, applied to a tool your AI client happens to call instead of a person who happens to log in.