Deterministic governance for agent actions
A seatbelt for the AI acting on your systems¶
Reeflex decides — before an agent's action reaches your data — whether it is safe to run, needs a human, or must be blocked. Across any backend, with zero LLM in the decision path: same action in, same decision out, every time.
Where to go¶
-
Get started
Install an adapter and watch Reeflex hold a destructive action in minutes — Claude Code, n8n, or WordPress. Observe-mode first, so nothing breaks.
-
Concepts
The Action Envelope, the five rules, allow / hold / deny, the fail-closed invariant, sessions and anti-fragmentation, and HIL / HOTL / AIL.
-
Adapters
An adapter turns a backend action into an Action Envelope and enforces the verdict. Claude Code, WordPress, n8n — or write your own against the spec.
What Reeflex is, in 30 seconds¶
An AI agent can now write to your database, edit your store, send your emails. Reeflex sits at that boundary. Every write is intercepted, normalized into a universal Action Envelope (verb + three risk axes + magnitude + session), and evaluated by an OPA/Rego policy that asks a sharper question than "is this user allowed?" — it asks "is this action safe, given the impact it would actually have?" The answer is one of three:
- allow — the action proceeds.
- hold — it waits for an approver you trust (a human, or an agent you trust — HITL / AIL).
- deny — it is blocked, with a reason the agent can read.
The engine is OPA/Rego plus classical logic. No LLM, no network, no wall-clock in the decision path — because a safety mechanism should be auditable and reproducible, not a second guess. If the engine is unreachable, it fails closed: nothing goes through.
This is documentation, not the marketing site
For the product pitch, see reeflex.io. These docs are the reference: concepts, architecture, adapters, policy, operations, compliance, and the REST API. Everything here is organized from the honest content already in the repository — including what the base policy does not catch.