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: does this agent have permission? Does this query require human approval?
- If permitted, the payload is signed with ML-DSA-65.
- Tool call executes.
- 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 sits between the agent and the MCP tool execution layer. Each tool call is individually evaluated against policy, signed if permitted, and audited. The agent developer does not need to modify MCP servers or tool implementations.
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 provides cryptographic action control for every MCP tool call.