This deep dive expands on the Loop Asia conversation with Matthias Biehl.

Matthias Biehl's governance framework — an LLM gateway, an MCP gateway, an A2A gateway, one at each point an agent could misuse something — is the architecture. It's not the whole job. Underneath all three sits a question Biehl only touches briefly with Jon Scheele: how do you authenticate and authorise an agent, at machine speed, across every control point, without rebuilding your security stack from scratch?

Biehl is blunt about why this gets skipped. "If you're building prototypes, being a little bit lax about your security is okay." Nobody hardens an internal demo. But his three-gateway model is only as strong as what's enforced at each checkpoint. A gateway that logs and rate-limits but doesn't authenticate isn't governance — it's a speed bump.

OAuth 2.1 as the connective tissue

His answer isn't a new protocol built for agents — it's the one already sitting in most enterprise security stacks. "The OAuth protocol, OAuth 2.1, is the de facto standard also for MCP, and you should use it on most of your APIs as well." That cuts against the assumption running through a lot of AI governance talk, that agent security is green-field, that LLMs reset identity and access management to zero. The MCP gateway between an agent and your enterprise systems needs the same authentication and authorisation already enforced at any API gateway protecting your REST endpoints. "All these investments that you did in your security architecture can be leveraged here as well." The gateway is new. The trust model underneath it doesn't have to be.

Why "just wrap the API" isn't the whole answer

Biehl raises a second question and leaves it open: "Shall we transform every REST API that we have built into an MCP endpoint? Is this just a mechanical transformation... or do we need to do some redesign, some rethinking around this?" His own answer is qualified — "there are some initial best practices... but I think the space is still evolving." A REST API was designed for a specific client with specific access patterns; an autonomous agent that calls it in loops, chains calls a human developer never would, and acts on the response with no one reviewing it first is a different risk surface, even if the protocol translation is trivial.

Authentication and authorisation aren't bolted onto the MCP endpoint after the fact — they're part of deciding whether that REST API should become one at all. An endpoint safe for internal applications your own engineers built and reviewed isn't automatically safe for an agent deciding for itself, moment to moment, what to call and how often.

Where this lands for a Technical Champion

For whoever owns the integration decision — the CTO, the Head of Architecture, the person who already tried solving part of this with a dev shop and hit a ceiling — the takeaway is narrower than "build an AI governance programme." Audit your OAuth 2.1 coverage across the API estate before building a single MCP gateway; that coverage is the foundation, not a parallel project. Treat every REST-to-MCP conversion as an access-control decision, not a protocol-translation task.

That's the sequencing question Blue Connector's advisory work sits in front of: not which vendor's MCP gateway to buy, but whether the OAuth coverage and access-control decisions get made before the infrastructure spend, using the API investment already on the books.