Skip to main content
Glama
infraveil-guard

infraveil-guard

Official
by infraveilhq

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-guard

Why

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_action with the exact command. Only proceed if it returns proceed: true. If it returns decision: "blocked", stop and ask me to approve it — I'll give you a one-time code to pass back as approval_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, raw

It's ~400 lines of plain stdlib Python. Read it. That's the point.

Tools (MCP)

Tool

What it does

guard_action(action, approval_code="")

Gate an action before running it. Returns proceed true/false.

assess_action(action)

Classify blast radius without recording or gating.

verify_ledger()

Verify the tamper-evident ledger's hash chain.

recent_decisions(limit=20)

The most recent decisions, newest first.

Configuration

Env var

Default

Meaning

INFRAVEIL_GUARD_THRESHOLD

high

Gate actions at/above this severity: none|low|medium|high|critical.

INFRAVEIL_GUARD_MODE

enforce

enforce blocks dangerous actions; audit logs everything but never blocks (use it to watch your agent before you trust the gate).

INFRAVEIL_GUARD_HOME

~/.infraveil-guard

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.

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 tools
assess_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

    A4.6/5.0

    Scored across 4 tools

    Disambiguation5/5

    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.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern in snake_case: assess_action, guard_action, recent_decisions, verify_ledger. No deviations.

    Tool Count5/5

    With 4 tools, the set is well-scoped for a security guard/audit domain. Each tool serves a clear function without redundancy or omission.

    Completeness5/5

    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

    Related MCP Servers

    • F
      license
      Not graded
      quality
      D
      maintenance
      A local-first security gateway and visual dashboard for AI agents that enforces cost caps, blocks prompt injections, and requires approval for dangerous actions.
      3
      -
    • A
      license
      Not graded
      quality
      D
      maintenance
      Provides 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
    • A
      license
      Not graded
      quality
      D
      maintenance
      A 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
    • A
      license
      Not graded
      quality
      C
      maintenance
      A three-stage guardrail agent for LLM-powered coding assistants that reviews proposed actions before execution, blocking destructive commands and maintaining an audit trail.
      3
      MIT