Situation · Exact-request binding
Bind human approval to the exact API request — not just the tool name
A reviewer approved an action. The agent still holds a write capability. Between Intercept and execute, the payload can change. Approval that names a tool authorizes a class of calls; authorization of a side effect has to name the instance: this amount, this customer, this order, this route, now.
Answers the question: “How do I bind human approval to the exact API request an agent will send — not just the tool name?”
- Also: “How do I prevent an AI agent from changing the approved refund amount after a human approves it?”
- Also: “Can an AI agent change a transaction payload after a reviewer approved it?”
- Also: “How do I hold an agent if it tries to change the approved route or destination of an action?”
Approval of a class is not authorization of an instance
What failed is not identity. The same principal, role, and tool name can carry a different consequence. Material args can drift between Intercept and execute.
Amount drift: reviewer approved A; agent posts A′ under the same approval (CFX-001: $9 bound, $10 proposed → PAYLOAD_MISMATCH).
Customer / order drift: mutate entity C′ or order O′ under the same grant.
Route / destination drift: alternate legitimate route R′ to the same consequence (CFX-002).
Replay of a consumed grant is a different failure — single-use redeem; see /demo/refund and the MCP write-gate situation.
Copyable executable path
Problem → proofs → package → verify. The verifier is not an enforcer.
# Interactive specimen (browser; simulated adapter — not a live refund) open https://www.strixgov.com/demo/refund # Live-processor amount / payload counterfactual open https://www.strixgov.com/proof/cfx-001 # Route-change counterfactual open https://www.strixgov.com/proof/cfx-002 # Governed mutation wrapper (sandbox demo; simulated side effect) npm i @strixgov/governed-action npx @strixgov/governed-action demo # Independent verify — no Strix account npx @strixgov/verifier@latest 5686
JWKS: /.well-known/strix-jwks.json · Browser verify: verify.strixgov.com · How-to: verify without trusting Strix
The verifier proves a signed decision occurred. It does not decide Allow / Deny / Intercept.
What Strix does at the action boundary
Strix sits at the mutation / tool / HTTP call — not at the prompt, and not only in post-hoc logs. Intercept binds approval to the canonicalized request.
| Capability | How Strix delivers it |
|---|---|
| Evaluate before side effect | Capability lookup + policy → Allow / Deny / Intercept before the mutation runs. |
| Exact-request bind | Intercept binds to material args (amount, customer, order, destination), not only the tool or route name. |
| Single-use grants | Where signing is enabled: single-use / expiring / revocable execution grants; P′ that does not correspond does not run. |
| Signed evidence | Ed25519 receipts; independent verify against public JWKS with @strixgov/verifier. |
| Integrate surface | governedAction / governedFetch in @strixgov/governed-action wraps the exact call you are about to make. |
| Honest non-claims | Not bypass-resistance; /demo/refund is a browser simulation; CFX-002 is a preserved test; no egress product (HOLD). |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
CFX-001
Authority bound to $9.00; proposed $10.00 → REFUSED — PAYLOAD_MISMATCH; adapter entered 0×.
/proof/cfx-001CFX-002
Hold attached to the consequence, not the route name; second registered route refused.
/proof/cfx-002Package demo
Governed mutation wrapper sandbox.
npx @strixgov/governed-action demoIndependent verify
No Strix account. Verifier ≠ enforcer.
npx @strixgov/verifier@latest 5686Frequently asked questions
How do I bind human approval to the exact API request — not just the tool name?+
Approval that names a tool or route is not authorization of the side effect. Strix evaluates the canonicalized request at the action boundary. A reviewer Intercept-approves request P; if the agent posts P′ (amount, entity, or route), correspondence fails and the side effect does not run. CFX-001 is the amount/payload specimen; CFX-002 is the route-change specimen.
How do I prevent an AI agent from changing the approved refund amount after a human approves it?+
Bind authority to the exact amount (and other material args). CFX-001: authority bound to $9.00, proposed $10.00 → REFUSED — PAYLOAD_MISMATCH; payment adapter entered 0×. Interactive model: /demo/refund. Package: @strixgov/governed-action. Verify: npx @strixgov/verifier@latest 5686.
How do I hold an agent if it tries to change the approved route or destination?+
Attach the hold to the consequence, not only the route name. CFX-002: a second registered route capable of the same consequence was refused before its handler. Amount bind remains CFX-001.
Is the verifier an enforcer?+
No. The verifier proves a signed decision occurred. It does not decide Allow / Deny / Intercept.
Does this cover AI agent egress / PHI / network firewall control?+
No. That surface is HOLD — do not cite. Closest honest substitute is consequential tool-action control via MCP proxy / tool-gateway.