---
{
  "title": "Model Context Protocol (MCP) security",
  "summary": "Treat AI tool servers as execution boundaries, constrain credentials and inputs, and distinguish untrusted tool text from authorized user instructions.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: MCP Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---
## What it means

MCP security protects the connection between AI clients, tool servers, and the resources those tools can access. Tool descriptions and results can contain untrusted content, while executions may carry powerful credentials. The execution boundary needs explicit authentication, authorization, input constraints, and isolation.

## A practical example

An assistant connects to a document tool with a narrowly scoped identity. The service checks access to each requested document and does not accept a tool description or returned page as approval to change permissions or call unrelated sensitive operations.

## What to check

Review server provenance, transport, credential scope, tool schemas, and authorization at execution time. Audit sensitive actions and isolate tool processes according to the resources and authority they require.

## A common pitfall

Installing a connector does not imply that every tool call is appropriate for every user. Descriptive text is not a substitute for a trusted permission decision.

## Think it through

Why verify permissions at the tool server even if the assistant has rules?

**Answer:** The server is the enforcement boundary and must reject unauthorized requests regardless of how the client generated them.

## The tool description is not permission

Imagine a fictional academy assistant can search course documents and update an internal task list. A document returned by the search tool contains text telling the assistant to publish all files. That text is source material, not trusted authorization for a new action.

The tool server must still enforce which user can access each resource and perform each operation. Client-side instructions help guide behavior, but they cannot replace a service rejecting an unauthorized request.

## Map authority before connecting tools

For the assistant, list read and write capabilities separately. A document-search tool should not receive an administrator credential merely because the assistant might someday need another operation. Limit the credential, exposed operations, and execution environment to the actual workflow.

Server provenance also matters. Installing or connecting a tool introduces software and service dependencies. Review who operates it, how it communicates, what data it receives, and how its implementation is maintained.

## Validate execution inputs independently

A model can generate incorrect or manipulated arguments. Tool schemas help describe expected input, while execution-time validation and authorization decide whether the request is acceptable. A plausible document identifier is not proof that the requesting user owns the document.

For sensitive changes, preserve an audit trail connecting the actor, request, resource, and result. Avoid recording credentials or unnecessary document contents just to make the log detailed.

For a paper exercise, draw the user, assistant, search server, and document store. Mark where instructions are trusted, where document text becomes untrusted data, and where permissions are enforced. Then add a task-update tool and describe the narrower authority it requires. Explain how the service would reject a manipulated request even if the assistant attempted it. This turns an AI integration into a concrete access-control design rather than relying entirely on the assistant's willingness to follow rules.

## Related concepts

- [[prompt-injection]]
- [[least-privilege]]
- [[trust-boundaries]]