Five Security Must-Haves for MCP Servers

In this article, we’ll explain the role of MCP servers before getting into the concrete security threats they introduce, and how to defend against them. Read on for real-world exploit examples from Notion, Anthropic, and GitHub, and a five-point, actionable security checklist you can use to harden any MCP deployment.

The Role of MCP and MCP Servers

Model Context Protocol (MCP) is an open standard that connects AI agents with external tools, data, and services. It defines a common interface so agents can discover and invoke tools (functions), access resources (data), or use prompts (predefined instructions) in a consistent way.

An MCP server exposes these capabilities. It sits between the agent and backend systems, translating requests into real actions through APIs or data queries. For example, a Gmail MCP server might offer a “read email” and “send email” tool, handling authentication and execution behind the scenes.

In short, MCP standardizes how agents interact with the outside world. The server acts as the secure adapter that grants access to services, manages credentials and permissions, and enforces boundaries.

Security Risks of MCP

Like any system that bridges AI with external actions, MCP introduces serious security concerns. The main risks center on credential theft, server compromise, prompt injection, and overly-broad permissions.

• Credential Theft & Account Takeover: MCP servers store OAuth tokens for connected services. If stolen, attackers can impersonate users, accessing or sending data as them. These token-based attacks often bypass login alerts, making detection difficult.
  
  
• MCP Server Compromise: A compromised server provides attackers all stored tokens and permissions. This enables actions across multiple services such as emails and calendars, databases, and CRMs systems without further breaches. Cached tokens may remain valid even after password resets, extending the threat.
  
  
• Prompt Injection (Tool Misuse): Malicious instructions hidden in input data or tool metadata can drive agents to misuse MCP tools. For example, a crafted document could trigger unauthorized email forwarding or dats exfiltration without visible malicious code.
  
  
• Overly-Broad Permissions: MCP servers often request expansive scopes (“all emails,” “all files”) when fine-grained access is needed. This violates the principle of least privilege. The result is an aggregate data silo enabling a server to pull together information from many sources. An attacker who hijacks an overly-permissioned MCP server could exfiltrate sensitive PII from HR systems, or leak confidential IP from engineering repositories, exposing the business to regulatory penalties, lawsuits, and competitive loss. Even legitimate use could raise privacy concerns if the MCP server operator itself isn’t carefully segregating or limiting what the AI can access. Fine-grained permissions are critical; otherwise, MCP can inadvertently concentrate sensitive data in one place, ripe for exfiltration or abuse.

These risks highlight MCP’s double edge: by centralizing access it empowers agents, but also increases attack surface. Without strict controls, an MCP server can become an attacker’s most efficient entry point.

Real-World Exploits Involving MCP Servers

While MCP is relatively new, security teams have already demonstrated exploits that illustrate these risks in action. 

Notion 3.0 lets AI agents perform multi-step workflows via MCP-style integrations, including internal documents, databases, and external connectors. Researchers showed how a malicious PDF embedded with a prompt caused a Notion agent to exfiltrate private client data using the “web search” tool. This exploit abused excessive trust in tool input schemas. The potential exploit shows how unchecked tool access plus prompt injection can expose sensitive corporate IP and PII without explicit user approval.

Anthropic, originator of MCP, shipped MCP Inspector with trusting defaults. Oligo Security found a critical RCE (CVE-2025-49596) that let a malicious webpage call Inspector endpoints and run arbitrary commands on a developer workstation. Attackers could obtain host control, steal credentials and source code, install backdoors, and move laterally. The root cause was unauthenticated default endpoints and overly broad privileges in developer tooling. Anthropic patched the issue, but the incident shows how one permissive component can trigger enterprise-wide compromise.

Back in May, researchers disclosed a prompt-injection flaw in GitHub’s MCP integration that let attackers trick agents into reading private repos and publishing that data in a public pull request. The exploit depended on agents holding OAuth tokens with coarse-grained permissions and processing untrusted issue text; no server breach was required. The incident demonstrates overly-permissive credentials plus automated agent behavior enable zero-click exfiltration of PII and proprietary code.

These examples underscore the reality of MCP-related threats: prompt injection and tool compromise are not theoretical. They have been proven with working exploits. Engineering and Security leaders planning on shipping  MCP servers must study these cases to anticipate how an attacker might attempt to abuse their own AI integrations.

5 Key Security Protections for MCP Servers

To safely deploy an MCP server for your product, it’s critical to implement multiple layers of security controls. Below are essential protections that software engineering and security teams should put in place:

1. Strong Authentication for Clients and Users

Require cryptographic identity for every connection. Use mTLS for service-to-service, short-lived OAuth tokens for agents, and SSO + MFA for humans. Treat developer tools like production: no run-by-default. Enforce token revocation and automated rotation on suspected compromise. Outcome: blocks unauthorized connectors, makes misuse traceable, and prevents silent impersonation.

2. Fine-Grained Authorization & Least Privilege

Some teams assume they can “stuff” permissions into authentication (e.g., OAuth tokens). Don’t do this. OAuth-style tokens are insufficient: they’re not granular enough (route-level scopes vs. resource- or record-level rules) and don’t model complex policies like hierarchies or contextual attributes. Revocation and time-bounding are imperfect in practice. Finally, tokens provide limited audit context, so logging and forensics are weak. Use OAuth for identity and dedicated authorization solutions like Oso for permissioning. Use the authorization solution to enforce fine-grained permissions for LLM and agentic AI access. This limits the damage of any compromise; even if an attacker hijacks the AI, they can’t go beyond what that tool was designed to do

3. Tool Registry & Manifest Integrity

Operate a default-deny registry. Require signed manifests, version pinning, provenance checks, and mandatory change approvals for metadata updates. Block silent post-install edits and require staged rollouts with reconsent for risky changes. Add automated supply-chain scanning for known-vulnerable dependencies. Outcome: prevents rogue or poisoned tools and reduces attack surface from third-party providers.

4. Operational Guardrails & Runtime Isolation

Treat high-risk actions as exceptions: require human approval, policy gates, rate/amount caps, and contextual checks (time, recipient, amount). Execute untrusted tasks in sandboxes/containers with syscall filtering, strict mounts, and egress controls. Monitor for anomalous patterns and automatically isolate suspicious sessions. Outcome: stops zero-click exfil and contains active abuse before lateral movement.

5. Observability, Auditing & Governance

Log every tool listing, invocation, and payload to immutable storage; feed logs to SIEM with tuned alerts. Monitor model outputs for risky disclosures and keep tamper-evident forensic trails. Couple technical telemetry with governance: pre-approval for integrations, threat models, scheduled red teams, and documented escalation/playbooks. Outcome: faster detection, cleaner investigations, and accountable risk decisions.

What’s Next?

MCP unlocks agent capabilities but centralizes attack surface: a single permissive component can expose PII, IP, and your business to regulatory and operational risk. 

Treat MCP servers as critical infrastructure. Apply strong authentication, fine-grained authorization, signed tool manifests, human-in-the-loop guardrails, sandboxed runtime controls, and tamper-evident observability. 

If you’re shipping an MCP server, validate, don’t guess. For fine-grained authorization, talk to Oso to run a focused risk assessment, threat model, and roadmap tailored to your product and deployment.