Where MLSecOps Meets MCP: Securing the Next Layer of Agentic AI

Where MLSecOps Meets MCP: Securing the Next Layer of Agentic AI

By Kopal Dixit

A year ago, "securing AI" mostly meant securing a model endpoint: rate limiting, input validation, maybe some prompt injection testing. Today, that scope has quietly exploded. Every enterprise I talk to is wiring its AI agents into real systems, such as ticketing tools, databases, and internal APIs, using the Model Context Protocol (MCP). And that's where MLSecOps, the discipline of securing ML systems across their full lifecycle, is being forced to grow up fast.

I've spent the last few months building an open source MCP security checklist with a healthcare lens, and the deeper I've gone, the more convinced I am that this is the conversation our community needs to be having right now, especially the women building careers in this space, because this is a genuinely new frontier where nobody has a five year head start on anyone else.

Why MCP changed the threat model

MCP is deceptively simple: it lets an AI agent discover and call tools on a server at runtime, instead of a developer hardcoding a fixed set of integrations. That flexibility is the whole point, and it's also the problem. Before MCP, an agent's capabilities were fixed at build time. With MCP, an agent can pull in tools it's never seen before, from a server it may not fully trust, and act on them immediately.

The numbers are already catching up to that risk. Security researchers filed more than 30 CVEs against MCP servers, clients, and infrastructure in just January and February of 2026, and roughly 43% of those were shell injection flaws. Palo Alto Networks' Unit 42 found something even more sobering: once an agent has five connected MCP servers, a single compromised server produces a 78.3% attack success rate against the whole setup. Chain a few integrations together the way most teams do for productivity, and you've built a house of cards.

This is exactly the gap OWASP is trying to close with the OWASP MCP Top 10, the first OWASP Top 10 project focused on a single protocol surface rather than an application layer. It's currently in beta, meaning the ten categories are stable enough to build a program around even though rankings may still shift. Those categories cover the ground you'd expect from an MLSecOps practitioner's nightmare list: token mismanagement, privilege escalation, tool poisoning, supply chain attacks, command injection, weak authentication, poor telemetry, shadow MCP servers, and context oversharing.

Two of those deserve special attention, because they're not "just" application security problems. They're new:

Tool poisoning happens when an adversary compromises a tool, plugin, or its output by injecting malicious or misleading context that changes how the model behaves. Your agent isn't being hacked in the traditional sense. It's being lied to, and it doesn't know the difference.

Shadow MCP servers and context oversharing are the quieter risks. Long lived MCP sessions mean a leaked token can do damage far longer than a typical API key breach, and without deliberate namespace isolation and session level context purging, one user's sensitive data can leak straight into another session's agent memory.

Why this matters more in regulated industries

This is where MLSecOps stops being a generic checklist and starts requiring domain fluency. In healthcare, "context oversharing" isn't an abstract risk category. It's a HIPAA violation waiting to happen. An MCP server that hands an agent unrestricted access to a patient records API, with no field level redaction and no audit trail, fails a compliance review before it fails a pentest.

That's the gap I've been building toward with my own checklist project: taking the OWASP MCP Top 10 and mapping each category to a PHI and HIPAA risk lens, not to replace the generic scanners already out there, but to give healthcare and other regulated industry teams a way to ask what a given risk category actually means when the tool in question touches patient data. I've built a proof of concept lab, a deliberately vulnerable MCP server next to a hardened one, to pilot the checklist against real attack behavior rather than just theory.

What this means for your MLSecOps practice, starting Monday

• You don't need to become an MCP protocol expert to start closing this gap. A few starting moves:

• Treat every MCP server as untrusted by default, the same way you'd treat a third party API. Don't grant it more scope than the specific task requires.

• Enforce short lived, narrowly scoped tokens for MCP sessions instead of long lived credentials. The OWASP research is unambiguous that token mismanagement is one of the top real world causes of breach.

• Inventory your shadow MCP servers. If your teams are spinning up MCP integrations faster than security can review them, you already have this problem. You just haven't found it yet.

• Build or borrow an audit mapping between MCP risk categories and your industry's compliance framework. It turns an abstract security review into a concrete one your compliance team can actually sign off on.

An invitation

If you're a woman early in your security career wondering where to plant a flag, this is one of the rare moments where the field is genuinely this new. MCP itself is barely a year old, and the OWASP framework for it is still in beta. There's no ten year veteran standing in your way here. I'd love for more of our community to get hands on with this: try breaking a test MCP server, map a risk category to your own industry, write down what you find. That's exactly how I ended up building mine, and I'll be sharing the checklist and lab openly once it's ready, so BWH readers can pressure test it and make it better.

Kopal Dixit is a Senior Information Security Engineering Analyst focused on DevSecOps and cloud security, and the founder of Behind the Firewall.