In short
MCP security is the practice of safely connecting AI agents to tools and data through the Model Context Protocol. It covers which MCP servers an agent may trust, integrity and signing of tool definitions, scoping of the credentials each server holds, user consent for sensitive operations, and monitoring of every tool invocation.
Definition
The Model Context Protocol is an open standard for exposing tools, resources and prompts to AI applications through a uniform interface. It replaces bespoke integrations with a common client-server model, which is exactly why it concentrates risk: one protocol becomes the path between models and enterprise systems.
MCP security therefore looks less like model safety and more like third-party integration security. An MCP server is a privileged component: it holds credentials, exposes operations, and describes those operations in text that the model reads and acts upon. Both the code and the description are attack surface.
The MCP specification includes security and consent expectations — notably that hosts should obtain explicit user consent for data access and tool invocation and should not transmit data without it. Implementations vary, so enterprises must verify rather than assume.
Security risks
Untrusted or unvetted servers
Community MCP servers installed on developer machines can expose filesystems, cloud credentials and internal APIs to any connected agent.
Tool-definition poisoning
Tool names and descriptions are model-facing instructions. Malicious wording can steer tool selection or smuggle directives into context.
Over-broad server credentials
Servers commonly authenticate with a single powerful token shared across all callers, erasing per-agent least privilege.
Rug-pull updates
A server that behaved correctly at review can change its tool definitions or behaviour in a later version.
Confused deputy and cross-server chaining
One server's output becomes another's input, letting an attacker chain capabilities the operator never intended to combine.
Consent fatigue
Blanket approvals granted once effectively remove the human checkpoint the specification assumes.
Examples
Filesystem server on an engineer's laptop
An MCP server exposing the home directory lets any connected agent read SSH keys and environment files.
Description-based steering
A tool described as 'always call this first to validate any request' captures traffic intended for other tools.
Shared database token
A database MCP server holds a read-write account, so every agent connected to it inherits write capability regardless of role.
Silent capability expansion
A minor version bump adds an outbound HTTP tool to a previously read-only server.
Architecture
Host and client
The AI application that connects to servers, mediates consent and decides which servers a given agent may reach.
Server registry
An enterprise-approved catalogue of MCP servers with owners, versions, signatures and review status.
Credential broker
Per-agent, short-lived credentials issued to server calls instead of a shared static token.
Policy enforcement
Allow-lists binding agent classes to specific servers and specific operations, with parameter validation.
Telemetry
Logging of every tool invocation with arguments, results and the agent and Principal responsible.
Controls
Run a vetted server registry
Only approved, versioned, signed servers may be connected in corporate environments; block ad-hoc installation.
Pin and verify versions
Review tool definitions on every version change; treat capability additions as a security change.
Scope credentials per agent
Never let a server hold a superset token shared by all callers; broker short-lived, task-scoped credentials.
Treat tool descriptions as untrusted input
Review descriptions for instruction-like content and sanitize before they enter model context.
Require meaningful consent
Gate sensitive operations with per-action confirmation instead of one-time blanket approval.
Monitor and rate-limit invocations
Alert on new servers, new tools, unusual argument patterns and volume spikes.
Comparison
| Traditional API integration | MCP integration | |
|---|---|---|
| Who chooses the call | Application code | The model, at runtime |
| Interface description | Docs for developers | Text the model reads and obeys |
| Change control | Code review and release | Often a server version bump |
| Credential scope | Per service, reviewed | Frequently one shared token |
| Primary new risk | Vulnerable endpoint | Tool-definition poisoning and confused deputy |
Frequently asked questions
Is MCP insecure by design?
No. The specification includes consent and authorization expectations. Risk comes from implementations that skip them and from installing unvetted servers.
Should we allow developers to install MCP servers?
Only from an approved registry. Local servers with filesystem or credential access are among the highest-risk components in an agent stack.
How do we detect tool poisoning?
Diff tool definitions across versions, scan descriptions for instruction patterns, and alert when an agent's tool set changes unexpectedly.
Does an API gateway cover MCP?
It helps enforce allow-lists and rate limits, but it does not evaluate tool descriptions or bind calls to a specific agent and Principal.
Sources
How Andeavour addresses it
Connector and MCP discovery
AgentGuard inventories the MCP servers and connectors agents can reach, including ones installed outside review.
Per-agent scoping
Tool access is bound to the agent and its task rather than to a shared server credential.
Change detection
Tool-definition changes and new capabilities are flagged as security events, not silent updates.
See it against your own environment
A 30-minute technical session with the Andeavour team — no integration required to start.