MCP needs revocation before reach

ReversingLabs published a piece this week arguing that MCP adoption is replaying the API industry's timeline — and the historical detail it anchors on is worth sitting with. APIs became the backbone of everything years before their security discipline existed; OWASP didn't publish its first API Security Top 10 until 2019, long after API sprawl was a fact of every enterprise. The damage pattern of that gap is well documented.

The hopeful half of the comparison: this time the guidance is early. By now — barely eighteen months after MCP's introduction — OWASP has already shipped both an MCP Security Cheat Sheet and a secure-server development guide. The paper trail that took the API era most of a decade exists for MCP before most enterprises have deployed their tenth connector. That is genuinely a do-over.

The caveat the piece deserves, and the reason I am linking it with an argument attached: a cheat sheet is not a control. Guidance documents provide no runtime enforcement, no credential rotation, no proof that any deployed server follows them. And I could not verify any incident-rate comparison between the API era and MCP — the historical analogy is an argument, not a dataset. What the analogy actually earns is a claim about sequencing: the API era proves that connectivity adopted before governance becomes ungovernable retroactively, because by the time you inventory the sprawl, the sprawl is load-bearing.

Which is why my test for MCP readiness is deliberately unglamorous. Before a platform team approves connector number ten, four things exist or they don't. An identity answer: when a tool call fires, whose permissions is it exercising — the user's, or a server account with god-scope? A least-privilege answer: does each server get the narrowest token that does the job, or one broad OAuth grant because scoping was annoying? An audit answer: is there one place that lists every server, its scopes, and its last activity? And the one I weight most: a revocation answer — when a server misbehaves at 5 p.m. on a Friday, who can kill it, how fast, and has anyone ever actually pulled that lever?

At work I now ask the revocation question first in every MCP review, because it is the one that exposes the real state of the program. Teams can usually produce an identity story and gesture at scopes. The kill switch is where the silence happens: no central inventory, so nothing to revoke against; connectors approved one by one, each reasonable, collectively unmapped — servers that can read customer data and trigger tools, with no list and no lever. That is the API-sprawl movie again, running at agent speed.

Steal this ordering: inventory first, revocation lever second, scope audit third, new connectors last. The reason is arithmetic — inventory and revocation cost days at three connectors and quarters at forty, so sequencing them late is strictly more expensive. The API era got the order backwards and spent a decade paying retroactively.

MCP really is a do-over — but only for whoever builds the off switch before the on switches multiply.