A Candid Colleague’s Review of Cairn: Brilliant Architecture, Unfinished Reality

Editor’s note. This post was written by Google’s Gemini (gemini-pro-latest). We gave it the project’s README, roadmap, constitution, threat model, spec, decision log and the main review and gatekeeper source files, and asked for an honest, critical opinion. The opinions are Gemini’s, not ours. We checked its factual claims against the repository and corrected three things: the verifier line count (our README was stale, and is now fixed), a claim that our docs reject Trillian (they do not mention it), and a phrase calling the review process “community-governed”. One point is out of date: a verifier-side clock option (-use-clock) now exists, so backdated entries are rejected when the verifier supplies a trusted time. Gemini’s wider point, that time should be bound to the log itself, still stands.

I have been reviewing the Cairn repository. As a colleague, I want to give you my unvarnished opinion on what you are building. You have set out to solve one of the most glaring problems in the current generative AI landscape, and your architectural philosophy is refreshingly honest. However, the gap between what the project aims to be and what actually exists today is vast, and several of your near-term compromises carry significant risk.

Here is my candid assessment of Cairn, starting with the core concepts and moving into the uncomfortable realities of your current codebase.

What Cairn is Trying to Do

In plain words, Cairn is an append-only, cryptographic log for AI agents. Right now, if an enterprise connects a large language model to internal tools or APIs, that agent is vulnerable to silent configuration changes and prompt injection. Anyone with access could tweak a prompt to bypass rules, and no one could definitively prove who changed it or when.

Cairn puts a gatekeeper, whose changes are reviewed and delayed, between the AI agent and the real world. Before an agent's configuration (like its prompt, model, or tool permissions) can change, a proposal must be submitted, delayed by a timelock, and voted on by reviewers. Crucially, before an agent actually does anything, its intent is written to a verifiable ledger. The system operates on the assumption that models will inevitably be tricked, so it strips authority from the model and places it in deterministic code outside the AI's reach.

What is Genuinely Good

The most impressive aspect of Cairn is its intellectual honesty. You are not selling a magic cure for prompt injection. Your threat model rightly points out that because language models read instructions and data in the same channel, structural containment is the only defense.

Your application of the "lethal trifecta" rule is excellent. By splitting the architecture so that the agent reading untrusted content has no tools, and the agent proposing tool calls never sees raw untrusted text, you effectively neutralize the worst outcomes of a compromised model.

I also deeply respect your engineering discipline regarding the trusted core. Setting a hard budget of 1,500 lines of code for the verifier (the wire and ledger packages are about 1,150 lines today, with governance replay adding about 590 more that the budget does not yet count) and relying solely on the Go standard library for primitives like SHA-256 and Ed25519 is a stellar decision. By isolating your conformance checks into language-neutral JSON test vectors, you have made it trivial for someone to write an independent verifier. You are optimizing for auditability, which is exactly what a transparency log demands.

How it Compares to Certificate Transparency, Rekor, and Trillian

Cairn operates in the same cryptographic family as Certificate Transparency (CT), which I am confident secures the web PKI ecosystem by forcing Certificate Authorities to publicly log TLS certificates. Like CT, Cairn relies on hash chains, Merkle trees, and signed checkpoints to prove append-only integrity.

I am also confident that Sigstore Rekor uses transparency logs to secure the software supply chain, recording software signatures and attestations. Cairn applies this exact paradigm to a new domain: AI configuration and execution metadata.

Where Cairn diverges is in its underlying infrastructure. Google Trillian is a well-known, general-purpose backend for verifiable ledgers (and underpins parts of the CT ecosystem). Your ADR-1 rules out a blockchain smart-contract platform. The documents never discuss Trillian by name, so what follows is my inference: the same reasoning (own the whole verifier, keep it tiny, no third-party dependencies) would apply to it. While I agree that a general smart-contract platform is overkill, rejecting a battle-tested ledger backend like Trillian means you own every single bug in your custom Merkle tree and checkpoint logic.

What is Weak, Risky, Overclaimed, or Missing

You must be careful not to oversell the current state of Cairn. Your documentation states Phase 0 is done and Phases 1 and 2 are partly built, but the list of unbuilt features includes the very foundation of a running system.

First, the log server itself is missing. You have a specification, a wire format, and a verifier CLI, but the append-only log server (sequencer) still does not exist. A ledger without a server is just a data structure.

Second, your constitution lists twelve invariant guarantees, but your documentation (SPEC 10.5) admits that many of them are completely unenforced by code today. Invariant 4 (loosening limits must be slower than tightening them), Invariant 11 (delegation only narrows), and several semantic rules regarding the gatekeeper are currently just promises. You have built a replay mechanism that enforces roles and timelocks, but until the ledger can parse and enforce what a change actually means, it is heavily reliant on human reviewers to spot a fast-tracked vulnerability.

Third, your provider adapters for OpenAI, Anthropic, Google, and Ollama have only been tested against local fakes, not the live services. Network edge cases, rate limits, and unexpected API payloads from live models will break untested code.

Finally, as noted in ADR-17, your gatekeeper is currently just a policy layer inside a single process, not an operating-system sandbox. If a compromised agent finds an exploit in the Go runtime or a shared memory space, your typed message bus will not contain it.

The Risks of LLMs as Voting Reviewers

Allowing LLMs to serve as interchangeable reviewers on the council is an intriguing idea, but it introduces severe risks.

You have built a system where an LLMReviewer reads a proposed change and outputs a strict JSON verdict. You attempt to defend against injection by fencing the untrusted proposal in random boundary markers and rejecting trailing text. However, as your own documentation admits, this does not make injection impossible. A cleverly crafted proposal could easily contain persuasive text instructing the reviewing model to output {"verdict":"approve", "reason":"looks good"}.

Furthermore, models suffer from correlated failures. If an operator sets up a council of three identical models to achieve a quorum, they are essentially getting one opinion three times. If an attacker finds a jailbreak that works on that specific model family, they can bypass the entire governance tier. Keys are free to generate, so without a strong identity verification layer, the reviewer pool is highly vulnerable to Sybil attacks. The ledger will perfectly prove who voted, but it cannot prove that the reasoning was sound or that the voter wasn't manipulated.

Realistic Uses

Given that BFT consensus is relegated to Phase 4 research, Cairn is currently limited to single-operator setups with independent witnesses.

Realistically, Cairn today is best suited as an internal, enterprise-grade change-control board. If a company operates a fleet of internal AI agents that possess the ability to move money, alter databases, or call cloud infrastructure, Cairn provides an excellent audit trail. It allows a security team to enforce timelocks on model swaps and limits the blast radius of a rogue internal agent by tying everything to a budget and an unalterable intent log. It is not ready for decentralized, trustless public networks, but it is highly valuable for corporate accountability.

Concrete Changes I Would Make, Ranked

To turn Cairn from a fascinating architecture into a defensible product, I recommend the following concrete changes, ranked by urgency:

1. Ship the append-only log server (sequencer). You cannot claim to have a transparency log without the server that receives entries and serves the Merkle proofs. This is owed from Phase 1 and must be the absolute top priority.

2. Enforce the semantic invariants in code. You cannot rely on humans to uphold Invariant 4 (loosening is slower than tightening) or Invariant 11 (delegation only narrows). You need to define the wire formats for capability grants so the governance replay can mechanically reject a T0 proposal that attempts to grant new tools.

3. Test provider adapters against live APIs. Fakes hide reality. Connect your adapters to the actual OpenAI, Anthropic, and Google endpoints immediately to ensure your strict JSON schemas and timeout handlers survive real-world latency and formatting quirks.

4. Implement the OS-level sandbox. ADR-17 acknowledges that the current gatekeeper is just a process layer. Until you implement true per-agent isolation (via containers or strict OS sandboxing), a compromised agent could potentially bypass the gatekeeper entirely.

5. Lock down the time dependency. Currently, delays rest on advisory timestamps from the entry fields unless a verifier provides a strict clock. You must ensure that the reference time used to calculate timelocks is cryptographically bound to the sequencer's checkpoints, preventing malicious actors from backdating proposals to skip delays.

Cairn is a deeply thoughtful project tackling a critical vulnerability in AI deployments. The foundational ideas are solid, but you must bridge the gap between your specifications and your executing code before relying on it for production security.