Publishing the source code for a security control does the opposite of what instinct suggests. Reviewable code earns trust because every assumption the developers made is visible. With AI agent tooling, that visibility matters: a policy gate you cannot read is a policy gate you cannot verify.
Vaikora Guard MCP is now published on PyPI as `vaikora-guard-mcp`, MIT-licensed, written in Python, and self-hostable. This post walks through what the code does, what you can verify, and what it means to put this between your agent and its tools.
What the proxy actually intercepts
Vaikora Guard MCP sits inline between an MCP-compatible AI agent and the tool it is about to call. Before the tool call executes, the proxy evaluates the request against your configured policy and returns one of four decisions: allow, block, modify, or require-approval.
Nothing executes until a decision is returned. That ordering is deliberate. Detection after execution is incident response. Enforcement before execution is a guardrail.
The proxy is not a sidecar or a logging hook. It is in the request path. If you configure it to block exfiltration of fields matching a PII pattern, the tool call carrying those fields does not reach the tool.
What the source code lets you check
Because the code is public and MIT-licensed, you can verify things that would otherwise require vendor trust:
- Decision logic is deterministic. Identical input produces identical output. There is no probabilistic scoring that might allow an edge case through on a second attempt.
- Audit log structure. Every decision is written to a SHA-256 hash-chained, tamper-evident log. You can read exactly how the chain is constructed, what fields are signed, and how tampering would be detectable.
- Content inspection modules. The gateway ships six content inspection modules. The source shows what each one evaluates and in what order.
- LLM provider adapters. Vaikora supports 12 LLM providers with no SDK migration. The adapter code shows how each provider’s request format is normalized before policy runs against it.
This is worth a half-day review by any security engineer who will operate the proxy in production. The licensing removes any barrier to doing that review.
A concrete scenario: agent calling a database tool
Say you have an AI agent connected to a Postgres tool via MCP. The agent is authorized to read customer records for support workflows. Without a policy gate, the agent can read any record, in any quantity, and return the results to whatever called it.
With Vaikora Guard MCP in the path, you configure a policy that:
- Allows reads against the support-scoped tables.
- Blocks reads that include fields tagged as payment data.
- Requires human approval for any bulk read above a row threshold you define.
When the agent constructs a tool call that would return a full payment history dump, the proxy evaluates the call, matches the block condition, and returns a block decision before the query reaches the database. The agent receives the rejection. The database never sees the query.
The decision, including the input hash, the matched policy rule, the timestamp, and the outcome, is written into the audit chain. If that session is later pulled for a compliance review, the record is there and verifiable.
Compliance presets and self-hosting
The proxy ships with presets for SOC 2, HIPAA, GDPR, PCI-DSS, and ISO 27001. Each preset is a configuration file that maps regulatory requirements to specific content inspection rules. You can apply a preset as a starting point and extend it with organization-specific policy.
Self-hosting means the proxy runs in your environment. The requests your agents make, and the tool call content, do not leave your infrastructure. The Vaikora Control Plane (the commercial product hosted by Data443) adds centralized policy management, the security integrations with Sentinel, CrowdStrike, and SentinelOne, and the enterprise audit dashboard. The open-source proxy gives you the enforcement core without that dependency.
Enforcement latency at P50 is 8ms, and at P99 is 45ms. For most agent workflows, this is not a meaningful overhead. For latency-sensitive pipelines, those numbers let you do the math before committing to the architecture.
What to do next
If you are evaluating this for a production deployment, three things are worth your time:
- Pull the package from PyPI and read the policy evaluation logic before you run it. The MIT license means no barrier to that review.
- Run the proxy against a test agent with a payload that should be blocked and confirm the audit chain entry is written correctly.
- Compare the available compliance presets against your regulatory requirements and document what custom rules you will need to add.
The repository is the reference. If the proxy behavior in production does not match what the source says it should do, that is a finding worth reporting.