The Model Context Protocol (MCP) gives agents a standardized way to discover and invoke tools, query databases, read and write files, and interact with external services. An MCP-enabled agent can query Postgres, create pull requests, send emails, and modify config files, all in a single session.
This creates a security problem that current guardrails were not designed to solve.
The new attack surface
Pre-MCP, the worst case was usually a bad response a human could catch. MCP-connected agents can:
- Read sensitive data: customer records, credentials, internal docs.
- Write to production: modify databases, push code, alter infrastructure.
- Trigger downstream actions: send emails, execute trades, provision resources.
- Chain operations: read from one system, transform, write to another without human review.
The hard question shifts from "what if the agent says something wrong?" to "what if the agent does something wrong, and we cannot prove what happened?"
Why current guardrails fail
Prompt injection detection and output filtering were designed for text-in, text-out. The OWASP Top 10 for LLM Applications identifies prompt injection as the top risk. In an MCP context, the critical moment is the tool invocation. By the time an output filter sees the result, the database was already queried. The pull request was already created.
Security must move to the action layer, where each tool call is evaluated and authorized before it executes.
Cryptographic action control
Treat every agent tool call as an action requiring explicit authorization:
- Agent decides to invoke a tool.
- Action is serialized (tool name, parameters, agent identity, timestamp).
- Policy evaluation: may this agent take this action? A blocking policy refuses the signature. Nothing waits for a person at this step. If a call needs human approval, your code checks the approval before it runs the tool.
- If permitted, the payload is signed with ML-DSA-65.
- Tool call executes once the signature comes back.
- Signed record stored as tamper-evident audit trail.
This gives you pre-execution policy enforcement, cryptographic identity binding, and tamper-evident audit trails, none of which prompt-level guardrails can provide.
In practice with MCP
Asqav does not sit in front of an MCP server by itself. If you run the agent in Claude Code, the asqav hook pretool command runs from the harness before each tool call. With the matcher * it fires for MCP tools too, and it needs no change to the MCP server or the tool. If you own the server code, you call sign() before the tool runs, which covers only the tools that make the call. Each path signs the calls it sees into a tamper-evident record. A call can still run unsigned, for example when the hook crashes and onFailure is not set. The Enforcement page says what each path can and cannot stop.
For regulated industries subject to EU AI Act or DORA, uncontrolled agent-to-tool interactions are a compliance liability. MCP makes agents dramatically more capable. That same capability makes action-level control essential.
Explore our documentation to see how Asqav signs and records MCP tool calls.
References
- Model Context Protocol specification, Model Context Protocol
- OWASP Top 10 for LLM Applications, OWASP GenAI Security Project
- FIPS 204: Module-Lattice-Based Digital Signature Standard, NIST
- Regulation (EU) 2024/1689 (EU AI Act), EUR-Lex
- Regulation (EU) 2022/2554 (DORA), EUR-Lex