Twelve lines of configuration are enough to let an AI agent delete records, exfiltrate files, or call a billing API it was never supposed to touch. The gap is not the agent framework. It is the absence of a policy decision point between the agent’s intent and the tool’s execution.
Vaikora Guard MCP is an open-source, MIT-licensed proxy that sits inline between an AI agent and its MCP-connected tools. Every tool call passes through a policy engine before it runs. The result is either an allow, block, modify, or require-approval decision. If the decision is block, the tool never receives the call.
What the Proxy Actually Does
The agent sends a tool invocation request in the normal MCP format. Vaikora Guard MCP intercepts that request, evaluates it against the configured policy rules, and either forwards it, rewrites it, holds it for human approval, or drops it with a structured refusal. The agent sees a response either way. The tool only sees requests that passed.
Policies are defined declaratively. A rule can match on tool name, argument values, calling agent identity, session context, or combinations of those signals. A rule blocking any `file_write` call where the destination path falls outside an approved directory, for example, takes about three lines to express. The engine evaluates it before the filesystem ever sees the request.
Every decision is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry records the tool name, the arguments, the policy rule that fired, the decision, and a timestamp. That chain is what makes the log useful for compliance review: entries cannot be modified without breaking the hash sequence.
Why Open Source and Self-Hostable
Organizations running AI agents over sensitive data need to know exactly where policy decisions happen and what they touch. A SaaS-only enforcement layer introduces a trust boundary that many security teams cannot accept, particularly in regulated industries.
Vaikora Guard MCP is self-hostable. The proxy runs in your environment, on your network, with your policy files. No tool call payload leaves your perimeter to be evaluated. The open MIT license means the policy evaluation logic is readable and auditable by your own team.
This matters practically. An organization in a HIPAA-regulated context can inspect every line of code that touches a tool call involving patient data. They can confirm that PHI arguments are never logged in cleartext, that block decisions fire before the tool receives anything, and that the audit chain is intact. They are not taking a vendor’s word for it.
Connecting It to the Enterprise Control Plane
The open-source proxy handles inline enforcement. The enterprise control plane adds centralized policy management, team-wide audit visibility, compliance presets, and SIEM integration.
Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 are included. Each preset ships as a policy bundle: a set of rules calibrated to the data types, tool categories, and action patterns that regulators and auditors specifically examine. A team that has never written a tool-call policy rule can start with the relevant preset and refine from there.
On the integration side, Vaikora pushes high-severity AI agent risk into Microsoft Sentinel, Microsoft Defender for Cloud, SentinelOne, CrowdStrike Falcon, and AWS Security Hub natively. A blocked tool call that triggered a critical-severity rule becomes a threat intelligence indicator in SentinelOne at severity 100, or a native incident in Defender for Cloud, without any custom engineering. SOC analysts see AI agent enforcement events alongside endpoint and network signals in the same workflow they already use.
Enforcement latency at P50 is 8ms, and P99 is 45ms. At those numbers, adding a policy gate to every tool call does not change the user-facing behavior of the agent in any way that matters operationally.
A Concrete Scenario
A developer is building an internal AI assistant connected via MCP to a database query tool, a file reader, and an email tool. No policy exists yet, so the agent can call all three with any arguments.
They deploy Vaikora Guard MCP in front of the three tools. They apply a policy that allows database queries against read-only replicas, blocks queries against production tables by name, allows file reads inside a defined directory, blocks file reads above it, and routes any email send to require-approval before delivery. Total configuration: one YAML file, about 20 lines.
From that point forward, every action the agent takes against those tools goes through the policy engine. The audit log records each decision. Nothing reaches production databases, files outside scope, or email recipients until a human explicitly approves it.
What to Check Next
The open-source Vaikora Guard MCP proxy is available now on GitHub. Start by reviewing the policy schema documentation to understand what signal is available for rule matching: tool name, argument paths, agent identity, and session metadata are all first-class fields. If you are working in a regulated environment, pull the relevant compliance preset and read what rules it contains before enabling it. That review is itself an audit artifact worth keeping.
If you need central policy management, cross-team audit visibility, or the SIEM integrations, the Data443 Vaikora enterprise control plane connects to the same proxy without changing the enforcement architecture.