Agent Warrant Protocol

Inspiration

AI agents are increasingly handed real credentials and told to "just fix it." A service-account key says an agent may edit DNS in general, but it never proves the agent was allowed to change this exact record to this exact value at this exact time. We kept seeing the same gap: intent lives in a chat message, approval lives in a checkbox, and execution lives in an audit log, with nothing cryptographically tying the three together.

We built Agent Warrant Protocol to close that gap — a human-authorization layer that binds a person's signature to one canonical action payload and enforces that binding at execution time.

What it does

Agent Warrant Protocol turns a high-risk agent action into a narrowly scoped, expiring, single-use warrant:

1. The agent proposes a change and explains the risk.
2. The backend freezes the exact before-state, after-state, expiry, and nonce into a canonical payload, then hashes it.
3. Foxit eSign generates a warrant PDF and routes it to a human for signature.
4. The backend verifies the completed envelope directly with Foxit — a redirect or webhook is treated as a prompt to check, never as proof.
5. Only then can the system atomically reserve and execute the exact signed mutation against the name.com sandbox DNS API.
6. The result is a hash-linked audit chain and a tamper-evident receipt that distinguishes proposed, signed, requested, and observed values.

The live demo updates one DNS record, rejects a replay, and can publish a _warrant TXT proof to the domain afterward.

How we built it

We wrote the protocol core in TypeScript with deterministic canonicalization and dual SHA-256 digests, so any change to the action or the authorization envelope breaks the signed document. The state machine is one-way: a warrant cannot go backward from a terminal state.

Three sponsor integrations power the live path:

• Foxit eSign generates the warrant PDF and manages the embedded signing session; the backend re-queries Foxit to retrieve and hash the signed artifact.
• name.com sandbox DNS provides the concrete protected action: read the record, execute the update, re-read for verification, and optionally publish a TXT proof.
• Xano owns the data model, workflow logic, persistence, and audit events.

A Kimi structured-output model turns plain-language intent into a constrained DNS proposal, and a lightweight operator UI drives propose → sign → execute → receipt. The whole app is deployed as Vercel serverless functions plus a static HTML client.

Challenges we ran into

The hardest part was making "signed" actually mean something. A webhook saying the envelope is complete is not proof, so we had to verify completion server-side with Foxit before allowing execution. Concurrency was another trap: two simultaneous execute requests had to race on an atomic AUTHORIZED → EXECUTING transition so a warrant can only be consumed once.

We also learned how easy it is to drift into security theater. A fancy PDF is meaningless unless the backend re-reads the live DNS state and enforces the signed precondition immediately before the mutation. Finally, wiring three real sponsor APIs end-to-end — with no mock fallback in the operator flow — forced us to handle provider ambiguity, read-after-write timing, and stable error surfaces without pretending a failure was success.

Accomplishments that we're proud of

We shipped a genuinely live, end-to-end prototype: a Kimi proposal, a Foxit eSignature, a name.com DNS mutation, and Xano persistence, all verified by 42 passing tests. Every sponsor call is real, not a mock.

We're most proud of the evidence model. The receipt separates proposed, signed, requested, and observed values, links every transition into a hash chain, and exposes the signed PDF and a DNS TXT proof — so an auditor can answer "what did the agent propose, what did the human approve, and what did the system actually do?"

What we learned

We learned that authorization is not a credential; it's a binding between a person, a payload, and a moment in time. Trust comes from verifying state at the boundary, not from decorating a request with a token. We also internalized three rules that now shape how we design agent tools: agents propose and humans authorize, fail closed on any mismatch, and preserve evidence before making claims.

What's next for Agent Warrant Protocol

The next step is a vendor-neutral authorization gateway for agentic systems. We want to add more protected action types — infrastructure changes, production deployments, database writes, and payments — plus multiple signers, policy rules for which actions require warrants, and native adapters for agent frameworks. Long-term, the goal is for every consequential agent action to ship with a signed, verifiable warrant instead of an ambient permission.

Built With

• dns
• esign
• foxit
• name.com
• xano