Frontier spoke

MCP Authorization — per-agent scopes, capability tickets, audit logs

Authorization is the hardest part of shipping an MCP server — and the most commonly failed. A July 2025 internet scan found 1,862 publicly exposed MCP servers with zero authentication; a follow-up seven months later found 41% of registry-listed servers still running with no auth at all. The protocol spec converged on OAuth 2.1 in March 2025, but most shipped servers predate the revision and haven't been updated. Getting this right is the difference between an asset and a liability.

By Chris Mühlnickel · 2026-05-16

What is MCP Authorization?

MCP Authorization is whether your [Model Context Protocol](/learn/agent-protocols/model-context-protocol) server uses per-agent OAuth scopes, capability-level permissions, audit logs of agent actions, and per-tool rate limits — rather than shipping with no authentication, a single shared API key, or auth applied at the wrong layer.

By the numbers

Why it matters

Authorization is the hardest part of shipping an MCP server — and the most commonly failed. The protocol layer is solved: every major vendor supports MCP, the SDKs are mature, the public registries index thousands of servers. The security layer is not. Knostic's July 2025 internet scan found 1,862 publicly exposed MCP servers running with zero authentication — anyone with the URL could call any tool. A February 2026 follow-up on 518 registry-listed servers found 41% were still running with no auth at all. The problem is not easing. The hub stub already calls this out as the highest-leverage Frontier watcher; this spoke is the deeper dive.

The auth gap compounds with implementation vulnerabilities. Equixly's March 2025 audit of MCP server implementations found 43% contained command-injection flaws — and that's before the lack of authentication is factored in. An unauthenticated MCP server with a command-injection bug is not a security problem; it's a remote code execution surface waiting for someone to find the URL. Most MCP servers are not deliberately malicious; they're early-stage projects shipped fast, with security as the deferred milestone that never lands.

The right pattern is OAuth 2.1 plus capability-level permissions plus audit logs plus per-tool rate limits. Each layer does different work. OAuth gives you per-agent identity and revocable tokens — you know which agent called which tool, and you can shut off a misbehaving one without breaking the rest. Capability permissions give you least-privilege at the tool level — an agent can call list_invoices but not create_refund, even within the same scope. Audit logs give you the post-hoc trail when something goes wrong — every tool call recorded with agent ID, user, parameters, and result. Rate limits per tool prevent the denial-of-service version of agent abuse — one runaway agent shouldn't be able to call your write API 10,000 times a minute. Skip any of these layers and the system is fragile.

The wrong patterns are well-documented and still common. First, no auth at all — the 41% finding above. Second, a single shared API key across all agents — one breach compromises everyone, and there's no per-agent identity for audit or revocation. Third, auth on the wrong layer — putting an API key check at the CDN and assuming that's sufficient, when CDN-layer rules can't enforce capability-level permissions or carry agent identity into the audit trail. Fourth, auth-but-no-scopes — implementing OAuth but granting universal access to every agent, which gives you identity but no least-privilege. All four patterns are alive in production.

The March 2025 spec revision moved the goalposts, and most servers haven't caught up. The MCP working group revised the authorization section in March 2025 to mandate OAuth 2.1 with PKCE for HTTP transport, require RFC 9728 protected-resource-metadata endpoints, and clarify dynamic client registration. Servers built before that — which is most of them — generally don't implement any of this. The compliance gap is real and growing; the spec is the floor, not the ceiling.

Where it's heading

The MCP authorization spec extension codifies the OAuth-plus-capabilities pattern. Today, OAuth 2.1 is mandated for HTTP transport and capability permissions are implementer's choice. Expect a follow-on spec revision (likely 2026-2027) that standardizes capability-ticket formats, scope-to-capability mapping, and audit-log schemas — so that an agent's capability claim is interoperable across MCP servers from different vendors rather than vendor-specific.

Security audits become baseline for B2B MCP procurement. SOC 2 Type II and ISO 27001 audit frameworks already cover API security in general; expect MCP-specific control families that auditors check for explicitly — OAuth compliance, audit-log retention, per-tool rate limits, capability-permission enforcement. Enterprise buyers will ask for the audit before they connect their agents to your server.

Per-agent identity verification spec emerges. Today, an agent identifies itself via a client_id at OAuth registration. Tomorrow, expect cryptographic attestation — the agent proves it's running on a specific model from a specific vendor with a specific user's consent, signed end-to-end. Anthropic, OpenAI, and Google all have early proposals; convergence to a standard is plausible by 2027.

Capability tickets standardize as a portable primitive. Right now, capability permissions are implementation-specific — every MCP server has its own way of expressing 'this agent can call this tool with these constraints.' Expect a standardized capability-ticket format (think JWT-like) that an agent can present at call-time and any compliant MCP server can verify. This unlocks delegation patterns (an agent can sub-delegate to another agent with a subset of its capabilities) and is the foundation for cross-vendor multi-agent flows.

Default-secure platforms emerge. Today, you build OAuth into your MCP server by hand. Tomorrow, expect platforms (Anthropic's hosted MCP, Cloudflare Workers MCP, AWS Bedrock AgentCore) where OAuth, audit logs, and rate limits are the default rather than a build-your-own. Self-hosted MCP becomes the legacy path; managed-MCP-with-auth-included becomes the new baseline.

Common mistakes

  • Shipping MCP with no authentication at all. The 41% finding. Most common in projects that shipped fast and deferred auth — the deferred milestone never lands. If your server has any write tools or any data worth protecting, no-auth is shipping a public RCE surface.
  • Single shared API key across all agents. Solves the 'how does the server know who's calling' question with the worst possible answer — one breach compromises every user, no per-agent revocation, no audit identity, no scope enforcement. The pattern looks fine in a prototype and is unrecoverable in production.
  • Auth on the wrong layer — CDN, not application. Cloudflare Workers, AWS WAF, and Akamai can rate-limit and block abuse, but they cannot enforce capability-level permissions or carry agent identity into your audit trail. CDN auth is defense in depth, not a substitute for OAuth at the application layer.
  • No audit logs. Even read-only tools need logging. An agent calling list_customers repeatedly is a data-exfiltration signal regardless of whether any write happened. Without audit logs, you find out about incidents from external parties — the worst-case discovery path.
  • No per-tool rate limits. A runaway agent calling your write API 10,000 times a minute is a denial-of-service event whether intentional or not. Rate-limit per tool, per agent identity, and per user — three different layers, each catching a different abuse pattern.
  • Ignoring the March 2025 spec revision. Most MCP servers were built before OAuth 2.1 was mandated for HTTP transport. The spec moved; the servers didn't. If your server's auth section still references the November 2024 spec, it's out of compliance with the current standard.
  • Conflating OAuth scope with capability permission. Scopes are coarse — they grant access to a domain. Capabilities are fine-grained — they grant access to specific tools or rows. You need both: scopes for high-level access control, capabilities for least-privilege within a scope. Implementing only OAuth scopes gives you identity but no least-privilege; you still have the 'one credential, universal access' problem at the tool level.

Frequently asked

What's the minimum viable auth pattern for an MCP server?

OAuth 2.1 with PKCE, per-agent scopes, and short-lived tokens. The March 2025 MCP spec revision mandates this for HTTP transport — anything less is non-compliant. Beyond the minimum, capability-level permissions (an agent can read invoices but not delete them), audit logs of every tool call with agent identity and parameters, and per-tool rate limits are what separates 'auth implemented' from 'auth implemented well'.

Why isn't a single shared API key enough?

Three reasons. First, a shared key has no agent-identity signal — when something goes wrong, you can't tell which agent on which user's behalf called the bad tool. Second, one breach compromises everyone — there's no way to revoke access for a single misbehaving agent without breaking every other client. Third, scope-less keys grant universal access — there's no way to say 'this agent can read but not write' or 'this agent can call list_invoices but not create_refund'. Audit, revocation, and least-privilege all need per-agent identity.

What's the difference between an [OAuth scope](/learn/glossary#term-oauth-scope) and a capability permission?

Scopes are coarse, capabilities are fine-grained. An OAuth scope is typically domain-level — 'read:invoices' grants access to the entire invoice surface. A capability permission is tool-level or even row-level — 'can call list_invoices but not create_invoice' or 'can read invoices for customers in this org but not others'. Most production deployments need both layers: scopes for high-level access control, capabilities for the specific actions an agent is allowed to take inside that scope.

What did the March 2025 spec revision actually change?

It mandated OAuth 2.1 with PKCE for HTTP-transport MCP servers, required RFC 9728 protected-resource-metadata endpoints for capability discovery, and clarified the dynamic client registration flow for agents. The change closed the gap between 'MCP works' and 'MCP works securely.' Servers built before March 2025 generally don't implement any of this — and they haven't been updated.

Why are 41% of registry-listed servers still running with no auth?

A few reasons compounding. Most MCP servers were built between Nov 2024 (protocol launch) and March 2025 (auth spec) — before the spec mandated OAuth. Many are hobby projects or proofs of concept that nobody has gone back to harden. Some are explicit 'no auth' design choices (public read-only data) that have legitimate use cases but make the public-exposed-count look worse than it is. The 41% figure includes all three categories; the dangerous subset is the production servers that should have auth but don't.

Do I need audit logs even for read-only tools?

Yes. Read-only tools can leak data — an agent calling list_customers repeatedly is a data-exfiltration signal even if no write happens. Audit logs let you spot patterns: which agent identity, which user, which tools, which frequencies, which time windows. The cost of logging is low; the cost of not logging is finding out about an incident from an external party.

Where does CDN-layer or WAF auth fit in?

It doesn't replace application-layer auth — it stacks on top of it. Cloudflare, AWS WAF, Akamai Bot Manager can rate-limit, geo-restrict, and block obvious abuse before requests reach your MCP server. They cannot enforce per-agent scopes, capability permissions, or audit-log identity. Treat edge auth as defense-in-depth, not a substitute for OAuth at the application layer.