The proxy sits between your AI agent and every tool it calls. Each call gets a policy decision before execution. That decision is logged. Those are the facts. What matters operationally is what you can actually inspect, configure, and extend when you run it yourself.
This post covers what the open-source release includes, how policy enforcement works at the call level, and what you need to think about before putting it in front of production workloads.
What the Open-Source Release Actually Contains
Vaikora Guard MCP ships under the MIT license. That means you can read every line that processes an agent tool call, fork it, modify it, and deploy it without a license fee or vendor approval. The "MCP-compatible proxy" label means it speaks the Model Context Protocol, so any MCP-compliant agent connects to it without an SDK migration. Vaikora supports 12 LLM providers in this configuration.
What you get in the repo:
- The inline proxy that intercepts tool calls before they reach the target tool
- The policy evaluation engine that produces one of four decisions: allow, block, modify, or require-approval
- The SHA-256 hash-chained audit log writer that records every decision in tamper-evident form
- Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001
What the open-source layer does not include is the enterprise control plane, which handles multi-agent fleet management, centralized policy authoring, and the SIEM integrations into Microsoft Sentinel, CrowdStrike Falcon, SentinelOne, and AWS Security Hub. That lives in the commercial tier.
How a Tool Call Actually Moves Through the Proxy
Take a concrete scenario. An AI agent is handling a support workflow and calls a tool to retrieve a customer record. The call hits the proxy before it reaches the data layer.
The proxy evaluates the call against the active policy set. At P50, that evaluation completes in 8 milliseconds. At P99, it completes in 45 milliseconds. The decision returned is one of four:
- Allow: the call proceeds unchanged
- Block: the call is stopped, the agent receives a structured refusal, and the decision is logged
- Modify: the proxy rewrites the call (stripping a parameter, masking a value) and forwards the modified version
- Require-approval: the call is held and a human reviewer is notified before execution continues
Every one of those decisions, including the timestamp, the policy rule that fired, and the call payload, gets written to the hash-chained audit log. Each log entry’s integrity is verifiable. You can prove to an auditor that a specific call was blocked at a specific time under a specific rule, and that the log has not been altered since.
Detection accuracy in testing is 99.9%, which matters because a policy engine that generates noise gets bypassed quickly. The proxy is built to sustain throughput of 10,000 or more actions per second, so it stays inline at scale without becoming the bottleneck.
Writing and Testing Policy Rules
Policy rules in Guard MCP are deterministic. There is no probabilistic scoring that produces a block sometimes and an allow other times for the same input. Given the same call and the same policy set, the engine produces the same decision every time. That predictability is what makes the audit log meaningful.
The compliance presets are a reasonable starting point. A team deploying into a healthcare environment activates the HIPAA preset and gets rules that cover PHI exposure patterns without writing them from scratch. The presets are readable configuration, not compiled logic, so you can inspect exactly what each rule checks and adjust thresholds or scope before you deploy.
For custom rules, you define the condition (which tool, which parameter pattern, which data classification signal) and the action (allow, block, modify, require-approval). Testing a rule before it goes live means running it against a captured sample of real tool calls from your agent and verifying the decisions match intent.
What to Check Before Production Deployment
A few things to verify before you put Guard MCP in front of live agent traffic:
- Latency budget: P99 at 45ms is the measured figure. Confirm your agent’s timeout configuration accommodates this, particularly for chains of tool calls where latency compounds.
- Audit log storage: the hash-chained log grows with every decision. Plan retention capacity and confirm your storage layer is append-only to preserve tamper-evidence.
- Policy gaps: the compliance presets cover common patterns. Custom tools in your agent’s tool set need rules authored explicitly. Audit your tool inventory before assuming coverage.
- Require-approval routing: if your policy uses the require-approval decision, you need a defined queue and a defined reviewer. Without that, calls will stall.
- Enterprise control plane need: if you are managing multiple agents or need SIEM integration for AI agent threats to flow into your existing detection and response workflows, the open-source proxy alone does not cover that. That is a design decision to make before you build around the repo.
Data443’s Vaikora page has documentation on the enterprise control plane and the native SIEM integrations if that scope is relevant to your deployment.
The concrete next step: clone the repo, activate the compliance preset closest to your regulatory environment, capture a representative sample of tool calls from your agent in staging, run them through the proxy, and read the audit log output. What the log shows you is what your enforcement posture actually is, not what you assumed it to be.