Loading lesson…
Model Context Protocol / Building & Securing
The trust boundaries around tools and data.
Reviewed by Yuvaraj
An MCP server extends a model's reach into the real world: it can read files, call APIs, query databases, and browse the web on a user's behalf. That reach is exactly what makes MCP a security-sensitive boundary. Every tool result flows back into the model's context, and every tool call executes with whatever privileges the server holds. This lesson maps the core threats you will face when building or connecting MCP servers, then shows the concrete defenses that break each attack chain. The framing throughout is defensive: assume the environment is hostile and design so that a single bad input cannot escalate into a harmful action.
MCP places a model at the center of a data-and-action loop. The host application embeds an MCP client; the client connects to one or more MCP servers; each server exposes tools, resources, and prompts backed by external systems.
Host app -> MCP client -> MCP server -> external systems (web, DB, email)
|
tool results flow back into the model's context
Two boundaries are easy to lose here. First, tool results are concatenated into the model's context alongside your system prompt and the user's message. The model has no built-in way to tell which tokens are trusted instructions and which are untrusted data it merely fetched. Second, when the model decides to call a tool, that call runs with the server's authority, not the caller's. A server holding a database credential or an OAuth token acts with the full scope of that credential.
| Risk | How it happens | Defense |
|---|---|---|
| Prompt injection via tool results | Untrusted content (web pages, files, tickets) returned by a tool carries text the model reads as instructions |
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
| Treat all tool output as data; never auto-run instructions found in results; require approval for consequential calls |
| Excessive agency / over-broad scopes | A server is granted more access than the task needs, so a hijacked model can do more damage | Least-privilege tool scopes; narrow, task-specific servers; deny-by-default |
| Confused deputy / token passthrough | A server holds downstream credentials and acts without checking the real caller's authority | Per-request authorization; never forward a client token straight to a third-party API; use audience-bound tokens |
| Malicious or compromised server | A server, or a later update, exfiltrates data or injects instructions into every result | Verify and pin sources; sandbox and isolate servers; log and monitor tool traffic |
The lesson of the trace is that no single defense is the whole answer, but the earliest and strongest cut is capability removal. An agent whose only tool is read_web_page has no path to email or read files, so step 4 cannot happen regardless of what the page says. Layering explicit consent and untrusted-data handling on top closes the remaining gaps.
For a curious beginner
A tool result is like a note a stranger left in a book. If you ask a librarian to read you the note, you do not then obey it. The model must treat fetched text the same way: content to reason about, never a command to run.
How it is actually used
Keep a hard separation between the trusted channel (system prompt, user turn, your policies) and the untrusted channel (anything a tool returns). Tag tool results as data, keep consequential capabilities behind explicit approval, and never let a tool result silently trigger another tool call without a policy check.
Authorization for HTTP transports
For servers exposed over HTTP, the MCP spec builds on OAuth 2.1: the server is a protected resource, the client obtains scoped access tokens, and tokens must be audience-bound to the server that issued them. Local stdio servers skip this handshake, but they still run with the privileges of the process that launched them, so isolation and least privilege still apply.
Common mistakes