MCP Server Security: Auth-Scoping Patterns That Actually Hold

The default shape, and why it's the problem

Wire an agent to a new system and the fastest path looks like this: mint one API key, hand it to the MCP server, expose three or four tools that all use it. It works in the demo. The problem shows up later, and it isn't a bug in any one tool — it's that every tool call now runs at the full privilege of that one key. A prompt-injected instruction, a confused multi-step chain, or a single malformed input doesn't get contained to "the tool it happened in." It inherits the blast radius of whatever that credential can touch.

This isn't hypothetical risk. Security researchers at Knostic scanned nearly 2,000 publicly accessible MCP servers and found that every single verified instance granted access to internal tool listings without any authentication at all — the servers weren't misconfigured exceptions, that was the norm they found. A separate analysis of more than 5,000 open-source MCP servers found over half storing credentials as static API keys or personal access tokens directly in environment variables, with only a small fraction using OAuth for downstream connections. The pattern isn't rare. It's closer to default.

Tool poisoning: why "the model didn't misuse the tool" isn't the whole threat model

Auth-scoping alone doesn't cover everything, and it's worth being honest about the adjacent risk: Invariant Labs documented "tool poisoning" attacks where instructions hidden inside a tool's own description — invisible to the user, read by the model — can hijack how the agent uses other, trusted servers in the same session. And the MCPTox benchmark found a 72.8% attack success rate for o1-mini across a test set of 20 LLM agents, 45 MCP servers, and 353 tools. The takeaway isn't "give up on MCP security" — it's that scoping the credential and validating the tool surface are two separate controls, and you need both, not either.

The pattern: trust-tier isolation, not one key for everything

The fix that actually holds up under those numbers isn't "write better prompts" or "add a disclaimer." It's scoping each tool to the minimum privilege it needs, so a compromised call can only do the one small thing that tool was scoped for — not everything the underlying system allows:

• Per-tool scopes, not per-service keys. Define scopes at the action level — billing:read, billing:refund, orders:read — and mint a credential (or a token with that exact claim) per tool, not per upstream service. A read tool should be structurally incapable of writing, not just "not supposed to."
• Separate the resource server from the authorization server. Your MCP server's job is to validate a token, not to issue one. If your server is reachable over a network at all, treat OAuth 2.1-shaped authorization as the baseline, not an upgrade path for later.
• An allowlist control plane, not an implicit one. The agent should be granted exactly what a manifest says it's granted — nothing inferred, nothing "probably fine because the key can do it." If the upstream system has no fine-grained scopes of its own, wrap it in a narrow internal proxy that only accepts the specific calls the tool needs.
• Short-lived tokens, rotated on a schedule. If a scoped token leaks, the damage window should be measured in minutes, not the lifetime of a static key nobody remembers to rotate.
• Log which scope was used on every call. If you can't answer "what could this tool have done" from your own logs after the fact, the scoping isn't finished — it's aspirational.

What this looks like on a real tool

# before: one fat key, implicit trust
billing_client = BillingClient(api_key=BILLING_MASTER_KEY)  # can refund, delete, export

# after: scoped credential, tool can only do what it's scoped for
billing_client = BillingClient(api_key=BILLING_REFUND_ONLY_KEY)  # billing:refund, nothing else

@mcp.tool()
async def refund(order_id: str, amount_cents: int) -> dict:
    """Issue a refund. Requires billing:refund scope — cannot delete or export."""
    logger.info("tool_call", tool="refund", scope="billing:refund", order_id=order_id)
    try:
        result = await billing_client.refund(order_id, amount_cents)
        return {"status": "ok", "refund_id": result.id}
    except billing_client.Unauthorized:
        return {"status": "error", "retryable": False,
                "message": "Refund scope rejected — check credential scope, not the code path."}

Notice what changed isn't the function body — it's what the credential behind it is structurally capable of. That's the actual control. Code-level "please only do X" is advice; a scoped credential is an invariant.

The checklist version

• Every tool's credential is scoped to the narrowest action it performs — verified by trying the tool with a scope it shouldn't have, not by reading the code and assuming.
• No tool accepts free-form input and dispatches at run time based on it — that's the single most common critical finding in real audits, and it collapses trust-tier isolation back into "one key for everything" even if the key itself was scoped.
• Tokens are short-lived and rotate on a schedule someone owns, not "whenever we remember."
• Every call logs which scope authorized it, queryable after the fact.
• Tool descriptions themselves are treated as untrusted input from other servers in the same session — not just the arguments a model passes.