Vaikora › Blog › Product Updates

Ship an MCP policy gate in under 15 minutes: what vaikora-guard-mcp does and how it works

Product Updates · Nov 12, 2026 · 4 min read

Five lines of Python and a YAML file are enough to put a policy check in front of every tool call an MCP-compatible AI agent makes. That is the practical starting point for vaikora-guard-mcp, the MIT-licensed proxy published on PyPI.

This post is for engineers who want to understand the mechanics before deploying, and for security teams evaluating whether open-source enforcement is viable for their environment.

What the proxy actually does

vaikora-guard-mcp sits inline between an AI agent and the tools it calls. When the agent issues a tool call, the proxy intercepts the full request, including the tool name, parameters, and calling context, and evaluates it against a loaded policy before anything executes.

The evaluation produces one of four decisions: allow, block, modify, or require-approval. Only after the proxy emits an allow decision does the tool call proceed. A block returns a rejection to the agent. A modify rewrites the call parameters before passing them on. A require-approval holds the call and routes it for human review.

This is enforcement before execution, not detection after the fact. If the policy says a tool call that touches a production database requires approval outside business hours, that call is held at the proxy. It does not execute speculatively and then get flagged in a log.

Every decision the proxy writes is signed into a SHA-256 hash-chained audit log, so the record is ordered and tamper-evident. That matters for compliance investigations where you need to show not just what happened, but that the log itself has not been altered.

Installing and running it

The package is on PyPI:

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

Point your MCP-compatible agent at the proxy endpoint instead of directly at the tool server. The proxy loads policy from a YAML configuration file. A minimal policy file names the tools in scope and specifies the default decision for calls that do not match any explicit rule.

A concrete example: an agent is connected to a filesystem tool that can read and write files. The policy file allows read calls to `/tmp` unconditionally, requires approval for any write call outside `/tmp`, and blocks calls to `/etc` entirely. The agent never sees the enforcement layer. It sends tool calls; some succeed immediately, some are held, some are rejected with an explanation the agent can relay to the user.

No SDK migration is required. The proxy works with the existing MCP interface.

Content inspection

The proxy ships six content inspection modules. These run on the tool call payload before the policy decision is finalized. Inspection modules can flag sensitive data patterns in parameters, such as credential strings, PII formats, or health data, and route those calls to a stricter policy path or block them outright.

This matters because tool call parameters are where data actually moves. An agent that constructs a database query with a patient record number in the WHERE clause is passing sensitive data at the point the call is made, not later. Inspection at that moment is the only place you can catch it before it goes somewhere it should not.

Connecting to the enterprise control plane

The open-source proxy is self-hosted and MIT-licensed. It runs entirely in your environment. For teams that need centralized policy management, audit log aggregation across multiple agents, SIEM integration, or compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001, the Vaikora Control Plane is the hosted commercial layer that connects to the same proxy.

The proxy is available on AWS Marketplace as a SaaS subscription, and the Vaikora-AzureSecurityCenter solution ships in the Azure Sentinel content hub. Decisions flow into Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub natively, with no custom connector work.

Throughput at the proxy level is over 10,000 actions per second, with P50 latency at 8ms and P99 at 45ms. For most agent workflows, the enforcement layer is not the bottleneck.

What to check before you deploy

Before pointing agents at the proxy in a production environment, review these:

• Policy coverage: every tool the agent can call should have an explicit rule. Calls that fall through to the default decision will follow whatever you set as the default, so an implicit allow-all default is a gap.
• Approval routing: if you use require-approval decisions, define who receives them and what the timeout behavior is. An agent waiting indefinitely for approval is a reliability issue.
• Log retention: the audit log is tamper-evident but you still need to decide where it goes and how long you keep it. For regulated environments, retention requirements vary by framework.
• Inspection module scope: not all six content inspection modules may apply to your toolset. Load only the ones relevant to the data types your agents handle to keep the decision path clean.

The source is on PyPI at `vaikora-guard-mcp`. Read the policy schema documentation before writing your first production policy file, specifically the precedence rules when multiple policy entries match a single tool call.

More from the Vaikora blog