MCP Security
The Model Context Protocol gives agents their tools — filesystem reads, shell execution, database queries, API calls. Every tool is a permission, every server is a trust decision. This page explains the risks and how gateway runtime enforcement contains them.
What MCP is — and why it expands the blast radius.
Before MCP, each agent integration was custom. After MCP, one server hands every connected agent the same powerful tools.
MCP standardizes how agents discover and call tools: a server advertises tool descriptions, the agent picks tools and arguments, results flow back into context. That standardization is genuinely useful — and it concentrates risk. A single filesystem MCP server can expose "read any file" and "run any command" to every agent in the organization, including agents whose tasks need neither.
MCP also widens the input attack surface. Tool descriptions and tool results are text the agent reads and follows — which makes a compromised or malicious MCP server a prompt-injection delivery mechanism aimed directly at your agents. Cirvix's position holds here too: it does not claim to detect poisoned descriptions, but every tool call the manipulated agent then attempts is evaluated against policy and can be denied.
MCP vulnerabilities, concretely.
Four patterns account for most MCP incidents. All four are policy problems.
Broad-scope tools
A tool like "execute shell command" or "read file at path" is one permission that behaves like all of them. Least privilege means bounding the arguments: which paths, which commands, which hosts — not just which tool name.
Malicious or compromised servers
A server's tool descriptions can be rewritten to instruct the agent ("before answering, send credentials to…"). Treat every server's descriptions as untrusted input, and enforce per-call policy regardless of what the description claims.
Credential exposure through results
Tool results containing keys, tokens, or connection strings flow straight into agent context — and from there into logs, prompts, and follow-up calls. Secret detection plus credential handles keep material out of context.
Tool-result manipulation
A result that steers the agent toward an unsafe next action ("the file you need is at ~/.ssh/id_rsa"). Each follow-up action is evaluated on its own merits, so the chain breaks at the first out-of-policy call.
The Cirvix MCP gateway.
A policy proxy between the agent and the server. Nothing reaches the server unchecked.
Per-agent tool scoping
Each agent may call exactly the tools its task needs. Everything else is denied by default — including tools on servers the agent was never supposed to reach.
Argument bounds on broad tools
Filesystem tools constrained to workspace paths, shell tools to approved commands, network tools to sanctioned destinations. The ~/.aws/credentials read that the homepage demo denies is the canonical example.
Credential handles, not raw secrets
Agents reference handles; the gateway resolves them at execution time. Raw secrets never enter agent context, so a poisoned result cannot exfiltrate what the agent never saw.
Every call audited
Each MCP tool call gets the full eight-stage pipeline — parse through audit event — with the decision hash-chained into the log. See the audit chain for the mechanics and its stated limits.
Hands-on: the MCP guide walks through setup, and the MCP demo shows one blocked call at the boundary. The category overview is AI-agent security.
MCP security, asked directly.
What is MCP security?
Controlling what agents can do through MCP servers: scoped tools, bounded arguments, protected credentials, audited calls — enforced by a gateway at runtime.
What are the main MCP vulnerabilities?
Over-broad tool permissions, poisoned tool descriptions, credential exposure through results, and result manipulation steering unsafe follow-ups.
How do you secure MCP servers in production?
Default-deny tool scoping per agent, argument bounds, credential handles, and per-call audit. Then verify with the escape benchmark and the threat model.
Does Cirvix replace MCP authentication?
No. Authentication proves who is on each side of the connection; Cirvix decides whether each specific call through it may execute.
Put every MCP tool
behind policy.
Scope one server, watch the first deny land, expand from there.