Vaikora › Blog › Product Updates

vaikora-guard-mcp is on PyPI: here is what it checks before an agent tool call runs

Product Updates · Nov 13, 2026 · 4 min read

Every AI agent tool call is a decision point. The agent has reasoned its way to an action, picked a tool, and assembled arguments. At that moment, before execution, is the only place where a policy check is both complete (you know the full intent) and still preventive (nothing has happened yet). That is the gap vaikora-guard-mcp is built to close.

What the package is and how it ships

vaikora-guard-mcp is an open-source, MIT-licensed Python proxy published on PyPI as `vaikora-guard-mcp`. It implements the Model Context Protocol (MCP), which means it sits inline between an MCP-compatible AI agent and the tools or APIs that agent calls. No SDK migration is required. Because it speaks MCP natively, any agent framework that already uses MCP sees it as just another server.

The gateway itself ships with six content inspection modules and adapters for the major hosted model APIs. The open-source layer is self-hosted. The commercial product, the Vaikora Control Plane, is hosted by Data443 and adds centralized policy management, audit dashboards, and the SIEM integrations.

What a policy check actually does at this layer

When an agent issues a tool call, the proxy intercepts the full request: tool name, arguments, and context. It evaluates that request against configured policy before forwarding anything downstream. The result is one of four outcomes: allow, block, modify (the proxy rewrites the request to strip or redact a value), or require-approval (the call holds until a human approves it).

A concrete scenario: an agent is working a support ticket and decides to call a database lookup tool with a customer email as the argument. If policy says that tool is only permitted for agents operating in a specific workflow context, or that PII arguments must be masked before the call reaches the tool, the proxy enforces that before execution. The tool never sees the raw value. If the same agent tries to call a file-write tool that is not on its allow list, the call is blocked and the decision is logged.

Because the enforcement is deterministic, identical input always produces an identical decision. There is no model scoring a risk and returning a probability. Policy either matches or it does not.

Latency and throughput at the proxy layer

The numbers matter here because inline enforcement only works if it does not break the agent workflow. The Vaikora gateway enforces policy at P50 8ms and P99 45ms, with throughput exceeding 10,000 actions per second. For most agent workflows, this is below the threshold where a human or a downstream system would notice the gate.

What goes into the audit log

Every decision, allow or block or modify or hold, is written to a SHA-256 hash-chained, tamper-evident audit log. The chain means any retrospective modification to a log entry breaks the hash sequence, making tampering detectable. For compliance purposes this matters: you can produce an ordered, verifiable record of what every agent was permitted or denied and when.

Compliance presets for SOC 2, HIPAA, GDPR, PCI-DSS, and ISO 27001 ship in the control plane, so teams do not have to map regulatory requirements to individual policy rules by hand.

Where SIEM integration sits in this picture

The open-source proxy handles enforcement at the tool-call layer. The enterprise control plane connects that enforcement signal to the rest of your security operations stack. Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent risk surfaces in Azure Security Center and Microsoft Defender for Cloud as native incidents without custom engineering. Threats are pushed into SentinelOne as Threat Intelligence indicators with severity mapped numerically: Critical at 100, High at 75, Medium at 50, Low at 25.

That path means a blocked agent action does not stay inside the AI platform. It becomes a signal in the same workflow your SOC uses for every other incident type.

Why open source at this layer

Putting enforcement logic in a closed binary creates a trust problem for the teams responsible for auditing AI agent behavior. They cannot verify what the proxy is actually checking. MIT licensing means security teams can read the inspection modules, modify policy logic for their environment, and confirm that what is running in production matches what they reviewed. The commercial control plane adds management and integration on top of a foundation the team can inspect.

What to check next

If you run MCP-compatible agents today, start by pulling `vaikora-guard-mcp` from PyPI and reviewing the six content inspection modules against the tool calls your agents currently make. Map your highest-risk tools (anything that writes data, calls external APIs, or handles PII arguments) to explicit allow or block rules. Then check whether your current logging gives you a tamper-evident record of those decisions. If it does not, that is the gap enforcement at this layer closes.

More from the Vaikora blog