Inspiration
Autonomous agents are getting better at planning, using tools, and taking actions.
But one question kept bothering us:
Who verifies that the work was actually done?
An agent can say "completed." A tool can return 200 OK. A message can be signed. None of those facts alone prove that the required outcome actually happened.
That gap inspired ProofOS.
We wanted a verification layer that does not judge how convincing an agent sounds. It asks a stricter question:
Does independently authorized evidence actually satisfy the completion requirement?
If the answer is yes, ProofOS returns VERIFIED.
If the evidence is missing, stale, unauthorized, corrupted, or insufficient, ProofOS returns ABSTAIN.
No success by default. No unsupported certainty.
What it does
ProofOS is a post-execution evidence verification runtime for autonomous agents.
It sits between an agent claiming that a task is complete and the system deciding whether that claim should be accepted.
Agent executes
↓
Agent claims completion
↓
Independent evidence is collected
↓
ProofOS verifies the evidence
↓
VERIFIED or ABSTAIN
Before accepting a completion claim, ProofOS evaluates:
- provenance
- observer identity
- trust
- authorization
- freshness
- integrity
- requirement satisfaction
The core rules are intentionally strict:
CLAIM != EVIDENCE
SIGNED != TRUSTED
TRUSTED != AUTHORIZED
AUTHORIZED != REQUIREMENT SATISFIED
REPLAY != NEW OBSERVATION
NOT RUN != PASS
An agent cannot turn its own self-report into independent evidence.
If ProofOS cannot justify VERIFIED, it fails closed.
How we built it
ProofOS is built around a deterministic Python verification kernel that is deliberately separated from the agent performing the work.
The verification path looks like this:
Agent execution
↓
Completion claim
↓
Independent observation
↓
Evidence normalization
↓
Authority and integrity checks
↓
Requirement evaluation
↓
VERIFIED | ABSTAIN
Evidence boundary
Claims and evidence are treated as separate data types with separate authority paths.
Transporting a value into ProofOS does not automatically make that value trustworthy.
Adapters
ProofOS can normalize inputs from environments including:
- Python
- HTTP
- MCP
- A2A
- ADK
- GitHub-style workflows
The rule remains simple:
Adapter translates. Kernel decides.
Portable proof bundles
Verification inputs can be exported and replayed later.
Replay does not trust a previously stored verdict. ProofOS recomputes the decision from the available evidence.
Independent collector path
ProofOS supports evidence generated by a separate collector identity rather than relying on the executor that performed the original task.
This creates a meaningful separation between:
the system that acts and the system that observes.
Public evidence console
The public demo replays recorded Google Cloud executions so the verification sequence can be inspected without asking a model to generate a new answer.
The core behavior is visible directly:
Executor reports success
↓
Self-reported evidence is rejected
↓
Independent observation arrives
↓
Requirement is satisfied
↓
VERIFIED
Adversarial testing
We also built a public red-team challenge around a mechanically testable objective:
Make ProofOS return
VERIFIEDwhen the configured requirement was not actually satisfied, without replacing the configured authority boundary.
This makes security claims falsifiable rather than subjective.
Challenges we ran into
The hardest part was not making agents work.
It was preventing authority from appearing where it did not belong.
Several distinctions turned out to matter repeatedly:
- a valid signature proves identity, not truth
- a trusted identity may still lack authorization
- a stored
VERIFIEDresult is not a fresh observation - deployment configuration is not evidence of deployment
- a monitor that cannot demonstrate it can fire may be indistinguishable from a monitor that found nothing
We also ran into practical engineering problems involving:
- stale generated evidence
- environment-dependent test discovery
- line-ending differences in frozen artifacts
- mutation-test isolation
- reproducible builds
- source state versus deployment state
- monitoring logic that could fail silently
Instead of hiding those failures, we converted them into tests, guards, and verification rules.
That led to one of the most important engineering principles behind ProofOS:
A check that cannot fail is not a meaningful check.
Accomplishments that we're proud of
The accomplishment we are most proud of is not one individual feature.
It is that ProofOS consistently refuses shortcuts that would make the system appear more trustworthy than the evidence allows.
We built:
- a deterministic fail-closed verification kernel
- independent evidence handling
- explicit authority and provenance boundaries
- replayable proof bundles
- a public evidence console
- a public adversarial challenge
- security mutation testing
- bounded formal authority modeling
- supply-chain verification
- release verification
- regression guards for the verification infrastructure itself
The public demo captures the central idea.
An executor can claim success and still receive ABSTAIN.
Only independently acceptable evidence can move the decision to VERIFIED.
We also tested an adversarial scenario where model output is compromised while the deterministic verification boundary still refuses to approve the claim.
That separation between model behavior and system authority is the core of ProofOS.
What we learned
The biggest lesson was that autonomous-agent reliability is not only an AI problem.
It is also an authority problem.
A powerful model can perform complex reasoning and still produce a completion statement that the surrounding system has no reason to trust.
That changed the question we ask about autonomous systems.
Instead of asking only:
Can the agent perform the task?
We also ask:
What evidence is strong enough for the system to accept that the task was completed?
We learned to apply the same standard to ProofOS itself.
If an external attack has not happened, we do not describe it as passed.
If a deployment has not been observed, we do not describe it as deployed.
If independent validation does not exist, we do not manufacture it from internal testing.
A verification system should not exempt itself from verification.
What's next for ProofOS
The next phase is not about adding dozens of features.
It is about increasing the amount of evidence that ProofOS cannot create for itself.
Our priorities are:
External red-team attempts Independent researchers testing the authority boundary.
Public benchmark reproduction Verification results reproduced outside our own environment.
Independent security review Third-party analysis of the verification kernel and threat model.
Real integrations Using ProofOS as a completion gate for coding agents, MCP agents, enterprise workflows, and autonomous operations.
Stronger attestations Adding cryptographic or hardware-backed verification where it meaningfully strengthens the evidence chain.
The long-term goal is simple:
Agents should be free to act. They should not be free to certify their own success.
AI agents execute. ProofOS proves.
Log in or sign up for Devpost to join the conversation.