Every MCP tool call carries a payload that describes what an AI agent wants to do. By default, nothing checks that payload against a policy before execution starts. The tool runs, the action completes, and the log entry appears afterward. If the action was out of scope, the damage is already done before anyone sees it.
Vaikora Guard MCP is an open-source, MIT-licensed, self-hostable proxy that sits inline between an agent and the MCP tools it calls. Every call passes through a policy engine that returns an allow, block, modify, or require-approval decision before the action executes. The project is available now on GitHub under a permissive license, and it requires no SDK migration to adopt.
What the Proxy Actually Does
The proxy intercepts the JSON-RPC message that an MCP client sends toward a tool. Before forwarding that message, it evaluates the call against a policy definition you control. The evaluation is deterministic: given the same call and the same policy, the outcome is always the same. There is no probabilistic scoring involved.
The four possible outcomes matter in practice:
- Allow: the call forwards to the tool unchanged.
- Block: the call is rejected and a structured error is returned to the agent. The tool never receives the message.
- Modify: the proxy rewrites the payload (stripping a field, masking a value, replacing an argument) before forwarding.
- Require-approval: the call is held in queue until a human approves or rejects it through the control plane.
Enforcement latency is P50 8ms and P99 45ms, which is low enough that it does not meaningfully change the response time the end user perceives in most agentic workflows.
A Concrete Scenario
Say an AI agent has access to a customer database tool that accepts a `DELETE` operation. The agent is supposed to help support staff look up records, not remove them. Without a guardrail, a prompt injection or a poorly scoped task could result in the agent issuing a DELETE call. The tool executes it.
With Vaikora Guard MCP deployed, you write a policy rule that matches on tool name `customer-db` and operation `DELETE`. The rule action is `block`. The proxy intercepts the JSON-RPC call, matches the rule, returns an error to the agent, and writes the decision to the audit log. The database never receives the request.
The rule itself is a few lines of YAML. You do not modify the agent code, the tool server, or the LLM integration.
What Gets Logged
Every decision, whether allow, block, modify, or require-approval, is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry chains to the previous one, so any retrospective alteration of a record breaks the chain at that point. For compliance investigations, this means you can produce a verifiable record of every tool call an agent attempted and every decision the policy engine made.
Compliance presets ship for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. These are starting-point rule sets you can extend rather than build from scratch.
Integration with Security Operations Tooling
The enterprise control plane integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. That matters operationally: when the proxy blocks a call at severity High or Critical, SOC analysts see that event in the same queue as other incidents. There is no separate console to check.
Specifically, high-severity AI agent risk promotes into Azure Security Center and Microsoft Defender for Cloud as native incidents, with no custom engineering required. Threat indicators route into SentinelOne with severity mapped numerically (Critical=100, High=75, Medium=50, Low=25), which means automated response playbooks can act on them without additional translation.
The proxy supports 12 LLM providers. Switching from one provider to another, or running multiple providers in the same pipeline, does not require changes to how enforcement is configured.
Who Should Deploy This
The open-source version is a practical starting point for:
- Security engineers building internal AI tooling who want policy gates without writing a custom interceptor.
- Platform teams adopting MCP who need to demonstrate that tool calls are governed before they reach sensitive systems.
- Compliance leaders who need a tamper-evident record of what agents were permitted to do and when.
The self-hosted path means the proxy runs in your environment. Telemetry stays under your control. Policy definitions live in your version control system, so changes go through your normal review process.
What to Check Next
Start by reviewing the tool calls your agents are currently making. Most teams do not have a complete list. Pull the MCP server logs for the past week and look at which tools were called, which operations were used, and whether any of those combinations would fail a basic least-privilege check.
Then look at what your current controls can actually intercept. If the answer is "the log, after the fact," that is the gap Vaikora Guard MCP is designed to close.
The GitHub repository includes a quick-start configuration, example policy files, and documentation for connecting to the enterprise control plane when you need centralized management across multiple agent deployments.