Vaikora › Blog › Product Updates

What vaikora-guard-mcp actually does when an MCP tool call arrives: a walkthrough of the enforcement path

Product Updates · Nov 10, 2026 · 4 min read

The MIT-licensed vaikora-guard-mcp proxy is published on PyPI and self-hostable. What it does is specific: it sits inline between an MCP client and the tools that client can call, runs a policy check against every tool invocation, and returns an allow, block, modify, or require-approval decision before the tool executes. Nothing runs first and gets reviewed afterward.

This post walks through what happens inside that path, why the design matters, and how to get started.

The gap vaikora-guard-mcp closes

MCP (Model Context Protocol) lets AI agents call tools, read resources, and trigger side effects in connected systems. The protocol itself has no built-in policy layer. An agent authorized to call a tool calls it. Full stop.

That means sensitive data can be exfiltrated through a file-read tool, destructive writes can run against databases, and external API calls can carry regulated content, all before any detection layer has a chance to fire. Detection after execution is useful. Prevention before execution is the actual control.

vaikora-guard-mcp adds that control as a proxy layer. The agent sends its tool call to the proxy. The proxy inspects the request, matches it against your configured policy, writes the decision to the audit log, and either forwards the call, blocks it, modifies the payload, or holds it for human approval. The tool only sees calls that passed.

What the inspection layer checks

The proxy ships six content inspection modules. Depending on your policy configuration, an incoming tool call can be checked against:

• PII and regulated data patterns (names, card numbers, health identifiers, national IDs)
• Prompt injection signatures in tool arguments
• Secrets and credential strings embedded in payloads
• Outbound data volume and destination patterns
• Custom keyword and regex rules you define
• Compliance preset rules for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001

A concrete example: an agent calls a `write_file` tool with an argument containing what looks like a Social Security number. Under a HIPAA preset, that call matches a PII rule. The proxy blocks the call and returns a structured denial to the agent. The tool never receives the payload. The decision, the matched rule, and the full request are written to the SHA-256 hash-chained audit log before the response goes back.

Deterministic policy, not probabilistic scoring

Every decision is deterministic. Identical input, identical policy, identical decision. There is no model scoring the riskiness of a call and returning a confidence value. The rule either matches or it does not. That matters for two reasons.

First, it makes the behavior predictable enough to rely on in production. Teams can write tests against specific tool call patterns and confirm the policy fires consistently.

Second, it makes the audit log meaningful. Each entry records the exact decision, the rule that produced it, and a hash linking it to the previous entry. The chain is tamper-evident. If someone modifies an entry, the hash chain breaks. That is the property compliance auditors care about when they ask how you know what your agents did.

Enforcement latency at P50 is 8ms, P99 is 45ms. For most agent workflows, that is not a meaningful addition to overall response time.

How to run it

vaikora-guard-mcp is published on PyPI as `vaikora-guard-mcp`. Install it, point your MCP client at the proxy endpoint instead of directly at your tools, and configure a policy file. The proxy starts accepting tool calls immediately.

```
pip install vaikora-guard-mcp
```

Configuration is a YAML policy file. You can start with one of the compliance presets and add custom rules on top. The proxy logs to stdout by default; you can route that output into your SIEM or store it locally.

For teams running the enterprise control plane through Data443, policy updates propagate to the proxy without restarts, and audit logs feed into the central dashboard with cross-agent visibility.

What to check before you deploy

Before pointing production agent traffic at the proxy, verify three things.

• Policy coverage matches your tool surface. List every tool your agent can call and confirm you have rules covering the data types each tool can receive or return. Gaps in coverage mean gap in enforcement.
• Approval routing is configured for high-risk actions. The require-approval decision holds the tool call pending a human response. That path needs an endpoint to receive the approval request. Configure it before you need it.
• Audit log retention meets your compliance requirement. The hash chain gives you tamper evidence. Retention policy is your responsibility. Decide where logs land and for how long before the first production call runs.

The source code is on GitHub under the MIT license. Review the content inspection modules against your data types, run the preset that matches your regulatory scope, and test with real tool call payloads from your agent before treating any configuration as final.

More from the Vaikora blog