Your AI agent has the same database access you do. That's the problem.

Give an AI agent access to your systems and it inherits your permissions —
all of them. It can read every customer record, delete every product,
send every email, issue every refund. Not because it's malicious. Because
it's authenticated, it's authorized, and nothing between the agent and your
data asks the one question that matters:

"Is this specific action safe to run, right now?"

Your identity provider already checked who the agent is. Your guardrails
already checked whether the prompt was toxic. But a perfectly
authenticated agent, with legitimate permissions and a clean prompt, can
still run the equivalent of DELETE FROM products — and every layer you
have says "looks fine."

That gap is what we built Reeflex
to close. It's open source (Apache-2.0), it runs in front of your
resources, and its entire base policy is five rules you can read in about
a minute.

The five rules

An agent wants to do something. Reeflex turns that action into a small,
boring description — what verb, how many things, reversible or not, does it
leave the system — and runs it past five rules:

• R1 — reads pass. Looking at internal data is allowed. The gate stays out of the way for the overwhelming majority of actions, which are harmless.
• R2 — big irreversible changes in production wait for a human. Force-deleting a broad batch of products in production doesn't get blocked forever; it gets held until a person says yes.
• R3 — system-wide destruction is refused outright. An irreversible, systemic change in production — "delete everything" — isn't a thing you approve. It's a thing you re-scope. It's the one permanent block.
• R4 — everything else is allowed by default. If no high-risk axis matched, the action runs. The gate is a floor for the dangerous cases, not a tax on the normal ones.
• R5 — the session has a delete budget. More on this one below, because it's the rule that catches the clever attack.

That's the whole policy. No machine-learning risk score, no thousand hidden
signatures — five rules, in plain readable code, that you can audit in the
time it takes to make coffee.

And one invariant underneath all five: the gate fails closed. If the
decision engine is unreachable — crashed, partitioned, misconfigured —
nothing goes through. A safety layer that fails open is a safety layer you
don't have.

The clever attack: death by a thousand small cuts

Here's the rule we're proudest of. Say your policy holds any bulk delete
over 20 items. An agent — misaligned, hijacked, or just confused by a bad
instruction — figures out it can delete 500 products by asking a hundred
times for 5 each. Every single request looks innocent. Under most systems,
all hundred go through.

Banks have caught this trick for fifty years. It's called structuring, or
smurfing: breaking one suspicious transaction into many small ones to
slip under the reporting threshold. Reeflex borrows the countermeasure
directly — R5 keeps a cumulative budget per session. The hundredth
batch of five trips the same limit the single batch of 500 would have.
Fragmenting a dangerous action buys the attacker exactly nothing.

We keep saying the policy is readable, so here is R5 — the entire
fragmentation guard, verbatim from the repo:

# R5: session delete budget — fragmentation resistance.
r5_require_approval_budget if {
    prior_deletes := object.get(input, ["cumulative", "count_by_verb", "delete"], 0)
    prior_deletes + input.magnitude.count > delete_session_budget
    not input.approval.present
}

Prior deletes this session, plus this batch, against one budget. That's the
whole trick — and it's the kind of code an auditor can actually sign off
on.

None of these rules are invented. Each one is a decades-old safety
principle pointed at a new target: change management (R2), safety
engineering (R3), transaction thresholds and fraud velocity checks (R5).
New rules for a new domain; old, proven ideas underneath.

What it deliberately does NOT catch

This is the part most security tools won't tell you, so here it is first:
the base policy does not catch everything, and any tool that claims it
does is lying.

• An agent reading 10,000 customer records is just a read. R1 allows it. That's exfiltration, and the base rules don't see it. (A mass-read guard is a natural extension — but it's not on by default, and we won't pretend it is.)
• Publishing one product at the wrong price is a single, reversible edit. Allowed. Correctness of content isn't something impact rules can judge.
• A patient attacker rotating across sessions dilutes the per-session budget.

The five rules govern structural, destructive impact, and they do it
well. They are a strong floor, not a ceiling. The policy is plain code —
extend it in an afternoon.

We think saying this out loud is the whole point. A gate you can't inspect
isn't a gate you can trust.

The other half: nothing happens in the dark

Two things make the rules usable in real life instead of just correct on
paper.

Observe mode. Turn Reeflex on and it changes nothing — it watches. Every
action gets a verdict written to the audit log, but everything still runs.
You get a report of what would have been held or denied, on your real
traffic, before you enforce a single thing. Install it on a Monday, read
what your agents actually did all week, then flip enforcement on with
thresholds you've already tuned.

The decision is yours. When a rule says "wait for a human," Reeflex
doesn't make the second call — it hands you the decision, with the context
to make it in five seconds. A human approves it (HITL), or an agent you
designate does — a private model, a supervisor agent, your call, never the
agent that raised the hold. We call that pattern
AIL — agent-in-the-loop.
Or your existing approval workflow does it. We flag; you rule. And every
handover is recorded: who approved what, when, under which rule. That
record happens to be exactly the evidence an auditor asks for.

The decision path itself has zero LLM in it. Same action in, same
verdict out, every time. We're not using AI to police AI — the whole point
is a layer that's boring, deterministic, and explainable.

Try it in thirty seconds — no install

We run a public evaluation endpoint with a public token. This is a real
engine making a real decision — an agent trying to hard-delete 50 items in
production:

curl -s https://api-dev.reeflex.io/v1/decide \
  -H 'content-type: application/json' \
  -H 'authorization: Bearer reeflex-eval-public-2026' \
  -d '{"action":{"verb":"delete","ability":"wordpress/delete-post"},
       "axes":{"reversibility":"irreversible","blast_radius":"broad","externality":"internal"},
       "magnitude":{"count":50},
       "target":{"environment":"production"},
       "agent":{"session_id":"sess-devto"}}'

{
  "decision": "require_approval",
  "rule": "reeflex.policy/irreversible_broad_prod",
  "reason": "irreversible broad change in production requires human approval"
}

(Response trimmed for readability — the live one also carries a hold_id
and an expiry timestamp. That's not decoration: the engine just created a
real, resolvable hold you could approve through the API.)

The gate is free forever. Everything that keeps you safe — the engine, the
five rules, human approval, observe mode, the kill switch, audit, SIEM
export — is open source and always will be.

What's covered today: Claude Code (every tool call, via a PreToolUse
hook), WordPress/WooCommerce (a standard plugin), and n8n workflows.
Database and GraphQL adapters are on the roadmap — and the adapter contract
is a public spec, so you don't have to wait for us.

pip install reeflex-claude      # governs a Claude Code agent
npm i n8n-nodes-reeflex         # a gate node for your n8n workflows

Run your own engine with one docker compose up, or start against the
public endpoint above. See how it all fits together at
reeflex.io, and the code is on GitHub at
github.com/Reeflex-io/reeflex.
Break it, fork it, tell us where the rules are wrong. The clone that
improves the rules is a clone that improves the standard — and that's a
trade we'll take every time.

Reeflex — a seatbelt for the AI acting on your systems.

Comments

[Alex Shev]

This is the right place to be paranoid. Agent permissions should be narrower than the human's day-to-day database access, because the agent will run more steps, faster, with less instinct for when a query is weird.

[Leo David]

Exactly right — and well put. "More steps, faster, with less instinct for when a query is weird" is the whole threat model in one sentence.

Narrower permissions for agents should absolutely be the baseline (least privilege got more important, not less, with agents). The trouble we kept hitting is that permissions are static answers to a dynamic question. A grant can express "this agent may delete products" — it can't express "deleting 3 products is routine, deleting 500 is an incident," or "the 40th delete this hour is different from the 1st." Scale, velocity, and reversibility live outside the permission model.

So I'd frame it as: scope the permissions as tight as the job allows, then judge the impact of what still fits through. The two layers cover each other's blind spots — and the second one is what catches the day the tightly-scoped agent gets a bad instruction and does something perfectly permitted, 100 times in a row.