The new MCP spec shifts security to developers. Concrete checklist to secure your MCP server without slowing your AI agents.
The new Model Context Protocol specification, published in late June 2026, shifts a critical part of security responsibility from the protocol itself to the developers implementing it. In concrete terms: if your MCP server exposes a sensitive tool without strict OAuth token validation, the vulnerability comes from your code, not from the protocol designed by Anthropic.
This is a shift in philosophy, not just a simple patch. Until now, MCP remained relatively permissive about how servers handled authentication. The new enterprise-ready version, documented by SecurityWeek in late June, closes that loophole and pushes teams to harden their implementations themselves. We already touched on this in Agentic commerce on Shopify: MCP is becoming the standard interface between AI agents and business systems. The thing is, plugging an agent into your CRM or order database without proper hardening is opening a door that nobody's watching.
What changed in the MCP spec in june 2026
The MCP protocol works as a unified interface: an AI agent—Claude, Cursor, or any compatible client—connects to it to call external tools without specific integration code. X (formerly Twitter) launched its own MCP server in late June to let agents like Claude or Grok Build access its platform directly, according to TechCrunch. HiBob did the same a few days earlier with an MCP integration connecting Slack to its HRIS.
This rapid adoption has a downside. The more MCP servers exposed publicly, the larger the attack surface grows. The new spec addresses this by formalizing stricter requirements around token management and OAuth scopes. But it doesn't enforce them technically—it documents what an "enterprise-ready" server should do. It's up to each developer to follow through or ignore it.
That's the counterintuitive part: a more secure spec on paper can make the ecosystem less secure in the short term, because it creates the illusion that the protocol already handles the problem. It doesn't. It documents the problem and hands you the hot potato.
The flaws we're already seeing in MCP deployments
Tool poisoning: when a server lies about what it does
An MCP server declares its tools via a manifest in natural language—a description that the agent reads to decide when to call it. Nothing stops a malicious or compromised server from declaring a tool as "read-only" that actually writes to your database. The agent trusts the description, not the actual code. This is the most documented attack vector in the MCP security community since early 2026.
Misconfigured OAuth, the number one vector
Most incidents stem from a classic mix-up: overly broad scopes, tokens that never expire, or worse, tokens shared across multiple agents on the same server. A compromised MCP token gives access to everything the scope allows, not just the current request.
No sandboxing between the agent and the file system
Many MCP servers still run locally with near-total disk access to keep development simple. That works fine until the agent receives a malicious prompt injected via an external document and executes a shell command it should never have been allowed to run.
How to secure an MCP server in production
Here's what we recommend in concrete terms, in order of priority:
- Granular OAuth scopes, one scope per tool, never a global "admin" scope.
- Short token expiration, 15 to 60 minutes, with explicit refresh rather than tokens living for weeks.
- Validate the tool manifest on each call, not just during initial handshake.
- Systematic sandboxing, isolated container, read-only file system except for a dedicated directory.
- Audit logs per tool call, with alerting on abnormal patterns (frequency, timing, unusual scopes).
- Rate limiting on the MCP server side, independent from the underlying API's rate limiting.
This list isn't revolutionary. It's basically standard API hygiene applied to a protocol younger than most REST standards. The difference is nobody has the reflexes yet, because MCP has been publicly available for just over a year.
One honest limitation to mention: these measures slow down development. One scope per tool means more configuration every time you add a new tool. If your team ships fast and iterates on an internal MVP not exposed publicly, this level of rigor might be overkill. Reserve it for servers actually exposed to third parties or handling sensitive data.
MCP vs classic REST API: security comparison
| Criterion | Classic REST API | MCP Server |
|---|---|---|
| Authentication | OAuth 2.0 / API keys, mature standard | OAuth built into spec, but implementation varies |
| Capability discovery | Static documentation (OpenAPI) | Dynamic manifest read by agent at runtime |
| Attack surface | Known, fixed endpoints | Tools declared dynamically, harder to audit |
| Access control | Well-established roles and permissions | Scopes still coarse-grained in practice |
| Ecosystem maturity | 15+ years of proven patterns | Under two years old, best practices still evolving |
The table speaks for itself: MCP isn't any less securable than a REST API, but the ecosystem of tools, scanners, and best practices hasn't caught up yet. It will. In the meantime, it's on you to make up the difference.
What the big players are already doing
Anthropic evolved its Claude model to Sonnet 5 in late June 2026, replacing Sonnet 4.6 released in February, according to 9to5Mac. A more capable model creates mechanically more risks on the agentic side: the more autonomous the agent's decisions, the greater the downstream impact of an upstream MCP flaw. X chose to expose a public MCP server to let agents like Claude or Cursor interact directly with its platform—a choice that demands particularly strict token governance at that scale. HiBob, meanwhile, went for a more closed integration, connecting its HRIS to Slack via MCP rather than exposing an open server to any client.
Two philosophies, two risk levels. If your Shopify store or internal SaaS is considering exposing an MCP server, the first question to ask: do you really need open access, or is access limited to your own agents enough?
Conclusion
Three takeaways. First, the new MCP spec doesn't automatically secure your deployments—it documents requirements you must implement yourself. Second, the most frequent flaws remain classics: overly broad scopes, non-expiring tokens, absent sandboxing. Finally, rigor comes at a velocity cost—save it for servers actually exposed.
If you're already running an AI agent connected to your stack via MCP, or still weighing a no-code solution against a custom implementation, we detailed the tradeoffs in No-code vs custom code for building an AI agent. Need a security audit on your MCP server before going live? Get in touch at fstck.co.
Frequently asked questions
How do i know if my MCP server is vulnerable to tool poisoning?
Verify that the manifest declared by each tool matches its actual behavior in production, not just the documentation. Simple audit: log each tool call and compare the real action (write, read, external call) to the description in the manifest.
Should i wait for MCP to mature before deploying it to production?
No, but adjust your rigor level to the server's actual exposure. An internal MCP server accessible only by your own agents on a private network tolerates fewer constraints than a server exposed publicly to third-party clients.
What's the difference between OAuth scopes on a REST API and those on an MCP server?
The principle is identical—limit access to what's strictly necessary—but the MCP spec encourages one scope per tool rather than one scope per resource. In practice, many current implementations stay too permissive because the tooling to manage this granularity easily hasn't matured yet.
Does a compromised MCP token give access to all server tools?
Entirely depends on scope configuration. If the token has a global scope, yes, the attacker gets everything that scope allows. That's why scope granularity isn't an optional detail—it's your first line of defense.
Is MCP riskier than a classic API integration?
Not intrinsically, but less mature in terms of audit tools and standardized best practices. Dynamic capability discovery, which is MCP's strength, also complicates the static security analysis we easily do on a REST API documented in OpenAPI.
