Welcome
You are about to invoke a tool that writes. Call Writ first.
If the decision is DENY, do not invoke the tool. Tell the user the write was refused and a receipt exists.
If the decision is ALLOW, invoke the tool once. The grant is spent.
If the decision is STEP_UP, do not invoke the tool. Tell the user a human sponsor must approve this write. The sponsor mints a grant, then you call POST /v1/check again.
Writ
Writ sits between your AI agent and the writes it wants to make — refunds,
provisions, deploys, emails, anything that changes state. Before the write
runs, the agent asks Writ: may this agent fire this action, for this
purpose, with this sponsor? The answer is ALLOW, DENY, or STEP_UP
(human approval required). Every answer is written to a tamper-evident audit
log as a receipt.
Three objects make up the whole product: a principal (who is acting and why), a decision (allow, deny, or step up, bound to the exact write), and a receipt (the audit record). Read Concepts for the full picture.
Get a key
You need two credentials, and they do different jobs:
- API key (
writ_...) — identifies the tenant. The agent uses it for every call: checks, receipts, policy reads. - Sponsor token (
writ_sp_...) — identifies the human. It approves grants and revokes principals. Shown once when the tenant is created; it is never recoverable and never stored by Writ.
The fastest path is the CLI:
That prints your API key and, for a new tenant, your sponsor token. Store the sponsor token somewhere safe — a password manager, not a chat log.
Joining a team instead? Get an invite code from a teammate and pass
--invite-code writ_inv_.... You get your own API key on their tenant.
Your first decision
Prove the intercept before wiring anything real:
The sandbox grant matches only demo_write on a demo- target, for 90
seconds, once. Real verbs work the same way: POST /v1/check matches a
grant on five fields — sponsor, agent, verb, target, purpose. No match is
DENY. Do not run the write.
Where next
- Concepts — principals, decisions, receipts, policy modes, grants, the kill switch, tenants. Read this before designing an integration.
- MCP server — give any MCP-compatible agent the eight Writ tools, and have it instrument its own codebase.
- Audit log — live streaming, SIEM ingestion, hash-chained tamper evidence, verification.
- CLI reference — every
./writcommand. - Dashboard — the web UI: usage, policy editor, team invites, live log, kill switch.
- API reference — the full endpoint reference. Paste your API key into Authorize; Fern keeps it in the browser.
Pricing
Free: 1,000 receipts a month, no card. Enough to actually run an agent against it. Every decision — ALLOW, DENY, STEP_UP — writes a receipt.
Over that, it’s metered: $0.01 per receipt. Usage aggregates through the month and Stripe bills you once. No subscription, no tiers to pick.
When the free tier runs out, POST /v1/check returns 402 payment_required with a portal_endpoint (/v1/billing/portal). Open the
dashboard’s Billing section — sign in with your API key, or have a
one-time link emailed to you (POST /v1/auth/magic-link) — and hit Add
payment method. That opens Stripe’s hosted portal, where the card goes on
file; Stripe sends you back to the dashboard, which confirms the card and
lifts the 402. Writ never touches card data.
Trying it is free two ways: the keyless sandbox demo (./writ sandbox)
proves the intercept with no signup, and the free tier needs no card.
Enterprise is annual commit + volume, priced on a call — the pilot’s receipt volume sets the commit size. Same meter: the audit log. chad@withwrit.com to talk.