How it works
Every routed money action meets the gate before execution.
Your integration proposes a refund, payout, or ledger write before the provider call. Sevra records Allow, Require approval, or Block. Your caller runs only with an execution token.
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 · ledger_write · journal_entry
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 submitted amount contributes to the numeric score. Currency and direction remain attached to the decision record.
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.
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 three
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 four
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.
Separate safety configuration
Autonomy is not the money verdict.
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.
Start with one test integration.
Start by routing a test integration through the guard. Review its verdicts and reasons before moving a production money path behind the same boundary.