The Model Context Protocol makes it straightforward to give an AI agent access to tools: databases, APIs, file systems, shell commands. What it does not include is a built-in way to say "this call is allowed, that one is not" before the action runs. That gap is what Vaikora Guard MCP is designed to close.
The specific problem
When an agent decides to call a tool, the MCP transport layer delivers that call to the server and the server executes it. There is no native interception point where you can evaluate the call against a policy and return a block or a modified version before anything happens. Detection after the fact is not the same thing as control before execution, especially when the tool being called can write to a database, send a message, or trigger an external API.
Most teams handle this by adding conditional logic inside each tool’s implementation, or by wrapping calls in application code. That works until you have more than a handful of tools, or until you need to change a policy across all of them at once.
What Vaikora Guard MCP does
Vaikora Guard MCP is a self-hostable proxy that sits between an agent and any MCP-compatible tool server. Every tool call passes through it. For each call, the proxy evaluates the request 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 modify. Blocked calls return a structured response to the agent; approval-required calls pause until a human responds.
The proxy is open-source under the MIT license. You can read the full implementation, host it in your own environment, and modify it without restriction.
Enforcement latency at P50 is 8ms, P99 is 45ms. At that speed, the gate does not materially affect agent responsiveness for most workflows.
How policy is configured
Policies are defined as rules that match on tool name, argument values, argument patterns, or combinations of those. A rule can:
- Block any call to a tool whose name matches a pattern (for example, blocking all shell execution tools in a production environment)
- Block calls where a specific argument contains a value matching a regular expression (for example, flagging calls that reference a production database connection string)
- Require human approval for calls that touch a defined set of sensitive resources
- Modify a call before it executes, rewriting an argument to a safer value
Rules are evaluated in order. The first matching rule wins. If no rule matches, the default action applies, which you configure as allow or block depending on your posture.
A concrete example: a coding agent has access to a file-write tool and a shell-execution tool. You configure the proxy to allow file writes under a specific directory, block file writes to any path outside it, and require approval for any shell-execution call. The agent can work freely within those bounds. Anything outside them is stopped before it runs, not logged after.
What gets recorded
Every decision, allow, block, modify, or approval, is written to an audit log. Each log entry is chained with SHA-256 hashing, so the sequence is tamper-evident. If a decision is challenged in an incident review or a compliance audit, you can produce the exact record of what was evaluated, what policy matched, and what the outcome was.
The enterprise control plane adds a dashboard over that log, along with real-time alerting, multi-agent policy management, and integration with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. For teams that need compliance presets, the platform ships configurations aligned to HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001.
Who this is for
If you are running agents against production tools and have not yet put a policy decision point in front of those calls, this is the fastest way to do it. The open-source proxy requires no SDK migration and works with any MCP-compatible setup.
If you are an AI platform team evaluating governance controls, the audit log and approval workflow are the two components most compliance reviewers will ask about. Both are present in the open-source version.
What to do next
Clone the Vaikora Guard MCP repository and read the policy configuration documentation before you deploy anything. Start with a block-by-default posture against a non-production tool server. Run your agent through a representative set of tasks, review what the audit log captures, and adjust your allow rules from there. Moving to production with an established policy set is significantly safer than adding rules reactively after something executes that should not have.