Twelve lines of YAML can block an AI agent from calling a destructive tool before the call ever reaches the target system. That is the practical premise behind the Vaikora Guard MCP server, now available as open-source code on GitHub for anyone building policy enforcement into agent workflows.
This post covers what the server does, how policy enforcement works at the code level, and how to wire it into an existing MCP deployment.
What problem this solves
MCP (Model Context Protocol) servers expose tools to AI agents. In a standard setup, an agent decides to call a tool and the call goes through. The server executes, returns a result, and the agent moves on. There is no native enforcement layer in the protocol that checks whether the call is permitted before execution starts.
That gap matters in practice. An agent operating on delegated authority can call file deletion tools, outbound API endpoints, or data export functions without any guardrail between the decision and the side effect. Detection after the fact does not undo a dropped table or an exfiltrated record.
The Guard server sits in front of tool execution and applies a policy decision at call time. If the call matches a deny rule, it stops there. If it matches an allow rule with conditions, those conditions run before the underlying tool receives the request.
How the enforcement layer works
The Guard server implements a simple intercept pattern. Every incoming tool call passes through a policy evaluation function before being forwarded to the actual tool handler.
Policy rules are defined in a YAML file. Each rule specifies:
- A tool name or glob pattern (e.g., `file_*` to match any file-related tool)
- An action: `allow`, `deny`, or `allow_with_approval`
- Optional conditions: parameter value checks, caller identity, time-of-day constraints, or environment tags
A concrete example: a rule that denies any call to `file_delete` where the `path` parameter starts with `/etc/` looks like this in the policy file:
“`yaml
rules:
– tool: file_delete
action: deny
conditions:
– param: path
operator: starts_with
value: "/etc/"
reason: "System path deletion blocked by policy"
“`
When the agent calls `file_delete` with `path: /etc/hosts`, the evaluator reads the rule, matches the condition, and returns a structured denial response to the agent before any file system operation runs. The denial includes the `reason` string so the agent (and any logging system) has a human-readable record of why the call was blocked.
Calls that do not match any deny rule pass through to the underlying tool handler unchanged. The performance overhead is limited to the policy evaluation step, which runs in-process.
The approval path
The `allow_with_approval` action is the third option. When a tool call matches a rule with this action, the Guard server pauses execution and emits an approval request. In the reference implementation, that request goes to a configured webhook endpoint. A human reviewer, or a secondary automated policy system, can then approve or deny the call.
This matters for actions that carry real risk but cannot be blanket-denied. A data export that is sometimes legitimate, a privilege escalation that requires a second set of eyes, or any operation where audit trail alone is not sufficient control. The approval event is logged with the full call parameters, the requesting agent identity, and a timestamp, so every decision has an auditability record regardless of outcome.
Wiring it into an existing setup
The Guard server is a standard MCP server. It registers itself as the tool provider, wraps the actual tool server, and proxies calls through the enforcement layer. From the agent’s perspective, nothing changes: it still calls tools by name and receives results or errors.
To add it to an existing deployment:
- Clone the repository and copy the example policy YAML
- Point the Guard server at the upstream MCP tool server via its config
- Register the Guard server as the tool provider in your agent framework instead of the original server
- Edit the policy file to reflect your actual rules
The repository includes a test harness that lets you run policy rules against sample tool call payloads locally before deploying, which makes it practical to validate rules without needing a live agent session.
What to check next
Pull the repository and read the policy evaluator source before writing any rules. The condition matching logic has a specific order of operations, and understanding it prevents gaps where a broadly written rule fails to catch an edge case.
Data443 Vaikora maintains the repository and publishes updates as the enforcement model develops. If you run into a tool call pattern the current condition types do not cover, the issues page is the right place to raise it.
After reviewing the evaluator, map your highest-risk tool calls first: anything that writes, deletes, or transmits data. Write deny rules for those, run them through the test harness, and deploy before extending coverage to lower-risk tools.