Vaikora › Blog › Product Updates

One proxy between your MCP agent and its tools: how vaikora-guard-mcp enforces policy before execution

Product Updates · Nov 6, 2026 · 4 min read

The gap in most MCP deployments is not authentication or logging. It is that nothing checks whether a tool call should run before it runs. The agent decides, the tool executes, and policy review happens afterward if it happens at all.

vaikora-guard-mcp closes that gap by sitting inline. Every tool call passes through the proxy. Policy runs. The call is allowed, blocked, or held for approval before the tool ever receives it.

What the proxy actually does

When an MCP client sends a tool call, vaikora-guard-mcp intercepts the request before forwarding it to the tool server. It evaluates the call against a policy file you define: which tools are permitted, which argument patterns are blocked, which combinations require a human approval step. The enforcement decision is deterministic: identical input always produces identical output.

The proxy is written in Python, published on PyPI as `vaikora-guard-mcp`, and licensed MIT. It is self-hosted. You control where it runs and what policy it loads.

Installation is one pip command:

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

Configuration is a policy file and an environment variable pointing to it. There is no proprietary SDK to adopt, no agent rewrite, no migration from whatever LLM provider you are using. Vaikora supports 12 LLM providers in its broader enforcement stack, and the MCP proxy inherits that provider-agnostic design.

What a policy file looks like in practice

Suppose your agent can call a `file_write` tool, a `shell_exec` tool, and a database query tool. You want to block shell execution entirely, allow file writes only to a specific directory, and require approval before any query that touches a table prefixed with `pii_`.

A policy entry for that scenario looks roughly like this:

```yaml
tools:
shell_exec:
action: block
reason: "Shell execution not permitted in this environment"
file_write:
action: allow
conditions:
- argument: path
pattern: "^/data/outputs/"
db_query:
action: require_approval
conditions:
- argument: table
pattern: "^pii_"
```

The proxy evaluates the incoming tool call against these rules. A `shell_exec` call is blocked immediately. A `file_write` to `/data/outputs/report.csv` passes. A `file_write` to `/etc/cron.d/` is blocked by the path condition. A `db_query` targeting `pii_customers` goes into an approval queue.

Nothing here requires the LLM or the agent framework to be aware of the policy. The enforcement sits at the transport layer.

Auditability alongside enforcement

Every decision vaikora-guard-mcp makes is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry records the tool called, the arguments, the policy rule matched, the decision, and the timestamp. Because each entry references the hash of the prior entry, any modification to historical records is detectable.

This matters for compliance teams. If an auditor asks what tool calls the agent made last Tuesday, and whether any were blocked, the log answers that question with a chain of evidence that cannot be quietly edited.

Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 are available through the Vaikora Control Plane if you need pre-built policy rules mapped to those frameworks rather than writing policy from scratch.

Where it fits in your stack

vaikora-guard-mcp sits between your MCP client and your MCP tool servers. It does not replace your existing IAM controls. If you have Azure RBAC, AWS IAM, or Snowflake roles governing what the agent's service account can do at the infrastructure layer, those still apply. The proxy adds a policy gate above that layer, one that understands the semantic content of a tool call rather than just whether the caller has a valid token.

For teams running agents connected to production systems, that distinction matters. A credential that is authorized to write files does not mean every file-write request from an agent should proceed unchallenged.

For SOC teams that want agent-level threats surfaced in existing tooling, the Vaikora Control Plane pushes blocked and flagged decisions into Microsoft Sentinel, SentinelOne, CrowdStrike Falcon, and AWS Security Hub natively.

What to check before you deploy

Before pointing the proxy at a production agent:

• Audit which tools your agent currently has access to. Many MCP deployments register more tools than the agent actually needs.
• Write a policy that starts with explicit allow rules for the tools you expect, and blocks everything else by default.
• Run the proxy in a staging environment first and review the audit log to confirm the policy behaves the way you expect before promoting it.
• Decide which tool calls warrant the approval flow versus a simple block. Approval queues create operational overhead; use them where human judgment genuinely adds value.

The source is on PyPI and the license is MIT. Start with the README, review the policy schema, and treat the first week's audit log as a signal about what your agent is actually doing, not just what you assumed it would do.

More from the Vaikora blog