AI Security

MCP connects AI to everything. Secure it before it does.

MCP servers bridge AI assistants to your tools and data, run with delegated permissions, and chain tool calls — so a single gap can be amplified into a real breach. Learn the threats, apply a minimum security bar, and self-assess your own implementation.

The threat landscape

A new attack surface, not just old API bugs

MCP servers carry traditional API risks and AI-specific ones. These are the patterns that show up most.

Tool poisoning

A crafted tool description hides instructions that trick the model into unintended actions or exfiltration — and descriptions are fed to the model automatically.

Rug pulls

A previously-approved tool is silently swapped or modified at runtime, bypassing the review that first cleared it.

Credential leakage

Config files store tokens in plaintext; a server (or LLM) with secret access can leak keys and be impersonated.

Excessive permissions

Over-privileged tools and broad scopes turn one compromised tool into many compromised systems.

Insufficient isolation

Shared state or a single service identity across users leaks context and enables impersonation and cross-tenant access.

Consent fatigue

Benign approval prompts flood the user, then a dangerous request slips past a desensitized human — MFA-fatigue for agents.

The security minimum bar

Six domains every MCP server should clear

Adapted from the OWASP GenAI “MCP Security Minimum Bar” and the SlowMist checklist — these are the domains the checker scores you against.

1

Strong identity, authentication & policy

Authentication in MCP is optional by default, and many examples ship over plain HTTP. Treat auth as mandatory and enforce policy centrally.

2

Strict isolation & lifecycle control

MCP servers manage many concurrent sessions and often share identity or compute. Without hard separation you get cross-tenant leakage and impersonation.

3

Trusted, controlled tooling

Tool descriptions are fed to the model automatically, and tools can be swapped after approval ('rug pulls'). Treat tool definitions as a trust boundary.

4

Schema-driven validation & prompt-injection controls

Treat every message — from the model and from tools — as untrusted. Funnel intent through schemas and gate high-risk actions.

5

Secrets & hardened deployment

Configuration files often store tokens in plaintext, and servers run with too much privilege. Lock down secrets and the runtime.

6

Supply chain, monitoring & governance

Malicious servers get uploaded to unofficial repositories, and threats surface at runtime. Verify what you install and watch what it does.