CommitLock

Agents can prepare the commitment. Only a human can authorize it. CommitLock freezes document intent, gates Foxit eSign behind one-use human approval, and verifies expected = authorized = executed.

Comment

Inspiration

AI agents are becoming increasingly capable of preparing documents, interpreting instructions, and operating external tools.

But document preparation and document authority are not the same thing.

An agent may be useful enough to generate a contract, inspect it, compare versions, and prepare it for signature. That does not mean the agent should automatically gain the authority to choose a signer, issue a signing request, or make a legally consequential commitment.

CommitLock was built around one invariant:

Agent preparation is not human authorization.

The goal is to let an agent do as much useful reversible work as possible, while keeping the authority required for irreversible execution outside the model boundary.

What it does

CommitLock is an authority control plane for agent-driven document workflows.

A user begins with a plain-language request, such as:

Prepare the approved supplier agreement for ACME Logistics and verify it before signature.

The model receives a deliberately bounded Foxit preparation surface consisting of exactly three reversible tools:

  • pdf_from_html
  • get_pdf_properties
  • pdf_compare

These allow the agent to generate, inspect, and compare documents.

The agent does not receive:

  • Foxit eSign authority
  • signer selection authority
  • signing credentials
  • the one-use CommitPermit
  • sendNow
  • the final provider payload

Once preparation succeeds, CommitLock reconstructs trusted material server-side and freezes the exact commitment before any consequential action becomes available.

A reviewer then authenticates and reviews that frozen commitment.

If approved, CommitLock issues a short-lived, one-use permit bound to that exact authorization. The permit cannot silently authorize a different artifact, signer, or action, and it is never exposed to the model.

Only after that human authorization can the trusted server perform the Foxit eSign handoff.

The Foxit workflow

Foxit is used on both sides of the authority boundary.

Before authorization, Foxit PDF Services provide the reversible document capabilities used by the agent to create, inspect, and compare the prepared document.

After authorization, Foxit eSign becomes available only through the trusted server-side execution path.

The human signer then signs through the real Foxit eSign experience.

CommitLock deliberately distinguishes:

preparation → authorization → dispatch → provider execution → verification

rather than treating them as one AI action.

Verification

CommitLock does not stop when an irreversible request is dispatched or when a provider returns a vague success signal.

After signing, the system observes the Foxit lifecycle, retrieves the executed artifact, re-extracts the committed material, and reconciles three independently derived truths:

EXPECTED = AUTHORIZED = EXECUTED

  • EXPECTED — the exact commitment frozen before authorization
  • AUTHORIZED — what the human explicitly approved
  • EXECUTED — what the provider actually produced

Reconciliation is shown only after the executed material has been independently verified.

Replay and ambiguity safety

Irreversible provider calls require different failure semantics from ordinary API calls.

If CommitLock cannot prove whether Foxit accepted an irreversible request, it does not blindly retry it.

The attempt is quarantined and recovery becomes read-only against the existing provider attempt.

This prevents a transient network ambiguity from becoming a duplicate signing request.

How we built it

CommitLock is built with:

  • Next.js
  • React
  • TypeScript
  • PostgreSQL
  • Google Vertex AI / Gemini
  • Foxit PDF Services
  • Foxit eSign
  • Zod
  • Vitest

PostgreSQL stores durable authority, prepared-artifact, dispatch, and lifecycle truth.

The browser is intentionally not treated as the source of authority. Human authorization, permit material, credentials, signer binding, and irreversible execution remain server-side.

The application exposes separate workspaces for:

  • Preparation
  • Human Review
  • Execution
  • Trusted Trace
  • Trust Model

This makes the authority handoff visible instead of hiding it behind a generic chat interface.

Challenges

The hardest part was not generating the document.

The difficult problem was designing a system where an AI agent remains genuinely useful without accidentally inheriting the authority of the application using it.

That required separating model capability from application authority, binding human approval to an exact frozen commitment, making authorization one-use, handling ambiguous irreversible calls without automatic replay, and verifying the executed artifact independently after signing.

What we learned

Agent safety cannot be solved only by asking a model to behave carefully.

The important boundaries need to exist outside the model.

The model can reason about what should happen.

The application must still control what is allowed to happen.

What we are proud of

The strongest part of CommitLock is that the human-in-the-loop step is not cosmetic.

The agent never receives the capability that makes the commitment irreversible.

The human approves one exact frozen commitment, the server performs one controlled execution attempt, and the final result is independently reconciled against what was expected and authorized.

Give the agent useful work, not authority.

Built With

Share this project:

Updates

Submission history