Shipping an MCP server that intercepts tool calls and applies policy before execution is a specific engineering problem. Most teams solve it late, after something has already gone wrong, because the tooling to solve it early has not been easy to self-host. That changes with Vaikora Guard MCP, an MIT-licensed, open-source proxy you can run in your own infrastructure today.
What the proxy actually does
Vaikora Guard MCP sits inline between an AI agent and the tools it calls. When an agent issues a tool call, the request passes through the proxy first. The proxy evaluates the call against a configured policy set and returns one of four decisions: allow, block, modify, or require-approval. The tool only executes if the decision is allow or approve-and-proceed. Nothing reaches the tool otherwise.
This is different from logging or monitoring. The proxy is in the call path. There is no out-of-band inspection happening after the fact.
Enforcement latency is P50 8ms and P99 45ms. At P99, that is 45 milliseconds added to a tool call in exchange for a deterministic policy decision. For most agent workflows, that is an acceptable trade.
How to set it up
The proxy is self-hostable, which means your tool call traffic never leaves your environment. Configuration is policy-file driven. You define which tools are allowed, which require approval, and what patterns in the payload should trigger a block or a modification.
A worked example: suppose an agent has access to a `write_file` tool. You want to allow writes to a scratch directory but block any write to a path matching `/etc/` or `/root/`. In the policy file, you add a rule that matches on the `path` parameter of `write_file` calls and blocks requests where that parameter matches the restricted pattern. When the agent tries to write to `/etc/cron.d/`, the proxy evaluates the payload, matches the rule, and returns a block decision. The tool call never reaches the file system.
The same mechanism applies to database tools, API call tools, shell execution tools, or any other MCP-compatible capability your agent stack exposes.
What the audit log gives you
Every decision the proxy makes is written to a SHA-256 hash-chained, tamper-evident audit log. That means each log entry is cryptographically linked to the one before it. If someone modifies or deletes a record, the chain breaks and the tampering is detectable.
For compliance purposes, this matters. Auditability of AI agent actions is increasingly a requirement under frameworks like SOC 2 and ISO 27001, both of which are covered by Vaikora’s compliance presets alongside HIPAA, PCI-DSS, and GDPR. The log tells you not just what the agent did, but what was evaluated, what decision was returned, and in what order.
Connecting to your existing security stack
Because the proxy is open-source, you can deploy it standalone and consume the audit log however you already consume logs. For teams running Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, or AWS Security Hub, Vaikora’s enterprise control plane connects natively without custom engineering.
High-severity decisions push into SentinelOne as Threat Intelligence indicators with severity scores mapped to Critical=100, High=75, Medium=50, and Low=25. Azure Security Center and Microsoft Defender for Cloud receive high-severity AI agent risk as native incidents. If your SOC is already triaging in those platforms, AI agent policy violations appear in the same queue as other signals, with no extra plumbing required.
The proxy supports 12 LLM providers. If your agent stack connects to multiple backends, you do not need to migrate SDKs or maintain separate instrumentation per provider.
Why open source matters here
The MIT license means you can read the enforcement logic, audit it, modify it, and run it without dependency on an external service. For teams building internal AI platforms under strict data residency requirements, self-hosting is often not optional. An open-source proxy with a documented policy format lets your security team review exactly what is being evaluated and how decisions are made, which is a requirement for any control you plan to present to an auditor.
Data443 publishes Vaikora Guard MCP as the open-source component. The enterprise control plane adds centralized policy management, the SIEM integrations, and the compliance preset layer on top.
What to check next
Clone the repository and read the policy schema before you write your first rule. Map your agent’s tool inventory against the four decision types: which tools should always be allowed, which should require human approval, which should be blocked outright, and which payloads need modification before passing through. Start with your highest-risk tool, the one with write access or external network reach, and write a policy rule that you would be comfortable showing an auditor. That exercise will tell you whether your current agent deployment has any policy definition at all.