When an MCP-compatible AI agent decides to call a tool, that call executes before most security controls even see it. The gap is not theoretical. A file-write, a database query, or an outbound API request triggered by an agent carries the same permissions as the process hosting the agent, and there is no checkpoint between "the model chose this action" and "the action ran." vaikora-guard-mcp is a small Python proxy that sits in that gap and applies a policy decision before the call proceeds.
It is published on PyPI as `vaikora-guard-mcp`, MIT licensed, and self-hosted. The source is available to read, fork, and audit.
What the proxy actually does
vaikora-guard-mcp sits inline between an AI agent and the LLM or tools it calls. Every tool call passes through the proxy. Before the call executes, the proxy evaluates it against configured policy and returns one of four decisions: allow, block, modify, or require-approval.
The decision is deterministic. The same input always produces the same output. That property matters for auditability because it means you can replay a log entry and verify what the system would have decided, without guessing.
Every decision is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry is signed into the chain, so any modification to a past record breaks the chain at that point. That gives security and compliance teams an ordered, verifiable record of every action the agent attempted, not just the ones that succeeded.
What you configure
Policy is expressed as rules tied to tool names, argument patterns, and content conditions. A worked example: you have an agent that can call a `send_email` tool. You want to block any call where the recipient domain is outside a list of approved domains, and require human approval for any call where the body contains text matching a pattern you define.
You write those conditions in the policy file, point the proxy at your MCP server, and the proxy enforces them at runtime. The agent code does not change. The MCP server does not change. The proxy interposes on the call path.
The six content inspection modules shipped with the gateway cover common patterns: PII detection, secret detection, prompt injection signatures, domain allowlists, payload size limits, and keyword matching. You can combine them in a single rule.
How it connects to the broader control plane
The open-source proxy works standalone. If you need centralized policy management, cross-agent visibility, or integration with your existing security tooling, vaikora-guard-mcp connects to the Vaikora Control Plane, which is the commercial product hosted by Data443.
From the control plane you can push policy updates to all proxy instances without redeployment, view audit logs across every agent in one place, and route high-severity decisions into SentinelOne, CrowdStrike Falcon, Microsoft Sentinel, or AWS Security Hub. The proxy itself does not require the control plane to function. It will enforce local policy and write to local logs whether or not the control plane is reachable.
Compliance presets for SOC 2, HIPAA, GDPR, PCI DSS, and ISO 27001 ship with the control plane. If you are operating under one of those frameworks and need to demonstrate that AI agent actions were controlled and auditable, those presets give you a starting configuration aligned to the relevant requirements.
Installation and first run
“`
pip install vaikora-guard-mcp
“`
After installation, you point the proxy at your MCP server address, supply a policy file, and start it. The proxy binds on a local port and accepts connections from your agent framework. No SDK migration is required. The proxy supports 12 LLM providers as-is.
Enforcement latency at P50 is 8ms, P99 is 45ms. At those numbers the proxy does not materially change the latency profile of most agent workflows.
What to check before deploying
- Confirm the policy file covers every tool your agent can call. An unconfigured tool falls through to the default action, which you should set explicitly.
- Review the audit log schema before you go to production. Know where the logs write, who can read them, and how long you retain them.
- If you run multiple agents, decide whether you want per-agent policy files or a shared policy pushed from a central source. Both work, but the answer affects how you manage policy drift.
- Test the require-approval path with a real approval workflow before relying on it. The proxy will hold the call, but something has to receive and resolve the approval request.
The repository README covers configuration options and the log schema in detail. That is the right starting point for evaluating whether the proxy fits your environment.