MCP Security Risks: How to Review Tools Before Agents Use Them
MCP makes tools discoverable by agents; the security problem is deciding which tools, scopes, transports, and tool chains are safe enough for the task.
Paste a manifest into the public demo or bring a scoped workflow to the private beta.
MCP turns tool access into a production boundary
The Model Context Protocol makes it easier for AI applications to connect to tools, data sources, and workflows. That is exactly why security teams need a review layer. Once an agent can discover a tool and invoke it, the tool catalog becomes part of the production attack surface.
A simple MCP server can be harmless when it exposes read-only documentation search. The same pattern becomes high risk when it exposes file writes, database updates, shell execution, email sending, cloud IAM mutation, payment execution, or arbitrary HTTP requests built from model-controlled input.
MCP security is not about distrusting the protocol. It is about treating tool use as a real authorization event. The agent is no longer only reading context. It may be crossing from language into action.
The manifest is only the start
A manifest or tool declaration tells you names, descriptions, schemas, transports, and declared capabilities. That is useful, but it is not enough. Security review has to ask whether the description matches behavior, whether the schema limits dangerous input, and whether the declared capability is too broad for the task.
Names can be misleading. A tool called summarize_ticket might also send email. A tool called fetch_url might let an agent post arbitrary payloads to attacker-controlled endpoints. A tool called run_script might quietly expose shell execution. Preflight should classify capability, not trust labels.
Hekate Torch reviews the visible manifest and then reasons about verbs, arguments, schemas, auth, approval boundaries, and chain risk. The output is not a vibe check. It is a concrete safe-call policy: allowed tools, blocked tools, and actions that require human approval.
Dangerous verbs and dangerous combinations
The first pass is dangerous verb detection. Delete, transfer, send, deploy, execute, write, update, upload, post, invite, share, export, approve, mint, redeem, and sign all deserve scrutiny. Some should be blocked outright. Others should require approval when used with sensitive data or external targets.
The second pass is tool-chain detection. A single database read might be legitimate. A single Slack post might be legitimate. The combination postgres.query:customer_table followed by slack.post_message:public_channel can become customer data exfiltration.
Other risky chains include filesystem.read:secrets to http.post:external, browser_fetch to shell_exec, github_read to github_write, wallet_balance to x402_pay, crm.read to gmail.send, and sage_quote to signer_call. MCP review has to evaluate paths, not just individual tools.
Prompt injection through tool results
Prompt injection often enters through content the agent did not create: a webpage, README, support ticket, email, API response, transcript, or document retrieved by a tool. The malicious instruction may say to ignore policy, reveal secrets, call another tool, approve a payment, or send data to a URL.
A secure MCP setup assumes retrieved content is hostile until proven otherwise. Tool results should be treated as data, not instructions. The agent can summarize or extract facts, but policy-sensitive actions should be gated outside the LLM path.
Preflight can simulate common attacks before production: malicious README, hostile webpage, poisoned API response, hidden instruction in a document, support-ticket exfiltration request, and a tool result that asks for a payment. The test is simple: did the agent call a dangerous tool, leak data, bypass policy, or request broader permissions?
Authentication and approval boundaries
Many MCP risks are actually auth risks. A read-only task should not request repo write, secrets read, admin, billing, deploy, or user-management scopes. A support summarizer should not get access to send external email. A research agent should not get arbitrary file write.
Approval boundaries should be explicit. If a tool can send a message outside the organization, mutate a production resource, spend money, access secrets, or trigger an irreversible workflow, the tool should declare when human approval is required. If that boundary is missing, preflight should warn or block.
The least risky setup is narrow scopes, task-specific tools, allowlisted destinations, input validation, output schemas, audit logs, and a policy engine that can deny actions before the tool call is executed.
The Hekate MCP review pattern
Hekate's MCP preflight pattern has five steps. Parse the manifest. Classify tool capabilities. Build a permission and data-flow graph. Detect dangerous chains. Compile the result into a safe-call policy and signed receipt.
The result is machine-readable and practical. An agent does not need a long essay. It needs to know that github.list_issues and github.get_issue are allowed, github.create_comment requires approval, github.delete_repo is blocked, and no tool may send customer data to an external webhook.
For human teams, the same scan produces findings, evidence, remediation, and a receipt. The developer can fix the manifest, narrow scopes, add approval boundaries, or split one dangerous tool into safer task-specific tools.
What to block immediately
Block arbitrary shell execution from model-controlled input. Block unbounded filesystem write. Block direct signer access from the LLM path. Block secret read unless the task explicitly requires it and the tool output cannot exfiltrate. Block arbitrary URL post when sensitive data is in scope.
Block payment execution above policy thresholds. Block cloud IAM mutation without explicit human approval. Block database write in production unless the agent has a narrow schema, idempotency, and rollback plan. Block public-message posting when the agent can read customer, health, financial, credential, or private-key data.
Those defaults may sound strict, but they are how agent systems survive contact with production. MCP gives agents tools. Hekate Gate decides which tools are safe enough to cross the threshold.
Hekate next steps
Test a manifest with dangerous tools, external sends, and payment-capable endpoints.
Read the MCP glossaryAgent-native tool exposure and why it changes the security boundary.
Compare Hekate Gate vs MCP gatewayHow security preflight differs from tool routing and gateway mediation.
View API docsMachine-readable Hekate surfaces for agents and operators.
FAQ
The biggest MCP security risk is unsafe tool access: a model-controlled agent can combine read, write, external-send, shell, signer, or payment tools in ways that create production impact.
No. Read-only and tightly scoped tools can be allowed automatically. Human approval should be required for irreversible actions, external sends, payments, secrets, and production mutations.
Hekate parses the manifest, classifies capabilities, builds a permission and data-flow graph, detects dangerous chains, and returns a safe-call policy with receipt evidence.