Vaikora › Blog › Product Updates

Building policy enforcement into an MCP server: what vaikora-guard-mcp does and how to run it

Product Updates · Nov 9, 2026 · 4 min read

Every tool call an AI agent makes is a decision point. If nothing checks that decision before execution, the agent acts on whatever the LLM returns, whether that is a file read, a database query, or an outbound API call. The check has to happen before the call, not after.

That is the problem vaikora-guard-mcp solves. It is an open-source, MIT-licensed MCP-compatible proxy written in Python, published on PyPI as `vaikora-guard-mcp`, and self-hostable with no dependency on a commercial control plane unless you want one.

What the proxy actually does

vaikora-guard-mcp sits between your MCP client (the AI agent or orchestrator) and the tools it calls. For every tool invocation, the proxy evaluates the action against a policy and returns one of four decisions before execution: allow, block, modify, or require-approval.

The decision is deterministic. The same input, evaluated against the same policy, produces the same output every time. That matters for auditability: when an incident happens, you can replay the exact inputs and show exactly what policy fired and why.

Every decision is written into a SHA-256 hash-chained audit log. Each entry is signed into the chain, so you can verify that no record was altered or deleted after the fact. That property is what makes the log useful in a compliance investigation rather than just an operational one.

How to deploy it

Installation is a single pip command:

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

Configuration is a policy file that defines which tools are allowed, which are blocked outright, which require a human approval step, and which inputs should be modified before the tool sees them. A minimal example blocks any tool call that attempts to write to a path outside a defined directory and requires approval for any call that sends data to an external endpoint.

The proxy exposes the standard MCP interface, so any MCP-compatible client connects to it without SDK changes. The agent does not know whether it is talking to the proxy or directly to a tool server. That transparency is intentional: you drop enforcement into an existing agent architecture without rewriting the agent.

Vaikora supports 12 LLM providers with no SDK migration, and the enforcement layer processes actions at P50 8ms and P99 45ms with throughput above 10,000 actions per second, so the proxy does not become the bottleneck in a production workflow.

Where policy actually fires

A concrete scenario: an agent is orchestrating a data pipeline. It calls a tool to read a configuration file, then calls a second tool to write output to an S3 bucket. Without a policy layer, both calls execute as long as the agent has the credentials to make them.

With vaikora-guard-mcp in front, the first call is evaluated against a policy that permits file reads from a specific path pattern. It passes. The second call is evaluated against a policy that flags any write to an S3 bucket outside an approved prefix. The proxy blocks the write before the tool executes and logs the decision with the full call parameters, the policy rule that fired, and a timestamp signed into the hash chain.

The agent receives a blocked response. It does not write to S3. No human reviewed it in real time, but a complete, tamper-evident record exists for whoever investigates later.

Connecting to a control plane

vaikora-guard-mcp is self-contained. You can define policies in local configuration files and run entirely on your own infrastructure. If your team needs centralized policy management, audit dashboards, or the compliance presets that ship for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001, the Vaikora Control Plane (hosted by Data443) connects to the same proxy without changing how the proxy is deployed.

The open-source package also integrates with Microsoft Sentinel, SentinelOne, CrowdStrike Falcon, and AWS Security Hub, so agent-level policy decisions can feed directly into your existing security operations workflow rather than sitting in a separate silo.

What to check before you deploy

Before you route agent traffic through any policy proxy, confirm three things:

• The policy file covers every tool the agent can call, including tools added by third-party MCP servers. Gaps in policy coverage are gaps in enforcement.
• The audit log destination is write-protected from the agent process itself. An agent that can modify its own audit log defeats the tamper-evidence property.
• Your approval workflow for require-approval decisions has a defined timeout and fallback. An agent blocked waiting for a human who never responds is a denial-of-service condition in an automated pipeline.

The source is on PyPI and available to inspect. Start with the policy file, map it to your actual tool surface, and treat any tool call that is not explicitly covered as blocked by default.

More from the Vaikora blog