Dangerous tool sequences are multi-step Model Context Protocol abuse where each tools/call passes a name allowlist but the ordering produces exfiltration, fraud, or destruction—for example export then delete, or clone then post secrets. MCP Trail Guardian implements tool-sequence policies (prerequisites, export barriers, create→confirm flows) and a risk engine with optional HITL on violations, plus DLP and catalog controls covered elsewhere in this series.
Why sequences matter
An allowlist on tool names is not enough when the model chains several permitted calls into a bad outcome. Each RPC might be valid; the order and intent are not. That is the same class of problem as business email compromise or SOX-style separation-of-duties: “create” and “approve” are both normal—just not when the same actor does both in one minute without controls.
Guardian addresses this with tool-sequence policies (ordering rules) and a risk engine that can use rolling state to block, send to HITL, or allow—based on what you configured, not on reading the model’s hidden chain-of-thought.
Example 1: “Export then delete” in a CRM or docs system
Scenario: A sales copilot connects to an MCP server that can list accounts, export a CSV, and delete records (or archive) for housekeeping.
Realistic pattern:
list_opportunities→ 2.export_to_file(CSV) → 3.delete_recordsfor “duplicates”
Why it is dangerous: Steps 1–2 look like reporting. Step 3 is destructive. An injected prompt or a confused model can exfiltrate then remove evidence or customer data in the same session.
Gateway angle:
- Sequence policy: require a human-approved or separate “delete” tool class after exports, or deny
delete_*afterexport_*within a time window. - Risk / HITL: route destructive tools to approval by default.
Example 2: Finance-style “create payee → pay → notify”
Scenario: Integrations with bill pay or banking MCP tools (or internal payment APIs exposed as tools).
Pattern:
create_vendororadd_payee→ 2.schedule_payment→ 3.send_confirmation_email
Why it matters: Legitimate workflows exist—but so do fraud and invoice manipulation where a malicious document steers the model to add a new payee and pay in one go. Real-world AP fraud and CEO fraud follow this shape.
Gateway angle:
- Sequence rules: e.g. mandatory
verify_payeeor dual approval forschedule_paymentwhen the payee was just created. - Risk engine: elevated score after new vendor + payment in the same session → HITL or block.
Example 3: Repo and secrets: clone → search → exfil
Scenario: DevOps MCP with git, grep, and Slack or email tools.
Pattern:
clone_repo→ 2.search_filesfor.env/ keys → 3.post_messagewith a “summary” that contains secrets
Why it is realistic: This mirrors real supply-chain and secret-leak incidents—each tool might be allowed for developers; the chain is the attack.
Gateway angle:
- DLP on arguments and tool results (block/redact before return).
- Sequence / policy: optional barrier after
cloneorsearchbefore post to external channels; HITL forpost_messagewhen prior tools touched secrets-shaped paths.
Example 4: “Shadow IT” server with a different catalog
Scenario: An unapproved MCP server appears in the client config (see Shadow IT).
Pattern: First tools/list from a new server, then high-risk tools/call burst.
Gateway angle:
- Catalog allowlists and per-server policies so unknown tools do not run silently.
- Abuse limits and budgets on
tools/callto cap runaway agents.
What MCP Trail does not claim
It does not “understand” natural-language intent the way a human does, and it does not read the model’s internal reasoning. It enforces what you define: sequences, risk thresholds, DLP, HITL, and limits on the MCP JSON-RPC stream. That is still enough to stop many real-world chained abuses.