The NSA likes to say, we don’t break standards, we break implementations. In that spirit let’s look at how OAuth may perform, as implemented in current practice, for MCP.

Anthropic announced Model Context Protocol (MCP) last November and it has attracted tons of attention as a simple way to plug in models, tools, and APIs. This means security teams need to pivot quickly to provide solutions for this new integration layer.

On a first pass, OAuth seems a logical starting point for an identity layer to underpin MCP flows. After all, OAuth is already in use for many API security systems. Indeed for most Infosec teams tackling MCP here and now, OAuth is the starting point for addressing MCP security.

However, there are some reasons to be concerned if, in practice, OAuth will improve security or degrade it. Let's start with identity protocols generally, they do not "solve" access control, instead the identity protocols give a way to transform an access decision (i.e. delegation) and move it around in a networked system. Since MCP provides a new integration layer for LLMs and agents, it is reasonable to expect that unexpected linkages will occur due to the combination of multiple integration layers plugged together over MCP resulting in over-permissioned access to data because OAuth permissions are not by default tuned to the new target environment.

Let's assume MCP achieves Anthropic's goal as a USB layer for LLMs and agents and becomes the de facto standard to plug in various APIs. What can OAuth reliably provide “out of the box” from a security perspective? Well, OAuth can mint a token with information about a client calling and what they are trying to gain access to, which then gives a recipient a start about mapping a caller and resource, but is that enough?

Let's look at some specifics that OAuth does _not_ provide out of the box:

• Do you want to ensure strong authentication? OAuth does not tell you about initial authentication types, and whether this was over phishing-resistant protocols.

• Do you want to ensure the API requests are not using stolen credentials? OAuth does not let you know if this token is being replayed from a legit user or an attacker machine.

• Do you want to know what device is running the request? OAuth does not tell you this.

• Do you want to set access control policies based on attributes, roles, events, actions, or semantics? OAuth does not give you this.

• Do you want to limit asset discovery and lateral movement? Like everything else, depends on the configuration, but in practice OAuth often makes this easier.

• Do you want to monitor access, e.g. who is on the system now? OAuth server logs do tell you this, but you need to load them into your SOC/SIEM and write monitoring code.

OAuth advocates (of which I am one) will argue that I am being unfair, of course, with different add ons, configurations, code, and certain OAuth profiles, you can bend the protocols to deliver some critical bits of much of the above. I am being deliberate to highlight the contrast here to show the gap between the things that Infosec teams typically want to get out of an access control system and compare that to what many teams deliver when they deliver a plain, vanilla, "we turned OAuth on, we're good" deployment. I believe that seeing many of these initial MCP efforts geared around "yes, we are hooking everything together with MCP, but we are ok, because OAuth will bail us out" will result in unexpected gaps like the above.

I will note here, that the questions above are ones I would be a starter set of ones I would expect a security team to ask securing any API communication. This is all foundational before 1) tackling the challenge of the MCP server proxy itself and how do you want to delegate identity and access through it? and 2) the new risks that MCP exposes, many of which relate to semantics and data, which OAuth likewise does not address.

New attack surfaces exposing limits of older security protocols built for different use case is not new. It is pretty similar to the early days of most technologies, when Apple Pay was turned on its fraud rates went through the roof immediately due to channels being left open, the early days of the web were rife with XSS and SQL Injection, etc. In the early days of Web services, one of Microsoft's stacks checked authentication by asking "did you send a certificate?" Not "did you send a valid certificate?"

There are so many precedents here for technology running ahead and security catching up as quickly as we can. What is different now is that in early days of new developments of say eCommerce or Mobile Payments or Web services, these were wholly new areas so the risks were real but some what limited to the new stacks that companies deployed. In the case of MCP, the models consume enormous amounts of extant assets, meaning there is an inside out attack surface that is a new problem for Infosec teams to solve. That will be a topic for another post. What can OAuth do to provide some comfort to Infosec teams in the meantime? Infosec teams can look to OAuth as part of an identity access layer, but the real work is well beyond that, into the identity proxies, the first mile and last mile tuning to provide access based policy decisions that map to these new attack surfaces.