By Teams that deployed MCP servers under the stdio model now face a hard cut: the new MCP specification removes session IDs, sampling, routes, and legacy cloud client information, and there is no direct migration path. Every old client handshake will break. Most organizations do not have a reliable inventory of which MCP servers are running, in which environments, or at what version — because stdio let developers spin them up anywhere, including on personal laptops.
In this interview on TFiR, Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, walks through how to audit existing MCP deployments, what the spec change removes, why clients break, and how standard network controls — firewalls, ACLs, and Layer 7 WAFs — are the correct first line of defense for MCP security.
Guest: Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai
Show: TFiR
Here is what every AI platform engineer and DevSecOps team running MCP in production needs to know.
Technical Deep Dive
Q: What is the first step when migrating from legacy stdio-based MCP servers to the new spec?
Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, says the starting point is inventory: identify every MCP server running across the organization, what versions they are on, and what features they use. Because stdio allowed developers to spin up MCP servers on laptops and in ad hoc environments, most organizations have undocumented server sprawl. Lightfoot recommends using load balancer logs and HTTP header inspection to detect and catalogue active MCP servers before attempting any migration work.
“I would start with just identifying what MCP servers you have that are out there now.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: What breaks in existing MCP client connections when teams upgrade to the new spec?
The new MCP specification is not backward compatible. Lightfoot explains that old client handshakes will fail immediately because the new spec has no session ID, no sampling, no routes, and no legacy cloud client information. There is no direct migration path from the older version; teams must treat the new implementation as a greenfield build rather than an upgrade.
“When you put the new version out, the old handshakes from the clients are going to break because there’s no session ID — none of that exists.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How can MCP migration reduce token bloat and improve AI agent efficiency?
Lightfoot frames the migration as a redesign opportunity. Token bloat was a widely reported problem with early MCP servers, and the forced rebuild creates space to rethink which tools belong in each server, how doc streams are structured, and whether the overall toolset can be simplified. He notes that tokenomics has become a primary concern for teams running agents at scale, and a leaner MCP server design directly reduces cost and latency.
“This is an opportunity to figure out what tools you actually need in your MCP servers, how they’re actually designed, what the doc streams look like.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How do you secure MCP servers at the network layer before adding AI-specific guardrails?
Lightfoot argues the network layer is where MCP security must start. Because the new spec runs over HTTP, existing controls apply directly: firewalls, access control lists, and Layer 7 load balancers or WAFs can now inspect MCP traffic via headers without needing to parse the JSON body. This means teams can enforce which clients are allowed to connect to an MCP server using the same tooling they already operate for HTTP services.
“Between your network layer — firewalls, your access control list — and then your Layer 7 load balancer or WAF, you can do some mitigation there.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: Can WAFs block prompt injection attacks targeting MCP servers?
Yes, according to Lightfoot. Some WAF implementations can inspect the payload for prompt injection patterns in addition to header-level controls. Because MCP now behaves like traditional HTTP, the same Layer 7 inspection techniques that protect web applications apply. This means prompt injection mitigation does not require a new category of tooling; it extends existing WAF policy to cover AI agent traffic.
“There are WAF applications that look inside of the payload — but we can actually just look at the headers now to really do some protections for our application.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: Is hallucination and unsafe AI agent behavior addressable at the protocol or spec level?
Lightfoot’s position is that the network and infrastructure layer handles what it can — access control, traffic filtering, prompt injection mitigation — but hallucination and emergent agent behavior are not fully solvable at the MCP spec level alone. The practical guidance is to layer controls: network first, then WAF and guardrails around the LLM or agent, accepting that no single layer eliminates risk entirely.
“How do you protect the server? Well, the network layer is the first place to start.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Resources & Documentation
- Akamai, edge security and cloud platform with WAF, load balancing, and API protection capabilities applicable to MCP deployments
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Of course, everybody has already deployed MCP in production, MCP client servers. What should those setups, what should those teams who have this very crazy, very complicated, very complex, you know, the whole MCP client server deployment, what should they do? What are the biggest migration or security things that they should be worried about?
Du’An Lightfoot: Yeah, so when it comes to the migration from traditional or the older version of MCP, one of the things you gotta think about is that I mentioned that when MCP was first rolled out, you had a lot of standard in, standard out. So what did that mean? You had developers spinning up MCP servers on a laptop all across your organization. Right. You had teams spinning up MCP servers in different environments. So the question is, do you have, let’s say, a load balancer, web application firewall to monitor the traffic to see what MCP servers are out there? Because you can look at the headers and identify that. So identify what MCP servers are out there. Right. Find out where they are, look at the logs, look at the versions and verify. Now, if you’re trying to migrate, there’s no real direct path from the older version. This is a new implementation, so you’ll have to focus on that. The second thing is that when you put the new version out, the old handshakes from the clients are going to break because there’s no session ID. None of that exists. The new version also doesn’t have sampling, doesn’t have routes, logging in, old cloud client information. So those are some of the things that you have to think about. But I would start with just identifying what MCP servers you have that are out there now. What are the features? Right. This is an opportunity to really design your MCP servers more efficiently. Because one of the biggest challenges with MCP servers from a few months ago, less than six months ago, was token bloat. And now everyone’s talking about tokenomics. This is an opportunity to figure out what tools do you actually need in your MCP servers? How are they actually designed? What does the doc streams look like? Can you simplify this and make it more efficient in your organization?
Swapnil Bhartiya: We can put as many guardrails as we want, we can even put gates. But we all know there was a saying in Jurassic Park, life finds a way, AI finds a way to break those. So hallucination is there, making things up and then try to validate it or even try to remove the traces there. In these new specifications or from your perspective as AI is moving into production, the kind of disclaimer that, hey, AI can make mistakes, double check is not going to work because damage can be done and damage can be much more severe, whether at standard level, protocol level, either the work is already underway or should be done to kind of prevent as much possible hallucination or such risky behavior where it can actually we have seen cases where agents interact with each other to compromise the secrets, you know, or to get access because they have to get something done. So they will behave just like humans behave, actually. So talk a bit about are these guardrails part of this specification? Or you feel that. No, that is something we must do, but that is for future.
Du’An Lightfoot: Yeah. So when you think about using AI, right? MCP is a server, right. How do you protect the server? Well, the network layer is the first place to start, right. What should actually connect to your MCP server? I would start there, right. And then if you have like a load balancer, well, your load balancer can do protection at that. Layer seven, right. Checking the headers because now it acts like traditional HTTP. So the. These are things we gotta think about. So between your network layer, which are firewalls, your access control list, and then your layer 7 load balancer or WAF web application firewall, you can do some mitigation there when it comes to guardrail. Now you’re thinking about the firewall around, let’s say the AI, whether it’s your AI agent or your LLMs. You could put guardrails to protect against those prompting injections. There’s some WAF applications that do that as well, that look inside of the payload. But there are mitigations that we’ve been doing traditionally with HTTP and now we can actually do that with MCP, since we don’t actually have to go in that JSON body, we can actually just look at the headers now to really do some protections for our application.
