The Problem with "We'll Add Auth Later"
MCP servers are built by developers who know their tools work. They test locally, everything connects, the agent makes tool calls, it's great. Auth is the last thing anyone wants to think about. And then they ship it.
Here's what we've observed in unprotected deployments. Not theoretical — observed.
Attack Pattern 1: Token Replay
Without auth, MCP tool calls often carry whatever credential the agent was given at startup — an API key, a service account token, sometimes a personal access token. These tokens are passed in HTTP headers.
MCP servers that log request headers (which many do for debugging) now have those tokens in log files. Log files that get rotated to S3. S3 buckets with misconfigured access policies. Anyone who can read the logs gets a working token with no expiry and no audit trail of what they did with it.
With AuthPlane MCP Auth: access tokens are JWTs that expire in 15 minutes. They're bound to specific MCP servers via the resource claim (RFC 8707). Even if someone extracts a token from a log, it's expired and scoped to a single server.
Attack Pattern 2: No Scope Enforcement
Many MCP servers expose tools like execute_query, write_file, send_email. Without auth, every agent that connects gets access to every tool. There's no way to give one agent read-only access and another write access. There's no way to restrict a debugging agent from sending emails.
AuthPlane MCP Auth implements tool-level scopes. A token for tools/read_db cannot call tools/write_db. The consent screen shows users exactly which tools an agent is requesting. Requests for unscoped tools return 403 insufficient_scope.
Attack Pattern 3: No User Identity in Tool Calls
When an agent calls a tool, the MCP server often doesn't know which user triggered it. This matters for multi-tenant systems. Without identity in the request, there's no way to enforce row-level security, rate limits per user, or audit which user's agent made a sensitive call.
With AuthPlane JWTs, every tool call carries sub (user ID), agent_id (which agent), and agent_chain (delegation path). MCP servers can enforce per-user and per-agent policies on every request.
Attack Pattern 4: Zero Audit Trail
When something goes wrong — an agent deletes data it shouldn't have, sends an email it wasn't supposed to, makes an API call that burns through rate limits — there's no way to reconstruct what happened without auth. No record of which agent made the call, on behalf of which user, at what time, with what inputs.
AuthPlane's audit log captures every token issuance, every revocation, every consent decision, every refresh. Stored with trace_id and span_id for correlation with request traces.
The Fix
The fix is straightforward: deploy AuthPlane MCP Auth alongside your MCP server. It handles the full OAuth 2.1 flow and takes under 5 minutes to deploy. Your MCP server gets a JWKS endpoint to verify tokens against, and every tool call arrives with a verified JWT that tells you exactly who the agent is, which user authorized it, and what tools it's allowed to call.