Know the blast radius
Every task is scored for what it could break.
Drop and recreate the production analytics table.
- write
postgres.write
DROP TABLE events
The problem with treating every action the same
A flat approval flow can't tell the difference between an agent drafting a reply and an agent wiring money or dropping a database. So teams pick one extreme: review everything and grind to a halt, or review nothing and pray. The signal that should drive the decision, how irreversible and far-reaching the action is, never gets measured, so it never gets used.
How risk assessment works
Blast-radius scoring
Each task is scored on reversibility, scope, and sensitivity of the tools it requests, surfaced as a low / medium / high pill on the approval.
Risk-based gating
Set thresholds: auto-approve low risk, require a human above a line, hard-block the truly dangerous.
Context-aware
The same tool scores differently by scope: github.read on one repo is not github.write across the org.
Tuned to your tolerance
Adjust where the lines sit per team or environment, so staging moves fast and production stays careful.
Human attention lands on the few tasks that could actually hurt.
It's one of six power-ups you get from approving the task instead of the tools.
Risk assessment
Every task is scored for how much damage it could do if approved. Low-risk work flows straight through; high-blast-radius work waits for a human.
Let your agents fly. Safely.
Free to start for solo developers. Sign up and put a gateway in front of your agents in minutes. No credit card required.