By The new Model Context Protocol specification removes server-side session storage, and most security teams are treating that as a win. It is not a reduction in risk. It is a redistribution of risk onto surfaces that many AI application developers have never had to defend before: client-managed cookies, long-running task ticket IDs, and server-rendered interactive forms passing through an AI layer.
In this interview on TFiR, Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, walks through what the stateless MCP specification actually changes at the protocol level, what new attack vectors it introduces, and what controls are now the developer’s responsibility to implement.
Guest: Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai
Show: TFiR
Here is what every platform engineer and AI application developer needs to know.
Technical Deep Dive
Q: What does removing session IDs from the MCP protocol actually change for security?
Du’An Lightfoot, Senior Developer Advocate for AI Engineering at Akamai, explains that the new MCP specification eliminates the session ID entirely, which means no more sticky routing and no server-stored session state. The immediate benefit is that an attacker can no longer steal a session ID and replay it. However, Lightfoot is clear that the risk did not disappear: app memory now travels through the client, and the server is responsible for issuing something functionally equivalent to a cookie that the client must return on each request. The server must then validate that the cookie has not been altered, that it belongs to the requesting party, and that it has not expired. The protocol specifies that this validation should happen but does not prescribe how to implement it.
“There’s no stealing of the session or the state and being able to replay it. The app memory now travels through the client.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: How does MCP’s human-in-the-loop confirmation capability work and what gaps does it introduce?
The new MCP spec allows tools to pause mid-execution and request explicit user confirmation before completing a destructive or irreversible action, such as deleting or modifying a file or database record. The server sends the pause request, the user replies, and execution continues. Lightfoot notes this is a meaningful safety control for agentic workflows, but it requires that the confirmation channel itself be secured against interception and spoofing, a detail the protocol leaves to the implementer.
“Tools can now pause and ask the user a question. The server can request: do you really want to do this?”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: Why do long-running MCP task ticket IDs become a security target?
When a developer triggers a long-running backend task through an MCP server, the server returns a ticket or job ID. The AI application drops the open connection, stores the ticket, and polls for status on a later request. This is a meaningful architectural improvement for async workloads, freeing AI coding agents such as Claude Code or Codex from holding open connections. But Lightfoot flags two risks: the ticket IDs themselves become high-value targets requiring the same integrity and ownership validation as session cookies, and because long-running tasks are cheap to initiate but expensive to run, they create a direct denial-of-service surface that attackers can exploit by flooding the server with task requests.
“Those ticket IDs for those long running requests, they become targets.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Q: What prompt injection and phishing risks do MCP app responses introduce?
MCP apps, a new interactive feature in the specification, allow the backend server to send structured data, forms, or other UI elements directly to the user through the AI layer rather than requiring the AI to render them. Lightfoot identifies this as a meaningful capability for verification flows and data collection, but notes it introduces prompt injection and phishing risk: malicious content embedded in a server-returned form can be presented to the user as a trusted AI response, bypassing the user’s normal skepticism toward external content.
“If you’re sending a form, now you’ve got to worry about prompt injection or phishing inside of that form when it comes back.”
Du’An Lightfoot, Sr. Developer Advocate – AI Engineering, Akamai
Resources & Documentation
- Akamai, edge and cloud security platform for AI application delivery and protection
- Model Context Protocol (MCP), open specification for context exchange between AI applications and tools
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Now let’s talk about some of the biggest things which is going to impact almost everybody, which is statelessness. Talk a bit about what does removing protocol label sessions unlock for organizations running mcps at a scale and how does that shift make changes to performance, reliability, repeatability and most importantly, security.
Du’An Lightfoot: The session ID has been removed from the new version of mcp. So there’s no more sticky routing, right? No more sessions stored by the server. Caching and tracing works like traditional APIs, but the one thing about that is that some of the risk has been removed, but it also didn’t vanish because you don’t have a session id. There’s no stealing of the session or the state and being able to replay it, right? The app memory now travels through the client. So anything that you want to remember and send back, that needs to happen via okay, I want to have a connection to this MCP server. Well, the MCP server may provide you a cookie like in a traditional application. And so when that cookie comes back, the requester has to send that back to the server. And now the server needs to analyze this to ensure that it who that the cookie or the state wasn’t altered, right? It belongs to the person that’s asking and it hasn’t expired. Now the protocol for the new MCP server does not tell us how to do that, but it says that this is something that you should do.
Swapnil Bhartiya: Beyond statelessness, the new spec also enables richer interactions from multi round trip requests and long link tasks to MCP apps and broader extensions model. Talk a bit about because when we look at Akamai, you folks enable so many businesses real time. I mean the use cases are just beyond comprehension. So talk a bit about what new possibilities will these unlock that developers, users, organizations, business were not able to do. Now we have to also consider security risk, whether they will eliminate them or introduce new risks.
Du’An Lightfoot: So when it comes to this new version of mcp, tools can now pause and ask the user a question. So let’s say you request to remove a file or change a file on a database or some other storage location, the tool can pause and the server can request hey, do you really want to do this? And you can reply back that say yes, I do want to do this. And then when it comes to long running tasks, if a developer is working on an application and they have a tool call for MCP server, then that workload is going to take a longer time on the back end. Well, the server can actually send a ticket or some ID number back to the AI application and the AI Application can now drop that request and on the next request check the status of that long running task. And to me that really that changes how we use AI, right? Because now the work happens on the server rather than tying up the connection between something like cloud code or Codex and it’s having that async communication, right? Or that synchronous communication that’s waiting, it now can be more asynchronous. We’ll say, hey, okay, this job is working, we can check back later and move on. Now one more thing that I’ll cover is that when it comes to apps, which is a new feature, interactive feature within mcp, is that it could actually send maybe a form or some type of data within the return from the server to the user. Which is interesting, right? Because now the back end can really send a request or some verification or some other type of app to the user through AI, rather than the AI having to render that. This can happen from the server. But there are some risks. Those ticket IDs for those long running requests, they become targets. So when we think about that, well, how do you protect against that? The same with the cookies in the state and verifying has it been altered? Does it really belong to the user that done the request? Has it expired? There needs to be some controls on the server to do that verification. Now another thing about those long running tasks is that now this is an attack surface, because those long running tasks could be cheap to implement, cheap to start, but then they’re costly to run. But also an attacker now could do a denial of service because now they’re doing a bunch of requests in that application. So that’s something we gotta think about as well. When it comes to the app, if you’re sending a form now you got to worry about prompt injection or phishing inside of that form when it comes back. So those are some of the things that we have to think about when we’re implementing or rolling out this new version of MCP and its features.
