Why MCP makes authorization the next enterprise challenge
As MCP standardizes agent integration, authorization is emerging as the next enterprise challenge.
A few years ago, connecting a language model to an internal system meant building a custom adapter for that specific pairing, then repeating it for every other pairing. Model Context Protocol standardized much of that connection layer, which helps explain why adoption moved as quickly as it did.
What it did not remove is the question of what happens after the connection is established. In local deployments, an MCP server may inherit the credentials or permissions available in the user's environment. Without deliberate scoping, an agent can therefore gain access beyond what a specific task requires. If downstream systems receive only the user's identity, audit logs may attribute agent-initiated actions to that user, making it harder to distinguish human intent from autonomous execution.
Enterprise permission models were not designed for this. They assume a human behind every credential, deliberating between choices, at human rather than machine speed.
Anthropic published the protocol in November 2024 with specifications, reference servers, SDKs, and adoption moved quickly through developer tooling companies including Block, Apollo, Zed, Replit, and Sourcegraph. The specification has since gone through several revisions. The July 2026 release makes the protocol core stateless, introduces a formal feature lifecycle with a minimum twelve-month deprecation window, strengthens authorization, and formalizes an extensions framework that includes Enterprise-Managed Authorization. The protocol is now hosted by the Agentic AI Foundation under the Linux Foundation.
The trajectory makes sense because the problem MCP solved was well-defined, and standardizing integration is the kind of work that produces immediate and visible relief.
MCP follows a host, client, and server model. The host acts as gatekeeper and coordinator, managing consent and keeping data isolated between clients, while each server exposes external capabilities such as database access, web APIs, or file systems. Clients and servers declare their supported features during the initial phase, and those declarations then govern the session.
In MCP terminology, tools, resources, and prompts are capabilities exposed by servers. The host coordinates connections and security boundaries, while clients maintain individual server connections and make those capabilities available to the application. This separation provides a standardized interaction model, but authorization still determines which capabilities an agent can exercise and under what conditions.
Enterprise access control rests on three assumptions: deliberation between actions, an audit trail that maps cleanly to intent, and a rough correspondence between what someone is permitted to do and what they can get through in a working day. Autonomous agents can challenge all three assumptions at once.
Security teams work on the principle of least privilege, which means giving an account only the access its job requires. An agent operating with credentials inherited from a human user may receive access far beyond what a specific task requires. Unlike a human operator, it can potentially exercise those permissions at machine speed.
For HTTP transports, MCP addresses part of this through an authorization model based on OAuth 2.1, with scoped tokens and servers that validate both token authenticity and required scopes before executing anything, returning standard 401 and 403 responses when a check fails. Recent revisions have hardened this further, aligning issuer validation and client credentialing with established enterprise OAuth and OpenID Connect practice.
The specification provides the mechanism. However, it cannot decide on anyone’s behalf how narrowly to scope a token, and that decision is governance rather than engineering.
The starting point is that an agent is a distinct actor, not an extension of whoever launched it. This has led to emerging concepts such as “Know Your Agent,” borrowing from identity-verification principles used elsewhere to ask a new question: how does an enterprise verify the identity and authority of an autonomous agent?
The recurring weaknesses are consistent. Permissions may be granted at the level of the human operator rather than the task. Static keys and long-lived tokens may remain in place without appropriate rotation. Schema validation can be overlooked, and audit trails may record the tool call without preserving enough context to reconstruct what triggered it.
Each of these is a governance decision that is presented as a technical one. We examine that pattern in agentic AI and the new security mandate, and MCP narrows it to a specific question: what a single token is permitted to do once the model decides when to use it.
MCP can be deployed in several ways. A server can run locally as a subprocess, which is the fastest option and suits the filesystem and Git integrations. It can also run remotely over HTTP with OAuth, one endpoint per server, which suits SaaS and multi-tenant work, or a single server can sit in front of many backends, presenting one catalog of tools and routing requests to the right place.
For enterprise-scale deployments, the gateway pattern deserves particular attention, because it turns scattered configuration into a policy enforcement point. A gateway can block specific actions, constrain parameters before they reach downstream systems, apply rate limits, and produce a single audit stream. Without one, each server enforces its own rules, and Model Context Protocol security across the enterprise becomes whatever the weakest deployment happens to be.
None of this argues against local servers. They remain the practical choice for single-user developer tooling, where the operator and the agent share one trust boundary. The problem begins when that pattern is carried into shared systems without revisiting the assumption behind it.
The protocol states clearly that a server should never trust what the client tells it, however reasonable it looks. That is easy to accept in principle but also equally easy to forget in practice, particularly when one team owns both sides. Either validate on the server or accept that the weakest client defines the security boundary.
The same shortcut shows up at the organizational level, and it costs more. Once connectivity is standardized, the harder enterprise question is often what the agent may do, on whose authority, and how that sequence can be reconstructed afterwards. If authorization is addressed only after a pilot is working, security review may uncover tokens scoped to individual employees or permissions broader than the task requires, forcing teams to revisit the identity model before production.
Treating agent authorization as part of the initial integration can avoid costly redesign later, even if it adds work to the first implementation.
The easiest way to report progress is to count deployed MCP servers. It's also one of the least useful measures of enterprise readiness because that number says nothing about what those servers can access or how that access is governed. More useful questions are:
The first question addresses technical scope. The second and third expose harder governance challenges, particularly around traceability and ownership. The third is particularly important because access can expand incrementally as teams adjust configurations to get integrations working. Without clear ownership, those changes can quietly broaden an agent's effective permissions.
The integration problem was real, and MCP solved it. But an agent is a new kind of actor inside systems that have never had one, and agent authorization is the part that must be designed rather than inherited.
An agent with overly broad access can still appear to be working exactly as designed. Nothing looks wrong until the audit trail has to explain an action nobody intended to authorize.
