WarrantCan you rely on what an agent decided? Ask for the record, not the data.
Warrant records every consequential decision your AI agents take: what allowed it, what it relied on, and who vouched for each piece of evidence. Evidence is held by digest, so a risk team, an auditor or another organisation can check the record without ever holding your customers' data.
pip install "warrantai[policy]"Open source, Apache 2.0 · Python 3.10+ and Node.js 18+ · runs entirely in your environment · built in Bengaluru
- Decision
- approve LN-7731 credit.msme.approve
- Acted by
- credit-agent 3.0.1 · laya@55cf4c4ebb4e/multilingual
- Had to be true
- metOB-1 Bureau pull from a named bureau, no older than 30 days
- metOB-2 GST turnover verified by the partner's data agent, warranted
- Evidence
- admittedbureau_pull from cibil
- admittedpartner GST verification from partner-data
- self-attestedpartner's message: filings verified from self
- Relies on
- partner-data's record 01M40T62…622C, committed and signed by partner-data
- Verdict
- committed proposed → warranted → committed
Checking the seal in your browser…
A real record from the SDK, from the worked loan below. Signed with a demo key whose seed is public, so it proves nothing outside this page.
Across seven models, agents claimed a task was complete 28.7 to 37.9 percentage points more often than the official evaluator confirmed it.
From execution logs alone, the best automated method found the agent behind a multi-agent failure 53.5% of the time, and the failing step 14.2%.
A record earns its seal. An agent's say-so never does.
An agent may claim anything. Your own policy says what has to be true, and which providers you accept for it. Seven rules decide whether each piece of evidence counts, and every rejection is written onto the record with its reason, so any verifier can recompute the verdict. The specification is open, CC BY 4.0: read version 0.2.
Seven rules decide whether evidence counts
- No self-attestation. The acting agent never supplies the evidence for its own obligation.
- Qualified providers. Only providers your policy names for that kind of evidence count.
- Freshness. Evidence too old at the time of the verdict is rejected.
- Digest-bound. Every admitted item carries a hash of what it was.
- Linked handoffs. An agent relying on another's output cites that agent's record, and never treats its claims as evidence.
- Type match. A bureau pull cannot stand in for a document it is not.
- Accountable humans. A reviewer is named and linked, by digest, to the exact material they were shown.
A lifecycle that cannot skip a step
proposedThe agent says what it intends.pending evidence / escalatedObligations are open, or policy sent it to a person.warranted or refusedEvery verifiable obligation met, or the answer is no.committedActed on. Reachable only from warranted.
Every change of state is a new record; history is never edited. Sensitive evidence is held as a salted digest with the salt in a sidecar: delete the sidecar and the personal data is gone while the signed record still verifies.
L1 · Recorded
Every record is chained and signed by a key the issuer has published. For any developer.
L2 · Warranted
Evidence rules enforced, and actions blocked without a warrant. For regulated workflows.
L3 · Attested
Checkpoints co-signed by an independent witness, optionally anchored to a public chain. For auditors, regulators and counterparties.
What a signature does not prove. It shows the record was sealed by the holder of the issuer's key and not changed since. It does not show the issuer never rewrote its own history before anyone else saw it. A witness that holds no records, and co-signs a checkpoint only when the new tree provably extends the last one, is what closes that.
What we do not claim. Whether records like these are admissible as electronic evidence in an Indian court, under section 63 of the Bharatiya Sakshya Adhiniyam 2023, is a question for a legal opinion. Blockchain is used, if at all, as a notary for a checkpoint, never as the ledger.
Share proofs, not data.
Between organisations, shared databases have never won; protocols have. Regulation forbids pooling customer data, no bank writes its credit decisions where a rival can read them, and agents decide too often for any consensus system to hold. So what crosses the boundary is small: a signed record and the digests behind it. This is the loan in the record above.
Partner data firm
GST agent
Verifies the applicant's GST filings. Evidence: the GSTN response, held as a salted digest.
Issues a signed record: committed
Co-operative bank
Credit agent
Cites the partner's record as its parent and pulls the bureau itself. The partner's own message is offered too, and rejected as self-attested.
Warranted, then committed
Sanction agent
Releases payment only on a warranted credit record, with fresh evidence and a named officer above the limit.
Six months later the loan defaults
The turnover turns out to be overstated. Without records, the bank has three logs in two companies and the regulator gets a narrative. With records, a verifier walks the parent links in minutes: either the partner's evidence digest does not match the GSTN response, and the fault sits in its step, or it does, and the fault is further upstream.
Illustrative. Locating the fault is not assigning liability: the contract between the parties decides who pays.
It works when only one side adopts
If the partner issues no records at all, the bank's gate treats its message as an unproven claim and refuses to warrant the credit decision until the bank's own accepted provider confirms the fact. The bank is protected on day one.
See which real decisions your change flips, before you ship it.
The SDK records decisions, checks them against your written policy, and replays real past decisions against your next prompt, model or policy.
approve when bureau score ≥ 720, on the larger modelapprove when bureau score ≥ 750, on a cheaper model
- Decisions that flip
- 0 of 200
- Flipped loans that later defaulted
- 0
- Cost per decision
- ₹3.15
| Loan | Decision | What happened to the loan |
|---|---|---|
LN-40000 | refer | not known yet |
LN-40002 | approve | not known yet |
LN-40003 | refer | performing |
LN-40032 | approve | default |
LN-40039 | approve | default |
LN-40042 | approve | not known yet |
LN-40047 | approve | default |
LN-40121 | approve | performing |
Wrap the decision, not the model
The policy check runs in-process, 0.26 ms at p99 in our benchmark. Recording is queued on a background thread; if the store is down, records spill to disk and the agent keeps working.
# released today
with w.decide("credit.approve", subject=loan.id) as d:
verdict = d.check(amount=loan.amount, bureau_score=score, foir=foir)
d.evidence("bureau_pull", uri=bureau.uri, content=bureau.raw)
if verdict.allowed:
d.act("approve", summary=result.summary)
w.outcome(subject=loan.id, label="performing") # months laterOr start from the traces you already have
warrant import rebuilds decision records from OpenTelemetry exports and checks each against your policy after the fact. Imported records are labelled origin: imported: findings, never evidence sealed at the time.
$ warrant import traces.jsonl --taxonomy taxonomy.yaml --policy policies --dry-run
read 24 span(s) in 6 trace(s) from 1 file(s)
would write 6 record(s) (dry run) to stream 'lending-import' with origin: imported
credit.approve: 6 decision(s), 6 with inputs, 6 with model calls checked against COL-02@2026.1, CR-07@2026.3
allow 3 deny 1 escalate 2 unchecked 0
3 decision(s) outside mandate:
LN-30002 escalate CR-07 clause 4.3 Refer tickets above 5,00,000 to a credit officer
LN-30003 deny CR-07 clause 4.1 Decline below bureau floor
LN-30004 escalate CR-07 default no clause matchedWhat you can install today, and what is still coming.
New since 0.7: the Agent Decision Record
- Issuer signing: an Ed25519 signature on every sealed record, with published and revocable keys
- Salted digests for sensitive evidence, kept in a sidecar that can be erased while the record still verifies
- Obligations and the seven admissibility rules, with a verdict any verifier can recompute
- The lifecycle, proposed to warranted to committed, with actions blocked without a warrant
- Parent links for handoffs between agents and between organisations, and warrant trace to walk them
- Checkpoints as RFC 9162 Merkle trees, with consistency proofs so a witness needs no records
- Witness co-signatures, and optional OpenTimestamps anchoring
- Conformance levels L1 to L3, reported by the verifier
- An adapter for Laya, an open-weight decision model that runs inside your own environment
- The same warrant engine in JavaScript since 0.8.0: obligations, the seven rules, fail-closed commit and transitions, pinned to the Python SDK by shared test cases
- One canonical form since 0.9.0: both SDKs hash a record as RFC 8785 specifies, so a record sealed by a Python store verifies in JavaScript, and the reverse
- Since 0.10.0: a document that is on file but was not relied on is recorded as an input and never counted towards an obligation
- Since 0.11.0: Temporal as a worker plugin in Python and TypeScript. The run's evidence travels with the workflow, so a decision cites activities that ran on other workers, and TypeScript workflow code can record decisions and approvals
- Since 0.11.0: policy versions are chosen by instant, so a boundary written with an offset such as +05:30 takes effect at the moment it names
In progress
- Console: explorer, review queues, calibration dashboards (in early access)
- Adapters for the OpenAI Agents SDK and CrewAI
- SSO and an auditor role, hosted India region
Shipped before 0.7.0
- Python and JavaScript SDKs: decide(), check(), evidence by hash, cost, outcomes, human verdicts
- Policy bundles in CEL with fail modes, embedded tests and a shared Python–JavaScript conformance suite
- Append-only store with a SHA-256 hash chain, export and an offline verifier
- Collector and PostgreSQL store for shared, self-hosted deployments
- warrant import: decision records from the OpenTelemetry traces you already have
- Replay: decision sets, targets, warrant test with JUnit output, and a GitHub Action
- Adapters for the Claude Agent SDK, LangGraph and Temporal, and an MCP server
- warrant outcomes, warrant calibrate and warrant pack: outcomes joined months later, reliability curves on your own book, and an evidence pack verifiable offline
- A model-agnostic decision-model interface, with TypeSafe's Jev as the first adapter; since 0.6.0 it records the probability of the chosen answer, not the vendor's margin
- Versioned question sets, golden-set drift checks, effective-dated policies and circuit breakers
The source, the specification and its schema are on GitHub, Apache 2.0; the packages are on PyPI and npm.
The format is free. Proof that a third party relies on is not.
Open source
Free
The SDK, policy checks, the sealed local store, replay, import and the verifier. Apache 2.0, on your own machines, for as long as you like.
Install from PyPITeam
₹1,500 per seat a month · $19
Planned for teams: shared decision sets and workspaces, hosted records and a version registry for prompts and policies. Early-access pricing, opening to design partners first.
Ask for early accessBusiness and Enterprise
Talk to us
The review console, enforcement in regulated workflows, long retention, and deployment in your own cloud. Every engagement starts with the two-week test.
Book the two-week testThe two-week test
One real workflow. Fourteen days. A finding on day one.
We start with what your agents have already done, not with a new integration. The fee is credited in full against your first year.
- Day 1Import the traces you already have, check every past decision against your written policy, and hand you the first finding.
- Days 2 to 5Instrument one live agent workflow inside your environment. Nothing leaves your systems.
- Days 6 to 12Record real decisions. Your risk team runs one review cycle on escalations, flagged decisions and a random sample.
- Days 13 and 14A written finding, a replay walkthrough for your engineers, and an export your auditor can verify offline.
Book the test
Leave a work email. One reply, from a person, within two working days.
Questions worth asking
Is the record format yours alone?
No, and it should not be. The Agent Decision Record specification is published under CC BY 4.0 and Warrant is its reference implementation under Apache 2.0. It is designed to sit beside the standards that already cover messaging, mandates and payment: an agent-to-agent message can carry a record reference, a payment mandate is one kind of evidence, and a payment can be released only on a warranted record.
Does Warrant slow my agent down?
Recording is asynchronous and added 0.16 ms at p99 in our benchmark; the in-process policy check took 0.26 ms at p99 (3,000 decisions, a three-clause policy, an Apple M5 laptop). Warrant is never in the path of your model calls. If the store is unavailable, records spill to disk and are sent later.
What data does Warrant store?
The decision, the policy result, cost and later outcomes. Evidence is stored as a reference and a content hash pointing back to your systems; capturing inputs and tool results is opt-in, meant for development and staging so replay has something to run on. Free-text fields can be redacted before anything leaves the process.
What stops someone editing a record?
The store refuses updates and deletes, and every record's hash covers the record before it, so a changed record no longer matches its seal. Someone with full database access could rebuild the whole chain, which is why an export, or just its last hash, held outside the store settles the question. Since 0.7.0 the store can also sign every record with your organisation's own key, and a witness that never holds your records can co-sign checkpoints only if the new chain provably extends the one it last signed, so rewriting history takes more than database access.
Which frameworks and models does it support?
Any agent you can call from Python or Node.js. You wrap the decision, not the model. Adapters for the Claude Agent SDK, LangGraph and Temporal name the tool calls or activities that are decisions and gate and record them without other changes; agents in an MCP-capable host use the MCP server.
How does it run in CI?
warrant test exits non-zero when decisions flip, a policy newly denies, or cost rises past your limit, and writes a JUnit report listing the exact decisions affected. There is a packaged GitHub Action, and the same command runs in any other pipeline.