MCP just lost its indie-hacker status: IT security got the keys back

Alright. Remember the last time you connected an MCP server to Claude Desktop or VS Code? You clicked “authorize,” pasted a token, and moved on. Nobody in your IT department saw any of it happen.

Multiply that by 200 employees, each wiring up their own MCP servers however they please, each with their own tokens sitting in local config files, and you understand why any halfway serious security team had a minor breakdown discovering this during an access review.

That’s exactly the hole the “Enterprise-Managed Authorization” extension comes to fill. And it just went stable, in July 2026.

The hack that worked well, until it didn’t

MCP was originally built for individual use. You open your client, connect a server, OAuth makes you click “authorize” once, and you’re done. Each developer manages their own connections, their own tokens, their own server-by-server authorizations.

For a solo dev or a small team, that runs fine. The problem shows up at enterprise scale. Nobody knows how many MCP servers are actually connected across the company. Nobody can revoke a departing employee’s access in one shot, because authorizations are scattered, one per server, one per machine. And the line between personal and professional accounts gets genuinely blurry when the token authorizing access to a critical internal tool is sitting in a dev’s personal config file.

That’s what the InfoQ article describes well: the per-user, per-server OAuth model generated endless manual onboarding work, and made it nearly impossible for a security team to enforce a coherent policy. Every connection was an individual decision, never a company decision.

What EMA actually changes

The core idea: take the authorization decision out of each employee’s hands and put it back in the hands of the company’s identity provider (IdP). Okta, Entra ID, whatever the name, as long as it implements the extension.

Concretely, the user does a single login, the one they already do every morning to access the rest of the company’s tools, and that login grants access to the MCP servers pre-approved by IT. No more server-by-server consent pop-up. No more personal token to generate and hide somewhere.

Technically, this relies on a token exchange mechanism, ID-JAG (Identity Assertion JWT Authorization Grant), which converts the identity already verified by the IdP into access to a given MCP server, without going through a full OAuth flow every single time.

Okta is the first identity provider to support this end to end, via its Cross App Access mechanism. Anthropic has implemented support on the Claude side, Visual Studio Code has added IDE support. And a good handful of companies already exposing MCP servers are following suit: Asana, Atlassian, Canva, Figma, Linear, Supabase.

So this isn’t some gadget published in a corner. It’s backed by the three players that matter for it to become a de facto standard: the one who makes the model, the one who makes the IDE, the one who makes the identity layer.

What’s still broken, and there’s a real thing broken here

This is where I’ll temper the enthusiasm a bit: EMA solves the connection problem, not the execution problem.

The article states this clearly, and it’s the most important point to remember. The architecture deliberately separates identity policy, which decides who can connect to which server, from execution authorization, which decides what the agent is allowed to do once connected. EMA handles the first layer. The second one, for now, still largely sits with the MCP server itself and its own per-tool authorization logic.

In other words: your IT department can now say “only devs on the payments team are allowed to connect to the MCP server that touches billing production.” It can’t yet say, with the same mechanism, “this agent can read billing logs but can’t trigger a refund.” That level of granularity still has to be built, server by server.

And there’s a second blind spot, broader than EMA itself, that SecurityWeek points out well: pushing MCP to enterprise scale shifts the security burden from the protocol to developers and platform operators. An Akamai expert quoted in the article puts it bluntly: critical security boundaries now depend entirely on the developer-side implementation. New MCP-specific HTTP headers that can leak API keys into logs or proxies, long-running async tasks that open up a denial-of-service surface, stored XSS via MCP Apps extensions. EMA doesn’t touch any of that. It settles who gets in, not what happens once they’re inside.

Which is to say, a company that deploys EMA and thinks “okay, MCP is secure now” is fooling itself. It’s one more governance building block, a good one, but one among others.

I already covered the pure architecture side in the article on the 2026 MCP protocol overhaul: the protocol becomes stateless, implicit sessions disappear in favor of explicit handles. EMA belongs to the same revision wave, but on a completely different axis. Where the protocol overhaul settles “how an MCP server holds its state,” EMA settles “who’s allowed to talk to that server in the first place.” Both efforts move forward in parallel, but they don’t overlap.

What this changes in a real workflow

If you work at a company with an IdP already in place, Okta leading the pack for now, the change is clear-cut. The security team can finally run an MCP access review that looks like an actual access review, not a treasure hunt through config files scattered across machines. When someone leaves the company, cutting their IdP account is enough to cut their access to every pre-approved MCP server, all at once. That’s real progress, and any security team that’s ever handled an employee departure with personal tokens scattered everywhere will tell you it was a genuine black hole before.

If you’re a solo dev or at a small shop without a proper enterprise IdP, this extension barely concerns you. You keep going as before: one click, one token, one server. It’s neither a regression nor progress for you, it’s just that the protocol you use now has two clearly distinct modes of operation, and the “governed” mode isn’t built for you.

If you build MCP servers meant for enterprise use, though, you can’t ignore this anymore. A server that doesn’t support EMA today becomes a natural candidate for exclusion from your customers’ centralized access policies, even if its classic OAuth works perfectly fine. The organizations already adopting the extension, Atlassian, Figma, Linear, didn’t do it out of technical vanity. They did it because their enterprise customers are about to start demanding it in their vendor security criteria.

The bottom line is that MCP is growing up. It was born as a tinkerer’s tool, something you quickly wire up to test an idea. It’s becoming, under pressure from the same players who pushed it in the first place, a protocol an IT department can audit, govern, and cut off with one click if needed. That’s good news for whoever needs to sleep at night knowing who has access to what. It’s one more layer of friction for whoever just wanted to connect an MCP server on a Saturday afternoon without having to ask anyone’s permission.

Sources

• MCP Enterprise-Managed Authorization Extension — InfoQ
• New Enterprise-Ready MCP Specification Brings New Security Challenges — SecurityWeek