How does MCP authorization work, and how do I secure MCP servers that coding agents use?

Two kinds of MCP server, two trust models#

A coding agent connects to MCP servers in two ways, and the security story is different for each.

A remote server speaks HTTP. The spec's authorization section covers this case, and it's built on OAuth.

A local stdio server is a process your agent launches on the laptop. The spec says implementations using stdio "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." So a local server has no login step. It gets whatever the developer has.

I'm quoting the current draft of the spec. Check which version your clients and servers implement.

How remote MCP authorization works#

Two rules from the spec carry most of the weight:

• Discovery. "MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728)." The client reads that metadata to learn how to get a token for this server.
• No foreign tokens. "MCP servers MUST NOT accept or transit any other tokens." A server only honors tokens issued for it.

The second rule is what kills token passthrough: a server taking a token issued for something else and forwarding it to a downstream API. If your MCP server fronts another service, it should get its own token for that service, not reuse the one the client sent.

The confused-deputy problem#

This one hits MCP servers that act as a proxy in front of a third-party API. The proxy holds its own relationship with that provider, and a careless consent flow can be tricked into approving a client the user never meant to approve.

The security best practices page is direct about the fix: "To prevent confused deputy attacks, MCP proxy servers MUST implement per-client consent and proper security controls." If you run or buy a proxy server, ask how it does per-client consent.

What OAuth doesn't cover#

OAuth answers "who is this client and what may it ask for." It says nothing about whether the tool you just called is honest, or whether the model should call it.

Tool poisoning. Invariant Labs described malicious instructions embedded in tool descriptions "that are invisible to users but visible to AI models." The same notice describes a rug pull: "a malicious server can change the tool description after the client has already approved it." The server you approved last week isn't necessarily the one you're talking to today.

Local servers. The spec's best practices list arbitrary code execution for local servers: "Attackers can execute any command with MCP client privileges." Installing one is running code on the laptop.

Third-party content. Claude Code's docs say to "verify you trust each server before connecting it," because servers that fetch external content can expose you to prompt injection (see Claude Code's MCP docs).

A checklist for each server an agent connects to#

• Who runs it? A vendor you have a contract with, your own team, or a stranger's package? Allow-list sources and pin versions.
• Remote or local? Remote servers should do OAuth and reject foreign tokens. Local ones inherit the developer's access, so treat the install command as code you're about to run.
• What credentials does it hold? Use read-only database users and narrowly scoped, short-lived tokens. A server holding an admin token turns a poisoned description into an admin action.
• What tools does it expose? List them. Flag anything that writes, deletes, sends, publishes or reaches the network.
• Can the tool list change? Pin it or re-review on change, because of the rug pull.
• Is it a proxy to a third party? Ask whether it does per-client consent and refuses tokens issued to someone else.
• Is there a record? You need to know which tool calls ran, with what arguments, in which session.

The built-in controls do real work. Allow-lists keep strangers' servers off the laptop, scoped credentials shrink what a bad server can reach, and sandboxes limit what a local server can touch. None of them judge a specific call in context: a permitted server's tool, called with arguments that came from poisoned content, looks like any other allowed call. For the install-time side, see vetting coding agent extensions and plugins.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Each MCP tool call, like every command, file edit and push, is checked against the session's intent before it runs. If a poisoned description gets the agent to read a private key and send it to a network call, that's a dangerous flow, and Harden blocks it and tells the agent why.

Deterministic rules decide the clear cases; a local model reviews calls in session context for risks including tool or MCP poisoning, and it can only make a verdict stricter. Decisions are made locally in milliseconds, one policy covers every agent, and it starts watch-only, so you can see which MCP calls your agents make before you enforce anything.

It's a layer. It doesn't replace scoped credentials, sandboxing or a server allow-list. More on the broader controls in MCP security risks and best practices.