Inspiration

AI agents are becoming capable of drafting contracts, reviewing documents, negotiating terms, and triggering real-world workflows.

But there is a critical difference between preparing a decision and having the authority to execute it.

We built Ratify around one question:

What if an AI agent could do almost everything required to prepare a document for signature — while making it architecturally impossible for that same agent to sign it?

Instead of relying on a prompt telling the AI “don't sign without permission,” Ratify treats human approval as a genuine security boundary.

The AI does the work.

The human retains the authority.


What it does

Ratify is a safety-first document workflow for AI-assisted agreements.

The agent can draft, review, and prepare a document for execution. But when the workflow reaches the point where a legally meaningful action could occur, there is a hard boundary:

The AI cannot access the signing credential.

Not “should not.”

Not “is instructed not to.”

It physically does not possess the capability required to sign.

A human must explicitly ratify the document before the signing path can proceed.

Ratify also protects against a more subtle problem: approving one document and signing another.

Human approval is tied to the approved state of the document. If the document changes after ratification, that approval is automatically revoked and the document must be reviewed again.

The workflow is therefore:

AI prepares → Human verifies → Human ratifies → Signing becomes possible

If anything changes:

Document changes → Approval revoked → Human must ratify again

This creates a clear, enforceable separation between AI assistance and human authority.


How we built it

Ratify was designed around capability separation, rather than prompt-based safety.

The AI-facing portion of the system handles the document workflow, while signing authority exists behind a separate boundary that the agent cannot reach.

That distinction matters.

If an AI hallucinates, follows a malicious prompt, misinterprets an instruction, or behaves more autonomously than expected, a rule saying “wait for human approval” is only as reliable as the agent following that rule.

Ratify takes a different approach:

Remove the capability entirely.

Human ratification is implemented as part of the workflow state rather than as a conversational instruction.

The system also detects when an approved document changes. Any such modification invalidates the existing approval, preventing an old authorization from being reused for new terms.

These safety properties are backed by an automated test suite that reached 123 passing tests, including regression tests covering the ratification and document-editing flow.

The Foxit document and eSign ecosystem provides the real-world document infrastructure around this architecture.


Challenges we ran into

The hardest part was not making the AI useful.

It was making the safety guarantees real, enforceable, and visible.

During development, some of Ratify's strongest protections already existed in the underlying logic and were fully tested — but they were difficult to demonstrate through the interface.

For example, Ratify could already revoke approval when an approved document changed. But there initially wasn't a clear UI path that allowed somebody watching the demo to actually see this protection activate.

That revealed an important lesson:

A security property should not only exist in code. Users need to be able to understand and verify it.

We redesigned parts of the workflow so these protections could be demonstrated directly, then added regression tests to ensure the changes did not weaken the underlying guarantees.

Another challenge was resisting the easiest implementation.

Giving the AI signing credentials and simply instructing it not to use them would have been much simpler.

But then the safety boundary would depend on model behaviour.

Ratify makes that boundary structural instead.


Accomplishments that we're proud of

The biggest achievement is simple:

Ratify's central safety guarantee does not depend on the AI behaving perfectly.

Even if the agent makes the wrong decision, it still cannot sign the document.

We also implemented approval integrity: changing an approved document automatically invalidates the previous human authorization.

And rather than treating these properties as assumptions, we built automated tests around them, reaching 123 passing tests during development.

Ratify demonstrates a broader principle for agentic systems:

Don't ask an AI to respect a boundary when you can design the system so it cannot cross that boundary in the first place.


What we learned

Building Ratify changed the way we thought about AI safety.

The strongest safeguards often should not live inside the model at all.

Prompts, policies, and model alignment remain useful, but high-consequence actions need another layer:

Capability control.

An AI agent can have enormous freedom to reason, draft, analyze, and recommend while still being denied the single capability that allows it to perform an irreversible action.

We also learned that human-in-the-loop systems must protect more than an approval button.

They need to preserve the relationship between:

what the human approved

and

what ultimately gets executed.

That is why automatic approval revocation became one of Ratify's most important protections.


What's next for Ratify

Document signing is only the first use case.

The same architecture could protect other high-consequence AI actions, including:

  • Releasing payments
  • Executing financial transactions
  • Accepting legal agreements
  • Changing account permissions
  • Submitting regulatory filings
  • Approving sensitive business actions

The longer-term vision is for Ratify to become a reusable human authorization layer for AI agents.

AI should be able to do the work.

Humans should retain the authority.

And the architecture should enforce the difference.

Built With

  • docker
  • fastapi
  • foxit-document-generation
  • foxit-esign
  • foxit-pdf-services
  • httpx
  • jinja
  • mcp
  • playwright
  • python
  • uvicorn
Share this project:

Updates

Submission history