-
-
TARS operator console showing selective revocation, compensation and recovery.
-
VERIFIED — Requirements R-01 through R-20
Inspiration
TARS REVOKE started from one question:
What happens when a coding agent makes a decision that is correct at the time, but the reason behind that decision becomes false a few minutes later?
Most agent safety tools focus on checking an action before it happens. They can block a dangerous command or remember why something was done, but once an action has been approved, that approval is usually treated as final.
I wanted to build something that keeps checking whether an action is still justified while the agent is working.
That became TARS REVOKE.
What it does
TARS gives important agent actions what I call a live warrant.
The warrant records the assumptions, evidence and tests that currently justify the action. It also tracks which patches, commands, commits, migrations or pushes depend on those assumptions.
When new evidence proves that one assumption is wrong, TARS does not stop everything.
It only revokes the affected actions.
For example, in the main demo, Codex is preparing a database migration and a push. New information about the production schema proves that an important assumption behind the migration is incorrect.
TARS then:
- revokes the affected migration and dependent changes
- restores effects that can safely be reversed
- prevents the push from being sent
- leaves unrelated work alone
- records exactly what happened
- produces a receipt that can be independently verified
The main difference is that TARS is not only asking whether an action is allowed to begin. It keeps asking whether that action should still be allowed to continue.
How I built it
I built TARS as a Python developer tool with a command-line interface and a local frontend.
The system tracks relationships between agents, assumptions, evidence, tests, warrants, actions and effects. When evidence changes, it follows those relationships to find the smallest part of the agent’s work that has actually been affected.
I also built:
- a deterministic offline demo
- compensation handlers for reversible effects
- a hash-chained event journal
- signed evidence and receipts
- core and strict verification commands
- crash and revocation benchmarks
- a qualification process for real Codex runs
The offline demo does not pretend to be a new live Codex run. It is a reproducible version of the same scenario so judges can test the project without needing credits or an API key.
The separate strict attestation preserves the evidence from the real Codex qualification runs.
How I used Codex and GPT-5.6
I used Codex throughout the project rather than only using it to generate the first version.
GPT-5.6 Sol helped with the harder architectural and security work. I used it to think through the warrant model, dependency tracking, revocation logic, recovery system, sandbox restrictions and the final qualification process.
When my remaining usage became limited, I moved to GPT-5.6 Terra for the final testing, packaging fixes and release verification.
Codex helped me move much faster, but I still had to make the main product decisions myself, especially the decision that authorization should only remain valid while the exact evidence behind it is still true.
Challenges
The hardest part was not making the demo look convincing. It was making the proof honest.
During clean-clone testing, the release process found that the Python package was trying to include the frontend before the frontend had been built. The project worked on my machine because those files already existed, but it failed in a fresh environment.
A later sandbox test also found that a basic blocked-path policy could be bypassed using an alternative macOS path. I replaced that approach with a stricter allow-only policy.
The qualification process was designed to fail closed. Failed runs were kept as failed runs instead of being edited or counted as successful evidence.
The three successful live Codex runs are tied to commit 8c58251. Two later commits fixed portable attestation packaging that was exposed during those runs. The final validated code release is e58b741.
What I am proud of
The finished project has:
- 311 passing offline tests
- exactly three successful real Codex qualification runs
- a strict R01–R20 attestation verified twice
- selective revocation of three affected effects
- automatic recovery of reversible effects
- a push blocked before it was dispatched
- an offline demo that judges can run without paid credits
I am most happy that the project does not depend on a fake terminal animation or an unverifiable claim. The demo, journals, receipts, experiments, compensation records and live-session evidence are all preserved.
What I learned
The biggest thing I learned is that permission should not be treated as permanent.
For autonomous coding agents, checking an action once is not enough. The assumptions behind that action can change while the agent is still working.
I also learned how important fresh-environment testing is. Several problems only appeared when the project was installed and tested away from my development machine.
What’s next
The next step would be integrating TARS more directly with coding-agent runtimes so warrants can be created and updated automatically during normal development.
I would also like to improve the visual dependency graph, add more recovery plugins and support multiple agents working on the same repository.
Memory tools answer:
“What did the agent know?”
Guardrails answer:
“Is this action allowed?”
TARS answers:
“This action was allowed, but the reason behind it is no longer true. Revoke it and recover.”
Build Week scope
TARS REVOKE was created during OpenAI Build Week. I used earlier internal TARS and Martin experiments as reference material, but the submitted continuous-authorization system was implemented during the submission period.
The live-warrant model, typed causal dependencies, selective revocation, compensation system, decisive experiments, operator console, Codex qualification process, benchmarks and portable release attestation were developed and validated during Build Week. The dated Codex session and commit history document this work.
Log in or sign up for Devpost to join the conversation.