DemigardGuard

Authorization and evidence layer

Half the judgment is yours.

Demigard Guard is the authorization and evidence layer for AI agents that touch infrastructure. The agent proposes. Policy decides. Every action leaves a record you can defend.

Read the design Docs index

01The problem

Agents already have the reach. They do not have the boundary.

  1. Agents delete pods, scale deployments, rotate secrets and run cloud CLIs today.

  2. Allow/ask/deny rules inside the agent are UX. The agent can still route around them.

  3. What is missing is a boundary the agent cannot cross, and a record of every crossing.

02The loop

Propose, weigh, decide, record.

The guard loop, left to right An agent proposes a plan to guardd. The policy engine decides, and the plan is hashed and stored. An action that requires approval branches up to a human approval gate before it can reach the executor. The executor acts with guardd's credentials, and the evidence record is written before the response returns. Agent no infra credentials propose guardd · trust domain Policy deterministic rules Plan store hash + step state requires approval Human approval T2 / T3 · signed plan hash approve Executor guard-held credentials execute Evidence record written before the response
The guard loop, top to bottom An agent proposes a plan to guardd, where the policy engine decides and the plan is hashed. Actions that require approval pass through a human approval gate for T2 and T3. The executor acts with guardd's credentials, and the evidence record is written before the response returns. Agent no infra credentials guardd · trust domain Policy deterministic rules, under 5 ms Plan store hash + step state Human approval T2 / T3 only · signed plan hash T0 and T1 skip this box Executor guard-held credentials Evidence record written before the response
Nothing reaches your infrastructure without passing the guard, and every crossing is recorded before the response returns.

03Tiers

Four tiers, fixed semantics.

Tier What happens
T0read allowed, logged, nobody is paged
T1reversible write allowed, dry-run first, verified after
T2destructive held until a human approves the blast radius
T3exec and secrets denied by default, per-request approval, timeboxed

Default deny. An unknown tool, verb or surface is T3. Approval binds to a hash, never to a description.

04Why it is different

Four claims, each one checkable.

  • Enforce where the credential lives.

    Not a proxy the agent can route around — the agent holds no infrastructure credential at all.

    Why it mattersA prompt is not a boundary when the process beside it holds the kubeconfig.

  • Approve the plan, enforce the step.

    Approval binds to a plan hash; each step is a single-use capability with a short TTL.

    Why it mattersAn edited plan no longer matches the hash, and a spent capability cannot be replayed.

  • Evidence, not logs.

    Intent, dry-run, verdict, approver, result, verification, rollback — one reviewable record per action.

    Why it mattersA log line says something happened. The record says who approved what, and what changed.

  • Framework-neutral.

    MCP, LangGraph, ADK, Strands, Claude Code — one audit trail instead of five per-framework permission systems.

    Why it mattersAdd a second framework without adding a second approval system.

05Documents

The design is written down.

06Status

Design phase. Local-first. No cloud dependency. The specification is public in the repository.

Repository