Most MCP servers act as bridges: they expose tools and pass calls through. Vaikora Guard MCP does something different at the protocol layer. Before any tool call executes, the server evaluates it against a policy and either permits, modifies, or blocks it. The source code is public, so you can see exactly how that happens.
What the repository contains
The Vaikora Guard MCP repository ships with three functional pieces:
- A Python-based MCP server that wraps any downstream tool set
- A policy engine that evaluates each `tools/call` request before forwarding it
- An audit log writer that records the request, the policy decision, and the outcome
The server implements the Model Context Protocol transport layer using standard stdio or HTTP/SSE, depending on how you configure it. That means any MCP-compatible agent runtime (Claude Desktop, a custom LangChain agent, or a headless workflow runner) can point at it without modification.
How a tool call actually gets evaluated
When an agent sends a `tools/call` message, execution does not go straight to the underlying tool. The call hits a pre-execution hook first.
Here is what that looks like in practice. An agent is configured to use a file-writing tool. It issues a call with parameters `{"path": "/etc/cron.d/agent-task", "content": "…"}`. The Guard MCP server receives that call and passes the full request object through the policy engine before touching the filesystem.
The policy engine checks the call against a set of rules expressed in a declarative YAML schema. A rule might say: deny any `file_write` call where `path` starts with `/etc`. The engine pattern-matches the parameters, finds a match, and returns a `DENY` decision with a reason string. The server never forwards the call. The agent receives a structured error that includes the denial reason, so it can surface that to a human or adjust its plan.
If no rule matches, the call receives a `PERMIT` decision and the server forwards it normally.
Writing a policy rule
Policy files live in a directory you specify at startup. Each file is a YAML document with a list of rules. A rule has four fields:
- `tool`: the name of the tool being called, or `"*"` for any tool
- `match`: a set of parameter conditions, supporting exact values, prefixes, and regex
- `action`: `permit`, `deny`, or `redact`
- `reason`: a human-readable string written to the audit log
A `redact` action is useful when you want the call to proceed but need to strip a parameter before it reaches the tool. For example, an agent calling a logging tool might pass a full user record. A redact rule can remove the `ssn` or `email` field from the payload before the call forwards, without the agent needing to know the field was removed.
The audit log format
Every evaluated call produces a log entry regardless of outcome. The entry includes the tool name, the full parameter set at evaluation time, the matched rule (if any), the action taken, and a timestamp. Entries write as newline-delimited JSON, which feeds directly into any SIEM or log aggregation pipeline that accepts structured input.
This matters for compliance. If an auditor asks which tool calls a specific agent made during a defined period, and which were blocked, the log provides that answer without reconstructing it from agent-side telemetry. The enforcement point produces its own record, independent of what the agent reports.
Deployment patterns
The Guard MCP server sits between the agent runtime and the tools it uses. There are two common placements:
- Sidecar: the server runs alongside the agent process on the same host, connected over stdio. Simple to set up, good for development and testing.
- Gateway: the server runs as a shared HTTP/SSE endpoint that multiple agents connect to. Policy changes apply to all agents at once without restarting any individual agent process.
The gateway pattern is more operationally useful in production. You update the YAML policy directory, and the engine reloads rules on a configurable interval. No redeploy required.
Data443’s Vaikora platform builds on this enforcement layer with additional controls, approval workflows, and centralized policy management for teams running multiple agents across different environments.
What to check next
Clone the repository and read `policy_engine.py` first. The evaluation loop is short and the matching logic is explicit. Then look at the example policy files in `/examples/policies`: they cover the common cases (path restrictions, parameter blocklists, redaction rules) and show the YAML structure you will need for your own rules.
If you are running agents against tools with write access to any external system, a file store, a database, or an API with side effects, verify that every call path goes through an enforcement point before execution. The source code is there. Read it, modify it, and run the test suite against your own tool definitions before putting it in front of a production agent.