Practical response guide. Use this to prepare decisions and evidence requests. Collection and containment must follow your organisation’s authority and secure handling arrangements.
Identify which component is actually suspect
An unexpected tool action does not automatically prove that the MCP server binary was compromised. The initiating client, a local package, a remote service, an authorised but excessive permission or an untrusted input may be involved. Begin with the observed action and map the components that could have produced it.
Record the client and server versions, deployment method, tool name, execution identity and destination system. Distinguish a local process from a remote endpoint. An incident involving a developer workstation may require endpoint investigation as well as review of the AI workflow.
Map the authority behind each connection
Follow the request from client to server to downstream service. Identify which credential is presented at each hop, who issued it and which operations it permits. Do not put raw tokens in the incident ticket. Use protected credential identifiers and secret-store references instead.
| Boundary | Investigation question |
|---|---|
| Client to server | Which client, identity and session initiated the request? |
| Server to tool | Which executable, package or remote endpoint handled it? |
| Tool to business system | Which principal performed the operation? |
| Returned content | Could an untrusted response influence a later action? |
Preserve deployment and execution evidence
Capture the relevant configuration, package provenance, approved version history and available execution records. Record collection time, collector and source. Keep the original evidence separate from working copies, and document any unavoidable changes made during urgent containment. Do not run a suspect package again merely to see what it does on a production system.
Correlate tool calls with destination-side events. A client transcript describing an action is weaker than a matching record from the system that accepted it. Where identifiers are missing, use time, principal and operation carefully and state the limits of the correlation.
Contain credentials as well as the server
Disconnecting the server can stop one path while a copied credential remains usable. Assess the scope of exposed secrets and the downstream sessions they may support. Coordinate revocation, replacement and business continuity with the relevant owners. The MCP security guidance highlights token passthrough and other trust-boundary risks; treat those as investigation hypotheses, not automatic findings.
- Pause the affected integration under agreed authority.
- Identify reachable downstream services and sensitive operations.
- Review credential exposure and revoke or replace as appropriate.
- Check queued tasks and actions already completed.
Establish what changed downstream
List attempted operations separately from accepted changes. Check whether records were read, modified, exported or deleted and whether a human approval was genuinely enforced. Examine the smallest evidence set capable of answering each question; a complete dump of business data is rarely the best first collection.
A useful impact register names the affected object, operation, identity, timestamp and evidence reference. Include unsuccessful attempts when they help explain the path, but do not count them as completed damage. Assign follow-up ownership where provider records are required.
Rebuild trust before reconnecting
Restore from an approved source and review configuration and permissions before reconnecting. Validate the specific failed boundary: intended tools remain usable, prohibited operations are denied and the identity is attributable. A clean package alone does not repair an excessive authorisation model.
Agree staged restoration, observation and rollback criteria. Our AI digital forensics service focuses on connecting the execution trail to the resulting system effects. The agent containment guide covers related decisions when multiple tools share one workflow.
Get help with the investigation
Atlant Security provides support for this response workstream as part of our AI incident response services. Start with the affected system, observed behaviour, business impact and urgency. We confirm availability, scope and a secure evidence channel before work begins.
Sources and review
Model Context Protocol: security best practices.
Reviewed 24 October 2026. The decision tables are Atlant Security planning guidance. Images are conceptual illustrations, not screenshots or evidence from a customer incident.
