my stuff, then you realize that not too way back, I wrote a chunk concerning the Model Context Protocol (MCP)—explaining what it’s, how it really works, and even walking you thru constructing your personal custom MCP servers. It was a deep dive into the shiny, promising world of agentic integration.
On the time, I used to be swept up by how elegant and powerful MCP felt. It was like discovering a universal adapter for AI agents (it’s!)—finally, I could connect large language models to any data source, tool, or API with ease. Every use case suddenly looked like an ideal candidate for MCP: document generation, customer support automation, even managing cloud deployments.
Then the news began rolling in.
First, there was the GitHub MCP vulnerability—a flaw that allow attackers exploit open-source MCP servers and siphon off user data. Then got here the critical distant execution exploit that allow unauthenticated users run arbitrary commands on hosts running improperly configured servers. And the cherry on top? Anthropic themselves needed to patch a severe vulnerability within the official MCP inspector tool, which had quietly opened a backdoor on hundreds of developer machines.
These weren’t theoretical risks. Real users—many similar to me—were getting burned for trusting a shiny latest thing just a little too fast.
It was around this time my partner, who’s deeply serious about security, asked me point-blank: “How within the hell is any of this secure? You’re just trusting random code from GitHub to run tools in your machine?”
That query stopped me cold. And it kicked off a long-overdue journey of digging into how other people were securing MCP—in the event that they were in any respect.
I began reading the spec closer, how enterprise users were configuring their deployments, testing community write-ups and criticisms. What I discovered was equal parts encouraging and terrifying. Encouraging, because there best practices and thoughtful security models being developed. Terrifying, because almost no person was using them.
So I made a decision to put in writing this guide.
MCP makes it incredibly easy to wire up an AI agent to do real, useful things—and that’s exactly what makes it just a little dangerous. When something feels that seamless, most of us don’t stop to ask the hard questions on security. We just assume it’ll be advantageous… until it isn’t. Unless you’re someone who lives and breathes cybersecurity, chances are high you didn’t think much about authentication, network exposure, or what happens if another person finds your server. This guide isn’t here to kill the thrill—it’s here to aid you use MCP without opening the door to hassle.
Table of Contents
- What “Secure MCP” Should Actually Mean
- Find out how to Avoid Becoming the Deputy That Gets Played
- Case Studies: Learning from Real MCP Security Breaches
- General Critiques—It’s Not Just MCP
- Future Outlook: Evolving Security in MCP and Agentic Protocols
- References
What “Secure MCP” Should Actually Mean
MCP does have a number of things going for it: built-in tool isolation, user consent prompts, and a local-first approach that keeps data in your machine unless you say otherwise. That is the part where the spec does its job.
But——none of that may prevent in case you’re out here YOLO-deploying your servers with root access, public ports, and no logging. That’s like putting a deadbolt in your front door after which leaving the keys in it. So let’s discuss what actual secure MCP usage looks like, in response to Anthropic, the community, and other people who’ve already learned these lessons the hard way.
How OAuth Works in MCP (Without Doing Anything Sketchy)
OAuth diagrams can feel like someone took a flowchart, spilled spaghetti on it, and decided that was ok. Boxes in every single place. Arrows in all directions. Mysterious “consent cookies” floating around like they’re self-explanatory.
But at the center of it, the concept is straightforward—especially in case you’re using MCP and also you care about not being creepy.
Let’s say your MCP-powered app desires to access a third-party service on the user’s behalf—possibly Dropbox, possibly Notion, possibly some obscure SaaS tool the finance team swears by. The catch: you wish to do it the user’s consent, not by sneaking behind their digital back.
So here’s the flow—minus the spaghetti:
Step 0: The User Already Logged In
You’re not ranging from scratch. The user has already authenticated along with your system, so that you’ve got the fundamentals: identity confirmed, session running, good to go.
No must ask them to prove they’re not a robot again.
Step 1: Actually Ask for Consent (Like a Decent System)
Now comes the vital part—third-party access.
As an alternative of doing something shady like token scraping or pretending to be the user, you redirect them to the third-party authorization server. Think Google, Microsoft, or Dropbox—the actual deal.
The third-party server pops up a consent screen:
“Hey, this app (via MCP) desires to access your data. Cool with you?”
The user reads it, thinks, “Sure, I trust this,” and clicks Approve.
Magic doesn’t occur yet—but a vital cookie does.
Step 2: The Consent Cookie and the Golden Ticket
Once the user approves, the third-party server sets a consent cookie for the mcp-proxy client. Consider it as just a little flag that claims, “Yes, this user gave explicit, non-coerced permission.”
Together with that, the server issues a 3P (third-party) authorization code and sends it back to the MCP Proxy Server. This code is sort of a golden ticket—limited-use, time-bound, but powerful enough to grant access.
Step 3: Code Exchange — The Secret Handshake
Now the MCP Proxy Server does what all good proxies do:
It takes the third-party authorization code and exchanges it for an actual access token — the thing that lets your app act on the user’s behalf.
But there’s a twist: the proxy also wraps that token right into a format that the MCP Client can understand—a correct MCP authorization code. Mainly: it translates it from “Dropbox-speak” to “MCP-speak.”
Step 4: Pass It Back (With Boundaries)
The Proxy sends the wrapped code back to the MCP Client.
Now, and now, the MCP Client can use it to call tools or access data on behalf of the user. But—and this part is very important—it might probably only do what the user consented to. No freelancing, no tool-hoarding, no “oops we accessed your calendar too” moments.
Why This Whole Thing Matters
This flow might look a bit complicated—nevertheless it’s designed that way for a reason.
- It puts the user answerable for what gets accessed.
- It guarantees consent is real, not assumed.
- And it avoids the horror movie scenario where the MCP Proxy becomes a silent middleman with superpowers.
Anthropic (and most of the people serious about agent security) recommend this pattern for a reason. In case you’re constructing agent systems that interact with third-party APIs, that is the best option to do it—with transparency, with structure, and most significantly, with the user’s explicit say-so.
How Malicious OAuth Proxying Works (a.k.a. Find out how to Impersonate a User Without Asking)
Sometimes, probably the most dangerous attacks don’t come from brute force. They arrive from confusion—not within the hacker, but within the system itself.
Enter the Confused Deputy Problem—an actual thing with an actual name, and yes, it feels like something from a spaghetti western. But as a substitute of a bumbling sheriff, we’ve got an OAuth proxy doing exactly what it was told… by the incorrect person.
Here’s how this sort of attack goes down:
Step 1: A Misleading Setup
Our attacker—we’ll call them EvilCorp (what can I say, I’m a fan of Mr. Robot)—starts by registering a legitimate-looking OAuth client with the third-party service. Think “TotallyRealApp, Inc.” with a redirect URI pointing to attacker.com.
The auth server approves it because, well, that’s how OAuth works—anyone can register a client.
Step 2: The Trap is Set
Next, EvilCorp sends the user a malicious link. This link looks normal on the surface—it references the legitimate mcp-proxy client ID—nevertheless it’s crafted to redirect to the attacker’s domain after authorization.
Here’s where things begin to smell fishy.
Step 3: The Cookie That Lied
The user clicks the link. No red flags pop up, because they’ve previously given consent to mcp-proxy, and their browser still holds the consent cookie from that session.
So when the third-party server sees the request, it shrugs and says:
“Ah, this again? Cool, they’ve already approved it. No must bug them.”
No consent screen. No confirmation. No idea they’re being targeted.
That is the moment:
The third-party auth server is acting because the deputy. It thinks it’s helping the legitimate client (mcp-proxy) do its job.
But it surely’s actually helping the attacker—since it doesn’t understand it’s being misled about and .
Step 4: The Token Goes to the Incorrect Place
The third-party service sends the authorization code to the MCP Proxy Server (still pondering that is a traditional flow).
The Proxy exchanges it for an access token, then wraps it into an MCP authorization code—standard procedure.
Then, the Proxy sends that MCP code to…
😬 attacker.com, because that’s the redirect URI EvilCorp snuck into the flow.
Congratulations: the attacker now has a totally authorized token tied to the user’s identity.
Step 5: The Attacker Becomes the User
With this MCP code, EvilCorp can impersonate the user. They didn’t need the user’s password. They didn’t need their approval. They simply needed the system to confuse
The proxy became the deputy—dutifully carrying out orders—without realizing it was working for the incorrect sheriff.
Why This Is a Security Nightmare
That is what security folks (like Anthropic) call a Confused Deputy Problem:
- The system that the authority (the MCP Proxy) gets tricked into using it (the attacker).
- The actual user? Completely out of the loop.
- Consent? Skipped.
- Damage? Potentially massive — from unauthorized data access to rogue tool execution.
Find out how to Avoid Becoming the Deputy That Gets Played
This isn’t a “we’ll fix it later” form of bug. It’s a fundamental architectural risk in case you don’t lock things down properly.
To avoid turning your proxy into an unwitting accomplice, Anthropic recommends a number of security best practices:
Authenticate Like You Mean It
Strong auth isn’t optional. It’s not a nice-to-have. It’s your entire defense line between “useful AI assistant” and “this thing just deleted my company database.” MCP now supports OAuth 2.1, so there’s no excuse.
All the time treat MCP servers like protected resources. Don’t let random clients connect and ask them to execute tools unless they’ll prove they’re allowed. Bonus points for using per-client API keys, dynamic registration, and really verifying the token audience.
Do not—and I can’t stress this enough—reuse static client credentials across different services. That’s the way you unintentionally invent a confused deputy attack and make your entire architecture one bad token reuse away from going full Mr. Robot.
Thou Shalt Not Pass (User Tokens)
One in every of the worst anti-patterns? Token passthrough. Imagine a client hands an MCP server a raw cloud token, and the server just forwards it like “sure, bro, I trust you.” Now the logs are broken, the audit trail is gone, and also you’ve bypassed all downstream rate limits.
The spec makes it clear—token passthrough is a no-go. Your server should either fetch its own tokens or thoroughly validate anything a client sends over. Every token must be tied to your server and used strictly for what it was meant for.
Validate Every thing (And Then Validate It Again)
MCP servers often wrap local system tools. That’s great — until someone passes image.jpg; rm -rf /. Suddenly, your “image converter” can also be a “file deleter.”
Validate all input. Don’t interpolate strings directly into shell commands. Use subprocess.run([...], shell=False) or similar secure calls. Normalize paths. Whitelist formats. Assume the AI is attempting to trick you—even when it isn’t. That’s just healthy paranoia.
This also applies to prompt injection. Sanitize incoming content. Wrap it. Audit it. MCP doesn’t magically make your LLM resistant to prompt attacks. If anything, it makes them more dangerous by giving those prompts real-world power.
Run It Like It’s Malware (Because It Might Be)
MCP servers should run with the fewest permissions humanly possible. Don’t give them root. Don’t give them access to your entire file system. Don’t allow them to confer with the web unless they absolutely must.
Containerize them. Use AppArmor. Use a sandbox. Restrict APIs. Block egress. Just assume that someday, something will go incorrect—and when it does, you wish the blast radius to be a spark, not a crater.
A compromised MCP server with write access to your database isn’t just bad—it’s .
Sessions Are Not Security
Sessions are for keeping track of context, not authenticating clients. Never treat session IDs as proof of identity. Never expose them in URLs. All the time tie them to user identity and store them server-side.
MCP’s statefulness makes this just a little tricky, especially across nodes. So yes, you’ll must get creative: shard sessions by user, validate identity on each request, and don’t let a legitimate session on node A mean anything on node B without re-authentication.
Otherwise, welcome to session hijacking hell.
Confirm Tools Like They’re Explosives
Simply because someone published an “email-sender” MCP server doesn’t mean it only sends emails. It could log them. Or rewrite them. Or forward them to your boss with a helpful “I QUIT” note.
Read the code. Use trusted registries. Don’t auto-update from GitHub without checking diffs. For critical use cases, fork the tool and control the lifecycle yourself. Until the MCP ecosystem has signing, metadata, and repute baked in, the burden is on you.
Mainly: in case you wouldn’t install a random binary from Reddit, don’t plug in a random tool from GitHub.
Log Like a Forensic Investigator
MCP isn’t like calling an API. Agents chain tool calls. They reason. They retry. You’ll need to know what happened when things go sideways.
Log all tool calls, inputs, outputs, timestamps, and user approvals. Monitor outbound traffic. Look ahead to spikes. In case your AI suddenly desires to call send_email 100 times at 3AM, possibly don’t sleep on that alert.
No logs = no visibility = no clue what the agent just did = good luck within the postmortem.
Humans Must Approve the Scary Stuff
This one’s obvious but often missed: AI shouldn’t delete files, send emails, or spend money without someone saying “yes, I would like this.”
That doesn’t mean you wish a 20-step approval flow. Just have a button. A prompt. Something. Even Claude Desktop requires you to approve tools one-by-one (unless you override that, which you shouldn’t).
Avoid consent fatigue. Batch low-risk approvals. Flag anything latest or sensitive. Don’t let the AI train you to click “Allow” reflexively like a caffeine-deprived cookie pop-up zombie.
These best practices aren’t just nice ideas—they’re seatbelts. You don’t skip the seatbelt since the automotive’s fast. You wear it the automotive’s fast. And MCP could be very fast.
Now let’s take a look at some case studies of what happens when those seatbelts are missing…
Case Studies: Learning from Real MCP Security Breaches
As an example why these best practices matter, let’s examine a number of real-world incidents and vulnerabilities which have emerged within the early days of MCP’s ecosystem. Each case highlights how failing to follow security guidelines can result in serious consequences – and conversely, how applying the above best practices can prevent or contain the damage.
Case 1: Distant Code Execution via Exposed MCP Inspector (CVE-2025-49596)
Sometimes, security lessons arrive in the shape of massive brow slaps. One in every of the earliest—and most avoidable—MCP-related vulnerabilities was discovered July 2025, courtesy of the Oligo Security team. The goal? Anthropic’s own MCP Inspector: a developer tool meant to make testing local MCP servers easier.
As an alternative, it made distant code execution easier.
The vulnerability—CVE-2025-49596—turned an area utility into an accidental attack surface. And all it took was a foul network config, no authentication, and a browser quirk with a catchy name: “0.0.0.0 Day.”
What Went Incorrect (Spoiler: Mainly Every thing)
MCP Inspector runs two components: an area UI client (your browser) and an area proxy server (handling MCP calls). But here’s the issue:
- The proxy server was listening on
0.0.0.0—which suggests network interface, not only localhost. - It had no authentication.
- It also lacked any form of origin or cross-site request forgery (CSRF) protection.
Mix that with “0.0.0.0 Day”—a bug where some browsers treated 0.0.0.0 as localhost—and also you’ve got a cocktail for distant code execution.
Oligo demonstrated that a malicious website could silently send commands to MCP Inspector using a cross-site request forgery (CSRF) attack. All of the user needed to do was… open a page. That’s it. No clicks. No warnings. Just vibes and root access.
Once exploited, the attacker could run shell commands, exfiltrate data, or burrow deeper into the system. All from the tool you installed to .
The Fix (a.k.a. What Should’ve Been There within the First Place)
The patch—MCP Inspector v0.14.1—was a direct implementation of the identical best practices you’ve examine 14 times on this post:
- Authentication token required for each request
- Origin and Host header validation to dam CSRF
- Session token verification before executing any motion
- Localhost-only binding — no more listening on the entire web by default
With these guardrails in place, those “just visit this site to get pwned” exploits stopped working. Since the server finally checked who was talking to it—and stopped trusting every request like an overenthusiastic intern.
What We Learned (The Hard Way)
This breach was a greatest-hits album of rookie mistakes:
- Trusting that “local” means “secure”
- Exposing tools on open interfaces
- Forgetting that browsers don’t care what you intended—only what’s possible
If the MCP Inspector had followed even a basic web app threat model, none of this may’ve happened. But since it was “just an area tool,” those precautions were skipped.
As Oligo Security put it:
The takeaway? Every MCP interface—regardless of how local, internal, or “only for testing”—needs real security controls. Which means:
- Require authentication
- Validate request origins
- Default to localhost
- Don’t leave debug ports listening on the general public web
Because in 2025, even your dev tools will be attack vectors—and your browser may not have your back.
Case 2: Prompt Injection via SQLite MCP Server Exploit
Let’s rewind to late June 2025, when Trend Micro turned on the highlight: certainly one of Anthropic’s reference SQLite MCP server implementations—not production-grade—harbored a classic SQL injection flaw that morphed right into a prompt injection nightmare. The blog headline says all of it: .
What Exactly Happened?
- The repo had already been archived by May 29, 2025, but had been forked over 5,000 times before then.
- The vulnerable engine built SQL queries by concatenating unsanitized user input with Python’s
sqlite3driver—no parameterization, no checks, just trust. - Enter prompt injection: the AI later reads database output and treats it as instructions. Cue malicious data disguised as a support ticket. The AI agent executes it—sending emails or deleting records—since it trusted “internal” data greater than logic.
Sean Park from Trend Micro summed it up:
In brief: SQL injection isn’t just an information layer flaw anymore—it’s a command prompt waiting to spring.
Why It Was Especially Dangerous
- The vulnerable server was openly available and meant as a reference, yet many reused it in real environments.
- It carried a supply chain risk: code widely copied and never patched.
- Anthropic explicitly said no fix can be issued—it was archived and marked “out of scope”.
That patch never happened, meaning vulnerabilities persist in the broader MCP world.
What Should’ve Been Done (And Still Can Be)
This attack chain—SQL injection → stored prompt injection → compromised agent workflows—demands layered defenses:
- Fix the server code: Use parameterized queries (never string-concat SQL) to sanitize inputs. It’s 2025, but OWASP basics still apply.
- Treat all stored content as untrusted: When your agent pulls content from an area DB, validate it prefer it got here from a stranger. Check the info types, escape special characters, and use secure wrappers or delimiters before including it in prompts or tool calls. Simply because you wrote it doesn’t mean it’s secure now.
- Require human approval for dangerous operations. Even after the AI processes internal data, any destructive command (e.g. deleting records or elevating privileges) needs to be gated behind a prompt or admin confirmation.
Trend Micro’s summary:
Case 3: When Enterprise Integration Met the Real World
It’s one thing to prototype with MCP in an area dev loop. It’s one other thing entirely when a billion-dollar company hooks it as much as real user data. In 2025, several early enterprise adopters of MCP learned this the hard way—on live infrastructure, with real customers watching.
Asana: The “Oops, That Wasn’t Your Data” Moment
In June 2025, Asana quietly rolled out a brand new MCP integration: the goal was to attach AI agents to their product suite to power automation and smart assistant features. But shortly after launch, things took a incorrect turn.
A bug within the system allowed one customer to access one other customer’s data—a textbook multi-tenant access control failure. When Asana discovered the problem, they acted fast: integration shut down, fix deployed, affected customers notified. Full credit for transparency.
Still, the foundation cause was a classic: shared infrastructure without properly isolated auth tokens or data partitions. In an MCP world, where agents and tools can span tenants, these controls aren’t optional—they’re survival gear.
Lesson: In case your MCP server serves multiple orgs, segregate all the things.
Which means:
- Auth tokens scoped per tenant
- Namespacing on tool invocations
- Context boundaries the AI can’t cross
- And no shared memory unless you know what you’re doing
Atlassian: Living Off AI, Literally
Over at Atlassian, the team integrated MCP into Jira Service Management, aiming to bring AI into ticket handling and workflow orchestration. It worked—possibly just a little well.
Security researchers at Cato Networks’ Threat Labs took a more in-depth look and discovered what they called a “Living Off AI” attack. The thought? Use prompt injection not only to hijack the AI’s response, but to abuse its access to backend tools—think scripting unauthorized actions by smuggling them into ticket comments or user fields.
Since the AI had elevated privileges and direct access to Jira APIs, a single poisoned prompt could trigger real, privileged behavior—without tripping the standard alarms. In an actual incident, this might escalate quickly from “weird ticket reply” to “suddenly deactivated accounts and modified permissions.”
To Atlassian’s credit, the design had audit logs and bounded actions, so this was caught before it caused damage. However the report underscored something everyone needs to listen to:
AI privilege != user privilege
Simply because the AI call a tool doesn’t mean it achieve this unsupervised.
What These Incidents Really Tell Us
Enterprise adoption of MCP isn’t nearly scaling—it’s about operationalizing security and trust. These real-world cases revealed that:
- Multi-tenant MCP servers must implement strict data and token isolation
- Prompt injection isn’t theoretical when agents are hooked into real workflows
- Privileged agents need bounded permissions and human-in-the-loop approvals
The excellent news? Each firms shared their experiences early—before things got worse. Their disclosures are a reminder that early transparency will be just as worthwhile as early adoption.
These cases above are only the tip of the iceberg. Trend Micro’s survey uncovered 492 MCP servers publicly exposed—none with client authentication or encryption—offering unfettered access to internal APIs, proprietary data, and backend systems, many hosted in public cloud environments like AWS and GCP.
Their research warns: these are usually not theoretical vulnerabilities. Exposed servers often act as direct backdoors into confidential systems, sometimes enabling attackers to list, modify, or delete cloud infrastructure using hardcoded credentials or wide-open tokens.
General Critiques—It’s Not Just MCP
A number of what’s going incorrect with MCP security isn’t latest—it’s the standard web risk in a flashier package. Consider MCP servers like third-party desktop plugins or browser extensions: easy to put in, easy to trust… until they’re not.
The danger? pondering—when in point of fact, defaults were wide open. Thought leaders in AI security emphasize that traditional security principles still apply:
Furthermore, the design of MCP made trade-offs—favoring usability over strict security. That made life easy for developers attackers began treating MCP servers like entry points. Now, developers are tightening default security settings, making token pass‑through forbidden by default, and hardening recommendations within the specification itself .
Future Outlook: Evolving Security in MCP and Agentic Protocols
At once, MCP and its cousins (similar agentic protocols akin to Agent2Agent, ANP, Agora, etc.) are like teenagers with superpowers—capable of fantastic things, but still determining boundaries, safety rules, and the way not to explode the home. But things are maturing fast. The subsequent generation of agent protocols can be less “duct tape and hope” and more “zero trust by design.”
Listed below are some ways we will expect things to evolve:
Stronger Identity and Trust Models
Currently, in case you show up with a working token, the MCP server shrugs and says, “Ok.” That’s advantageous for now—but long run, we’re heading toward a zero-trust model, where identity is verified not only once at login, but on each tool call.
We might even see concepts like that cryptographically discover not only the human user but the precise agent or chain-of-tools involved, allowing finer access control. Other agent protocols (e.g. inter-agent communication standards like A2A or ANP) are being designed with structured handshakes for each interaction. This implies when Agent A desires to confer with Agent B, they perform a capability negotiation and auth exchange every time, ensuring neither blindly trusts the opposite without verification. Such patterns could inform a future MCP 2.0 where every tool execution request carries a proof of the caller’s authenticity and maybe intent. Also, as industry consortia become involved, we would see standard schemas for agent identity (much like how OIDC standardizes user identity claims).
Granular Permissions and Automatic Sandboxing
Future versions of MCP are prone to include first-class support for . Imagine an MCP schema declaring: “This server provides a delete_file motion—it requires admin privileges.” An AI client could then implement that only certain roles or approved agents can call that motion. Granular permissioning was noted on the MCP roadmap as an area of exploration (e.g., “granular permissioning for human-in-the-loop workflows”). Furthermore, we will expect automated sandboxing to turn out to be standard. Consider it like browser extension permissions—but for tools like send_email or modify_infrastructure. Some proposals suggest that MCP servers could declare a “safety profile” – e.g., whether or not they perform file writes, network calls, etc. – and AI runtimes could then routinely run more dangerous servers in isolated sandboxes or VMs. This fashion, even when an MCP server is compromised, the harm is contained. The concept is analogous to web browser extensions that run in isolated contexts with only specific allowed API calls.
Integrated Audit and Traceability
If we wish to trust agents with real work, we want to know what they did, when, and why. In the long run, agent protocols like MCP may include built-in tracing, telemetry, and audit hooks—so when your AI assistant deletes 4,000 rows from the CRM, there’s a paper trail.
For instance, an MCP request could carry a session fingerprint or trace token that each one components must log, making it simpler to correlate events. Efforts could align with initiatives like OpenTelemetry—envision standardized telemetry for AI agent motion. Security frameworks may additionally coalesce around a typical event format for AI agent activity (very like Open Cybersecurity Schema Framework (OCSF) created a typical format for security logs). The result? You may finally debug your agents with no need a prompt archaeologist.
Policy and Governance Layers
Similar to we have now firewalls and access control lists for networks, we’re going to want AI governance policies for agents. Think:
- “Agent may not access financial APIs between 10pm–6am.”
- “Never output greater than 100 rows from a database unless redacted.”
- “No, you’ll be able to’t delete the production environment on a Friday.”
These rules won’t live the agent—they’ll sit above it, enforced by governance services or agent policy gateways (a few of which exist already, like Zenity‘s policy-layer observability tooling).
In tandem, expect education and culture to evolve: organizations will craft AI acceptable usage policies. Similar to we have now HR policies for worker behavior, orgs will start publishing AI behavior guidelines—and protocols like MCP will need enforcement points to match.
Cross-Protocol Security Consistency
As MCP evolves, it won’t live alone. Agent protocols like A2A (for multi-agent collaboration), Agora (for open marketplaces), and even robot communication protocols are emerging—and so they all must play well together.
Which means:
- Shared security context across protocols
- User identity and permission propagation between agent layers
- Avoiding “loophole attacks” where an agent switches protocols to bypass policy
We’ll probably see security brokers that mediate between protocols—ensuring core security principles (auth, audit, allowlists, etc.) apply regardless of where the agent operates. And yes, standards bodies like IETF or IEEE might eventually step in with the “Agent Security Best Practices RFC 9001.”
Until then, we’re stitching it together ourselves.
Continuous Community Involvement
Finally, the long run of MCP security can be heavily influenced by community involvement. The present trajectory—with open RFCs, public debates, and rapid responses to discovered issues—is encouraging. We will expect more SEP (Standard Enhancement Proposal) submissions specializing in security (for example, an SEP for a standardized permission schema, or an SEP for encrypted invocation contexts, etc.).
Security researchers, industry leaders, and devs are already shaping the protocol’s direction through:
- Publicly disclosed flaws and postmortems that actually help others
- Open-source audits and patches
- Contributions from teams like Trail of Bits, and Protect AI
- Blog posts and community debates (see: Omar Santos, Cisco)
Eventually, we may even get certified secure MCP server implementations—complete with an audit badge and a comforting checklist.
Until then, security in MCP isn’t a solved problem—it’s a live one. But no less than we’re not pretending anymore.
MCP and its fellow agentic protocols are ushering in a brand new era of AI capabilities—one where AI agents don’t just think and speak, but on our digital behalf. With that comes a mixing of application security, API security, and AI safety concerns unlike anything before. One of the best practices we’ve outlined here boil right down to an easy ethos: treat your AI agents as you’d a brand new junior worker with root access – give them only the access they need, watch what they’re doing, and double-check when they fight something dangerous. The community’s experiences up to now show that once we do this, we will reap the advantages of MCP’s flexibility opening the door to chaos. By constructing in security from the bottom up—and repeatedly iterating on it as threats evolve—we will enable the long run of agentic AI with confidence and control.
References
- Anthropic. (2024). . https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
- Anthropic. (2024). . https://modelcontextprotocol.io/specification/
- CyberNews. (2025). . https://cybernews.com/security/github-mcp-vulnerability-has-far-reaching-consequences/
- The Hacker News. (2025). . https://thehackernews.com/2025/07/critical-mcp-remote-vulnerability.html
- GBHackers. (2025). . https://gbhackers.com/anthropic-mcp-inspector-vulnerability/
- The Hacker News. (2025). . https://thehackernews.com/2025/04/experts-uncover-critical-mcp-and-a2a.html
- Trend Micro. (2025). . https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/mcp-security-network-exposed-servers-are-backdoors-to-your-private-data
- Trend Micro. (2025). . https://www.trendmicro.com/en_ca/research/25/f/why-a-classic-mcp-server-vulnerability-can-undermine-your-entire-ai-agent.html
- Cato Networks. (2025). . https://www.catonetworks.com/blog/cato-ctrl-poc-attack-targeting-atlassians-mcp/
- CyberArk. (2025). . https://www.cyberark.com/resources/threat-research-blog/session-hijacking-ai-agents
- Strobes Security. (2025). . https://www.strobes.co/blog/mcp-agent-rce-analysis
- Trail of Bits. (2025). . https://blog.trailofbits.com/categories/mcp/
- Protect AI. (2025). . https://protectai.com/research
- Wiz.io. (2025). . https://github.com/wiz-sec
- Zenity. (2025). . https://zenity.io
- Anup.io. (2025). . https://www.anup.io/p/the-agentic-protocols-that-will-define
- RFC Editor. (2020). . https://datatracker.ietf.org/doc/html/rfc8707
- OpenTelemetry. (2024). . https://opentelemetry.io
- OpenID Foundation. (2014). . https://openid.net/specs/openid-connect-core-1_0.html
- OCSF Project. (2024). . https://www.ocsf.io/
- GitHub. (2025). . https://github.com/mcprotocol/mcp-stack
- GitHub. (2025). . https://github.com/langchain-ai/langgraph
- Hacker News. (2025). . https://news.ycombinator.com/
- Think Robotics. (2023). . https://thinkrobotics.com/blogs/learn/robot-communication-protocols-a-comprehensive-guide
- Noqta. (2025). . https://www.noqta.tn/blog/secure-agent-interaction-architecture
