The security risks specific to MCP servers, and how to address them

When developers ask about securing AI agents, most of the answers they find are about prompt injection. That's the right place to start, but it's not the whole picture. It's especially incomplete if what you're actually building is an MCP server.

An MCP server has a distinct security surface. It's a network-accessible service that any compatible AI client can connect to. It exposes tools that agents can invoke. It sits between the model and your production systems. The threats it faces are specific, and the mitigations for some of them are different from what you'd apply to a regular API.

This article covers five risks, drawn from OWASP's agentic AI security work, applied specifically to the MCP context. For each one: what the risk is, how it plays out on an MCP server, and what to do about it.

The five risks at a glance

01. Unauthenticated tool access

The MCP spec requires OAuth 2.1. Most tutorial implementations ignore this entirely. The result is MCP servers that are openly callable by any agent, or any attacker, with no identity check at all.

This isn't an edge case. The default for a new MCP server, in most frameworks, is no auth. Developers add it later, or don't. And because agents connect programmatically rather than through a browser, there's no login screen to make the gap obvious.

What goes wrong: without authentication, your MCP server's tools are publicly callable. An attacker who knows your server URL can invoke tools directly, bypassing the agent entirely.

Mitigation

Add OAuth 2.1 to your MCP server. The server needs to do two things: return a 401 with a metadata endpoint on unauthenticated requests, and verify access tokens on every tool call. The authorization server handles the rest.

  
// Point clients to your auth server via metadata
app.use('/mcp', (req, res, next) => {
  if (!req.headers.authorization) {
    res.set('WWW-Authenticate',
      `Bearer realm="https://auth.workos.com"`
    );
    return res.status(401).json({ error: 'unauthorized' });
  }
  next();
});
  

WorkOS AuthKit acts as a drop-in OAuth 2.1 authorization server for MCP servers. Your server handles token verification; AuthKit handles everything else. Read the setup guide.

!!Go deeper: OWASP ASI03: Identity and privilege abuse.!!

02. Prompt injection via tool results

Your MCP server's tools read external content. Emails, documents, database rows, web pages. Any of that content can contain instructions designed to hijack the agent's next action.

The model reads your tool's result the same way it reads your system prompt. There's no technical distinction between trusted instructions and untrusted data from the model's perspective. Both enter the context window as text. An attacker who can control what your tool returns can redirect the agent.

‍What goes wrong: if your tool fetches user emails and returns them raw, a malicious sender can embed agent instructions in an email body. The model processes them as legitimate commands.

Mitigation

Treat every tool result as untrusted data. Sanitize before returning. Use structured schemas that constrain what values are valid. For high-risk actions triggered by tool results, require explicit human approval before execution. Read how to defend against prompt injection attacks.

!!Go deeper: OWASP LLM01: Prompt injection.!!

03. Excessive agent permissions

When an agent connects to your MCP server, it typically gets access to all of your tools. All of them, all the time, for the entire session. That's a large blast radius.

Least privilege (the principle that any actor should have access to only what it needs for the current task) doesn't come automatically with MCP. You have to design for it explicitly. Most servers don't.

What goes wrong: an agent asked to summarize a document connects to your server and receives tool access that includes write and delete operations. A hallucination or injection can trigger them.

Mitigation

Scope tool access per session. The agent declares what it needs; your server grants only that subset. Session-scoped authorization, where access is time-limited to a specific task and automatically revoked when the session ends, is the right architectural pattern here.

Pipes is WorkOS's implementation of session-scoped authorization. A human approves a session; during it the agent can invoke permitted tools; when it expires, access ends. The agent cannot renew it.

!!Go deeper: OWASP ASI: Excessive agency.!!

04. Persistent token exposure

MCP servers often need to call third-party services on behalf of users: Slack, GitHub, Google Drive, Salesforce. The easiest approach is to store OAuth tokens and use them for the duration of the session. The agent holds them the whole time.

This works. It's also a significant exposure. The agent now holds long-lived, full-scope credentials for multiple services. If it's compromised, or behaves unexpectedly, those credentials can be misused across every connected service simultaneously.

What goes wrong: an agent holding tokens for GitHub, Slack, and Google Drive in memory is a single point of credential failure. A prompt injection that exfiltrates context can harvest all three at once.

Mitigation

Don't hand long-lived tokens to agents directly. Issue scoped, task-specific access. Revocation should be possible per service and per agent, without touching any other connection.

!!Go deeper: Best practices for secrets management.!!

05. Missing audit trail

When something goes wrong (and it will), you need to be able to answer: which agent called which tool, with what arguments, on whose behalf, and when. Without a structured audit log at the MCP layer, this is nearly impossible to reconstruct.

Most MCP server implementations log nothing by default. Application logs capture server errors. They don't capture a complete picture of agent behavior across a session.

What goes wrong: a user reports that data was modified. You have no way to know which agent session triggered the change, what tool it called, or whether it was acting on their behalf or not.

Mitigation

Log every tool call at the MCP layer with: agent identity, user identity, tool name, arguments (sanitized), response status, and timestamp. This becomes your audit trail, and the foundation for incident response, compliance, and user trust.

Putting it together

These five risks aren't independent. A server that fixes unauthenticated access but ignores audit logging is a server you can't investigate after an incident. A server with scoped permissions but persistent token exposure is still one injection away from a credential leak.

The mitigations compound. OAuth 2.1 gives you identity. Identity makes audit logs meaningful. Scoped sessions limit blast radius. Structured tool results reduce injection surface. Each one makes the others more effective.

If you're starting from scratch, do them in order: auth first, then scoped access, then audit logging, then input validation. If you have an existing server, start with auth. Everything else depends on knowing who's calling.

Secure your MCP server with WorkOS

WorkOS covers both entry points depending on where you are in your build.

If you need to add auth to an MCP server without a full platform migration, AuthKit acts as a drop-in OAuth 2.1 authorization server. Your MCP server handles two things (token verification and a metadata endpoint) and AuthKit handles everything else. Get started with AuthKit for MCP.

If you already have auth and want to add session-scoped access, Pipes handles time-limited authorization for agent sessions with human approval built in. Learn about Pipes.