Every AI agent that calls a tool executes code your infrastructure trusts. The tool call runs with whatever permissions the agent has, and if the call is malicious, sensitive data has already moved or the action has already completed before any detection layer sees it. The question is whether you want a policy check before execution or a forensic record after it.
Vaikora Guard MCP is an open-source, MIT-licensed MCP-compatible proxy that sits inline between an AI agent and the tools or LLMs it calls. Before each action executes, the proxy applies a deterministic policy decision: allow, block, modify, or route to a human for approval. The project is self-hostable, which means your data and your rules never leave your own environment.
What the Proxy Actually Does
When an agent issues a tool call, the request goes to the Guard MCP proxy instead of directly to the tool. The proxy evaluates the call against your configured policy rules, then takes one of four actions:
- Allow: the call passes through unchanged.
- Block: the call is stopped and the agent receives a structured refusal.
- Modify: the proxy rewrites the call, stripping or replacing content before it reaches the tool.
- Require approval: the call is held in a queue until a human reviewer approves or denies it.
Every decision, regardless of outcome, is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry is linked cryptographically to the one before it, so you can verify that no record was altered or deleted after the fact. That matters for compliance reviews and incident investigation.
Enforcement latency at P50 is 8ms and at P99 is 45ms. The proxy handles more than 10,000 actions per second, so it is practical to put in front of production agent workloads, not just test environments.
How Policy Gets Configured
Policy is defined declaratively. A rule specifies a condition and an action. Conditions can match on tool name, parameter values, prompt content, data patterns (such as regular expressions for PII or credential formats), or the identity of the calling agent. Actions map directly to the four enforcement outcomes above.
A concrete example: an agent has access to a file-write tool. You write a rule that blocks any call to that tool where the destination path matches your secrets directory, and a second rule that requires human approval for any call that writes more than a defined byte count to an external endpoint. Both rules evaluate before the tool runs. There is no race condition, no post-execution hook, and no reliance on the tool itself to enforce anything.
Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 ship with the proxy, so teams working under those frameworks have a baseline policy set they can review and tighten rather than building from nothing.
Integration With Existing Security Tooling
If you are running the enterprise control plane alongside Guard MCP, the proxy integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent risk surfaces in Azure Security Center and Microsoft Defender for Cloud as native incidents, with no custom engineering required. Threats are pushed into SentinelOne as Threat Intelligence indicators with severity mapping (Critical=100, High=75, Medium=50, Low=25), so your SOC sees AI agent policy violations in the same workflow they use for every other threat category.
The proxy supports 12 LLM providers without requiring an SDK migration, which means you can add it to an existing multi-model agent architecture without rewriting your integration layer.
What Self-Hosting Means in Practice
Because the proxy is self-hostable, the policy engine and audit log run inside your environment. No tool call payloads, no prompt content, and no audit records are transmitted to an external service unless you configure an outbound integration deliberately. For organizations with data residency requirements or air-gapped environments, that architecture is often the only acceptable option.
The MIT license means you can inspect the enforcement logic, modify it, and integrate it into internal tooling without licensing friction. The audit log format is documented, so you can pipe records into your SIEM or long-term storage without depending on a proprietary export.
What to Check Next
If you are deploying AI agents in any capacity, the concrete first step is to map which tools each agent can call and whether any of those tools have access to credentials, sensitive data stores, or external network endpoints. That inventory tells you where a policy enforcement layer adds the most immediate value. From there, pulling the Vaikora Guard MCP repository and reviewing the default compliance presets against your own regulatory requirements is a practical way to assess the gap between what you have today and deterministic pre-execution control.