KBbridge Logo
· 5 min read· Angelo Nardone

MCP ships its biggest revision yet: what changes, what risks it brings, and why your KB shouldn't depend on it

aimcpsecuritygenexusai-agents
MCP ships its biggest revision yet: what changes, what risks it brings, and why your KB shouldn't depend on it

If you keep half an eye on AI, something happened this week worth looking at closely if you build on GeneXus. MCP —the protocol an AI agent uses to reach your tools and your knowledge— just got its biggest revision since it existed. The final version ships on July 28, 2026, and it isn't a touch-up: it rewrites how the protocol works underneath. The good news is that the standard is maturing. The fine print is that it becomes more capable and, at the same time, more demanding to run securely.

We already devoted a post to what MCP, A2A and ACP are. This is the update: what changed now, what new risks it brings, and what it means for your Knowledge Base.

What changes in the new version

In plain terms, four big moves:

  • A stateless core. The protocol-level session is gone: the startup handshake and the session identifier disappear. Any request can land on any server instance, with no stickiness. It scales better on ordinary HTTP infrastructure.
  • Long-running tasks, made official. The Tasks extension graduates from experimental: an agent can now kick off work that runs for minutes or hours, and the client drives it with tasks/get, tasks/update, tasks/cancel. It's literally the plumbing for agents that work for hours —the ones we wrote about here—.
  • Server-rendered interfaces (MCP Apps). A server can ship interactive HTML that the client renders inside a sandboxed iframe.
  • Harder authentication. It aligns with OAuth 2.1 and OpenID Connect; among other things, the client must now validate the iss parameter (RFC 9207) to close off a family of mix-up attacks.

The detail that matters: it breaks compatibility. The handshake is gone, the session header is gone, some error codes change. Existing SDKs and servers have to migrate; there's a transition window to do it. Translation: if your integration lives glued to whatever MCP version is current, this is the kind of change that eats your weekend.

The other side: more attack surface

Here's the part worth reading slowly, especially in banking, government, or Japan. The specification itself shifts security from "guaranteed by the protocol" to "depends on how you implement it." It's a reasonable call for scaling, but it moves the responsibility onto whoever operates the server. Analysts have already flagged new risks:

  • Cross-tenant workflow hijacking. With no protocol-level state, predictable IDs could let an attacker latch onto an active workflow or reach another agent's data on a shared server.
  • "Hit-and-run" denial of service. Creating a long task is cheap for the attacker and expensive for the server: fire off costly work and disconnect.
  • Header-based leakage. The new HTTP headers tempt developers into stuffing API keys, tokens, or PII where they don't belong —and that flows through every proxy, load balancer, and log along the path—.
  • Injection in the interfaces (MCP Apps). Server-rendered HTML reopens the door to good old XSS.

This isn't forum theory: in June 2026, US cybersecurity agencies —the NSA and CISA— published dedicated MCP security guidance. When the government issues a document like that about a protocol, it's because it's already in production in serious places.

None of this means "MCP is insecure." It means MCP grew up, and with size come the responsibilities of a genuine distributed system. That's healthy. It's also a reminder.

The pattern we've seen before

A month ago we wrote about how ACP merged into A2A within months of being born. Today MCP is being rewritten wholesale. This isn't chaos: it's a young technology consolidating fast. But it leaves a practical lesson, the same one as always: the plumbing changes. The must-have acronym from six months ago migrates versions today, merges into another, or changes its security rules.

So the question that matters isn't "which protocol do I marry?" It's: "which part of my work has to survive the plumbing changing?" And the answer, if you build on GeneXus, is a single one: your knowledge.

What this means for GeneXus + KBbridge

Here's where it all falls into place. KBbridge was never "an MCP server." It's the bridge that keeps your Knowledge Base connected to whatever comes next —and it does that by decoupling what lasts from what changes—.

  • Your KB, as text in your own Git. That's the stable layer. MCP can move from 2025-11-25 to 2026-07-28 and to whatever follows; your knowledge isn't touched. The bridge updates; your KB stays.
  • The documentation MCP is local and 100% offline. 46,750 chunks covering GeneXus versions 9 through 18, no API keys and no outbound traffic. Notice that a good share of the new risks —OAuth mix-ups, cross-tenant hijacking, registry poisoning, leakage through proxies, DoS against shared servers— live in the remote, hosted, multi-tenant world. A local, offline server simply doesn't expose that surface. For banking, government, or air-gapped environments, that's not a detail.
  • You pick the provider, and you can also build your own. Because the KB is text, you can generate your own MCP servers inside GeneXus. With a simple prompt, connecting Claude to KB Editor, I built an MCP server in about 6 hours, generated directly in GeneXus, with no need for Node.js or Python. And if you build your own, you now have the new specification's guidance to make them secure —which is exactly the kind of decision the 2026 version puts in your hands—.

KBbridge replaces none of this and competes with none of the platform. It does what the name promises: it builds the bridge so three decades of knowledge stay plugged into the era of agents, without being tied to this month's protocol version.

To try it

If you want to see your KB turned into something an agent can read, version, and query over MCP —local and offline—, start with Getting Started. There's a 15-day free trial, no card required.

Built by GeneXus developers, for GeneXus developers.

Sources