NEW! Data443 Acquires Vaikora – Real-Time AI Runtime Control & Enforcement for AI Agent

Home | Blog | Vaikora Guard MCP Is MIT-Licensed: What the Codebase Gives You and What You Still Need to Build

Vaikora Guard MCP Is MIT-Licensed: What the Codebase Gives You and What You Still Need to Build

MIT licensing means you can read exactly what runs between your AI agent and every tool it calls. That is worth more than documentation, because documentation describes intent and source code describes behavior.

Vaikora Guard MCP is Data443’s open-source, self-hostable proxy that sits inline in the Model Context Protocol chain. Every tool call an agent makes passes through it. Before the call reaches the tool, Guard MCP applies a policy decision: allow, block, modify, or route to a human for approval. Nothing executes first and gets reviewed later.

What the Proxy Actually Does

Guard MCP intercepts the MCP message at the point an agent requests a tool invocation. It evaluates the request against your policy configuration, then returns one of four outcomes:

  • Allow: the call proceeds unchanged
  • Block: the call is rejected and the agent receives a structured error
  • Modify: Guard MCP rewrites the request (strip a parameter, redact a value) before forwarding it
  • Require approval: the call is held, a human reviews it, and it either proceeds or is rejected

The four-outcome model matters because "block or allow" is too coarse for production agents. An agent drafting an email might be allowed to send, but only after a compliance check removes a field it should not have included. Modify handles that without stopping the workflow.

What MIT Licensing Changes

With a proprietary proxy, you trust the vendor’s claim about what the proxy does. With MIT licensing, your security team can verify the interception logic, the policy evaluation path, and the audit write. That verification capability is meaningful for any organization that needs to demonstrate control over AI agent behavior to an auditor.

The codebase is also forkable. If your environment has a tool type or a data classification rule that the default policy engine does not cover, you can extend it without waiting for a release cycle.

Self-hosting means the proxy runs inside your own infrastructure. Tool call content, policy decisions, and audit records do not leave your environment unless you route them somewhere explicitly.

The Audit Log

Every decision Guard MCP makes writes to a SHA-256 hash-chained, tamper-evident audit log. Hash chaining means that if a record is altered after the fact, any record downstream of it fails verification. For regulated industries, that property is the difference between an audit log and evidence.

The log entry includes the agent identity, the tool requested, the parameters passed, the policy rule that matched, and the outcome. That record exists whether the call was allowed or blocked.

What You Get in the Open-Source Build Versus the Enterprise Control Plane

The open-source Guard MCP gives you the enforcement proxy, the policy engine, the four-outcome decision model, and the audit log. It supports 12 LLM providers with no SDK changes required and is compatible with any MCP-compliant tool server.

The enterprise control plane adds centralized policy management across multiple agents and deployments, the compliance presets (HIPAA, PCI-DSS, GDPR, SOC 2, ISO 27001), and the SIEM integrations. 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, with no custom engineering. Threats push into SentinelOne as Threat Intelligence indicators with severity mapping at Critical=100, High=75, Medium=50, Low=25.

If you are running a single agent in a controlled environment, the open-source build may be sufficient. If you are running agents across multiple teams or need to demonstrate compliance posture centrally, the control plane fills gaps the open-source build does not address.

A Concrete Scenario

Consider an agent that has access to a file system tool and a network request tool. Without a proxy, both tools execute on whatever the agent decides. With Guard MCP and a policy that blocks any network call to an unrecognized external domain, the agent can still read local files freely, but any attempt to exfiltrate data to an unexpected endpoint is blocked before the call leaves the proxy. The audit log records the attempt, the matched rule, and the block decision. If that event meets your severity threshold, the enterprise control plane can push it to your SIEM automatically.

That enforcement happens at P50 8ms latency and P99 45ms, so the proxy does not become a performance bottleneck in production.

What to Check Next

Clone the repository and read the policy evaluation logic before you configure anything. Understand which fields Guard MCP inspects in the MCP message and what your policy files can reference. Then map your highest-risk tool calls (anything that writes, sends, or calls an external API) to a policy rule. Start with block rules for the clearest prohibitions and add modify rules where you need conditional behavior rather than hard stops.