Vaikora › Blog › Product Updates

Policy checks before an MCP tool call runs: how vaikora-guard-mcp works and what it blocks

Product Updates · Nov 7, 2026 · 4 min read

Every tool call an AI agent makes is a decision point. If nothing checks that decision before execution, the agent acts on whatever the LLM decides, with whatever data is in context, against whatever target system is reachable. That is the gap vaikora-guard-mcp was built to close.

The package is MIT-licensed, written in Python, and published on PyPI as `vaikora-guard-mcp`. It runs as a self-hosted proxy that sits inline between an MCP-compatible agent and the tools it calls. Before any tool call executes, the proxy evaluates a policy and returns one of four decisions: allow, block, modify, or require-approval. The same input always produces the same decision. No probabilistic scoring, no model judgment at the enforcement layer.

What the proxy actually intercepts

When an MCP agent issues a tool call, that call carries a tool name, arguments, and context. vaikora-guard-mcp intercepts the call at the proxy layer before it reaches the tool. The six content inspection modules examine the payload for things like sensitive data patterns, disallowed destinations, restricted tool names, and policy conditions tied to the calling agent's identity or session context.

A concrete example: an agent with access to a CRM integration and a file-write tool is working through a customer support workflow. The agent decides to export a contact record to a local path. The proxy receives the tool call, checks it against the active policy, and blocks it because the destination path falls outside the approved output scope in the policy file. The agent gets a structured refusal. The tool never executes. Nothing is written.

That check takes roughly 8ms at the median, 45ms at the 99th percentile. At throughput, the enforcement layer handles more than 10,000 actions per second.

Writing a policy and reading the audit output

Policy is defined in a configuration file the proxy loads at startup. Rules reference tool names, argument patterns, agent identifiers, and content conditions. A minimal rule looks like this:

```
rules:
- name: block-external-write
match:
tool: file_write
argument.path:
not_prefix: /approved/outputs/
action: block
```

Every decision the proxy makes 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 and is detectable. For compliance programs that require proof of control at the point of execution, that log is the artifact. It records what the agent tried to do, what policy matched, what decision was made, and when.

Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 ship in the package so teams are not building rule sets from scratch against those frameworks.

Where the enterprise control plane fits

The open-source proxy is fully functional on its own. Teams running it at scale, or who need centralized policy management across multiple agents, connect it to the Vaikora Control Plane, which Data443 hosts. The control plane handles policy distribution, audit log aggregation, and integration with security platforms including Microsoft Sentinel, SentinelOne, CrowdStrike Falcon, and AWS Security Hub.

For teams that want AI agent threats surfaced in their existing security tooling, the control plane pushes indicators into SentinelOne as Threat Intelligence entries with severity mapped to numeric values (Critical: 100, High: 75, Medium: 50, Low: 25), and promotes high-severity risk into Azure Security Center and Microsoft Defender for Cloud as native incidents without custom engineering.

The proxy also supports 12 LLM providers with no SDK migration, so the enforcement layer does not require changes to how the agent was built.

What to check before you deploy

Before putting the proxy in front of a production agent, two things are worth confirming. First, map every tool the agent can call and what data each tool can read or write. Policy rules that are not grounded in that inventory will have gaps. Second, run the proxy in audit-only mode first. Audit-only lets every call through but records what would have been blocked, so you can tune the policy before enforcement is active.

Install from PyPI with `pip install vaikora-guard-mcp`, review the policy schema in the repository, and start with the preset closest to your compliance requirement. The audit log will show you what the agent was actually doing before you decided what to allow.

More from the Vaikora blog