Enterprise MCP adoption keeps outrunning its authorization layer

Your pipeline already runs untrusted dependencies as a privileged identity. Comforting, isn't it. Now bolt an AI agent onto that pipeline and ask it to call arbitrary tools on your behalf. The connective tissue most teams are reaching for is the Model Context Protocol, and per The New Stack this week, the seam that keeps showing is the authorization layer that should sit between the agent, the protocol and the actual resources behind it.

The framing in that report is blunt enough to quote. "Every enterprise company is seemingly trying to adopt the Model Context Protocol," The New Stack writes, "to connect its AI agents to tools." The piece's focus is the missing enterprise authorization layer for that adoption. Read it once, then re-read it through the eyes of whoever runs your CI/CD.

Why this is a CI/CD question, not a model question

MCP started as a sensible idea. Standardize how a model gets a list of tools, calls them, and feeds the results back into a reasoning loop. Inside one engineer's laptop, that is mostly an ergonomic problem. Inside a build, it is a delegation problem, and delegation without scoping is just shared credentials with a new logo.

Sketch the wiring on a whiteboard for thirty seconds. A CI job starts. It instantiates an agent. The agent reads a manifest of MCP servers, each one offering a few tools, and chooses which to call to finish a task: open a pull request, query a metrics store, list secrets in a namespace, post to a chat channel. Each of those calls, on the other side of MCP, hits a real API with a real identity attached.

Whose identity?

That question is the entire story. The honest answer in most production wirings today is: the server's, not the user's. Which is fine on a demo, and grim everywhere else.

The two failure modes worth naming

The first is the classic confused-deputy shape. A tool exposed over MCP runs with whatever long-lived credential the server happens to hold. The agent, acting on behalf of a user or a build, asks the tool to do something. The downstream API sees the tool's identity. Audit logs say "the bot did it." Try answering a regulator's question with that string.

The second is credential sprawl. Every MCP server needs a token. Tokens accumulate. Rotation across the estate becomes the kind of toil that gets a Jira ticket opened and then quietly closed.

Neither of these is a flaw in the protocol. They are the things an enterprise authorization layer would have to deal with: short-lived attenuated credentials per call, an audit trail that survives the indirection, scope reduction at the tool boundary, and a clean answer to "what is this agent allowed to do, on this build, for this user, against this resource, right now."

What "real auth" would actually look like

The requirements are well-known from every previous federated-tool story. Per-request, scoped, short-lived credentials. Identity that propagates through the protocol instead of terminating at the server. A policy decision point that lives outside the tool itself. Logs you can use to answer a discovery question six months later.

Familiar list. The reason MCP keeps catching "missing authorization layer" headlines is that the protocol shipped first and the policy work is catching up second. That is exactly the order most useful protocols arrive in. It is also exactly the order in which production teams paper the gap over and move on.

The trust read for the people shipping this

Until the layer is real, an MCP-enabled CI job should be reasoned about the way every other piece of privileged automation is reasoned about: minimum viable scope on the server-side credential, ephemeral where you can swing it, and the assumption that any tool exposed to the agent is a tool exposed to the model. Which, depending on the day, is also a tool exposed to the prompt that just landed in the issue tracker.

Concede the genuine upside, because there is one. A standardized way to enumerate and call tools is better than the bespoke webhook spaghetti it replaces, and a real authorization layer can in principle be added underneath without redesigning the surface above. That is the bet enterprise adopters are making.

It is also the bet that has to actually pay out before this becomes safe by default rather than safe by review.

A model that calls tools. A pipeline that runs as you. A protocol still drawing its own auth boundary.

Pick two, until you can't.