Publishing source code changes what you can actually verify. When Vaikora Guard MCP shipped as an MIT-licensed Python package on PyPI, it gave security engineers and AI platform teams a way to read the enforcement logic, run it on their own infrastructure, and confirm that every tool call gets checked before it executes, not logged after the fact.
This post covers what the package does, how it sits in a typical agent workflow, and what you get from the open-source version versus the enterprise control plane.
What Problem It Solves
An AI agent calling tools without a policy gate can read files it should not, call external APIs without approval, or write to databases outside the scope of the task it was given. The Model Context Protocol makes it straightforward to expose tools to agents, but MCP itself does not enforce what an agent is allowed to call or what parameters it is allowed to pass.
Vaikora Guard MCP sits inline between the agent and whatever MCP server it is targeting. Before each tool call executes, the proxy evaluates the request against a configured policy and returns one of four decisions: allow, block, modify, or require-approval. The agent does not reach the tool until that decision comes back.
How the Proxy Is Structured
The package is written in Python and published as `vaikora-guard-mcp` on PyPI. Installation is a single pip command. You configure it with a policy file and point your agent at the proxy endpoint rather than directly at the MCP server.
The proxy ships six content inspection modules. These cover the common enforcement cases:
- Tool name allow/deny lists
- Parameter value inspection against defined patterns
- Sensitivity classification of data in transit
- Prompt injection detection in incoming arguments
- Rate and quota controls per agent identity
- Require-approval routing for defined action classes
The proxy is self-hosted. Your tool call traffic does not leave your own network on the way to a third-party enforcement service.
What a Blocked Call Looks Like
Say an agent is running a customer support automation workflow. The MCP server it calls has a `send_email` tool. Policy is configured to block any `send_email` call where the `to` parameter matches a domain outside the approved list.
The agent constructs the call and sends it to the proxy. The proxy evaluates the `to` parameter against the policy rule. The domain is not on the approved list. The proxy returns a block decision with a reason string. The agent receives the rejection before the underlying MCP server sees the request at all. The email never sends.
Every decision in that sequence, including the block, is written to a SHA-256 hash-chained audit log. The log entry is tamper-evident. If someone asks later whether that call was blocked and why, the record is there with a verifiable chain.
Enforcement Latency
The proxy adds latency to each tool call. The overhead at P50 is 8ms and at P99 is 45ms. For most agent workflows, that is acceptable. For latency-critical paths, the figure is worth checking against your own requirements before deploying inline.
What the Enterprise Control Plane Adds
The open-source proxy handles enforcement locally. What it does not provide out of the box is centralized policy management across multiple agents, dashboards over audit data, compliance presets, or integration with your existing security stack.
The Vaikora Control Plane, hosted by Data443, adds those layers. Compliance presets ship for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. Integrations push enforcement signals into Microsoft Sentinel, Microsoft Defender for Cloud, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity decisions surface as native incidents in those platforms without custom engineering.
The proxy and the control plane connect through the same enforcement path. The open-source version is not a stripped-down demo. It runs the same inspection modules and writes to the same audit log format. The control plane adds governance at scale.
What to Check Before You Deploy
Before you put the proxy inline in a production agent workflow, verify three things.
- Policy coverage: Map the tools your agent can call and define an explicit allow or block rule for each one. An implicit allow on unconfigured tools defeats the point.
- Audit log retention: Decide where the hash-chained log goes and how long you keep it. If you are targeting SOC 2 or similar compliance, that retention period is a control requirement, not an option.
- Approval routing: For any tool class you mark as require-approval, you need a defined path for who receives the approval request and on what timeline. Undefined approval flows stall agents in production.
The source code is on PyPI as `vaikora-guard-mcp`. Start by reading the policy file schema and the inspection module configuration before writing your first rule. That is where the actual behavior lives.