How Vardhold works
Vardhold sits between AI agents and the machine. It asks one question before every action it can see coming, and records everything else as it happens.
On this page
The problem it solves#
AI coding agents such as Claude Code, Cursor and GitHub Copilot, and the MCP servers they call, run shell commands, read and write files, and reach the network with every right the signed-in person has. Endpoint security sees the processes that result. It does not see which agent started them, why, or whether anyone agreed.
Vardhold adds that missing layer: it knows the agents, decides what each one may do, involves a person when it matters, and keeps a record that stands up in an audit.
The parts#
| Part | What it does |
|---|---|
| Service | Runs as LocalSystem and holds the policy, the approval queue and the audit log. It listens on 127.0.0.1 only, so it is never reachable from the network. |
| Hook | vardhold-hook is registered machine-wide with Claude Code and Cursor. Before each tool call, it sends the action to the service and returns the verdict to the agent. |
| MCP proxy | vardhold-mcp-proxy sits between any MCP client and server and checks every tools/call, including the paths, URLs and commands in its arguments. |
| Telemetry | A private Windows ETW session records process starts, file writes and deletes, and network connections of every agent process, including agents without hooks. |
| Tray app and dashboard | Show approval prompts and the dashboard: agents, live timeline, approvals, alerts, policy editor, MCP servers and settings. |
| Admin CLI | vardhold covers the same controls for scripts and incident response. |
The life of an action#
- The agent asks to act. Claude Code wants to run
git push --force origin main. Before it runs, the hook sends the service the agent, the action (shell.exec), the command and the working folder. - The policy decides. Rules are read top to bottom and the first match wins. Paths are compared the way Windows resolves them, and commands are checked against the files they name, so spelling a path differently does not change the outcome.
- A person decides, when the rule says ask. The action waits in the approval queue. The tray app shows what the agent wants, the rule that asked and how the same request was decided before. Deny is one click; allowing needs an administrator's confirmation.
- The agent gets its answer. Allowed actions run. Blocked actions do not, and the agent is told which rule stopped it, so it can explain and choose another way.
- Everything is recorded. The event is written to the audit log with the agent, process, target, rule and verdict, chained to the record before it, and streamed to your SIEM.
Before it runs, or as it happens#
How much control Vardhold has depends on how an agent can be reached. Vardhold is explicit about the difference, on the dashboard and in every event (source).
Modes#
| Mode | Behaviour | Use it when |
|---|---|---|
monitor | Records and alerts, never blocks or asks | Learning what agents do before you enforce |
enforce | Applies every rule as written | Normal operation |
strict | Uses each rule's verdict_strict, and any checked action that no rule matches needs approval | High-assurance machines, or during an incident |
Raising the mode is open to anyone at the PC. Lowering it needs administrator confirmation.
Evidence you can rely on#
Every audit record is chained to the one before it with HMAC-SHA256 under a per-machine key. Approvals, alerts and policy versions are sealed with the same key. Removing, editing or reordering records is detected, and the chain head is recorded in your SIEM every hour so you hold an independent copy to check against. Details: Security model.