The problem Warrant solves

An AI agent can decide what to buy. It can't prove it was allowed to.

Today the only real control is a human clicking approve on every action — which stops scaling the moment agents do anything at volume, and turns the human into a rubber stamp. The alternative, handing an agent a payment credential and hoping, is worse.

Warrant is the authorization layer in between. A human writes their spending rules in plain English. Claude compiles that paragraph into numbered, enforceable clauses and flags every ambiguity it finds instead of guessing — the human resolves those flags before anything becomes enforceable.

After that, every proposal an agent makes is evaluated by deterministic code against the confirmed warrant, and comes back ALLOW, ESCALATE, or DENY with the governing clause cited. Claude compiles the policy; it never makes the runtime decision.

Only an ALLOW or an approved ESCALATE ever opens a Prava sandbox payment session. A refusal makes zero outbound calls — no session, no credential requested, nothing to cancel or reverse. Every decision lands in an append-only, hash-chained authorization record that exports as JSON.

The refusal is the product. Anyone can build an agent that buys things. The hard part is an agent that can prove it was allowed to.

Challenges I ran into

Ambiguity is the real problem, not parsing. My four-sentence policy looked unambiguous to me. Claude found three genuine conflicts in it — including one between "approved suppliers only" and "never buy from a new supplier without approval": is an unknown vendor refused outright, or escalated to me? Both readings are defensible. Rather than let the model pick, the compiler surfaces each conflict as a flag the human must resolve before the warrant becomes enforceable. Resolving that flag on camera is the most honest moment in the demo.

Keeping the model out of the decision. It's tempting to let Claude judge proposals too. I deliberately didn't. The evaluator's input type structurally excludes clause English — it can only see structured constraints — so the allow/escalate/deny outcome is code, reproducible and testable, not a generation. 125 tests pin that behaviour, including that a DENY makes zero outbound calls even when an approval is forcibly injected.

Provider reality. Sandbox payment sessions created cleanly 15 times out of 15, but the credential leg failed in five distinct ways over a day of testing — embedded frames stalling the FIDO clock, single-use links burning on reload, and one clean identity verification that still returned a provider-side credential error. Each mode is now either closed by design or covered by a documented fallback. The last one turned out to be a stale enrolled card; the full passkey flow completed once the correct test card was enrolled.

Spend counts at authorization, not settlement. A lapsed session keeps its headroom consumed. That's the correct direction of error for a spending cap — ten in-flight sessions must not evade it — but reconciliation isn't built, and the export carries a hold/settled/not-counted status so it could be added. It's disclosed in the README rather than hidden.