infraveil-guard is a local MCP server that connects an AI assistant to an action-classification and approval workflow on the operator’s machine. It assesses proposed commands for blast radius, can stop actions at a configured severity threshold, and records decisions in a local hash-chained ledger. When an action is blocked, a separate human can review and approve it through the local command-line interface. The server is designed to work offline, without an account, API key, or network connection.
What can infraveil-guard do?
Its tools cover the decision before an action, optional gating, and review afterward. The guard can classify actions such as destructive file operations, database changes, infrastructure deletion, force pushes, and Kubernetes namespace deletion. Operators can choose audit mode to log decisions without blocking, or enforce mode to block dangerous actions at or above the configured threshold.
- guard_action gates a proposed action and can accept a human-issued approval code.
- assess_action classifies risk without gating the action.
- verify_ledger checks the local hash chain for tampering.
- recent_decisions returns decision history.
- Blocked actions can be approved by a separate human in the local CLI; the resulting code works once and expires after 15 minutes.
How infraveil-guard connects and authenticates
The server runs locally as an MCP server over stdio, started by a local command. It does not connect to a vendor service and requires no service account, API key, or network connection. The vendor names Claude Code and Cursor as example clients and says the server works with any MCP client; it does not provide a complete compatibility matrix. The agent must be configured to route the actions being governed through the guard. Approval authority stays with a separate human using the local CLI.
Who is infraveil-guard best for?
It suits people using coding or infrastructure agents who want proposed destructive actions classified, selected actions held for human approval, and decisions recorded locally. It may fit workflows involving shell commands, SQL, or infrastructure and cloud operations, provided the operator configures the agent to use the guard. No vendor account, subscription, or API key is needed. The operator remains responsible for enforcing the workflow and validating approval and recovery controls.
What infraveil-guard can access and change
The server evaluates the proposed action it receives and stores decisions, an approval queue, and its hash-chained ledger locally. If an operator approves a blocked action and supplies the one-time code, the guard can allow that action to proceed; the consequential change is made by the agent or its execution environment, not by the ledger. The guard is not a sandbox or an unbypassable enforcement boundary: it depends on the agent being configured to route actions through it. The documented default local directory holds the ledger and approval queue.
Alternatives to infraveil-guard
For adjacent infrastructure and deployment workflows, Docker MCP Server is a related option for Docker work, while AWS MCP Server is for AWS tasks. Terraform Official MCP Server is another option when the workflow centers on Terraform. These listings address related infrastructure contexts; they are alternatives to consider, not substitutes for infraveil-guard’s documented approval and local-ledger workflow.
