Skip to content

Financial control for AI agents

Control the money your agents move.

Route each refund, payout, or ledger write through Sevra before the provider call. The guard returns Allow, Require approval, or Block, with the reason and an execution token only when your caller may proceed.

Control gateIllustrative demo
Illustrative caller-routed requests receiving Allow, Require approval, or Block. The selected five-dollar refund is held after a rolling duplicate signal and has no execution token.
TimeActionEvidenceVerdict
08:32:01read · txn_9920read onlyallow
08:32:04payout · vendor · acct_3301money movementrequire approval
08:32:07refund · $5 · card_••4402repeat #1,204require approval
08:32:15transfer · treasury_outprotected pathblock
Request · #1,204Require approval
refund$5.00 USDcard · ••4402
Evidence
Rolling duplicate signal
Durable state
Held for approval
Execution token
Not issued
Sevra returns a verdict and request-level record. It does not hold or move funds.

Sevra decides and records. It never holds or moves funds.

The problem · illustrative pattern

A $5 refund to the wrong customer, 1,204 times.

Each request can sit under a spend limit while the rolling pattern carries far more risk. An agent that can issue one refund can issue thousands. A guard needs the action, target, reported movement, policy, and repeat signal — not the amount alone.

Illustrative · without guardUnbounded
read · txn_9920provider called
refund · $5 · card_••4402 · request #1,204provider called
payout · vendor · acct_3301provider called
read · acct_*provider called
transfer · treasury_out · ext_bank_71provider called
5 provider calls · no gate verdicts
Illustrative · with SevraControl gate
read · txn_9920allow
refund · $5 · card_••4402 · request #1,204require approval
payout · vendor · acct_3301require approval
read · acct_*allow
transfer · treasury_out · ext_bank_71block
2 allowed · 2 require approval · 1 blocked

How it works

Every routed money action is evaluated before your caller runs it.

Your integration submits a refund, payout, or ledger write to the guard before the provider call. Sevra returns Allow, Require approval, or Block; your code honors that verdict and executes only when an execution token is present.

Illustrative guard flowsample sequence

input

Action

refund

Movement

$5 USD · card_••4402

Agent

agent_07

decision engine

  • Action class
  • Reported movement
  • Protected target
  • Repeat pattern
  • Policy

decision → action

Allow

Caller may run

token issued

decision recorded

Require approval

Wait

held ticket

case file attempted

Block

Do not run

no token

reasons recorded
Application record · gate decision and reasonsview logs →

Reversibility scoring

Judged by whether it can be undone.

A dollar threshold cannot distinguish one wrong refund from a rolling sequence of them. Sevra's deterministic engine combines the submitted action class, reported movement, protected target, repeat-pattern signal, and operator policy. The profile shown here is an illustrative view of those controls, not a live customer metric.

Illustrative policy profile
3.3 / 4.0
sample index
01234Reversibility3.4+0.8Containment3.1+0.7Auditability3.8+0.8Approval coverage3.3+0.8Blast-radius control2.9+0.7Repeat pattern3.5+0.7
Illustrative profileSample baseline

Escalation

A held action can carry a case file. Not just a ping.

This illustrative ESC-2207 case shows the 1,204th same-pattern refund request held without an execution token. The case file carries the action, score, reasons, and approval requirement. In the configured scenario shown, an eligible refund also includes Stripe test-mode reproduction evidence.

CASE FILE· ESC-2207illustrative09:45:40Guard requestrefund $5 · request #1,204 · billing/payments09:45:40ClassifiedPROTECTEDpayment path · rolling duplicate signal09:45:41Case file openedopenedaction, score, reasons, and approval requirement recorded09:45:43Test evidence addedreproducedeligible refund · tenant Stripe test key configured09:45:44Decision reasonspayment path · rolling duplicate signal09:45:44Escalatedawaitingcase file ready, awaiting human decisionhuman decision requiredApproveDeny

Agent safety settings

Configure autonomy separately from price.

The 0–4 value is a safety setting for each agent, not a plan entitlement. It does not replace the proactive money verdict or grant permission to bypass the guard. Policy, protected paths, deterministic scoring, and repeat signals still decide each routed money action.

L0

Observe

Shadow-only label; guard verdict still applies.

L1

Notify

Notify on eligible non-money remediation.

L2

Suggest

Suggest eligible changes for review.

L3

Approve

Apply reviewed changes within the safety boundary.

L4

Autonomous

Act only where policy and safety controls permit.


Why it holds

The judgment is the product.

Start with one guarded money path. The same explicit-boundary pattern can extend to deploys, migrations, and database writes as those integrations ship.

Deterministic judgment

For caller-routed actions, Sevra combines action class, reported movement, protected targets, repeat signals, and policy into an explicit verdict.

A human on the hard calls

When the guard returns Require approval, the action stays held without an execution token while a person reviews the available request evidence.

A case file, not a ping

A held action can attach a diagnostic case file with its action, score, reasons, and approval requirement. The hold remains enforced if case-file creation or enrichment is unavailable.

An attributable application record

Each routed decision is persisted on its guard request. A would-be Allow requires its initial gate-event write; some hold, block, and approval annotations remain best-effort.

Product directionshipped wedge → expansion
DATABASE WRITESMIGRATIONSDEPLOYSMoneyrefunds · payouts · ledger

Money is the shipped wedge. The outer rings show expansion direction, not current coverage.

Route the money call. Keep the gate.

Start with one caller-routed action in a test integration. Review the verdict and reasons, then put the same explicit boundary in front of a production money call.