Few things make me rage like getting a CORS error when I’m building something. CORS is something that developers love to hate because it always seems to cause issues. Testing out your new API in a browser for the first time? CORS error. Moving your web page out of local dev to your staging environment? CORS. Adding a new HTTP method to your API? CORS.

Despite how annoying it is, CORS is incredibly useful. It’s saved hundreds—maybe thousands—of APIs from being pirated by preventing unauthorized web apps from embedding them in frontend code. Put simply, CORS prevents you from including someone else’s backend in your app and calling it yours.

We’re seeing a tidal wave of attention around a recent(ish) development in the world of AI: the model context protocol (MCP). MCP is a specification that defines how Large Language Models (LLMs) interact with tools. It establishes a standard way for these LLMS to discover what functions are available, find the best way to build prompts, and access static resources.

Everyone and their sister is scrambling to get in the MCP rush while the getting’s good. Be it building their own server or hosting servers for others, this digital land grab is moving so fast it’s leaving massively important things like security by the wayside.

I’ve heard MCP defined as “just a wrapper for OpenAPI.” 🙄 Setting aside that massive trivialization (MCP is much more about establishing intent, context, and safe usage patterns), this mentality has led to a flood of proxy MCP servers—servers that do nothing more than forward requests to existing APIs on behalf of an LLM.

flowchart LR
    A(You) -->|Ask a question| B("MCP Client <br/>(Cursor, Claude, etc..)")
    B --> |Invoke|C("MCP Server")
    C -->|Call directly| F("3rd Party API")

In practice, this means that any API—public, 3rd party, internal, or otherwise—can be quickly dressed up as a model tool by someone who doesn’t own it, control it, or even understand its original intent. The wrapper doesn’t need permission. It doesn’t validate ownership. It just forwards requests.

This might seem harmless on the surface (the API was public, right?), but it creates a dangerous precedent of normalizing the repackaging of APIs as agent tools without consent or accountability. Circle back to the problem that CORS is solving for us - looks like we’ve got a new attack vector we’re massively unprepared for.

Why doesn’t CORS work as is?

CORS prevents unauthorized frontends from calling your API directly. It is, by all means, not a foolproof mechanism. Developers can simply bypass it by implementing the backend for frontend (BFF) pattern where the request is handed off to a backend service to (traditionally) call the API and perform a data transformation.

An MCP server is not proxying these calls to your API from a frontend. Far from it. CORS as it sits today won’t help you here. And for the record, please don’t rely solely on CORS for unauthorized access prevention, that’s not what it’s for.

What we need is a way to pair intent with interopability—so when an LLM hits your API, the API knows why, who, and whether it’s ok.

One of the nice things about CORS is that you don’t have to use it. If you want your API called from anywhere, throw in a Access-Control-Allow-Origin: * to your response headers and you’re off to the races. But if you did want to restrict access, you can simply add Access-Control-Allow-Origin: readysetcloud.io and nobody else will be calling that endpoint from their UI.

Another reason CORS won’t work to prevent your API from being pirated by an MCP server is that there’s no neutral-party enforcer. CORS is enforced by your browser—not your frontend code, and not your API itself. The browser slaps on an Origin header every time the frontend makes an HTTP request. The API returns the Access-Control-Allow-Origin header to signal to the browser who’s allowed to call it. If those values don’t match… 💥

So… what do we do?

Enter the highly-opinionated can of worms. There’s lots of things we can do, and honestly it’s not for one person to decide. MCP is a specification with a handy set of SDKs to help you adhere to it. It’s not a validation authority.

We need something like browsers in the AI agent world. A neutral third-party that doesn’t dig into your business, but does its best to protect and validate clients, servers, and server backends.

Ecosystems that host MCP servers are a great start. Let these ecosystems host, scale, observe, validate, and protect downstream resources. They are essentially “browsers for AI” that can be used to leverage safety mechanisms. They could add in a new MCP-Origin header to HTTP requests going out from MCP servers and listen for a similar Allow-MCP-Origin header from the API responses.

sequenceDiagram
    participant Ecosystem as MCP Server Ecosystem
    participant Server as MCP Server
    participant API as API Server

    Ecosystem->>Server: Request to access external API
    Server->>API: OPTIONS Request (Preflight)
    note right of Server: Headers:<br/>- MCP-Origin: https://mcp-server.com

    API->>API: Validate MCP-Origin against allowed origins

    alt Origin allowed
        API->>Server: 200 OK Response
        note left of API: Headers:<br/>- Allow-MCP-Origin: https://mcp-server.com<br/>- Allow-MCP-Methods: GET, POST

        Server->>API: Actual GET/POST Request
        note right of Server: Headers:<br/>- MCP-Origin: https://mcp-server.com<br/>- Content-Type: application/json

        API->>API: Process request
        API->>Server: 200 OK with requested data
        note left of API: Headers:<br/>- Allow-MCP-Origin: https://mcp-server.com

        Server->>Ecosystem: Return API data
    else Origin not allowed
        API->>Server: 403 Forbidden
        note left of API: Headers:<br/>- Allow-MCP-Origin: https://approved-server.com

        Server->>Ecosystem: Error: API access denied
    end

But it’s not that easy

There’s a lot more nuance with LLMs invoking APIs automatically. Lots of bells, knobs, and whistles to configure or restrict. What if API producers don’t want certain models to be invoking their tools? For every commercial LLM with a solid set of guardrails, there’s a dozen malicious ones designed to wreak havoc.

MCP servers are a dime a dozen. It might quickly become unmanageable to allow-list individual servers. Maybe we need to do it from the ecosystem level? If the MCP server hosting ecosystems provide a strong vetting of intent and quality, an API could perhaps allow any MCP server vended from them.

These knobs add complexity via configuration and options. As much as we (as humans) like our options, we sure do suck at making them, let alone agreeing on them. Case and point, look at the discussion on providing stateless support for MCP.

Off the top of my head, if we as a community decided on MCP CORS, we’d probably want to support at a minimum:

• Allow-MCP-Origin: Indicates the MCP servers allowed to invoke the API.
• Allow-MCP-Functions: Allow list of endpoints via their operation id.
• Allow-MCP-Host: The MCP server hosting ecosystem.
• Allow-MCP-Models: Allow list of AI models allowed to invoke endpoints.

All-in or no?

Despite the apparent attack vector we aren’t talking about 😬 I’m still all-in on MCP. Like any emerging standard, there’s going to be churn, polarizing opinions, and missed requirements. It’s always rocky to get people to converge because most people think their way is the “best way”. While we all know the “best way” depends on your specific use case, adhering to a standard almost always emerges the best choice in the long run.

We’re far off from addressing this concern. Heck, we aren’t even sending client metadata to MCP servers when invoking tools. But we’ll get there.

What I see is a HUGE opportunity for startups and enterprises alike to get in on the ground floor and help shape the AI agent ecosystem with respect to MCP servers. We haven’t really seen an opportunity like this since 2008 when Google Chrome was released and the “modern browser war” took off to define an entirely new frontier.

I’m excited, but am going to approach it with cautious optimism. If you’re building in this space—or thinking about how to secure it—I’d love to hear your thoughts.

Happy coding!