ONE ACTION UNDER CONTROL / 01
Approval has a boundary.
Try crossing it.
An agent wants to refund $4,200. Authorize it, change the request, then try using the approval twice.
Runs entirely in your browser.
Sample data. No payment is initiated.
01 / REQUESTED ACTION
Issue a refund
- Agent
- refund_agent
- Payment
- demo_payment_1042
- Currency
- USD
The walkthrough starts with a $4,200 refund.
02 / AUTHORIZATION
An action is waiting.
Start by attempting the refund without an authorization. Follow what reaches the simulated payment adapter.
03 / SIMULATED PAYMENT ADAPTER
No refund operation invokedFOLLOW THE RESULT
Inspect the evidence.
Each authorization or execution decision creates a signed demonstration record. Verify the original, then alter a copy to see signature verification fail.
| STEP | DECISION | REASON | ADAPTER CALLS |
|---|---|---|---|
| Attempt the refund to create your first record. | |||
BROWSER-GENERATED KEY / ECDSA P-256
Evidence is yours to inspect.
Session keys are created locally. These records are not Strix production receipts.
View the latest signed record
No record yet.
Verification checks this session’s signatures and record chain against the included public key. It does not establish trusted Strix identity or prove a real payment occurred. A modified copy never changes your original evidence.
THE ENGINEER’S QUESTION
Where does the control sit?
At the call that produces the effect. This walkthrough models exact-request binding and one-use authorization before a simulated refund adapter.
- How do I let an AI agent issue a refund for an approved amount — only once?
- How do I prevent an AI agent from changing the approved refund amount after a human approves it?
FAQ — refund once / change after approve
How do I let an AI agent issue a refund for an approved amount — only once? This walkthrough models exact-request binding and one-use authorization before a simulated refund adapter. Authorize amount A for the sample payment; change the amount or reuse the authorization and the simulated adapter is not invoked. It is an in-browser model (ECDSA P-256 session keys), not a live processor refund and not a production Strix receipt. For a live-processor counterfactual of amount bind, see CFX-001.
Can the agent change the refund payload after a reviewer approved it? If approval is bound to the exact request, a changed amount is a different action. In this demo, a mutated request does not consume a valid grant and does not call the simulated adapter. CFX-001 records the same correspondence failure against a live charge (PAYLOAD_MISMATCH).
Executable path: /demo/refund · /proof/cfx-001 · /situations/bind-approval-to-exact-request · npx @strixgov/governed-action demo · npx @strixgov/verifier@latest 5686
agent requests a refund
→ check authorization for this exact request
→ refuse changed or consumed authorization
→ consume valid authorization
→ invoke the refund adapter
→ record the outcomeReal deployment requires server-side enforcement, atomic consumption, protected credentials, and controls over alternate execution routes. This browser model is editable by its visitor.
YOUR NEXT ACTION
What is holding your
agent out of production?
Bring one consequential action. Start a One Action Under Control evaluation with its execution route, approval conditions, and the proof you need.
Explore Strix’s published proof demo ↗That separate walkthrough also uses demonstration evidence.
Production evidence you can verify without a Strix account: npx @strixgov/verifier@latest 5686 · JWKS /.well-known/strix-jwks.json · how-to verify without trusting Strix · situation bind approval to exact request.