How it works
From proposed action to logged decision.
An agent that can issue one refund can issue 1,204 of them. Route each money action through Sevra before the provider call, then let the returned verdict decide what your code does next. Here is the path an integrated action takes.
The path of one action
Step one
An agent proposes an action.
Your integration proposes the action to Sevra before it calls the money system. The refund, payout, or ledger write arrives as a guard request first, and your code executes only after an Allow verdict with an execution token.
Agent
Proposes an action
agent_42 · write:ledger
Sevra · guard
Evaluates, records, returns
caller must honor the verdict
Production
Billing · ledger · payouts
caller proceeds only on Allow
Step two
Sevra scores the risk.
The deterministic engine combines the submitted action class, movement, protected target, repeat-pattern signal, and operator policy. It records the resulting score and reasons, then returns Allow, Require approval, or Block.
Action class
A deterministic taxonomy sets the action's base reversibility. Refunds, payouts, transfers, and ledger writes start as irreversible.
Reported movement
The amount, currency, and direction your integration submits contribute to the decision record and score.
Protected target
The submitted target and action class are matched against protected paths such as payments, ledger, auth, treasury, and data loss.
Repeat pattern
For money actions, the rolling duplicate detector can compare the submitted class, target, amount, currency, and idempotency source.
Policy
Your explicit rules set a base verdict. Matched protected paths, duplicate signals, and block-level scores can only make it stricter.
Step three
Autonomy is a safety setting.
Each agent carries a configured level from 0 to 4 for the remediation path. It is not a pricing meter or a shortcut around the money guard. Routed money actions still receive their verdict from policy, protected paths, deterministic scoring, and duplicate signals.
- 0
Observe
The shadow-only configuration label. Proactive guard calls still return and enforce their real verdict.
- 1
Notify
Notify on eligible non-money remediation. This is not permission to move money.
- 2
Suggest
Suggest eligible changes for review. Money execution still follows the guard verdict.
- 3
Approve
Apply reviewed changes within policy and the current reviewed-change safety boundary.
- 4
Autonomous
Act only where policy, protected paths, and current safety controls permit.
The guard returns one of three verdicts
Allow
Returns an execution token after the gate decision is recorded.
Require approval
Returns a held ticket and attempts to attach a case file for a human decision. The hold does not depend on that evidence succeeding.
Block
Returns no execution token and records the reasons available to the gate.
Step four
When it escalates, it can attach a case file.
An escalation is not limited to a bare yes-or-no prompt. When Sevra holds a routed action, it attempts to attach a case file with the action, score, reasons, and approval requirement. The hold remains enforced if that evidence is unavailable. Eligible refunds and payouts can add Stripe test-mode reproduction evidence when you configure a test key.
A decision you can make in one read, not a guess in the dark.
Step five
Decisions leave durable request evidence.
Sevra persists each routed decision and its reasons on the guard request. A would-be Allow fails closed if its initial gate-event write fails. Some hold, block, and approval annotations are best-effort today, so the lifecycle stream is not presented as complete, cryptographically immutable, or tamper-proof.
Gate decisions carry recorded reasons. Approval outcomes carry attributable decision entries.
See it run on your stack.
Start by routing a test integration through the guard. Review its verdicts and reasons before moving a production money path behind the same boundary.