# AI agent and MCP security: constrain the tool, not just the prompt Canonical: https://www.web3sec.news/blog/ai-agent-mcp-security-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: AI agents & MCP Published: 2026-11-08 Updated: 2026-11-08 A runbook for agent integrations, local servers, authorization, data access and realistic prompt-injection tests. ### Diagram: A tool connection crosses several trust boundaries. Check the client, server and upstream system as separate principals. ![An MCP client sends a scoped tool request to an authenticated server, which calls an upstream system with its own authorization. Returned data travels back as untrusted evidence. Connecting a server does not give returned content authority over future actions.](https://www.web3sec.news/diagrams/mcp-trust.svg) [Full-size SVG](https://www.web3sec.news/diagrams/mcp-trust.svg) · [PNG download](https://www.web3sec.news/diagrams/mcp-trust.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Inventory every boundary in the agent workflow Assign an integration owner and list the model-facing tools, MCP servers, connected services, local processes and identities used by the agent. Record which tools read private data, write externally, execute code or change permissions. Include tool descriptions and updates in the reviewed configuration: they influence how the agent selects an action even when they are not visible in the user’s ordinary prompt. Distinguish local stdio servers from remotely hosted HTTP services. The MCP authorization specification addresses HTTP transport authorization; a local server is also executable software running with the operating-system permissions it receives. Installing a convenient server package can therefore expose files or environment variables before any model decision occurs. Treat installation and runtime access as separate review steps. ## Enforce a narrow, explicit authority model The MCP security guidance covers token passthrough, confused-deputy behavior and server-side request risks. Use the intended authorization flow and validate tokens for the resource that receives them. Do not accept an arbitrary upstream token as proof that a client may perform every downstream action. Scope each integration to the user, tenant, resource and operation it actually needs. Our procedure is to separate read-only research from privileged execution. Use an execution environment with limited filesystem and network reach, explicit upload destinations and task-scoped credentials. An approval should display the concrete action, recipient and data involved. Keep the enforcement component independent from untrusted document text; a web page or tool result cannot legitimately grant itself additional authority. ## Test hostile content against outcomes Create synthetic documents and repository comments containing instructions to send a dummy secret to a controlled unauthorized destination. Also test a tool response claiming to be an administrator or requesting installation of another tool. The success criterion is that policy prevents the prohibited action, even if the model attempts it. Refusal wording alone is not an adequate measure of the tool boundary. For remote servers, test user and tenant isolation, expired tokens and incorrect audiences through authorized staging tests. For local servers, verify allowed files, child processes, environment variables and network destinations. Record what a compromised server could do without further approval. Repeat the tests when tools, permissions, server versions or workflow goals change, because each can change the reachable impact. ## Contain an integration and preserve an action trail Keep a kill switch that disables the integration and invalidates its credentials without requiring the agent’s cooperation. Log initiating user intent, tool identity, proposed operation, authorization result and external destination while excluding secret values. Preserve enough content context to explain a suspected injection through a restricted evidence process rather than logging every private document by default. During an incident, stop affected tool access, identify completed actions and review downstream service audit logs. Revoke sessions or tokens and reverse authorized reversible changes through a trusted operator. Removing a malicious prompt from a document does not undo a sent message, changed permission or uploaded file. Restore the integration only after its authority and the demonstrated failure mode have been reviewed. ## Controls to take away - A prompt cannot reliably replace a permission boundary. - Local MCP servers are software installation and process-isolation decisions. - Recovery follows completed tool actions, not only the text that triggered them. ## Work through the boundary Local planning worksheets; they do not inspect or change accounts or environments. - [Build a permission review plan](https://www.web3sec.news/tools/agent-permissions): Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent. - [Prepare the research environment](https://www.web3sec.news/tools/research-preflight): Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Inventory tools, server transports and execution identities. - [ ] Review local server code and its operating-system access. - [ ] Scope authorization by resource, user and operation. - [ ] Test injections against blocked outcomes using dummy data. - [ ] Maintain an independent kill switch and action audit trail. ## Sources & further reading - [MCP: security best practices](https://modelcontextprotocol.io/docs/draft/tutorials/security/security_best_practices) - [MCP: authorization specification, draft](https://modelcontextprotocol.io/specification/draft/basic/authorization) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)