Securing MCP Servers: Authentication & Authorization in the Age of AI Agents
10 min read · May 2026 · Architecture & Security
As AI agents gain the ability to call tools, read files, and take actions on behalf of users, the systems powering those capabilities — MCP servers — become critical security boundaries. Getting auth wrong here isn’t just a bug. It’s a blast radius.
What is an MCP server, briefly?
The Model Context Protocol (MCP) is an open standard that lets AI systems — like Claude — communicate with external tools and data sources through a structured interface. An MCP server exposes capabilities (tools, resources, prompts) that an AI client can invoke. Think of it as an API gateway, but purpose-built for AI agents rather than human-written code.
When you connect Claude to your calendar, your codebase, or your CRM through an MCP server, the server becomes the gatekeeper between what the AI can request and what it can actually do.
Key concept: MCP servers are not passive data stores. They are action surfaces — they can send emails, modify records, trigger deploys, and run code. The stakes for auth failures are therefore much higher than in read-only APIs.
How auth in MCP servers differs from normal apps
In a traditional web application, a human sits at the keyboard. They log in, see a UI, and make deliberate choices. The authentication model is built around that reality: a session cookie, a JWT, maybe an MFA prompt. The user is present — and their intent is legible.
MCP changes the picture in three important ways:
Traditional app
- Human initiates every action consciously
- Browser session ties identity to interaction
- UI friction slows down accidental actions
- Scope is usually implicitly tied to the screen
- Auth errors are visible and recoverable
MCP / AI agent
- AI can chain many tool calls autonomously
- Identity is delegated — the user isn’t watching
- No UI friction — actions are silent and fast
- Scope must be explicit and auditable
- Auth errors may silently affect downstream tasks
The most important shift is delegation. When a user asks Claude to “clean up my inbox and schedule follow-ups,” they’re delegating a chain of actions. The MCP server has to trust that the token it receives really represents that user’s intent — and only that user’s granted permissions — not the full power of the underlying service account.
Common mistake: Reusing a single admin service account across all MCP tool calls. This gives the AI blast-radius equivalent to a root shell. Any prompt injection, misconfigured tool, or logic error becomes catastrophic.
Authentication vs authorization — the distinction that matters
Authentication answers: who are you? It verifies identity. In MCP, this usually means verifying a signed token (OAuth 2.0 access token or JWT) presented by the MCP client on behalf of the user.
Authorization answers: what are you allowed to do? Even after the server confirms the caller’s identity, it must check whether that caller has permission to invoke a specific tool, access a specific resource, or perform a specific action.
In practice, MCP servers must enforce both — and most security failures happen when one is assumed from the other. Proving identity does not grant permissions. Permissions don’t prove identity.
Why securing MCP servers is critical
A poorly secured MCP server is uniquely dangerous because it sits at the intersection of AI agency and real-world systems. Several attack surfaces emerge that don’t exist in traditional APIs:
Prompt injection via tool results
If an attacker controls data that gets returned to an AI through a tool call (e.g., a document with embedded instructions), they can hijack the agent’s behavior. A secured MCP server limits what the AI can do next — containing the damage even when the AI itself is manipulated.
Over-privileged delegation
Users often grant MCP integrations broad OAuth consent without understanding the full tool surface. If the server doesn’t enforce least-privilege on a per-tool basis, a user’s “read my calendar” consent silently also covers “delete all events.”
Multi-tenant leakage
In hosted MCP deployments serving multiple users, a missing tenancy check on resource IDs means user A’s tool call could read or modify user B’s data. This is especially common when developers hardcode resource paths or skip per-request identity checks.
Real risk: Because AI agents can call tools in loops — iterating over lists, processing batches, following links — a single authorization gap can be automatically exploited at scale before any human notices.
Scope-based and role-based authorization
The two dominant models for MCP authorization map onto familiar patterns from OAuth and RBAC, but they need to be applied at the granularity of individual tools and resources — not just the server as a whole.
Scope-based authorization (OAuth model)
Scopes are strings declared during OAuth consent that specify exactly which capabilities are granted. A well-designed MCP server maps each exposed tool to one or more required scopes, and rejects calls where the token’s granted scopes don’t cover the tool being invoked.
| Scope | Description | Sensitivity |
|---|---|---|
calendar:read |
List and read calendar events. No write access. | Low |
calendar:write |
Create and modify events. Requires explicit consent. | Medium |
contacts:read |
Read contact names and emails. No export or delete. | Medium |
email:send |
Send emails on behalf of user. | High |
Here’s how a scope check looks inside an MCP tool handler:
// Example: scope check inside an MCP tool handler
async function handleSendEmail(request, token) {
const scopes = await verifyToken(token); // ['calendar:read', 'contacts:read']
if (!scopes.includes('email:send')) {
throw new AuthorizationError(
'Missing required scope: email:send'
);
}
return emailService.send(request.params);
}Role-based authorization (RBAC model)
Where scopes work well for user-delegated access, roles work better for server-to-server or enterprise contexts where users have organizational identities. A role bundles a set of permissions — typically organized around job functions rather than individual capabilities.
In an MCP context, roles might be: agent:read-only, agent:contributor, and agent:admin. Each role permits a fixed set of tools. The AI receives a token that carries the user’s role, and every tool invocation is checked against the role’s permission set before execution.
Best practice: Combine both models — use OAuth scopes for user-delegated consent (controlling what users authorize the AI to do) and RBAC for organizational access control (controlling what roles are allowed to use which tools at all). Scopes narrow the user’s grant; roles narrow the organizational permission.
Example scenario: AI assistant with email + calendar access
Setup: Priya is a VP at a company using Claude as an executive assistant. The AI is connected to an MCP server exposing tools for Gmail, Google Calendar, and the company’s internal task tracker. She authorized the integration with the following OAuth scopes during setup:
calendar:readcalendar:writeemail:readtasks:write
The request: She asks Claude: “Review my unread emails, block time for anything urgent on my calendar, and create tasks for action items.”
How the MCP server handles each tool call
Step 1 — listUnreadEmails() — requires email:read
Token has email:read ✓ — server returns emails. Agent reads subjects and summaries.
Step 2 — createCalendarEvent() — requires calendar:write
Token has calendar:write ✓ — server creates a 2-hour focus block. Resource is scoped to Priya’s calendar only (tenancy enforced by user ID in token).
Step 3 — createTask() — requires tasks:write
Token has tasks:write ✓ — three tasks created in Priya’s task tracker, tagged with source email IDs for traceability.
Step 4 — sendEmail() — requires email:send
Claude considers drafting a reply to one email. The token does not have email:send — server rejects the call with 403. Agent reports back to Priya that she’d need to grant send permission for this action.
Outcome
- 3 of 4 tool calls succeed within granted scopes
sendEmailblocked — scope not granted, no data exfiltrated
This scenario illustrates the principle of least privilege in action. The AI was not given a master key to Priya’s Google account. It was given exactly the permissions she consciously approved — and the MCP server enforced those boundaries at every tool invocation, silently containing the agent’s blast radius.
Closing thoughts
Securing an MCP server isn’t dramatically different from securing any API — the patterns are familiar: token validation, scope enforcement, tenancy isolation, audit logging. What is different is the urgency. AI agents are faster, more autonomous, and more capable of chaining actions than any human using a web app. The cost of a missing authorization check scales accordingly.
The right posture is to treat every MCP tool as a privileged operation, every token as untrusted until verified, and every scope as the minimum necessary — not the maximum convenient. Build that in from the start, and the AI agent becomes a powerful, trustworthy collaborator rather than a security liability.
TL;DR: Verify identity on every request. Enforce scopes per tool, not per server. Isolate tenants by user ID in the token. Log every tool invocation. Grant the minimum scope, not the maximum convenient one.