New MCP Specifications Fix Security Issue But Open Many More

Agentic AI , Artificial Intelligence & Machine Learning , Governance & Risk Management New MCP Specifications Fix Security Issue But Open Many More Model Context Protocol Rewrite Leaves More Security Decisions to Developers Rashmi Ramesh (rashmiramesh_) • June 29, 2026     Credit Eligible Get Permission The new MCP specifications fix a long-standing weakness in how AI agents authenticate to external tools, but security experts say it shifts key safeguards to developers. (Image: Shutterstock) The Model Context Protocol is getting its biggest rewrite since launch, and the changes fix one well-known security weakness while creating several new ones. See Also: Edge Transformation: Top 5 SASE Predictions and Trends The protocol's lead maintainers David Soria Parra and Den Delimarsky last month published details of the latest update to MCP, which is essentially a connector that allows artificial intelligence agents to call outside tools such as a database or a booking system while they work. The update removes the session tracking feature that has defined how AI agents talk to tools since the protocol debuted. The final specifications ship today. MCP previously used to track who it was talking to through a "session," when an AI agent first connected to a tool, the tool's server handed it an ID code called a session ID, and the agent had to show that code on every message after that, the way a wristband proves someone already paid to get into a concert. The catch was that the session ID was the only thing standing between a legitimate user and an impersonator. If an attacker got hold of that one code, by intercepting it, finding it logged somewhere or guessing it, they could use it to act as the real user on that server. The new version removes session IDs, so any server can handle any request without needing to remember who sent the last one. That closes off the old risk, but it doesn't remove the need to track who is doing what across a conversation. Maxim Zavodchik, senior director of threat research at Akamai who co-wrote a blog on the new updates, said the trade-off sums up the release. Companies gain new features, but they lose a security check the protocol used to handle for them and now have to build it themselves, he told ISMG (see: MCP Protocol Bug Let Attackers Execute Code in Cursor). The ID code hasn't disappeared, but it works differently. Instead of a server issuing it, the server creates a token, like an order number, and the AI agent carries that number forward in the conversation, repeating it back on later messages. Maya Pik, a researcher at security firm Backslash, compared the change to swapping a bouncer who recognizes a guest's face for a paper ticket: The ticket is easier to manage at scale, but anyone who gets hold of it can use it too. The number now is in plain text, in the chat, where it can be copied by anyone. Pik said a tool can even trick the AI agent into picking up a number it was never supposed to use, and the agent will go along with it, because nothing in the system tells it not to. Zavodchik said the new draft specifications address this risk, saying that if a server receives a tracking number from an agent and that number affects what the agent is allowed to access, the server must check that the number hasn't been tampered with before trusting it. The problem is that the rules don't explain how to do that check. They leave the method up to whoever builds the server. Zavodchik said this is because the protocol needs to support tasks that pause partway through, like a workflow that stops to ask a person for approval and then picks back up minutes or hours later. A single, fixed way of checking the tracking number would have to work the same for a task that finishes in one second and one that pauses overnight, and the rule makers decided that forcing one method onto every situation would make the pause-and-resume tasks harder to build. So they instead left the method open. The downside is that nothing forces anyone to do the check at all. A company that skips it or uses easy-to-guess tracking numbers opens the door for one user to hijack another user's task, or to reach data that belongs to someone else (see: Static Credentials Expose MCP Servers to Risk). The flexibility also means two companies can both follow the new rules correctly and still end up with different levels of protection, because only the outer boundaries are set. What happens inside the boundaries is up to each company. He lists several instances where this could play out: One company might trust a tracking number sent by a user without question, while another verifies it with a digital signature first. One might let background tasks run with no limit on how long or how often, leaving itself open to being overwhelmed by junk requests, while another sets firm limits. Asked which of these gaps companies are most likely to miss, Zavodchik said all of them. A second new gap involves file access. Older versions of MCP had a feature called Roots, which allowed an AI agent's host application to tell a server which folders or files it was allowed to touch. The new rules retire that feature and tell developers to handle file permissions a different way, through settings on the individual tool, through plain web addresses pointing to a resource or through the server's own configuration. It sounds like a small technical swap, but Pik said it removes the one rule every server used to be forced to follow and replaces it with several optional ones. She explained that in one actual case, an AI agent was asked to write a routine report and ended up reading 340 unrelated files, including passwords and access keys stored on the same system, then sending that information out to another server, simply because it had no rule stopping it from looking wherever it wanted. Zavodchik said the security gaps predate AI, explaining how MCP recreates the "insecure direct object reference" weakness, where a system checks whether an ID number is valid but not whether the person holding it is actually supposed to have it. A second old web problem is one where a system sends two descriptions of the same request, one in a short label and one in the longer message body, and they don't match. Different parts of the system can disagree about what the request actually says, making room for confusion that an attacker can exploit. What's new is how much a server has to explain about itself. A person using a website doesn't need the site to describe its own buttons, but an AI agent does. Since an agent can't be pre-programmed to know every tool it might encounter, each server has to describe in detail what it does and how to use it. The description, written for the agent's benefit, also hands an attacker a ready-made user guide. The release also adds a feature called MCP Apps, which allows a server to send back data along with an interactive screen, a form or button panel that can be displayed inside the program the agent is running in. To keep it from doing damage, the screen runs in a locked-down container. Pik says that this is riskier when the agent is running in a programmer's coding tool rather than a web browser, because if anything breaks out of that container, it lands on the programmer's own files and passwords, not just a browser tab. A fake panel could also be built to look like a normal login box and trick someone into typing in a password. Zavodchik connects this to another familiar web problem: a hacker planting harmful code on a page that runs automatically whenever someone else opens it, here showing up in an AI interface instead of a website. Separately, in previous MCP iterations, an access token - the credential an agent uses to prove it is allowed to use a given tool - could sometimes be issued for one server and be accepted by a different one, because nothing in the token said which server it belonged to. Identity company WorkOS said the new rules address this by having each token name the one specific server it was issued for, so a server checking that name can catch and reject a token meant for somewhere else. Whether every server actually performs that check is still up to whoever builds it, but the information needed to catch the mismatch is now part of the token, which wasn't true before. The new rules also require an agent to double-check which login system issued its credentials, closing off a trick where a fake login system could otherwise slip in. Another concern raised by AI infrastructure company TrueFoundry involves background tasks, which are jobs an agent starts and checks on later rather than right away. Starting one of these costs the agent almost nothing, but running it can cost the server real time and computing power. The blog says that the new rules don't set any limit on how long a task can run or how many a single agent can start, leaving that up to each company to decide, which means an unwatched task could keep running and consuming resources far longer than intended.