Policy enforcement for AI agents has a timing problem. Most approaches inspect what an agent did after the fact, which means the tool call already ran, the file was already written, the API was already called. Vaikora Guard MCP is an open-source, MIT-licensed proxy that sits inline between an agent and its tools and applies a policy decision before each action executes.
This post explains what it does, how it works architecturally, and what you can do with it today.
What "inline" means in practice
When an AI agent runs inside an MCP-compatible environment, it invokes tools by sending structured requests: "call this function with these arguments." In a standard setup, that request goes directly to the tool. Vaikora Guard MCP intercepts it first.
The proxy receives the tool call, evaluates it against your configured policy rules, and returns one of four decisions: allow, block, modify, or require-approval. The tool only executes if the decision is allow or modify. Block and require-approval stop execution before anything irreversible happens.
This is different from wrapping tools with custom logic or adding a post-execution audit hook. The enforcement happens at the protocol level, before the call leaves the agent runtime.
The policy model
Rules are expressed as conditions on tool name, argument values, calling context, and any metadata your agent attaches to the request. A few examples of what that looks like in practice:
- Block any call to a file-write tool where the target path falls outside an approved directory.
- Require human approval before a tool call that would send email to an external domain.
- Modify a database query tool call to strip a disallowed column name before it reaches the database.
- Allow all read-only tool calls from a specific agent identity, without escalation.
The proxy evaluates these rules deterministically. There is no probabilistic scoring or model-based judgment in the enforcement path. The rule either matches or it does not. That determinism is what makes the system auditable: you can reconstruct exactly why a specific decision was made.
Audit log and tamper evidence
Every decision Vaikora Guard MCP makes is written to a SHA-256 hash-chained audit log. Each entry includes the tool name, the full argument payload, the policy rule that was applied, the decision, and a timestamp. The hash chain means any modification to a prior entry invalidates all subsequent entries, making tampering detectable.
For compliance teams: this log structure is designed to satisfy the auditability requirements in frameworks like SOC 2 and ISO 27001 without additional tooling. The log is local and self-hostable, so the data does not leave your environment.
What the open-source release includes
Vaikora Guard MCP ships under the MIT license. The repository includes:
- The proxy server itself, compatible with any MCP-compatible agent framework.
- A policy engine with a declarative rule format.
- The hash-chained audit logger.
- Example configurations for common enforcement patterns (file system guardrails, network call restrictions, approval workflows).
- Docker and Kubernetes deployment examples.
Self-hosting is the default model. You run the proxy, you control the policy files, and the audit log stays on your infrastructure.
Connecting to the enterprise control plane
The open-source proxy is a complete enforcement point on its own. Organizations that need centralized policy management across multiple agents, real-time visibility into decision telemetry, or integration with security tooling can connect it to the Vaikora enterprise control plane.
That layer adds native integrations with Microsoft Sentinel, Microsoft Defender for Cloud, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity decisions from the proxy surface as incidents in those platforms automatically, without custom engineering. Severity mapping follows a fixed scale: Critical=100, High=75, Medium=50, Low=25, so triaging teams see consistent signal regardless of which agent generated the event.
The proxy also supports 12 LLM providers without SDK migration, so you are not locked into a specific model vendor when you change your agent architecture.
Performance at scale
Enforcement latency is P50 8ms, P99 45ms. The proxy handles more than 10,000 actions per second. For most agent deployments, those numbers mean enforcement adds no perceptible delay to the agent’s task loop. For high-volume pipelines, the throughput figure matters more: a single proxy instance can cover a large fleet of agents without becoming a bottleneck.
Where to go from here
The repository is public. If you want to try it:
- Pull the repo and run the proxy locally against a test agent.
- Write two or three policy rules that reflect actual guardrails you care about (a path restriction, a network call limit, anything concrete).
- Run an agent that would violate one of those rules and verify the block decision appears in the audit log with the correct rule reference.
That test takes under an hour and tells you immediately whether the enforcement model fits your agent architecture. If you hit edge cases in the policy language or want to discuss approval workflow design, the issue tracker is the right place.