infraveil-guard
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@infraveil-guard assess risk of 'DROP TABLE users'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
infraveil-guard
A seatbelt for your AI agent. Put a governed, tamper-evident gate in front of
the destructive things an agent can do — rm -rf, DROP TABLE, terraform destroy, git push --force, kubectl delete namespace, DELETE FROM … with no
WHERE. The agent proposes; the dangerous ones are blocked until a human
approves them out of band; every decision is written to a local hash-chained
ledger you can verify.
Offline by design: no account, no network, no telemetry. It runs entirely on your machine. Open your network tab — it talks to nobody.
pip install infraveil-guardWhy
Coding agents (Claude Code, Cursor, and friends) are great until the one time
they run rm -rf in the wrong directory, or drop the production database to "fix
a migration." You don't want to read every command — you want the catastrophic
ones to stop and wait for you. That's all this does, and it does it well.
Related MCP server: Agent File Guardian
Wire it into your agent
Add it as an MCP server. For Claude Code / Cursor / any MCP client:
{
"mcpServers": {
"infraveil-guard": {
"command": "infraveil-guard"
}
}
}Then add one rule to your agent's instructions (CLAUDE.md, system prompt, etc.):
Before running any shell command, SQL statement, or infrastructure/cloud operation, first call
guard_actionwith the exact command. Only proceed if it returnsproceed: true. If it returnsdecision: "blocked", stop and ask me to approve it — I'll give you a one-time code to pass back asapproval_code.
That's it. Safe commands sail through (and are logged). Dangerous ones stop.
How approval works (the part that matters)
When the agent hits something dangerous, guard_action returns blocked and an
action_id. The agent cannot approve itself — by construction, not by good
behavior. You approve in your own terminal:
$ infraveil-guard approvals
1 action(s) blocked, waiting for approval:
[9b58e9c499b3] CRITICAL CRITICAL risk: drop table (+0 more). Irreversible.
DROP TABLE users;
approve with: infraveil-guard approve 9b58e9c499b3
$ infraveil-guard approve 9b58e9c499b3
Action requesting approval
id: 9b58e9c499b3
risk: CRITICAL (IRREVERSIBLE)
why: CRITICAL risk: drop table. Irreversible.
command:
DROP TABLE users;
Approve this action? [y/N] y
APPROVED. Give the agent this one-time code:
8f2510
It is valid for 15 minutes and works exactly once.You hand the agent 8f2510; it calls guard_action("DROP TABLE users;", approval_code="8f2510"); the guard checks it, lets it through once, and records
the approval. The code is minted only by the human CLI, is single-use, and
expires — so an agent can't forge or replay it.
Inspect everything — trust nothing
Every decision (allowed, blocked, approved, denied) is appended to a hash-chained
ledger at ~/.infraveil-guard/ledger.jsonl. Editing, deleting, reordering, or
inserting any line breaks the chain:
$ infraveil-guard verify
{ "ok": true, "count": 42, "message": "Hash chain verified across 42 entries - no tampering." }
$ infraveil-guard log 10 # the last 10 decisions, rawIt's ~400 lines of plain stdlib Python. Read it. That's the point.
Tools (MCP)
Tool | What it does |
| Gate an action before running it. Returns |
| Classify blast radius without recording or gating. |
| Verify the tamper-evident ledger's hash chain. |
| The most recent decisions, newest first. |
Configuration
Env var | Default | Meaning |
|
| Gate actions at/above this severity: |
|
|
|
|
| Where the ledger and approval queue live. |
What this is — and isn't
It is a high-signal classifier + an out-of-band human-approval gate + a tamper-evident local log. It's the smallest honest version of "a human approves before anything irreversible happens."
It is not a sandbox. It works because your agent is told to route actions
through guard_action — a cooperative guardrail, not an unbypassable jail. That
is a deliberate trade: in exchange you get something you can install in one line,
read end to end in an afternoon, and run with no account, no network, and no
dependency on anyone else's infrastructure — including ours. Nothing here calls
home, checks a license, or needs a server to keep working. It does one job and
owns it: stop the catastrophic actions and wait for a human. Yours to fork and
run forever.
Related
Part of Infraveil's open-source tools for running backends you own:
infraveil-lockin — scan a repo and score how locked in your app is to one cloud provider (
npx infraveil-lockin).infraveil — a policy DSL you enforce in CI, plus offline audit-ledger and signature verification.
License
AGPL-3.0-or-later. Use it, fork it, read every line. If you run a modified version as a network service, share your changes. © Infraveil Corporation.
Available Tools
4 toolsassess_actionA
Classify the blast radius of an action WITHOUT recording or gating it. Use this to reason about risk; use guard_action when you actually intend to run it. Returns risk (none/low/medium/high/critical), whether it is reversible, the specific dangerous capabilities found, and a recommendation.
action: the command/SQL/tool call to assess (required).
Inputs: action (required). Returns: result
guard_actionA
Check an action BEFORE you run it. Pass the exact command, SQL statement, or tool invocation you are about to execute.
Returns JSON with proceed (true/false). If proceed is false and decision
is "blocked", the action is dangerous and a human must approve it out of
band: tell the user to run infraveil-guard approve <action_id> in their own
terminal, then call this tool again with the one-time approval_code they
give you. You cannot approve your own action. Every decision is recorded in a
local tamper-evident ledger.
action: the exact command/SQL/tool call about to run (required). approval_code: the one-time code a human produced via the CLI (optional).
Inputs: action (required), approval_code. Returns: result
recent_decisionsA
Return the most recent guard decisions from the local ledger (newest first): what was allowed, blocked, or approved, with risk and timestamps.
limit: how many entries to return (1-500, default 20).
Inputs: limit. Returns: result
verify_ledgerA
Verify the local guard ledger's hash chain - proves no decision has been edited, deleted, reordered, or inserted. Returns ok plus where any tampering was found. This is the 'trust by inspection' check; it reads only local files and trusts nothing remote.
Inputs: no named parameters. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 4 tools
Each tool has a distinct purpose: assess_action for risk assessment without recording, guard_action for pre-execution gating, recent_decisions for history review, and verify_ledger for integrity verification. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case: assess_action, guard_action, recent_decisions, verify_ledger. No deviations.
With 4 tools, the set is well-scoped for a security guard/audit domain. Each tool serves a clear function without redundancy or omission.
The set covers the full lifecycle: risk assessment (assess_action), action gating (guard_action), audit review (recent_decisions), and integrity verification (verify_ledger). No obvious gaps.
Related MCP Connectors
Human-in-the-loop approval for agent actions, with verifiable action-bound receipts.
Decision-assurance for AI agents: an auditable action boundary + receipt before it acts.
Preventive human-approval write-gate for AI agents: writes commit only after a human approves.
Authorize AI agent tool calls before they run: policy-as-code, human approval, signed receipts.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA local-first security gateway and visual dashboard for AI agents that enforces cost caps, blocks prompt injections, and requires approval for dangerous actions.3-
- AlicenseNot gradedqualityDmaintenanceProvides a human-in-the-loop security layer for AI agents by intercepting file operations, explaining them with a local LLM, and enforcing a deterministic policy that requires user approval for risky actions.MIT
- AlicenseNot gradedqualityDmaintenanceA default-deny SQL firewall sidecar for AI agents that enforces per-agent policies on database queries, provides safe rewrites, and maintains a tamper-evident audit chain.AGPL 3.0
- AlicenseNot gradedqualityCmaintenanceA three-stage guardrail agent for LLM-powered coding assistants that reviews proposed actions before execution, blocking destructive commands and maintaining an audit trail.3MIT