What MCP changes
Incorrect or confidential text outputs can already cause harm. Tool access adds direct actions in connected systems. MCP is the protocol through which an assistant is offered tools and data sources: read files, create a ticket, run a query.
Two things shift as a result. First, there is a trust boundary between client and server that has to be authenticated and authorised. Second, text the model reads somewhere can lead to an action. Both points are familiar from classic application security but show up here in new packaging.
The specification accounts for this: there is a dedicated document with security guidance that is explicitly meant to be read alongside the authorization specification and the OAuth security recommendations from RFC 9700.
Confused deputy: the consent that gets skipped
The first described attack concerns MCP servers that sit as a proxy in front of a third-party API. The server uses a fixed client ID towards the third-party authorization server but allows its own clients dynamic registration.
After the first regular sign-in, the third-party authorization
server sets a consent cookie for that fixed client ID. An attacker
now registers a client of their own with a
redirect_uri they control and sends the user a
crafted link. Because the cookie is still there, the authorization
server skips the consent dialog. The authorization code ends up
with the attacker.
The specification phrases the countermeasure as an obligation: MCP
proxy servers must obtain consent per client before forwarding to
the third-party authorization server. That includes a register of
approved client IDs per user, a dedicated consent page with CSRF
and clickjacking protection, and an exact, not pattern-based check
of the redirect_uri. One detail decides success or
failure: the session with the state value may only be
set after consent. Whoever sets it earlier renders the consent page
ineffective.
Token passthrough: foreign tokens must be rejected
The specification labels it an anti-pattern when an MCP server accepts tokens from the client without checking whether they were issued for it and passes them through to the downstream API. The rule is unambiguous: MCP servers must not accept tokens that were not explicitly issued for them.
The reasoning is practical. Rate limiting, request validation and monitoring hang on the token's audience. Whoever bypasses it bypasses the controls. On top of that comes logging: the downstream service then sees requests that appear to come from a different identity than the server that actually forwards them. After an incident, that is the difference between a reconstruction and a guess.
Prompt injection meets tools
MCP does not solve prompt injection, it raises the stakes. The OWASP Top 10 for LLM Applications 2025 lists prompt injection as LLM01 in first place. Also relevant here are LLM06 Excessive Agency, meaning overly broad powers of action for a model, and LLM05 Improper Output Handling, meaning the unchecked further processing of model output.
The critical combination is untrusted content and broad tool permissions. If a model follows an injected instruction from a ticket, it can use its permitted tools to carry out an unwanted action.
An example. A team connects its assistant to the ticket system and allows it to propose changes in the repository. An external party then creates a ticket that instructs the assistant to remove a security check from the code. The assistant may confuse the injected instruction with its actual task. Limited permissions, an isolated workspace and human review before merging the change reduce the impact. A system prompt alone does not replace these controls.
The most effective countermeasure is not a filter rule but a permission decision: which tool does the agent get at all, which actions require a human confirmation, and what gets logged.
Keep permissions small, grant approvals individually
The specification dedicates a section of its own to permission
design. A token with broad permissions such as
files:* or admin:* increases the damage
on theft, makes revocation harder and renders the logs useless,
because a blanket permission no longer shows what the user actually
wanted.
What is recommended is a tiered model: a minimal set at the start
that covers only low-risk read and discovery operations, and a
targeted escalation via a WWW-Authenticate challenge
as soon as a privileged operation is attempted for the first time.
As common mistakes the specification explicitly names: blanket
permissions such as * or full-access,
bundling unrelated rights, and the assumption that the permissions
claimed in the token replace server-side authorization.
Local or remote: two risk profiles
Protected HTTP MCP servers check authorization on every request and accept only tokens intended for them. Protocol version 2026-07-28 removes protocol sessions. Application state handles, such as workflow IDs, must still be protected against hijacking and bound to the authorized user. They do not replace authentication. Check the protocol version actually in use: older implementations may still use sessions [1, 2].
Local servers are something else: programs that run on the user's machine and can have direct system access there. The specification names three attack paths: a malicious start command in the client configuration, a malicious payload in the server itself, and access to a server running unsecured on localhost. If a client supports one-click configuration of local servers, it must obtain consent beforehand that shows the complete, untruncated command and requires an explicit approval.
For companies this is the practically most important passage of the whole document. An MCP server from a package registry is executable code with the rights of the signed-in user. It belongs in the same approval process as any other software, and it belongs in a sandbox with restricted file and network access.
Checklist for operations
- Every MCP server has a named owner and an approval status.
- Local servers run in a sandbox with restricted file and network access.
- The server rejects tokens that were not issued for it.
- Consent is obtained per client,
redirect_urichecked exactly,statesingle-use and short-lived. - State handles are protected against hijacking; authentication and permissions are checked on every request.
- Writing tools are approved individually, not as a group.
- Tool calls are logged with identity, action, timestamp and outcome. Parameters are recorded only as needed; credentials and sensitive content are omitted or masked [5].
What you can decide afterwards
- Which MCP servers may run in your organisation, who approves them and who is accountable for them.
- Which tools an assistant gets for reading, which for writing, and which actions need a human confirmation.
- What tokens, consents and logs have to look like before a server goes into production.
Frequently asked questions
Is a good system prompt enough against prompt injection?
No. The model does not reliably distinguish between instructions from the operator and instructions inside the text it reads. What works is the permission decision: small permissions, individually approved write tools and confirmations for critical actions.
Are local MCP servers safer than remote ones?
No, they have a different risk profile. A local server runs with the permissions of the signed-in user and therefore belongs in the same approval process as other software, plus a sandbox with restricted file and network access.
May we use MCP servers from public registries?
Yes, but like any other third-party software: with review, a named owner and an approved version. An MCP server is executable code running with the user's permissions, not a configuration detail.
Sources
- MCP Specification: Security Best Practices Model Context Protocol, specification 2026-07-28
- MCP Specification: Authorization Model Context Protocol, specification 2026-07-28
- OWASP Top 10 for LLM Applications 2025 OWASP GenAI Security Project
- RFC 9700: Best Current Practice for OAuth 2.0 Security IETF, January 2025
- Logging Cheat Sheet OWASP Cheat Sheet Series