pliuzv0.1.x

Concepts

The mental model

Five nouns and one chain. Once these click, the rest of the docs are reference.

What is an approval gate for AI agents?

An approval gate pauses an AI agent before it executes a sensitive action — a tool call that can move money, delete data, or send a message — and requires a human to approve, reject, or edit it first. The action runs only once a person has authorized it, and that decision is recorded. Pliuz adds approval gates to any agent framework with a one-line wrapper, routes the decision to Slack or a web inbox, and writes it to a tamper-evident audit trail.

The flow

lifecycle
agent calls a gated tool
        │
        ▼
   POST /approvals  ──►  policy evaluation (JSONLogic, no LLM)
        │                      │
        │              auto-approve / auto-reject / notify
        ▼                      ▼
   pending  ────────►  human decides (Slack / web inbox)
        │                      │
        ▼                      ▼
   agent unblocks  ◄──── approved / edited / rejected
        │
        ▼
   tool executes  ──►  POST /:id/execution  ──►  append-only hash chain

Agent

Your AI process. Each agent has its own API key (pli_live_…) — revocable individually without rotating the rest. Agents are soft-deleted on revoke (forensics preserved), never hard-deleted.

Tool

A function that can touch the real world (pay, delete, send). Registered with its declared risk. A tool flagged requires_approval=false short-circuits to auto-approve with an honest provenance flag.

Policy

A declarative rule (JSONLogic, ~12 whitelisted operators, no LLM in the critical path) deciding what happens when an agent wants a tool: auto-approve, auto-reject, or notify → a human in the matched approver_group decides. Policies are versioned (immutable snapshots) and can run in shadow mode to test in production without affecting traffic.

Approval

One gated call. It carries the tool, args, originator and context. A human can approve, edit & approve (the edited args are what execute — never the originals), or reject with a reason. Authorization is enforced identically across REST, web inbox, and Slack: only an admin or a member of the policy's approver group (or an active delegate) can decide; auditors are read-only.

The hash chain

Every event lands in an append-only table, each row chained by SHA-256 over the previous event's canonical payload, per tenant. Anti-UPDATE/DELETE/TRUNCATE triggers enforce immutability at the database. The args that were approved are anchored by hash, so rewriting them after the fact breaks the chain.

Independently verifiable
Export the chain with its signed v2 manifest and verify it offline with our open-source verifier. Pin the signing key through an independent channel: a key delivered inside its own export proves consistency, not identity.

Glossary

Approval gate for AI agents
A control that pauses an AI agent before it executes a sensitive action (a tool call) and requires a human to approve, reject, or edit it first, so the action runs only once a person has authorized it.
Human-in-the-loop approval
A pattern where a person reviews and authorizes an agent's high-risk action at runtime — before it executes — rather than reviewing logs after the fact.
Tamper-evident audit trail
An append-only, cryptographically hash-chained record of every agent decision — who approved what, and when — that can be verified offline, so the history cannot be rewritten without detection.
Policy-as-code
Declarative, version-controlled rules that decide which agent actions are auto-approved, auto-rejected, or routed to a human. Pliuz uses JSONLogic, with no LLM in the decision path.
AI agent control plane
The system that governs how autonomous agents act in production — enforcing policies, human approvals, and audit — separately from the agent's own logic.
Runtime enforcement
Blocking or allowing an agent action at the moment it is about to happen, as opposed to compliance documentation or observability, which describe what already happened.