Vaikora › Blog › Product Updates

Why we MIT-licensed a Python MCP proxy that blocks tool calls before they run

Product Updates · Nov 6, 2026 · 3 min read

Publishing open-source security tooling is a commitment. If the code does not hold up to scrutiny, the scrutiny is public. That is exactly why we did it with vaikora-guard-mcp, and why the enforcement logic is inspectable line by line.

What the proxy actually is

vaikora-guard-mcp is a self-hosted MCP-compatible proxy written in Python and published on PyPI under the MIT licence. It sits between an MCP client (your agent) and the MCP server (your tools). When the agent issues a tool call, the proxy intercepts it, evaluates it against your policy, and returns an allow, block, modify, or require-approval decision before the downstream tool ever receives the request.

The decision is deterministic. Identical input, identical output. There is no probabilistic scoring that might go a different way on the next request. Policy is defined explicitly, evaluated consistently, and every outcome is written into a SHA-256 hash-chained audit log that cannot be silently edited after the fact.

Why open source for this specific component

The proxy is the trust boundary. If a team is going to place it inline in front of production tool calls, they need to read the enforcement code, audit the policy evaluation path, and confirm it does what it claims. A closed binary in that position is a demand for blind trust.

Publishing under MIT means you can fork it, modify it, run it on your own infrastructure, and inspect every line. The Vaikora Control Plane (the commercial product hosted by Data443) handles the enterprise layer: centralized policy management, the full audit trail UI, SIEM integrations, and compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. The proxy is the enforcement point. The control plane is where you operate at scale.

A concrete scenario

Say your MCP agent has access to a file-read tool and a network-request tool. Without a proxy, every tool call the agent decides to make goes straight to execution. The only gate is whatever the agent's own reasoning applies, which is not a gate you can audit or enforce from outside the model.

With vaikora-guard-mcp in front:

• A file-read call targeting a path outside the allowed directory hits a block decision before the filesystem is touched.
• A network-request call to an unlisted external host triggers a require-approval decision and pauses until a human confirms.
• A benign tool call within policy passes through with an allow decision, the full call logged, and the agent none the wiser about the inspection that just happened.

Enforcement latency at P50 is 8ms, P99 is 45ms. For most tool calls, that is below human perception and well inside acceptable agent response time.

What you give up by not having this

Without an inline proxy, your control surface for MCP tool calls is limited to what you can reconstruct after execution. Log aggregation, post-hoc anomaly detection, and agent-side guardrails all have one problem in common: the tool already ran. If that tool call exfiltrated data, wrote to a database, or called an external API with a credential, the event you are investigating is already complete.

Pre-execution enforcement is a different category of control. The action either happens or it does not. The audit log records which outcome applied and why, not what you found when you looked at logs later.

Getting started

Install from PyPI:

`pip install vaikora-guard-mcp`

The repository is public and the licence is MIT, so the first step is reading the proxy code, not filling out a form. Write a policy file that reflects what your agent is and is not permitted to do. Run the proxy locally against a test MCP server. Confirm that your block and require-approval cases fire as expected before you point it at anything sensitive.

If you are running agents across multiple teams or need compliance preset enforcement and centralized audit, that is where the control plane becomes relevant. But the proxy works as a standalone enforcement point, and that is intentional.

Check what tool calls your existing MCP agents are making today, before you add any proxy. The list is usually longer than teams expect.

More from the Vaikora blog