Find the trust boundary that changed
A Model Context Protocol incident can involve a local server, a remote service, a client, an authorisation flow or the business API behind a tool. Start by naming the implementation and deployment. “We use MCP” does not establish how credentials are stored, how tools are approved or which permissions a server can exercise.
Useful observations include an unexpected tool definition, a server package change, an unfamiliar consent request, a new outbound destination or an operation outside the intended task. These signals call for investigation; they do not by themselves prove that the protocol or every connected server is compromised.
The first scoping questions
- Which client, server and package or deployment version were involved?
- Was execution local or remote, and under which operating-system or service identity?
- Which tools and downstream APIs were available to that session?
- Which scopes and consent decisions were used? Do not send tokens themselves.
- What was the observed effect in the destination system?
- Who can authorise disconnecting the server, disabling the integration or changing its access?
Evidence and containment options
| Observation | Preserve through authorised owners | Containment decision to assess |
|---|---|---|
| Tool or server changed | Approved definitions, package provenance, deployment history and run records | Pause the affected integration and review the deployed version |
| Unexpected identity use | Consent, token issuance and destination audit records | Restrict or revoke implicated grants without breaking unrelated services |
| Suspicious local execution | Process context, approved collection of host records and package details | Involve endpoint responders and isolate the affected execution boundary |
| Unintended external operation | Arguments, tool response, job status and downstream changes | Stop queued work and determine whether a reversal is safe |
Reconnect only after validation
A replacement token is not sufficient if the server package or its permissions remain untrusted. Review the server source or provenance available to the customer, deployment, tool definitions, client approval behaviour and downstream authorisation. Then exercise a legitimate operation and the previously unsafe condition in an approved environment. Verify the resulting state, not just a model’s description of success.
A local server may have access beyond a remote API connector. Include the relevant host owner and endpoint investigation when indicated. A remote server may depend on a third-party provider’s records and remediation; document that dependency in the recovery decision.
Technical reference and related support
The MCP security best practices discuss implementation risks including authorisation and token handling. The linked documentation is a draft; its version matters when comparing implementations. For connected-agent actions, continue to AI agent incident response; for credential exposure, see AI API key compromise.
Discuss your situation
Build an incident brief with non-sensitive context, or request a scope discussion. We confirm people, access, fees and availability before work begins.
