Vaikora › Blog › Product Updates

Checking MCP tool calls against policy before they run: how vaikora-guard-mcp works under the hood

Product Updates · Nov 8, 2026 · 4 min read

Publishing an open-source MCP proxy means every AI agent team can now drop a policy enforcement layer between their agent and its tools in a single `pip install`, without writing a custom interceptor or modifying the LLM SDK they already use. That is what vaikora-guard-mcp does, and this post explains the mechanism.

Why the tool-call layer needs a gate

MCP gives agents a standard way to discover and invoke tools. The protocol itself is neutral. It routes a call. It does not evaluate whether that call should run, whether the parameters carry sensitive data, or whether the requesting agent has standing to invoke a particular tool at all.

The result is that most MCP deployments today push every tool call straight through to execution. If a prompt injection tricks an agent into calling a file-write tool, or if an agent composes a database query that includes PII it was never supposed to touch, the action runs before anything in the stack has a chance to object.

A gate at the tool-call layer stops that. The agent constructs the call. The gate inspects it. The gate either allows execution, blocks it, modifies the parameters, or routes the call for human approval. The tool only runs if the gate says yes.

What vaikora-guard-mcp actually installs

vaikora-guard-mcp is MIT licensed, written in Python, and published on PyPI as `vaikora-guard-mcp`. Self-hosted, no telemetry sent anywhere by default, no dependency on a commercial control plane to function.

Installing it is:

```
pip install vaikora-guard-mcp
```

It sits inline as an MCP-compatible proxy. The agent points at the proxy instead of pointing directly at the tool server. The proxy intercepts the tool call, runs it through the configured policy, and then either forwards it or rejects it. No SDK migration. No change to how the agent was built.

The proxy ships six content inspection modules. These cover things like sensitive data pattern matching in call parameters, tool-name allowlisting and blocklisting, and schema validation before a call reaches a tool that might execute irreversible actions.

Every decision is written to a SHA-256 hash-chained, tamper-evident audit log. That means you get an ordered, verifiable record of every tool call attempted, the policy result, and the reason. If an agent is later involved in an incident, the log tells you exactly what it tried to do and what the gate decided.

A concrete example

Say an agent is connected to three tools: a file reader, a web search, and a database writer. Your policy says the agent can read files and search the web, but database writes require human approval during business hours and are blocked entirely outside them.

Without a gate, that logic lives nowhere. With vaikora-guard-mcp in front of the tool server, you define the policy in configuration. When the agent calls the database writer at 11pm, the proxy intercepts the call, matches it against the policy, and returns a block decision before the tool executes. The attempt is logged with a timestamp, the matched rule, and a decision hash. The database is never touched.

The same mechanism applies if the agent constructs a file-read call with a path parameter that resolves outside an allowed directory, or if call parameters contain what looks like a Social Security Number. The content inspection modules catch those cases at the proxy layer.

Enforcement latency and throughput

A gate that adds seconds to every tool call is not viable in an agentic workflow. vaikora-guard-mcp enforces at P50 8ms and P99 45ms, and the enforcement layer handles over 10,000 actions per second. For most agent deployments, that overhead is not perceptible.

Detection accuracy in testing is 99.9%. The practical implication is that the proxy is not a source of false-positive noise that agents need to work around.

Connecting to the enterprise control plane

The open-source proxy works standalone. For teams that need centralized policy management across multiple agents, audit log aggregation, compliance presets (HIPAA, PCI-DSS, GDPR, SOC 2, ISO 27001), and SIEM integration, the proxy connects to the Vaikora Control Plane hosted by Data443. That connection is optional and does not change how the proxy enforces locally.

The control plane also pushes AI agent threat signals into Microsoft Sentinel, SentinelOne, and CrowdStrike Falcon, so a prompt injection attempt or a policy violation from an agent shows up in the same workflow your SOC already uses for other alert types.

What to check next

If you are running agents over MCP today, start by listing every tool those agents can call and asking whether anything in your current stack enforces policy on those calls before execution. If the answer is no, pull the package, review the configuration options in the README, and decide which tool categories need an allow, block, modify, or require-approval posture. The audit log alone, even before you configure any blocking rules, will show you what your agents are actually attempting.

More from the Vaikora blog