MCP Incident Response: What to Do If a Server Is Compromised

If an MCP server is compromised, act in this order: disconnect it from every AI client, revoke and rotate the tokens and keys it held, preserve the logs, work out what it could reach and what it did, then remove or update it before reconnecting anything. Speed matters most in the first hour, because a compromised server keeps whatever access you gave it.

"Compromised" covers several situations. The server might be a malicious package, a legitimate server with a newly published vulnerability, or a trusted server that an AI was tricked into misusing. The steps overlap, and the playbooks below show where they differ.

This guide follows the shape of NIST SP 800-61 Revision 3, NIST's incident response guidance published in April 2025 as a Cybersecurity Framework 2.0 Community Profile. MCP-specific steps come from the spec and real advisories, checked on 28 October 2026.

Signs an MCP server may be compromised

Watch for:

• Tool calls nobody asked for, or calls at odd hours.
• Emails, messages or files sent that no one remembers sending.
• New or changed tools or descriptions you did not expect.
• An AI app asking to install or reconfigure a server out of the blue.
• Outbound connections from a local server to unknown addresses.
• A security advisory or vendor notice about a server you use.

Logging makes these visible. Without it, you often learn from a customer or a bill. See MCP audit logging.

The first hour

1. Disconnect. Remove or disable the server in every AI client that uses it. Stop any local server process. If you use a gateway, block the server there too.
2. Revoke access. Revoke the OAuth grants and API keys the server held, at the connected service or your identity provider. If you use the Enterprise-Managed Authorization extension, its docs say revocation at the identity provider takes effect "immediately across all MCP clients."
3. Rotate secrets. Change any password, key or token the server could read, including ones in environment variables or config files on the same machine.
4. Preserve evidence. Copy client, gateway and server logs before anything is deleted or rotated out. Note the server version and config.
5. Tell the right people. Your incident owner, IT provider and, if customer data may be involved, your legal adviser.

OWASP's guidance on shadow MCP servers gives the same core sequence when an unapproved server is found: contain it, preserve it for forensics, and rotate exposed credentials.

Scoping the damage

Ask what the server could reach, then look for what it did.

Downstream logs can be misleading if a server forwarded tokens it should not have. The MCP Security Best Practices warn that with token passthrough, downstream logs "may show requests that appear to come from a different source." Keep that in mind when matching activity to users.

Scenario playbooks

A malicious or impersonated package

Example: in September 2025, Postmark warned about a fake "postmark-mcp" package that blind-copied emails to an outside server.

1. Remove the package from every machine. Search developer laptops, not just servers.
2. Follow the vendor's advice. Postmark recommended checking email logs and rotating credentials that may have been sent by email.
3. Switch to the vendor's official server, confirmed through its own documentation.
4. Review how the package was chosen and add a publisher check to your server security review.

A vulnerability in a server or SDK you run

Example: the official TypeScript SDK's advisory for CVE-2026-104850 says affected clients that may have connected to an untrusted server should rotate secrets and revoke tokens, not only upgrade.

1. Check whether you run an affected version and whether the vulnerable feature or mode was on.
2. Upgrade to the fixed version, or disable the feature if you cannot.
3. Read the advisory for extra steps such as rotation.
4. Check logs for signs of exploitation during the exposure window.

Our incident tracker lists fixed versions for many MCP advisories.

An AI tricked into misusing a trusted server

Example: Invariant Labs showed a prompt injection in a public GitHub issue leading an agent to leak private repository data into a public pull request.

1. Remove or close the leaked content, such as the public pull request or message.
2. Find the source of the injected instructions and quarantine it.
3. Narrow the agent's access, for example to one repository per session.
4. Add approval for the action that leaked data. See prompt injection through tool results.

An exposed local server

Example: a MySQL MCP server advisory describes an SSE mode with no authentication that bound to all network interfaces.

1. Stop the server and check what was listening, and on which interfaces.
2. Review the connected database or system for unexpected queries or changes.
3. Rotate the database or account credentials the server used.
4. Restart only on stdio, or on 127.0.0.1 with a token, inside a sandbox.

Recovery

Reconnect only when:

• The server is removed, replaced, or updated to a fixed version.
• All exposed credentials are rotated.
• Scopes are reduced to what is needed.
• Logging is on, so you would see a repeat.

Restore data from backups where records were changed or deleted. CISA's small business guidance stresses testing restores, not just scheduling backups.

After the incident

Hold a short review within two weeks. Record:

1. What happened, in a timeline.
2. How it was detected, and how long it took.
3. What made it worse or better.
4. What will change, with owners and dates.

Update your MCP security checklist and your playbook. CISA also recommends reviewing your incident response plan after incidents and near misses.

Notification duties to customers, regulators or partners depend on your location, industry and contracts. Get legal advice on those. This guide is not legal advice.

Next step

The best time to plan is before an incident. Our MCP readiness audit checks whether your logs, token revocation and inventory would support a fast response. More guides are in the MCP security center.

Frequently asked questions