Vaikora › Blog › Product Updates

vaikora-guard-mcp is on PyPI: install it, write a policy, block a tool call before it runs

Product Updates · Nov 7, 2026 · 4 min read

Forty-five milliseconds at P99. That is the enforcement overhead Vaikora adds between an MCP agent and the tool it wants to call. For most workloads that number is invisible to users and meaningful to security teams, because it means every tool call gets a policy decision before execution without slowing the agent down in any practical sense.

vaikora-guard-mcp is the open-source piece of that enforcement layer. It is MIT-licensed, written in Python, published on PyPI, and self-hosted. You run it as a proxy between your MCP agent and whatever tools the agent can call. Every call passes through a policy check. The result is one of four decisions: allow, block, modify, or require-approval. Nothing executes until a decision comes back.

What the proxy actually does

The agent sends a tool call to the proxy instead of directly to the tool. The proxy inspects the call against your policy, writes the decision to a SHA-256 hash-chained audit log, and either passes the call through or stops it. The audit log entry is signed at write time, so the record of what was allowed or blocked cannot be altered after the fact.

That signing matters for compliance. When an auditor asks what a specific agent did with a specific tool on a specific date, you produce an ordered, tamper-evident record rather than reconstructed logs. Vaikora compliance presets ship for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001, so the policy structure is not something you build from scratch.

The proxy supports 12 LLM providers with no SDK migration. You point it at the provider you are already using.

A concrete scenario

Say you have an MCP agent that can call a file-write tool, a database-query tool, and an external HTTP tool. Without a policy gate, the agent decides at runtime which tools to call and with what arguments. If the agent is manipulated through prompt injection or simply misconfigured, it can exfiltrate data through the HTTP tool or write to paths it should never touch.

With vaikora-guard-mcp sitting inline, you write a policy that blocks any HTTP call to a domain outside an allowlist, blocks file writes outside a specified directory, and requires human approval before any database query that includes a DROP or DELETE statement. The agent cannot bypass those rules because the proxy sits between intent and execution. The agent never reaches the tool directly.

If a blocked call matches a high-severity rule, the decision is available to your SIEM. Vaikora integrates natively with Microsoft Sentinel, SentinelOne, CrowdStrike Falcon, and AWS Security Hub, so the signal from a blocked tool call lands in your existing detection workflow without custom plumbing.

Installing and running it

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

From there you configure your policy file, point your MCP agent at the proxy endpoint, and the proxy handles the rest. The self-hosted design means your tool call traffic does not leave your infrastructure. The commercial control plane, hosted by Data443, adds centralized policy management, team-level audit dashboards, and the integrations with external SIEMs and XDR platforms. The open-source proxy works independently if you want to stay fully on-premise.

What the open-source boundary is

The proxy enforces policy. The control plane manages policy at scale across multiple agents, teams, and environments. The MIT license on the proxy means you can inspect every line of enforcement logic, fork it, integrate it into internal tooling, or contribute to it. There are no telemetry callbacks home, no license checks at runtime.

If you are running a single agent in a controlled environment, the proxy plus a local policy file is enough to enforce before execution and produce an auditable record. If you are running agents across teams or cloud services, the control plane becomes the practical choice for visibility and governance.

What to check next

Pull the package, read the policy schema documentation in the repository, and write one rule that reflects an actual constraint you have today, something a team member would have to enforce manually without it. Run the proxy against that rule with a test agent and inspect the audit log entry it produces. That is the fastest way to judge whether the enforcement model fits your environment and whether the latency at your workload is acceptable.

The repository is public. Issues and pull requests are open.

More from the Vaikora blog