AI purchasing authorization

Decide whether an AI purchasing agent is allowed to spend

Warrant turns a human-confirmed spending policy into deterministic purchase authorization. The runtime returns ALLOW, ESCALATE or DENY and cites the clause that governed the decision.

View Pricing Open the Warrant repository

Maturity

Current maturity: a local, single-operator demonstration with Prava sandbox payment sessions. No real-money processing is claimed.

Who it is for

Built for teams placing agents near a purchase

Agent-commerce builders
Payment and commerce infrastructure teams
Procurement automation teams
Enterprise AI teams evaluating policy-led purchasing

The problem

Model judgement is not spending authority

An agent can propose a purchase. The authority to approve, escalate or refuse it must come from a policy a person has confirmed, evaluated by code whose result does not depend on model judgement at runtime.

How it works

From policy to a clause-cited decision

1 · Write policy

A person states spending rules in plain English.

2 · Compile

Claude maps the policy into numbered clauses and exposes ambiguities.

3 · Confirm

A person resolves ambiguity and confirms the mandate.

4 · Propose

An agent submits a purchase proposal.

5 · Decide

Deterministic code returns ALLOW, ESCALATE or DENY with the governing clause.

6 · Act or stop

Only the supported authorized path may reach the downstream sandbox provider.

7 · Record

The decision and available outcome evidence are appended to the authorization record.

By design

The product moment is a refusal

A proposal can sit below every numeric limit and still be denied because its supplier is not approved. The denial cites the exact clause; the provider receives no call.

Evidence

Verified in the repository

A Warrant DENY makes zero outbound provider calls. Only the supported human-approved escalation path can open a Prava sandbox payment session; the ALLOW path is authorized and recorded but is not wired to the provider.

Verified · CL-41

Warrant appends decisions to a hash-chained authorization record. The record is tamper-evident; it has no digital signature and makes no non-repudiation claim.

Verified · CL-42

Warrant currently runs as a local, single-operator demonstration and all payment interaction is Prava sandbox-only. Spend counts at approval and reconciliation that releases expired holds is not built.

Verified · CL-43

Try it

Run the evidence path

The repository includes a keyless test suite, five headless decision scenarios and a local operator console. Provider interaction remains sandbox-only.

Open the Warrant repository

Limits

Trust comes from the boundary

Current limitations

Prava interaction is sandbox-only; no real money moves.

The console is local and single-operator, not a hardened service.

The ALLOW path is authorized and recorded but is not wired to the provider.

Spend counts at approval; release of expired holds is not implemented.

The authorization record is tamper-evident, not signed and not non-repudiable.

Partnership

Evaluate a bounded design partnership

Teams exploring purchasing authorization can open a public GitHub issue with the agent, payment boundary and policy question they need to test.

Start a public product conversation

Put Warrant Guardian in front of your policy

See the refusal path and the evidence record on a task of your choosing.

View Pricing Contact Us