Most teams building AI agents treat policy enforcement as a post-deployment problem. By the time a tool call fires and you inspect the log, the action has already happened. Vaikora Guard MCP is an MIT-licensed, self-hostable proxy that sits in the call path and makes a decision before execution, not after.
This post explains what the proxy does mechanically, how policy decisions work, and what you get from the open-source release versus the enterprise control plane.
What Sits in the Call Path
Vaikora Guard MCP runs as an MCP-compatible proxy between an AI agent and the tools or LLM providers it calls. Every tool call passes through the proxy. For each call, the proxy evaluates the request against a policy set and returns one of four decisions: allow, block, modify, or require-approval.
That decision fires before the underlying tool executes. If the decision is block, the tool call never reaches the target. If it is modify, the proxy rewrites the request parameters and forwards the sanitized version. Require-approval queues the call for a human to review before anything runs.
The proxy supports 12 LLM providers with no SDK migration. You point your existing agent at the proxy endpoint and the provider-specific routing stays internal to the proxy.
Enforcement latency is P50 8ms and P99 45ms. At 10,000-plus actions per second, the proxy is designed to stay out of the hot path even under load.
How Policy Decisions Work
Policy in Vaikora Guard MCP is declarative. You define rules that describe what tool calls are permitted, under what conditions, for which agents or agent roles. The proxy evaluates each incoming call against the rule set and produces a deterministic outcome.
A concrete example: an agent has access to a file-read tool and a send-email tool. Your policy says file reads are allowed only for paths under `/data/reports/`, and outbound email requires approval if the recipient domain is not on an allowlist. An agent that tries to read `/etc/passwd` gets a block decision. An agent that tries to send to an external address gets queued. The agent that reads `/data/reports/Q1.csv` and sends to `finance@yourcompany.com` gets two allow decisions and continues.
Compliance presets are included for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. These give you a starting rule set tuned to each framework’s data handling requirements, which you can extend or restrict.
The Audit Log
Every decision, regardless of outcome, is written to a SHA-256 hash-chained, tamper-evident audit log. The chain means you can verify after the fact that no record was modified or deleted. Each entry records the agent identity, the tool called, the parameters, the policy rule that fired, and the decision reached.
This matters for two reasons. First, you can reconstruct exactly what an agent did and why each action was allowed or blocked, which is necessary for incident investigation. Second, the log format is designed for compliance review: you can show an auditor a complete, unmodified decision trail without custom tooling.
Detection accuracy is 99.9% in testing. The proxy does not rely on heuristics or probabilistic scoring. Each decision is deterministic against the policy rule set, which is what makes the audit trail meaningful.
What the Open-Source Release Includes
The open-source package is MIT-licensed and self-hostable. You get the proxy itself, the policy engine, the audit log writer, and the MCP compatibility layer. There is no usage cap or telemetry sent upstream.
Out of the box you can run it locally, containerize it, or deploy it alongside your existing agent infrastructure. Configuration is file-based, so policy-as-code workflows and version control fit naturally.
The enterprise control plane adds a central policy management UI, multi-agent fleet visibility, native integrations with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub, and automated severity-mapped threat indicator pushes (Critical=100, High=75, Medium=50, Low=25 in SentinelOne). It also promotes high-severity AI agent risk into Azure Security Center and Microsoft Defender for Cloud as native incidents with no custom engineering. Vaikora Guard MCP is available on GitHub.
What to Check Before You Deploy
Before running the proxy in front of a production agent, work through three questions:
- What tools does each agent have access to, and which of those have write, send, or delete capability? Those are the calls that need explicit policy coverage first.
- Do your compliance requirements map to one of the five included presets, or do you need custom rules for specific data types or destinations?
- Who owns the approval queue for require-approval decisions? If no one is monitoring it, queued calls will stall and the agent will appear to hang.
Start with a read-only agent and a logging-only policy mode. Review the audit log for a few hours to understand the call patterns before switching decisions to enforce. That gives you a baseline before any block decisions affect live workflows.