Visit Website →
← Back to blog

MCP Security: Turn Spec Requirements Into a Checklist in One Week

October 14, 2026
MCP Security: Turn Spec Requirements Into a Checklist in One Week

Treat every MCP server and every tool response as untrusted data, the same way you'd treat input from an anonymous API on the open internet. The immediate work is concrete: inventory every MCP connection in your environment, enforce an allowlist with deny-by-default, harden OAuth token validation against audience and passthrough failures, require schema-validated tool outputs, and turn on structured auditing before you expand agent autonomy any further.

TL;DR:

  • Because MCP servers can change tool manifests after approval, pin each accepted manifest’s cryptographic hash and verify it at every session start.
  • For public clients, require PKCE with S256; reject token passthrough, validate issuer and audience on every request, and keep access token lifetimes short.
  • Require human approval before irreversible actions such as payments, deletions, or outbound messages, and run sensitive tools in isolated execution contexts.
  • Audit logs should capture each manifest hash, tool call, returned payload hash, and authorization event so investigators can reconstruct the exact tool version used.
Gyrence
Build Safer MCP Web Workflows
Gyrence’s hosted MCP endpoint returns typed responses, including failure cases, so agents can reason about web data without guessing.
Explore the hosted MCP endpoint

Table of Contents

What MCP is and why it creates protocol-specific risks

The Model Context Protocol connects an AI client (an agent, an IDE plugin, a chat interface) to one or more servers that expose "tools": callable functions described by a manifest. The client reads the manifest, decides which tools to expose to the model, and relays tool calls and responses over a transport, either HTTP or STDIO for local processes.

The risk surface comes from what happens to that manifest and those responses once they arrive. Tool descriptions are not metadata sitting quietly in a config file. They get pulled directly into the model's context window alongside the user's prompt, meaning a tool description can carry instructions the model may act on before you ever see the tool's actual output.

  • Manifests and tool descriptions are read as natural language and become part of the LLM's effective instructions, not just a function signature.
  • Tool call responses flow back into context the same way, so a compromised server can inject new instructions mid-conversation.
  • MCP supports dynamic discovery: servers can update manifests after a client first connects, which means an approval granted on day one says nothing about what the tool looks like on day thirty.

That last point is the structural problem. A connection approved once, with no re-verification, is a connection you've stopped watching.

Key MCP security risks worth prioritizing

Not every risk deserves equal engineering time. These are the classes that show up repeatedly in research and practitioner reports, ranked roughly by how much damage they cause relative to how easy they are to exploit.

  1. Tool poisoning. A malicious or compromised server ships a tool description containing hidden instructions, a pattern that includes the "rug-pull" variant (a tool behaves normally at approval time, then the manifest changes later) and "tool shadowing" (a newly installed server redefines or intercepts calls meant for a trusted tool).
  2. Indirect prompt injection via tool outputs. Even a legitimate tool can return attacker-controlled content, a scraped web page, a document, an email, that carries instructions the model treats as legitimate context.
  3. Token and authentication failures. Token passthrough, missing audience validation, and mix-up attacks (a token issued for one resource accepted by another) let a credential meant for one server reach a different one entirely.
  4. Confused deputy and SSRF vectors. An external MCP server can be positioned to make your trusted infrastructure issue requests on its behalf, reaching internal services that were never meant to be reachable from the outside.
  5. Shadow integrations. Developers add MCP servers through CLIs, desktop apps, or IDE extensions that never pass through security review, quietly expanding the attack surface with connections nobody's tracking.

The CSA research note on MCP tool poisoning documents proof-of-concept exploits showing high attack success rates in lab evaluations, reinforcing that inventory, hash pinning, and gateway enforcement are not optional hardening steps but baseline controls. The common thread across all five risk classes is a trust model built around one-time approval. OWASP's cheat sheet for securely using third-party MCP servers makes the same point from a different angle: the fix is continuous verification, not a better initial review.

Threat scenarios and real-world examples

Abstract risk categories are easier to prioritize once you see how they chain together in practice.

  • Rug-pull exfiltration. A tool approved for a benign purpose, say, formatting text, later has its manifest silently updated to include instructions that direct the model to attach sensitive conversation history to its output. The CSA proof-of-concept work documents this pattern leading directly to data exfiltration, because nothing in a typical deployment re-checks a manifest after the first approval.
  • Manifest tampering over an insecure channel. When manifest fetches aren't integrity-checked, a position between client and server (a compromised network path, a malicious proxy) can tamper with the manifest in transit. The failure that enables this isn't exotic: it's simply the absence of a hash check at session start.
  • Shadow integration exposure. A developer installs an MCP server from a CLI tool or package to speed up a side task, and that server now has the same access to the agent's context as every reviewed integration, without ever appearing in a security inventory.
  • Downstream impact. The consequences cluster into three buckets: unauthorized data disclosure, actions taken by the agent that it was never meant to be authorized for, and compliance exposure when regulated data moves through an unreviewed channel.

None of these require a sophisticated attacker. They require a gap between what was approved once and what's actually running now.

Authorization and token best practices

Most of the auth failures above trace back to skipping steps the MCP specification already covers. The MCP authorization specification builds directly on OAuth 2.1 and is explicit about what a conforming client and server must do.

  • Validate token issuer and audience on every request; a token minted for a different resource should be rejected outright, not accepted because it happens to be well-formed.
  • Never pass a token through to a downstream service unmodified. The specification calls out token passthrough as an insecure pattern specifically because it breaks audience binding.
  • Require PKCE with S256 for any public client, and prefer confidential clients wherever your deployment model allows for one.
  • Keep access tokens short-lived, rotate refresh tokens on use, and store both using your platform's secure credential storage rather than plain environment variables or local files.

Audience binding under RFC 8707 is the detail most implementations skip, and it's the one that stops a stolen or leaked token for one MCP server from being replayed against another.

Pro Tip: Set your token lifetime to the shortest window your refresh flow can tolerate; a leaked token that expires in minutes is a much smaller incident than one valid for a day.

Deployment and architecture controls

Individual auth fixes don't help if you don't know how many MCP connections exist in the first place. Architecture controls close that gap at scale; for an in-depth look at prompt injection defenses and architectural design, see prompt injection defense for security teams.

  • Build and maintain a full inventory of MCP connections, including ones added through dev environments, CLI tools, desktop apps, and automated pipelines, not just the ones your platform team provisioned.
  • Move to a deny-by-default posture: a server has to be explicitly allowlisted before any client in your organization can connect to it.
  • Record a SHA-256 hash of every accepted tool manifest and re-verify that hash at the start of each session, catching both rug-pulls and in-transit tampering before a poisoned manifest reaches the model.
  • Route MCP traffic through a gateway or proxy that inspects manifests, enforces schema and policy centrally, and gives you one place to apply controls instead of hardening every third-party server individually.

A gateway works the same way a web application firewall does: consistent enforcement at the boundary scales better than trying to vet every integration by hand, a point OWASP's MCP cheat sheet makes directly when it recommends deny-by-default and runtime schema checks over relying on connect-time trust.

Pro Tip: Treat manifest hash pinning the way you treat dependency lockfiles: an unexpected change is a build failure, not a silent update.

Hash mismatch stopping a deployment build

Runtime validation and isolation

Architecture controls stop known-bad connections. Runtime controls handle the responses that make it through anyway.

  • Require tool outputs to be structured JSON validated against a strict schema; a tool that returns free-text where a schema expects fields should fail closed, not get passed to the model as-is.
  • Run high-privilege tools in isolated execution contexts that an external server has no path to reach, so a compromised low-privilege tool can't pivot into a sensitive one.
  • Enforce human approval for irreversible actions, payments, deletions, outbound communications, and build step-up authentication flows for anything above a defined sensitivity threshold.
  • Establish a behavioral baseline for each tool shortly after onboarding, then alert on deviations: a tool that suddenly requests network access it never used before is a signal, not noise.

Anthropic's engineering guidance on code execution with MCP notes that running tool logic inside a sandboxed execution environment keeps intermediate results out of the model's context entirely, reducing exposure, though it adds its own sandboxing and resource-management overhead. Schema enforcement at the gateway catches the bulk of simple injected-instruction attempts; what's left over is structured fields that accept commands, which still need their own validation layer.

Observability, logging, and red-team readiness

You can't investigate what you didn't log, and with MCP, the thing you need to reconstruct is a chain of manifest versions, not just a request history.

  1. Log every manifest load, the manifest's hash, each tool invocation, a hash of the returned payload, and every authorization event tied to that session.
  2. Correlate those logs so you can reconstruct, after the fact, exactly which tool version an agent was using at any point in a session, not just that "a tool" was called.
  3. Build tool-poisoning proof-of-concept cases into your red-team exercises, and run automated static analysis against manifests using tools like mcp-scan to catch known injection patterns before they reach production.
  4. Keep an incident playbook ready: demote the agent's autonomy level, isolate the affected connections, and revert to the last known-good pinned manifest while you investigate.

Pro Tip: Store payload hashes, not just payloads; it keeps your audit trail lightweight while still letting you prove exactly what a tool returned during an incident.

Priority one-week checklist for engineering teams

Spreading these controls over roughly two weeks keeps the highest-risk gaps closed first without asking a team to redesign its MCP architecture overnight.

  1. Week 0: Inventory every MCP connection across dev, CLI, desktop, and pipeline environments, block any unknown or unreviewed server, and flip your default posture to deny.
  2. Week 1: Pin manifest hashes for your highest-privilege tools, turn on audience validation and PKCE for every auth flow, and require structured, schema-validated outputs for any sensitive tool call.
  3. Week 2: Stand up a gateway or proxy for centralized policy enforcement, start red-team testing with tool-poisoning scenarios, and enable full structured logging across manifest loads and tool invocations.
WeekPrimary focusKey control
Week 0VisibilityInventory connections, deny-by-default
Week 1AuthorizationManifest hash pinning, PKCE, audience validation
Week 2EnforcementGateway deployment, red-team tests, full logging

Gyrence operational perspective: design choices that reduce MCP risk

A few of the controls above show up concretely in how we built our own hosted MCP endpoint. Every call across our five primitives, Search, Traverse, Fetch, Extract, and Map, returns a typed, discriminated-union response, which means schema validation isn't an afterthought bolted on by whoever integrates us: failure modes are part of the type itself, and an agent (or a human reviewer) can tell a successful extraction from a blocked one without guessing.

  • Typed response unions give downstream systems a structural contract to validate against, rather than a wall of untyped text to parse and hope.
  • Spending caps and predictable per-call credit pricing limit the blast radius of a misbehaving agent making unbounded calls, a different failure mode than tool poisoning but one that compounds it.
  • Our hosted MCP endpoint comes with a setup guide that gets a connection running in a few minutes, and a broader walkthrough for mapping our primitives into a working MCP client for teams building their own integration layer.
  • Our developer guide and agent framework documentation cover onboarding patterns for LangChain, CrewAI, AutoGen, and native MCP clients.

Governance and prioritization for MCP defenses

The teams getting this right have stopped treating MCP approval as a one-time gate and started treating it as a process that runs continuously: automated re-verification of manifests and tokens, not a checkbox signed off at onboarding. If you can only fix one thing first, fix the controls around your highest-privilege tools, the ones that can move money, delete data, or send communications on a user's behalf, because that's where a poisoned manifest does the most damage.

Progress here isn't a feeling. It's a baseline you can measure against: known-good manifest hashes, expected call patterns per tool, and red-team results that improve release over release.

— Glen

Get typed, validated web data through our hosted MCP endpoint

We built our API around the same principle this article argues for: structured, typed responses that surface failure modes instead of hiding them, so your agent validates results instead of guessing at them. Spending caps keep usage predictable, and our hosted MCP endpoint connects in minutes using the setup guide.

Gyrence

Check plan options and metered pricing or visit the Gyrence overview to see the five primitives in action.

FAQ

What is the single most important MCP security practice?

Treat every MCP server and every tool response as untrusted, the same stance OWASP recommends for third-party MCP usage. In practice that means inventorying connections, enforcing an allowlist, and validating tool outputs against a strict schema before anything reaches the model.

How does tool poisoning actually happen?

A server ships a manifest with hidden instructions embedded in a tool's description, or changes that manifest after initial approval in what's known as a rug-pull. The CSA research note documents proof-of-concept exploits where this pattern led directly to data exfiltration.

Does OAuth 2.1 fully secure an MCP deployment?

OAuth 2.1 compliance is necessary but not sufficient on its own. The MCP authorization spec also requires audience validation, PKCE for public clients, and rejection of token passthrough, all of which need explicit implementation beyond a standard OAuth flow.

What should be logged for MCP security auditing?

Log every manifest load and its hash, each tool invocation, a hash of the returned payload, and all authorization events tied to the session. This lets you reconstruct exactly which tool version an agent used at any point, which matters when a manifest changed mid-deployment.

How do I prevent shadow MCP integrations?

Require every MCP connection, including ones added through CLIs, desktop apps, or developer tooling, to pass through a central inventory and allowlist before it can be used. Pairing that with a gateway or proxy that enforces policy at the connection boundary catches servers added outside normal review.

Sources