AI Radar · Trend Readout #1 | Problem domain: agent interoperability convergenceData window: 2026-W33 – W35 | 4 independent signals, 2 counter-signals2026-08-29
Last week I was evaluating a popular AI tool on GitHub. 17,200 stars.
The pitch was appealing: let AI drive your browser and handle repetitive web work. Installation looked simple — open source, free, MIT licensed, all code public, and not a single line that ships your data anywhere.
Step one of the setup instructions: turn on Chrome's remote debugging and hand over control.
I stopped there. Because that browser is signed into my brokerage account, my site's admin panel, and the management access for every social platform I run.
Click "Allow", and what the AI receives is not "the ability to operate web pages." It is the ability to act as every identity I am already logged into.
It will not steal my password. It has no need for one. I already logged in for it.
Why this is suddenly everywhere in 2026
Two years ago, AI could only talk. You asked, it answered. That was the whole loop.
What changed is that someone gave AI hands — a standard interface that lets it actually do things: read your files, query databases, publish posts, place orders.
That interface is MCP (Model Context Protocol), introduced by Anthropic in late 2024. Think of it as the USB standard of the AI world: before it, every AI needed a custom cable to every tool. After it, you plug in and it works.
Then came A2A (Agent-to-Agent), which governs something else entirely — how AI talks to other AI. If MCP gives an agent hands, A2A gives it a voice, so it can hand work off to another agent.
Through 2025 the space was messy. Google had A2A, IBM had its own ACP, everyone wanted to set the rules. It looked like another format war — Blu-ray versus HD DVD, all over again.
Then it ended in the first half of 2026. And the way it ended was unusual.
Nobody won, because everyone stopped fighting
A2A shipped 1.0 in April 2026, with 150+ organisations behind it. The version number is not the point. The point is that Google donated it to the Linux Foundation — a protocol it led, handed to a neutral body.
IBM had already folded its ACP into A2A. Not a partnership — a withdrawal: abandoning its own spec to adopt a competitor's.
In December 2025 the Agentic AI Foundation was formed, co-founded by Anthropic, Google, OpenAI, Microsoft, AWS and Block — six companies that compete viciously, jointly governing one standard. By May 2026 it had grown to 190 member organisations, one of the fastest-growing projects in Linux Foundation history.
On the MCP side, the Python and TypeScript SDKs alone are downloaded 97 million times a month. Every major AI provider — Anthropic, OpenAI, Google, Microsoft, Amazon — has adopted it.
Four signals, one conclusion: the fight is over.
And it did not end with anyone winning. It ended when everyone realised they were never standing in the same place — MCP governs tools, A2A governs agent-to-agent, WebMCP governs the browser. They were never competitors; they are floors in the same stack. Name the floors, and the war disappears.
For anyone building on AI, this is good news: you no longer have to bet on which spec survives.
But before writing this, I went looking for the opposite
When four signals all point the same way, that is the most dangerous moment. So I went to find out what is wrong with the picture.
What I found replaced the conclusion of this piece entirely.
First, the MCP spec marks identity verification as optional.
This is not implementation laziness. It is written into the specification: authorization is optional. In plain terms — a service built exactly to the official spec may skip checking who is calling it, and remain fully compliant.
The top two entries on the 2026 MCP Security Top 10 are Unauthenticated Access and Confused Deputy (letting something privileged act on behalf of something that is not). Neither requires a clever attacker. The door was never locked.
Second, an architectural flaw disclosed this April affects an estimated 200,000 running instances.
Not 200,000 different pieces of software — the same flawed thing installed 200,000 times, the way a single lock model with a design defect ends up on 200,000 doors. The exposed supply chain covers more than 150 million package downloads.
And it does not converge easily: patching the source is fast, but those 200,000 copies already in the wild depend on each operator updating their own. Those services are also scattered across community directories where nobody verifies anything.
Third, it is hard to trace.
MCP traffic is spread across independent services. After an incident, finding out what actually happened is closer to a treasure hunt than reading a log.
Speed of adoption | State of security |
|---|---|
108,245 MCP services worldwide | Identity verification is optional |
15,570 added in the last 30 days | 200,000 instances hit by one flaw |
519 new services per day | Directories verify nothing; logs are fragmented |
My read: the battlefield did not disappear, it moved
The protocol war is genuinely over. But if that leads you to conclude that AI infrastructure has stabilised, you have misread it.
Convergence happened at the governance layer — who owns the standard, which foundation holds it, who gets a vote. That layer has settled.
The security layer has not converged at all. And the first effect of protocol unification is not safety. It is faster spread — including the spread of the problems.
519 new services a day, the lock optional, nobody checking. That is not a mature ecosystem. That is an ecosystem where adoption is running far ahead of its safety mechanisms.
The battlefield moved from "which protocol should I use"to "how do I use it safely." And no foundation is working on the second one.
Where this read could be wrong
The honest counter-argument: new technology spreading first and adding safety later is normal, not a crisis.
TLS, OAuth and npm all walked the same path — grow wild, suffer a few incidents, then converge through better tooling and better defaults. If MCP follows that road, today's numbers are adolescence, and they will look unremarkable in two years.
I do not rule that out. But one difference keeps me cautious:
An npm vulnerability steals your code.An MCP vulnerability steals your permissions.
An unlocked MCP service does not walk away with your source. It walks away with every action you authorised your AI to take — including every account you already logged into on its behalf.
Leaked code can be rewritten. Permissions, once used, have already done whatever they did. The blast radius is different, and so is the window to respond.
Back to that "Allow"
Look at that 17,200-star tool again and it becomes clear.
It did nothing wrong. Open source, runs locally, ships no data anywhere, MIT licensed — fully compliant with everything this ecosystem asks for.
The problem is not that it behaves badly. The problem is that this ecosystem's default permission scope is too wide — and the tool is simply following the default, honestly.
My verdict was "watchlist", with one mandatory condition attached: if it gets tested, it connects only to a dedicated clean browser, never the daily one. The cost is losing half its usefulness. I accept that cost.
Protocol convergence makes it easier for AI to connect to everything. That is simultaneously its value and its risk.
If you are installing AI tools lately, one habit is worth forming. Before you click "Allow", ask:
What exactly am I handing over?
Sources
- The State of Agentic AI Standards in 2026: MCP, A2A, WebMCP, OSI
- Everything your team needs to know about MCP in 2026 — WorkOS
- Open-Source MCP Servers — Glama Registry
- The Ultimate Guide to MCP Security Vulnerabilities — Aembit
- MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure — Cloud Security Alliance
- 11 Emerging Security Risks with MCP — Security Boulevard
Produced by AI Radar at ProfitVision LAB, in collaboration with the development team. The candidate pool, screening verdicts and full evidence chain are public in the ai-radar registry.
