AI Agent Spend Guardrail & Receipt Audit Workbench

Agent Transaction Presets (Click to Test Counterfactuals)

Cryptographic Spend Policy

Max Single Tx Cap $150.00

Daily Velocity Budget Cap $500.00

Allowed Vendor Whitelist

Allowed Expense Categories

Pending Transaction Request

Requested Amount ($)

Vendor Name

Category

Real-Time Guardrail Policy Evaluator

Daily Budget Consumption $345.00 / $500.00

Prior Spend: $225.00 Remaining Budget: $155.00

Local OCR & Receipt Text Parser

Receipt Text / Image OCR Input

Extracted Key-Value OCR Proof

Casper Wallet Daily Transaction History

Tx ID	Vendor	Amount	Category	Status

Five local checks decide a simulated spend result

Your browser does not support video.

Read the explanation

Two stored history entries total two hundred twenty-five dollars. A one hundred twenty dollar candidate produces projected daily spend of three hundred forty-five. Remaining budget is calculated before the candidate: five hundred minus two hundred twenty-five equals two hundred seventy-five. Evaluating a candidate does not append a new ledger entry or transfer money. Five checks cover the single transaction cap, daily cap, case-insensitive vendor membership, category membership and receipt amount agreement. Equality is allowed at either cap. Receipt agreement requires a positive extracted total and an absolute difference below one cent. The default Cloudflare candidate satisfies all five local conditions. This is a browser demonstration, not an enforced payment authorization. Receipt parsing uses a regular expression and the first matching amount. If a line item contains a dollar sign followed by one hundred twenty before a later Total Paid of one hundred thirty, it extracts one hundred twenty. Without a match it takes the largest decimal number; missing date and invoice receive fixed defaults. This is text parsing rather than image OCR. A simulated proof signature and exported JSON are not independent cryptographic evidence.

Agent Spend Guardrail Logic and OCR Verification

How does an automated payment workbench evaluate agent transaction guardrails against prior spend history and invoice text?

This workbench demonstrates client-side policy evaluation for automated payment requests. It tests five independent checks: a single-transaction ceiling, an aggregate daily spend cap, vendor whitelist membership, category matching, and exact total reconciliation between the requested amount and the parsed receipt text. A transaction is authorized only when all five guardrails evaluate to true.

The workbench operates entirely in local JavaScript using regular expressions to extract amounts from raw text rather than a computer-vision OCR model. Furthermore, telemetry signatures and 'Casper Dollar' labels are simulated demonstrations and do not execute consensus transactions or cryptographic smart contract proofs on the live Casper Network.

Try a worked example

Click the 'Unauthorized SaaS' preset button. The requested vendor changes to Notion Labs Inc ($140.00 in Productivity). The policy engine evaluates the list of allowed vendors and categories, flagging both 'Approved Vendor Whitelist' and 'Category Match Filter' as VIOLATION. The status banner updates to 'GUARDRAIL VIOLATION — TRANSACTION REJECTED' while leaving the ledger history intact.

Five-Rule Decision Pipeline

Every transaction evaluation calculates current cumulative spend by summing executed prior ledger entries ($180.00 + $45.00 = $225.00 in the initial state) plus the pending amount ($120.00 = $345.00). It then verifies that the pending sum satisfies the single-transaction cap, daily cap, whitelist arrays, and receipt total match.

Text Heuristic Matching vs Vision OCR

The local parser searches the text area using regular expressions for keywords like 'Total', 'Amount', or currency signs, falling back to the highest two-decimal numeric token. In production deployment, enterprise agent guardrails require cryptographic signature verification or attested multi-party audit controls rather than client-side regex matching.