Learn / Model Context Protocol security: servers, tool poisoning, auth

Model Context Protocol security: servers, tool poisoning, auth

Securing the client-server protocol that lets AI agents discover and call external tools, including malicious or compromised tool servers.

11 of 48postings ask for it (23%)

AI Security Architect57%of 7 AI Security Engineer38%of 16 AI Security Consultant20%of 5 AI Security Researcher0%of 4 AI Red Teamer0%of 9 AI Governance and Risk Lead0%of 7

Researched on 2026-09-26 with AI assistance. Links and summaries can change; verify details with the original source. Not yet reviewed by a person.

What it is

The Model Context Protocol connects an AI host application to external tools and data through three parts: the host, an MCP client inside it, and MCP servers that expose tools over the protocol. The trust relationship is asymmetric: the host trusts the server to scope its tool effects, and the server trusts that call parameters came from an authorised host with vetted inputs, and both assumptions are often wrong.⁹

MCP security work covers the whole life of a server, from creation and deployment to operation and maintenance, with threats grouped by attacker type including malicious developers, external attackers, malicious users and plain implementation flaws.⁶

Two problem families dominate. One is content the model reads and obeys: tool descriptions, server instructions and tool output. The other is classic protocol and identity work: OAuth 2.1 authorization, audience and consent handling, and input validation inside the server itself.¹³⁹

OWASP's MCP Top 10 beta names the recurring risks as token mismanagement, scope creep, tool poisoning, supply chain tampering, command injection, prompt injection via context, weak authentication and authorization, missing audit and telemetry, shadow MCP servers, and context over-sharing.⁵

Why postings ask for it

11 of 48 postings (23%) ask for it, and the weight sits with builders and designers: 57% of the 7 AI Security Architect postings and 38% of the 16 AI/Agent Security Engineer postings, against 0% in research, red team and GRC.^P

Architect and engineer demand tracks the work: deciding which servers an agent may connect to, pinning what a server is allowed to say to the model, and making a remote server behave as a proper OAuth 2.1 resource server with per-client consent rather than a token forwarder.^P¹²

Consulting asks in 20% of 5 postings, which matches the review work clients need: server inventory and registry vetting, since one study of 67,057 servers across six public registries found 833 vulnerable servers and 18 with suspicious descriptions.^P⁷

Concepts you should be able to explain

If you can say each of these out loud in two minutes, with an example, you are ready for the technical part of an interview on this skill.

Host, client, server and the asymmetric trust

An MCP deployment has a host (the AI application), a client inside it that speaks the protocol and routes calls, and servers that expose tools. Tool call parameters come out of LLM reasoning, so a server must treat every parameter as untrusted input. The host in turn cannot assume a server keeps its tool effects inside the scope its description claims.⁹

Tool poisoning

Tool descriptions are read in full by the model but usually shown to the user in simplified form. An attacker who controls a server can hide instructions in a description, for example telling the model to read ~/.cursor/mcp.json and ~/.ssh/id_rsa and pass the contents in a spare parameter while explaining maths to the user. Invariant showed this against a popular MCP client and found a malicious server can also override instructions from other, trusted servers.³

Line jumping and server instructions

Poisoned content reaches the model during connection and tool listing, before any tool is actually invoked, so approval prompts on individual calls arrive too late. Trail of Bits calls this line jumping and treats server instructions, tool descriptions and input schemas as the surface to review and freeze. The same wrapper also strips ANSI control characters used to deceive the user in terminal output.⁸

Toxic agent flows

The tools themselves can be honest and the flow still be malicious. With the GitHub MCP server connected, a prompt injection planted in a public issue turned a benign request to review issues into the agent pulling private repository data into context and publishing it in a pull request on the public repo. This needs no compromised tool, only an agent that mixes untrusted content with privileged reach, and it gets worse when users switch on always-allow.⁴

Rug pulls and trust-on-first-use pinning

A server can present clean tools at install time and change them later, including via a tools/list_changed notification. The countermeasure is pinning: record the approved server instructions, tool descriptions and input schemas, compare on every connection and on change notifications, and block downstream calls until a human approves the new configuration. Servers are identified by their launch command or URL, so any change to that string counts as a new server.⁸

MCP authorization for HTTP transports

Authorization is optional in the spec, but HTTP-based servers that use it act as OAuth 2.1 resource servers and must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), returning WWW-Authenticate on a 401 so clients can find the authorization server, whose metadata (RFC 8414) the client must then use. Dynamic client registration (RFC 7591) is a SHOULD, which is why client identity is weak by default. STDIO servers should not use this flow and take credentials from the environment instead.²

Confused deputy in MCP proxy servers

A server that proxies to a third-party API with one static client ID, while letting MCP clients register dynamically, can be tricked once the third-party authorization server has set a consent cookie: a crafted link with a new client ID and attacker redirect_uri skips the consent screen and the authorization code lands with the attacker. The spec requires per-client consent stored server side, exact redirect_uri matching, CSRF protection, framing protection, and consent bound to a specific client_id rather than to the user.¹

Registry vetting and server supply chain

Servers arrive through public registries whose vetting and ownership checks are weak, so hijacked or adversarial servers can enter a host, and once integrated the attacker-controlled metadata shapes model reasoning while the host executes without independent verification. A study of 67,057 servers over six registries found widespread conditions for server hijacking and invocation manipulation, plus 833 servers with exploitable code. Pre-integration analysis of metadata and code is the control point.⁷

Use fictional data and authorised sandboxes. Remove employer details and secrets from any portfolio write-up. Time estimates exclude setup. Check model and cloud costs before running tests, set spending limits, and delete lab resources afterwards.

Three exercises

In order of difficulty. Free tools. Keep what you build; it is evidence.

1Reproduce a tool poisoning attack on a local serverabout 2 h

You can show a poisoned tool description, what the client displayed, and what the model actually did with it.³⁹

Write a local stdio MCP server with one harmless tool (add two numbers) plus a spare string parameter.
Put hidden instructions in the docstring, modelled on the Invariant example, telling the model to read a decoy file you created and pass its contents in the spare parameter.
Connect it to any MCP-capable client you already run and issue a normal arithmetic request.
Record what the user-visible UI showed versus the full description the model received, and where the decoy file contents ended up.
Write five review questions you would now ask of any third-party tool description.

Tools: Python, an MCP server SDK, a local MCP client, a text editor

2Pin a server configuration and catch a rug pullabout 3 h

You can demonstrate detection of a silent tool description change and explain what pinning does and does not cover.⁸

Clone and install mcp-context-protector with uv, then reconfigure your client to launch your server through the wrapper.
Approve the initial configuration through the wrapper CLI and confirm tool calls work.
Edit a tool description to add hidden instructions, restart, and record the block and the approval prompt.
Repeat by emitting a tools/list_changed notification instead of restarting, and note the difference.
Change the server launch command trivially and explain why the wrapper treats it as a new server.

Tools: git, uv, mcp-context-protector, your local MCP server from exercise 1

3Review a remote MCP server as an architectabout 4 h

You can produce a findings table for an HTTP MCP server covering authorization, consent, parameter trust and logging, mapped to named risks.¹²⁵⁹¹⁰

Stand up or pick an HTTP MCP server you control and check whether it publishes protected resource metadata and returns WWW-Authenticate on 401 per RFC 9728.
Model the confused deputy conditions: static third-party client ID, dynamic client registration, consent cookie, missing per-client consent, and note which apply.
On a server you run yourself, never a third-party hosted one, add a tool that fetches a URL, then test whether it can be steered at 169.254.169.254, 127.0.0.1 and a redirect chain, and note DNS rebinding as a bypass of literal IP blocklists.
Check what the server logs for each tool invocation and whether an investigator could reconstruct a session.
Map each finding to an OWASP MCP Top 10 item and propose one control per finding, including which containment pattern limits blast radius.

Tools: curl, Python, a local OAuth-capable test identity provider, a notes file

Practice questions

Written from the concepts above, not collected from a named employer. Open one, answer it out loud, then tick the points you covered; the score stays in this browser.

Walk me through tool poisoning and why per-call user approval does not stop it.Tool poisoning, Line jumping and server instructions