Vaikora › Blog › Product Updates

An open-source MCP proxy that blocks policy-violating tool calls before they execute: what it does and how to run it

Product Updates · Nov 8, 2026 · 3 min read

Most MCP servers trust the agent completely. The tool call arrives, the server runs it, and whatever happens next is not logged in any meaningful way. That is the gap vaikora-guard-mcp closes.

vaikora-guard-mcp is an MIT-licensed Python package, published on PyPI, that sits between an AI agent and the tools it can call. Before any tool executes, the proxy evaluates the call against policy and returns one of four decisions: allow, block, modify, or require-approval. The action either runs or it does not. There is no detection-after-the-fact loop.

What the proxy actually intercepts

When an agent issues a tool call over MCP, the request reaches vaikora-guard-mcp before it reaches the underlying tool. The proxy inspects the call, runs it through the configured content inspection modules, and applies the matching policy rule. If the call is blocked, the tool never executes. The agent receives a structured response explaining the decision.

This matters because the enforcement point is before execution. A prompt-injection attempt that tries to redirect a file-write tool to an unauthorized path gets blocked at the proxy layer. The file system never sees the request.

Identical inputs always produce identical decisions. The policy engine is deterministic, which means you can reason about it, test it, and explain it to an auditor.

Installing and connecting it

```
pip install vaikora-guard-mcp
```

From there, you configure the proxy with your policy file and point your MCP client at the proxy endpoint instead of the upstream tool server. No SDK migration is required. The proxy handles the MCP protocol layer transparently.

A concrete example: an agent has access to a database query tool. You write a policy rule that blocks any tool call containing a DROP or TRUNCATE keyword. The agent attempts a call with that payload. vaikora-guard-mcp intercepts the call, matches the keyword rule, and returns a block decision with the policy ID that triggered it. The database never receives the query. The decision is written to the audit log.

The audit log

Every decision, allow or block, gets written to a SHA-256 hash-chained, tamper-evident log. Each entry is signed into the chain, so any post-hoc modification breaks the hash sequence. This is not just useful for debugging. It is the record you need when a compliance reviewer asks what an agent did and why a particular call was or was not permitted.

The audit chain produces an ordered, verifiable history of agent behavior at the tool-call layer. That is a materially different artifact from application logs, which can be edited or rotated without detection.

What the open-source package includes vs. the control plane

The vaikora-guard-mcp package is self-hosted and ships six content inspection modules plus adapters for the major hosted model APIs. It is the enforcement gateway.

The Vaikora Control Plane, the commercial product hosted by Data443, adds centralized policy management, multi-agent visibility, compliance presets for SOC 2, HIPAA, GDPR, PCI DSS and ISO 27001, and native integrations with Microsoft Sentinel, CrowdStrike Falcon, SentinelOne and AWS Security Hub. For teams running a single agent in a controlled environment, the open-source package is sufficient. For teams operating multiple agents across production systems, the control plane handles policy distribution and aggregated audit review.

Who this is for

Security engineers building guardrails for AI agents deployed in production. AI platform teams that need to demonstrate to their security counterparts that tool call access is governed, not just hoped for. Compliance teams that need an evidence trail showing which calls were permitted or blocked and under what policy.

The proxy does not replace your existing IAM or RBAC controls. It adds an enforcement layer on top of them, specifically at the MCP protocol boundary where those controls currently have no visibility.

What to check next

Pull the package from PyPI, review the policy schema in the repository, and map your highest-risk tools, the ones with write access to data stores, external APIs, or secrets, against the inspection modules. Start with a single tool, run the proxy in audit-only mode to observe what calls your agent is actually making, then enable enforcement once you have a baseline. That sequence will surface more unexpected behavior than most teams expect.

More from the Vaikora blog