MCP Security Risks: What Enterprises Must Control

Model Context Protocol made a hard problem easy: an agent can discover and use a system's capabilities without bespoke integration. Ease is also the risk. Servers get built quickly, credentials get borrowed, third-party servers get installed from a repository, and six months later the security team cannot say which agents can reach the ERP or what would happen if a document contained the wrong sentence. This guide sets out the risks that recur in FISTA's reviews of MCP deployments and the control for each. It builds on the architecture in the Model Context Protocol for the enterprise whitepaper and the threat model in AI agent security risks.

Why does the protocol not solve security?

MCP defines how a host discovers a server's tools, resources, and prompts and how calls and results travel between them. It does not decide which agents may reach which servers, which tools each agent may use, what a tool may do inside the system it wraps, or how results should be treated by the model. Those decisions are yours. The protocol's contribution is that every capability passes through one inspectable path, which makes the decisions enforceable if you put an enforcement point on that path.

What are the recurring risks?

Risk	How it happens	Consequence
Over-privileged servers	Built on admin or broad service accounts for convenience	Any steered agent can read or change anything the server can
Injected instructions in tool results	Documents, tickets, pages, or rows contain text crafted to redirect the agent	Data exfiltration or unauthorized actions through the agent
Unvetted third-party servers	Installed from public repositories without review	Malicious or vulnerable code running with your credentials
Credential exposure	Secrets in configuration files, prompts, or logs	Long-lived credentials leaked through injection or log access
No gateway	Agents connect to servers directly	No consistent identity, permissions, rate limits, or logging
Vague tools	update_record with free-form payloads	Cannot be permissioned or gated; model guesses
Unregistered servers	Teams publish servers outside the platform	Unknown attack surface; no owner
Version drift	Unpinned protocol libraries	Silent behavior changes; unpatched vulnerabilities

What are the controls?

Agent identity and delegated context

Every agent carries its own identity plus the identity of the user it serves, and the effective permission is the intersection of the two. Servers never run under a human's session or a shared account. The model is described in non-human identities for AI agents.

Per-tool least privilege

Each tool gets the narrowest principal that can perform it: read-only for reads, scoped writers for reversible writes, and consequential actions as separate tools that most agents never receive. Design guidance is in how to design tool permissions for AI agents.

Approval gates

Consequential writes pause for a human, enforced at the gateway so the control applies regardless of which host initiated the call. See human-in-the-loop AI explained.

Untrusted-content handling

Tool results are data. Servers label content that originates outside the enterprise; hosts keep it out of the instruction position; and when the agent's plan changes after reading external content, high-risk actions require confirmation. The threat is explained in what is indirect prompt injection.

Credential brokering

Servers obtain short-lived, scoped credentials from a broker at call time; nothing long-lived lives in configuration or prompts. See secrets management for AI agents.

Server vetting and sandboxing

Third-party servers go through review or come from trusted publishers, run with pinned versions in sandboxes with egress limits, and are registered with explicit permissions. Treat them as supply chain; see AI supply chain security.

Gateway enforcement and logging

A gateway authenticates agents, authorizes each tool call, applies rate limits, and logs the agent identity, delegated user, tool, parameters, and outcome with a trace identifier. Building one is covered in how to build an MCP gateway.

Registry and lifecycle

Every server is registered with an owner, capabilities, classifications, and versions; periodic scans confirm no server exists outside the registry; retirement revokes identities and credentials.

How should a deployment be reviewed?

Question	Evidence expected
Which agents can reach which servers and tools?	Registry and gateway policy
What principal does each tool use?	Credential configuration per tool
Which tools are consequential, and are they gated?	Classification and gate configuration
How are tool results treated?	Host configuration; injection test results
Which third-party servers run, and how were they vetted?	Vetting records, pinned versions, sandbox configuration
Where are secrets?	Broker configuration; absence from files and prompts
What is logged?	Sample logs with agent, user, tool, and trace
What happens on incident?	Kill switch test; see AI agent kill switch design

What are the failure modes we see most?

1. Admin credentials that were "temporary."
2. No gateway because the first deployment had one server.
3. Public servers installed by developers outside any review.
4. Free-form write tools that cannot be gated.
5. Logs without redaction that become a second data store to protect.

How does FISTA Solutions help?

FISTA Solutions is an official Anthropic partner and reviews and builds MCP deployments as part of its AI enablement practice, with the gateway, identity, permission, and vetting controls above designed in from the start. Every AI agent FISTA delivers uses that layer, and our forward deployed engineers work with your security team so the controls fit your platform. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.

To review an existing deployment, message FISTA on WhatsApp, or read the MCP adoption checklist for the pre-launch list.