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

Home | Blog | vaikora-guard-mcp on PyPI: What the MIT-Licensed Proxy Does Before a Tool Call Executes

vaikora-guard-mcp on PyPI: What the MIT-Licensed Proxy Does Before a Tool Call Executes

The gap between an AI agent deciding to call a tool and that call actually executing is where policy enforcement belongs. Most deployments leave that gap empty. vaikora-guard-mcp fills it by sitting inline as an MCP-compatible proxy, evaluating every tool call against a deterministic policy before the call reaches its destination.

The package is MIT-licensed, written in Python, and published on PyPI as `vaikora-guard-mcp`. You self-host it. No data leaves your environment to reach a policy engine you do not control.

What "inline" means in practice

An MCP-compatible agent sends a tool call request. vaikora-guard-mcp intercepts that request before forwarding it. It runs the request through six content inspection modules, compares the result against your configured policy, and returns one of four decisions: allow, block, modify, or require-approval. Only after an allow decision does the call proceed.

This is different from logging after the fact or alerting after execution. The call does not execute until the policy check completes.

Consider a concrete scenario: an agent is tasked with summarizing customer records and is given read access to a database tool. The agent, through prompt injection in a retrieved document, attempts to call a tool that writes data to an external endpoint. vaikora-guard-mcp evaluates that tool call against policy, finds it outside the allowed action set, and blocks it. The agent receives a rejection. The write never happens.

Enforcement latency at P50 is 8ms, P99 is 45ms. At 10,000 or more actions per second, the gate does not become the bottleneck.

Why MIT and self-hosted matters for security teams

Open-source publication under MIT means you can read every line of the enforcement path. For teams operating under SOC 2, HIPAA, GDPR, PCI-DSS, or ISO 27001, that auditability over the tool itself is not a nice-to-have. Compliance reviewers will ask what sits between your AI agents and your production systems. "A black box SaaS proxy" is a harder answer than "a self-hosted, MIT-licensed proxy with a published audit chain."

Every policy decision is written to a SHA-256 hash-chained, tamper-evident audit log. The chain gives you an ordered record of what was allowed, blocked, modified, or held for approval, and the hash chain means a deleted or altered entry is detectable. That record is local to your environment.

Compliance presets and what they configure

vaikora-guard-mcp ships with compliance presets for SOC 2, HIPAA, GDPR, PCI-DSS, and ISO 27001. Each preset configures the inspection modules to flag patterns relevant to that framework: PHI patterns for HIPAA, cardholder data patterns for PCI-DSS, data subject identifiers for GDPR, and so on.

You are not writing regex from scratch for each framework. The presets give you a starting policy. You extend them to match your agent’s specific tool set and the sensitivity of the data it touches.

How it fits with the control plane

The open-source proxy is the enforcement point. Vaikora’s commercial control plane, hosted by Data443, is where you manage policy centrally, view the audit log across multiple agents, and integrate with your existing security tooling. Vaikora connects to Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub without custom engineering.

For teams that want a single place to govern many agents across many environments, the control plane handles that. For teams that want only the local enforcement gate to start, the MIT-licensed proxy is enough to get policy checks in front of tool calls today.

What to check before you deploy

Before running vaikora-guard-mcp in a production agent environment, confirm a few things:

  • Which tools your agent can call. The proxy enforces against a policy you define. If you have not enumerated the tool set, write that inventory first.
  • What data flows through each tool call. Tool call payloads often contain more than the agent’s explicit input. Retrieved context, memory contents, and injected instructions all pass through. Inspect a sample before writing policy.
  • Who can approve held actions. The require-approval decision path needs a designated reviewer. Define that workflow before you enable it.
  • How you will verify the audit chain. SHA-256 hash chaining gives you tamper evidence only if you periodically verify the chain. Build that check into your security operations routine.

Install the package from PyPI, review the source, configure a policy against your agent’s tool manifest, and run a test pass with blocked actions enabled before you point it at production traffic.