Recovery Authority

Analysis basis

This report is based entirely on the self-reported project description provided by the author. No external verification, traction data, revenue figures, customer names, or independent sources are available. All statements should be treated as claims made by the author.

The description states that Recovery Authority is an open-source Codex plugin. It turns destructive actions into a two-key protocol, requiring:

1. Proving the exact inverse works.
2. Human release of authority through a separate channel.

Key technical elements include:

• Rust-based TUI (terminal user interface) for control room display
• Use of Ed25519-signed capabilities bound to operation, scope, state, proof, and expiry
• Support for POSIX filesystem deletion, local SQLite mutation, scoped PostgreSQL mutation, and git reset --hard
• Isolated drills for restoration
• MCP (Model Context Protocol) runtime written in TypeScript on Bun
• Linux sandboxing via Bubblewrap
• Human broker owns Ed25519 key; model-facing worker cannot approve itself

Inference The product appears to be a security tool built specifically for coding agents, with an emphasis on preventing accidental or malicious destruction through verification before execution.

The author positions Recovery Authority as a security layer that shifts focus from preventing destructive actions to proving they can be undone. The key claim is:

“A backup is a noun. Recovery is a verb. I wanted destructive permission to depend on the verb.”

This evolution moves beyond conventional safeguards like sandboxes or checkpoints, which address different aspects of risk.

The author also emphasizes:

• Not promising recovery but proving it
• Keeping approval outside the chat
• Using full-database artifacts for cascading schema changes
• Composing multi-effect work as a compensated saga
• Blocking unsupported effects instead of weakening claims

Claim vs Fact

These are self-reported positioning and intent statements, not evidence of actual deployment or performance.

The description does not explicitly name target customers or personas. However, it implies:

• Developers using AI agents (e.g., Codex) in environments where destructive actions could cause harm
• Organizations managing sensitive data or infrastructure with high-risk automation needs

It targets users who may be building or deploying coding agents that interact with file systems, databases, and version control.

Inference Likely aimed at developers working in AI agent development, especially those concerned about safety and reversibility of operations. Not yet evidenced as having specific customer segments or ICP defined beyond general developer use cases.

No business model or pricing information is provided. The project is described as open-source, with no mention of monetization strategies, licensing terms, or paid tiers.

Not evidenced: No indication of revenue streams, subscriptions, or commercial offerings.

Technical details include:

• Built using Rust (TUI), TypeScript/Bun, Node.js, PostgreSQL, SQLite, Linux, Bubblewrap, MCP SDK, Zod contracts
• Uses Ed25519 signing keys, JSON-RPC, CLI tools, shell parsing, and AST analysis
• Implements sandboxing with Bubblewrap, Unix socket protocol, and constrained filesystem views
• Supports multiple destructive operations: POSIX deletion, SQLite mutation, PostgreSQL mutation, git reset
• Includes a consequence graph (non-authoritative) and proof-bound expiring capabilities

Inference Strong technical foundation for a security tool targeting AI agents. Demonstrates deep integration with system-level components and multi-platform support.

The description includes:

• 132 Bun tests, 5 Rust tests, and 3 Linux sandbox integration tests
• Demo showing installation, recovery preparation, proof display, approval, and commit
• Verification matrix covering real PostgreSQL restore drills, cascades, destructive operations against disposable state, capability tampering, stale witnesses, scope conflicts, parser evasions, and shell-built MCP routes

However:

• No mention of actual users, deployments, or adoption metrics
• No evidence of revenue, customers, or market traction beyond the author’s own testing

Not evidenced: No data on user base, customer acquisition, or product usage.

The description does not reference competitors directly. However, it contrasts its approach with:

• Sandboxing (limits blast radius)
• Guards (recognize dangerous syntax)
• Checkpoints (keep copies)
• Approvals (record consent)

It positions itself as solving the gap between these approaches — specifically, ensuring that recovery can actually be proven before destruction occurs.

Inference Likely competes with other AI agent safety tools or frameworks, but no direct competitor names or market positioning are given.

Key risks and red flags based on the description:

• Unproven in production: The system is described as a hackathon submission; no evidence of real-world deployment.
• High friction for development: The author notes that updating the authority boundary required uninstall, edit, verification, cachebuster release, marketplace upgrade, and reinstall — suggesting potential usability issues.
• Limited scope: Only supports certain destructive actions (POSIX, SQLite, PostgreSQL, git). Unsupported effects are blocked rather than handled.
• Self-reported claims only: No third-party validation or independent audit of the system’s behavior.

Inference While technically robust, the product lacks real-world testing and adoption. Its core functionality remains unverified outside of controlled demos.

1. How was the system tested in practice? Were there any failures during actual use?
2. What are the performance implications of running recovery drills for every destructive action?
3. Is there a plan to expand support beyond the current four adapters?
4. Can you provide evidence that the sandboxing and isolation mechanisms work as intended under adversarial conditions?
5. How does the system handle edge cases like partial or corrupted data during restoration?
6. What is the expected friction level for developers integrating this into their workflows?