Most AI agent security conversations focus on what to log after a tool call executes. Vaikora Guard MCP inverts that: policy runs before execution, and the action only proceeds if the policy allows it.
That distinction matters because an agent that has already written to a database, posted to an API, or exfiltrated a file has already caused the harm. Detection after the fact documents the breach. Enforcement before execution prevents it.
What Vaikora Guard MCP Is
Vaikora Guard MCP is an open-source, MIT-licensed, MCP-compatible proxy that sits inline between an AI agent and any tool or LLM it calls. It ships as a self-hostable component, so your data and your policy decisions stay inside your own infrastructure.
The proxy intercepts each tool call, evaluates it against your configured policy, and returns one of four deterministic outcomes: allow, block, modify, or require-approval. The agent never reaches the tool until that decision is made.
At P50, enforcement latency is 8ms. At P99 it is 45ms. At 10,000 or more actions per second, that decision overhead is negligible for almost every agent workload.
Every decision, allowed or blocked, is written to a SHA-256 hash-chained audit log. That structure is tamper-evident by design. If an auditor or incident responder asks "what did this agent do and why was it permitted," the log answers that question without relying on memory, reconstructed logs, or agent-side telemetry that the agent itself could have influenced.
How Policy Enforcement Works in Practice
Consider a code-execution agent that has access to a file system tool, a shell tool, and an external HTTP tool. Without a policy gate, all three are available equally. The agent decides which to call and when.
With Vaikora Guard MCP inline, you can write a policy that blocks any shell call whose arguments contain `rm -rf`, that requires human approval for any HTTP call to a domain outside an allowlist, and that allows file reads within a specified directory tree. Those rules evaluate at the call boundary, not after the call completes.
The agent sends the tool call. The proxy evaluates it. If the shell call matches the block rule, the agent receives a denial. The shell never executes. The deny event is written to the audit log with the call payload, the matched rule, the timestamp, and the SHA-256 chain entry.
That is deterministic policy enforcement. There is no statistical model deciding whether the call looks malicious. The rule either matches or it does not.
Compliance Presets and SIEM Integration
Vaikora ships with presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. These are starting configurations, not finished policies, but they cover the most common control categories: data residency restrictions, PII handling rules, access scope limits, and audit requirements. Teams building toward a specific compliance posture can start there and tighten from their own requirements.
The enterprise control plane connects to Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity blocks become native incidents in those platforms without custom engineering. Threats pushed to SentinelOne carry severity scores mapped as: Critical=100, High=75, Medium=50, Low=25. High-severity AI agent risk surfaces in Azure Security Center and Microsoft Defender for Cloud as native incidents.
That means a SOC analyst can see an AI agent policy violation in the same queue as a network alert, with the same severity taxonomy, without building a custom integration.
Why Open Source Matters Here
The MIT license matters for two practical reasons.
First, security teams can read the enforcement code. You are not relying on a vendor’s description of what the proxy does before it touches your agent traffic. You can verify it.
Second, self-hosting means your tool call payloads, which may contain sensitive data, API keys, or internal identifiers, do not leave your network for a cloud evaluation service. The policy decision happens in your environment.
Vaikora Guard MCP is available on GitHub. The repository includes the proxy, policy configuration documentation, and example rules for common agent architectures.
What to Check Before You Deploy
Before putting the proxy inline, work through these questions:
- Which tools does your agent have access to, and which of those carry meaningful risk if misused?
- What is your approval workflow for require-approval decisions? The proxy can hold a call for human review, but someone has to be on the other end of that queue.
- Are your compliance presets a starting point or a finished policy? Review each rule category against your actual regulatory requirements before treating it as coverage.
- Is your audit log storage tamper-evident end to end? Vaikora’s hash chain covers what the proxy writes. Your storage layer needs to preserve that integrity.
Start with the highest-risk tool in your agent’s scope. Write one concrete block rule and one require-approval rule. Run the agent against a test workload and confirm the audit log captures what you expect. Then expand policy from there.