Policy enforcement for AI agents has a placement problem. Most teams add guardrails at the application layer, after the agent has already decided what to do. By the time a check runs, the tool call is either in flight or already complete. Vaikora Guard MCP is built to fix that placement: it sits inline between the agent and the tool, and every decision happens before execution.
That package is now published on PyPI as `vaikora-guard-mcp`, MIT-licensed, written in Python, and self-hostable.
What the MCP Proxy Actually Does
The Model Context Protocol (MCP) is the layer where an AI agent expresses intent as a tool call. That is exactly where policy should be applied, before the intent becomes an action.
Vaikora Guard MCP intercepts every tool call at that layer and applies a deterministic policy check. The result is one of four decisions: allow, block, modify, or require-approval. The agent never touches the tool until that decision is made. If the policy says block, the call stops. If it says require-approval, a human gets the prompt before anything executes.
Because the check is deterministic, identical input always produces an identical decision. There is no model scoring a risk probability that varies by run. The policy is a rule; the enforcement is consistent.
Why Determinism Matters for Auditability
Non-deterministic controls produce audit records that are hard to reason about. If the same agent action gets allowed on one run and blocked on another, explaining that difference to a compliance reviewer is painful.
Every decision Vaikora Guard MCP writes to the audit log is signed into a SHA-256 hash-chained record. The chain is tamper-evident: you can verify that no decision was altered or deleted after the fact. That is the kind of audit trail that satisfies SOC 2, HIPAA, GDPR, PCI-DSS, and ISO 27001 reviewers, because it shows not just what happened but that the record itself is intact.
A Concrete Scenario
Suppose an agent is tasked with reading customer records and drafting a support response. The agent calls a database tool with a query that happens to include a wildcard pattern touching fields outside the support context, pulling more data than the task requires.
Without an inline policy gate, that query executes. The agent gets the data. The overage is invisible unless you happen to audit LLM context logs later.
With Vaikora Guard MCP in place, the policy rule that restricts database tool calls to approved field sets evaluates the call before it reaches the database. The call either gets modified to strip the disallowed fields, or blocked outright, depending on how the policy is written. The decision is logged with the full call context, the policy that matched, and the outcome.
The agent never sees the out-of-scope fields. The log shows exactly why.
Setup and Integration
Installing from PyPI:
“`
pip install vaikora-guard-mcp
“`
The proxy sits between your MCP-compatible agent and whatever tools it calls. Because it speaks MCP natively, there is no SDK migration required on the agent side. You configure policies in the control plane, and the proxy picks them up at runtime.
For teams running hosted models, the proxy supports 12 LLM providers without requiring changes to the existing model integration. Enforcement latency at P50 is 8ms, P99 is 45ms, so the inline placement does not meaningfully change the agent’s response time from the user’s perspective.
Vaikora Guard MCP is the open-source component. The enterprise control plane, hosted by Data443, is where you manage policy centrally, review the audit chain, set approval workflows, and push decisions into connected security tooling like Microsoft Sentinel, CrowdStrike Falcon, or SentinelOne.
What to Check Before You Deploy
Before standing up the proxy in a production agent workflow, work through these questions:
- Which tool calls in your current agent setup have no policy gate at all? Start there.
- What data types can those tools return, and do you have classification rules that should restrict access?
- Do any tool calls require human approval before execution, and does your current setup enforce that or just recommend it?
- Who owns the audit log today, and does it satisfy your compliance framework’s integrity requirements?
The GitHub repository has the full source, configuration schema, and example policies. Reviewing the policy structure before writing your first rule is worth the time. The decisions you configure are the ones that run, and there is no fallback scoring to catch what the policy misses.