Vaikora › Blog › Product Updates

One Python package, one pip install: enforcing policy on MCP tool calls before they execute

Product Updates · Nov 7, 2026 · 3 min read

The gap between an AI agent deciding to call a tool and that tool actually running is where policy enforcement belongs. Most setups have nothing there. The agent reasons, the tool executes, and any review happens afterward in a log file, if anyone checks.

Vaikora Guard MCP closes that gap. It sits inline between the agent and the tools it calls, checks every tool invocation against a deterministic policy, and returns allow, block, modify, or require-approval before the call executes. The package is MIT-licensed, written in Python, self-hostable, and published on PyPI as `vaikora-guard-mcp`.

What "inline" actually means here

A standard MCP setup has the agent send a tool call request directly to the MCP server. With Guard MCP in place, the request goes through the proxy first. The proxy evaluates the call against configured policy rules, writes a signed decision to the audit log, and either passes the call through or stops it. The underlying MCP server never sees a blocked call. The agent gets back a policy decision with a reason, not a silent failure.

This matters because the enforcement point is the right place to put the control. Detecting a bad tool call in a log after it ran means the action already happened. Blocking at the proxy means the state of your systems, files, APIs, and data stores does not change.

How the policy decision works

Policy evaluation in Vaikora is deterministic. Identical input always produces an identical decision. There is no model scoring the risk and returning a probability. A rule either matches or it does not, and the outcome is fixed.

A concrete example: you configure a rule that blocks any tool call that writes to a path outside `/data/output/` or that includes a parameter matching a pattern for credentials. An agent that constructs a file-write call targeting `/etc/cron.d/` hits the block rule. The proxy returns the decision, logs it with a SHA-256 hash-chained entry, and the cron directory is never touched.

The same logic applies to API calls, shell commands, database queries, or any other tool registered in your MCP configuration. The rule set is yours to define.

What ships in the package

• Six content inspection modules covering common risk categories: data exfiltration patterns, credential exposure, path traversal, prompt injection signals in tool parameters, PII patterns, and policy scope violations
• Adapters for the major hosted model APIs, so the proxy works regardless of which LLM the agent uses
• Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001, which give you a starting rule set without writing everything from scratch
• A tamper-evident audit log where every decision is signed into a SHA-256 hash chain, ordered and verifiable

The proxy handles over 10,000 actions per second with a P50 enforcement latency of 8ms and P99 of 45ms. At those numbers it does not introduce meaningful delay for any real agentic workflow.

Self-hosted versus the control plane

The open-source proxy runs entirely in your environment. You own the policy files, the audit logs, and the deployment. If you need centralized policy management across multiple agents or teams, real-time visibility into enforcement decisions, or the SIEM integrations (Microsoft Sentinel, CrowdStrike Falcon, SentinelOne, AWS Security Hub), that is what the Vaikora Control Plane adds. The two work together. The proxy enforces locally; the control plane manages at scale.

Data443 made the proxy MIT-licensed specifically so teams can audit the enforcement code, run it on-premise without a cloud dependency, and integrate it into existing pipelines without a contract. The commercial product sits on top, not in the way.

Getting started

Install from PyPI:

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

Point your MCP client at the proxy instead of directly at your MCP server, configure your first policy file, and run a test tool call. The audit log entry for that call is your first verifiable enforcement record.

From there, the practical next step is reviewing which tool categories your agents actually call and writing rules that match your real risk surface. Start with write operations and anything that touches external APIs or credentials. Those are the calls where a wrong decision causes state changes you cannot easily reverse.

More from the Vaikora blog