View on GitHub · 174
Docs

How it works

GitHub · ★ 174

Deterministic policy decides, under fixed risk weights. ML only produces evidence. The verdict stays reproducible, and the record is signed, chained, and verifiable offline.

iaga-verify · offline
# hand an auditor the chain and one public key
iaga-verify chain.json --key <hex>

CHAIN OK  // signatures + hash links verified, no server

A deterministic engine decides

Every allow, review, or block verdict is issued by the deterministic risk engine. It is deterministic under fixed risk weights: the weights are runtime state, and they change when you feed the engine signal through POST /v1/risk/feedback. Same input, different weights, different verdict. Machine-learning models produce scores the policy can read, never the decision. Models are pinned by digest and re-read from the receipt on replay, not re-run. That is what makes a run reproducible from its own record: anyone holding the public key can show the chain was not altered after signing. Legal non-repudiation needs a qualified signature, which is Enterprise · planned.

Dictum — a typed policy DSL with deterministic tree-walk evaluation and a Hindley-Milner type checker — layers on top when you load a bundle with iaga serve --policy. The merge is stricter-wins: an overlay can only tighten the engine’s verdict, never loosen it. Dictum builtins act on the real payload: secret_ref() detects credentials and PII, and url_host() enforces a per-host egress allowlist. Every block or review records its cause in the signed receipt, and receipts hash-chain across a whole session into one tamper-evident hash chain.

# type-check a policy (always available)
iaga policy check no_pii_egress.dictum

# load a Dictum bundle as a live overlay on top of the YAML profile
iaga serve --policy strict.dictum

Every verdict is signed and chained

Each verdict becomes an Ed25519-signed receipt linked to the previous one in a hash-chained append-log, per run. Replay re-verifies the whole signed chain offline. The signer is a pluggable trait, and the open build ships one implementation: it reads a 32-byte Ed25519 key from a file path, so you can inject your own key (BYOK) from any secret store that can materialize a file.

# list runs, then replay one
iaga replay --list
iaga replay <run_id>

# verify signatures + hash links only
iaga replay <run_id> --verify-only
Signed receipt✓ verified

run_id
9f2c…a17b
verdict
ALLOW
prev
3a8e…0c44
body_hash
b71f…9de2
sig · ed25519
5e9a…f3c1

Anyone verifies it offline

Export a run, then verify it with the standalone iaga-verify binary. It has no database, no server, and makes no call home. It checks the Ed25519 signatures and the hash chain against one public key. It is the artifact you can put in front of an auditor: one file, one key, no server.

# export a run, then verify it anywhere, fully offline
iaga replay <run_id> --export chain.json
iaga-verify chain.json                      # -> CHAIN OK
Hash-chained append-log
R0R1R2R3head

It is a layer, not a replacement

IAGA Sentinel records signed evidence next to the agent stack you already run. Point any SDK at the HTTP sidecar (POST /v1/inspect), or run the MCP proxy to sign every tool call. Whatever routes or enforces underneath, the evidence layer goes on top of it. Signed receipts can also flow into your OpenTelemetry stack as spans.