Cairn Framework

Part 13 of the Cairn series. Since Dev log 9 there have been three steps: language-neutral vectors for the Merkle proofs, an abuse catalogue with a warning in the verifier, and then the big one, a full review of everything by three different AI vendors. OpenAI read all the code. Gemini read all the documents. DeepSeek read both. This post lists what each of them found, what was real, what was wrong, and what went wrong on my side while I was doing it. These are AI reviews. They are not a professional security audit, and nothing here should be read as one. Where Dev log 9 left off Dev log 9 ended with hash-only payloads, durable opening storage, and vectors for those formats. It listed what was not built, and two items on that list were vectors for Merkle proofs and a catalogue of the ways someone could misuse the framework. Both are done now, so this post starts there. Step 1: vectors for inclusion and consistency proofs The Merkle tree in Cairn follows RFC 9162. A proof format th...

Part 11 of the Cairn series. Dev log 7 made the log hold agents to the grants they have. It ended by naming the gap: an agent that has never held a grant is not checked at all. This post is about closing that gap, one bug it turned up, and what two clean audits do and do not tell us. The gap After dev log 7, replay checked every action of an agent that held a grant against that grant. But "held a grant" was the trigger. An agent that had never been given one was unconstrained, because the rule that binds an agent to a grant could only start once there was a grant to be bound to. The simplest way around the whole system was never to ask for a grant. That was a sensible default while grants were new. It is a poor default for anyone who wants the log to mean "everything an agent did was inside what it was allowed to do". So the fix is not to change the default for everyone. It is to let a deployment write the stricter rule into the log itself, where every verifier ...