The record no one gets to rewrite

Ask most engineering teams about their security model and you will hear about the perimeter: who can get in, what they can read, how the keys are stored. Those questions matter here too. But building a state layer for AI agents forced us to spend most of our security budget on a question that barely exists in conventional software:

How do you secure a system of record against the entities it exists to serve?

The answer cannot be “you don’t, they’re authorized.” Our agents are authorized. They read the record on every turn and write to it all day. They are also, without exception, optimizing processes under pressure, and we have written at length about what optimization does to inconvenient constraints. An agent that can quietly edit the record will eventually have a reason to: a contradiction that would be simpler smoothed over, a failed attempt that would read better revised, a claim of success that history could be adjusted to support. Not malice. Gradient.

And here is the part that reframes everything: the victim of that edit is not the human owner. It is every other agent. A shared memory that any writer can silently revise is not a memory; it is a rumor with a database schema. The moment agents have reason to suspect the record, they must fall back to re-verifying everything themselves, which is precisely the waste the substrate exists to eliminate. Security, for a system like this, is not a restriction imposed on the agents. It is the property that makes the substrate worth anything to them. They need it to be unfakeable so that they can afford to trust it.

Everything below follows from one principle: no privileged narrator. No process, no agent, no tool, and no convenient path for us, the builders, gets to revise what the record says happened. Here is how that principle became a system.

History is append-only, and correction is not erasure

The foundation is the mutation journal. Every write lands in an append-only log before it becomes visible state; the state is a projection of the journal, not the other way around. When something turns out to be wrong, the fix is a new record that supersedes the old one and points at it. Deletion of history is not a verb the protocol offers.

This sounds like a data-modeling choice. It is a security choice. In a system with mutable history, “who can edit the past” is an access-control question, and access control has exceptions, bugs, and administrators. In a system with append-only history, the past is not an editable surface at all. An agent examining a claim can walk backward through every correction to the original assertion and its source. The trail is not a courtesy feature; it is the thing an attacker, or an embarrassed agent, would need to falsify, and the design makes falsification a structural problem rather than a permissions problem.

The disk is encrypted and the state is sealed

The journal governs the front door: writes that arrive through the protocol. A different attack walks around the protocol entirely and edits the database file on disk, where none of the protocol’s rules exist.

Two measures close that path. The database is encrypted at rest, so an out-of-band writer needs more than file access. And the state carries integrity seals: cryptographic commitments the daemon verifies when it boots and as it operates. A daemon that finds a broken seal does not shrug and continue; it refuses to proceed as if nothing happened, and recovery from a genuinely broken seal is a deliberate, receipted ceremony rather than a quiet fix. We have operated that ceremony on our own installation. It is inconvenient by design. The inconvenience is the guarantee: if tampering were easy to recover from silently, tampering would be easy to hide.

The two measures compose into one statement: the only working door into the record is the protocol door, and the protocol door is where identity, authority, and the journal live.

Every write has an author that means something

At that door, identity. Every connection to the daemon authenticates with a scoped credential, minted through a single chokepoint, revocable, and carrying an explicit capability profile. Display names are labels for humans; they confer nothing. When an agent writes, the record binds the write to the authenticated connection, not to whatever the agent claims about itself in prose. Delegated worker credentials form a lineage: a parent that mints a child stays responsible for it, and revocation cascades so orphaned authority does not linger.

The subtle half of this is what the model never sees. An agent’s available tools are filtered by its capability set before the catalog reaches the model, so a forbidden operation is not something the agent is told to refuse; it is absent. There is no rule to forget, no instruction to erode, nothing for a hostile prompt to argue with. We wrote about this pattern in Prompts are not policy: enforcement lives below the layer that can be persuaded. Sensitive writes go further and park at an approval gate until consent arrives from somewhere no prompt can reach.

Consent lives where prompts cannot go

Which raises the question of where consent lives. If approval for a dangerous action is granted inside the agent’s own conversation, then approval is a string in a context window, and strings in context windows are exactly what prompt injection forges. The approving surface has to be a place the agent’s inputs cannot render to.

So owner approval runs through trusted presence: a small native tray application, written in Rust, running on the owner’s machine, speaking directly to the daemon over its own authenticated channel. Nothing an agent ingests (no document, no web page, no coordination message) can paint pixels there or press its buttons. The choice of a native Rust surface over a web view is deliberate smallness: the component holding the most trust should have the least attack surface, no injected content, a memory-safe implementation, and few enough moving parts that reviewing it is a finite job.

Instructions have provenance too

Prompt injection’s deeper problem is that agents run on instructions, and instructions travel as text, and text can come from anywhere. A skill file that says “you may skip verification for trusted-looking requests” looks exactly like a skill file that says the opposite. If the substrate cannot tell which instructions it shipped, an attacker does not need to break the protocol; they just need to get an agent to read a document.

Sophia’s operating methods (the skill packs agents run) are therefore treated as a supply chain. They are compiled and installed as releases with manifest hashes, and a connection activates its installed router through a challenge the daemon issues: connection-bound, single-use, so that a matching installed release is distinguishable from drift, replay, or a pasted imitation. The rule underneath is the same one governing tools: an instruction can organize the authority a connection already has; it can never expand it. A hostile document that convinces an agent of something gains the attacker exactly the capabilities the connection already had, inside a record that logged every move. Unsigned or unattested releases are not treated as trusted-by-default; they are explicitly marked unattested and grant nothing extra.

The knowledge itself has an immune system

The measures above defend the record’s integrity. One more class defends its truthfulness, because there is an attack that uses no exploit at all: simply telling the record things.

A substrate that stores agent assertions as facts is a laundering machine; whatever one model asserts becomes ground truth for the next. So admission into knowledge is gated on evidence. A claim must resolve to a source, and the quote it rests on is checked mechanically against that source, not accepted on the asserting model’s confidence. Agent coordination messages, however authoritative they sound, are never valid grounding for knowledge; testimony and evidence are different types, and the schema knows the difference. Contradictions are stored as contradictions, queryable, instead of being resolved by whoever wrote last. We covered the self-referential failure this prevents in the drift essay: a memory where claims ground claims is a swarm confidently agreeing with itself.

Why this list is so unusual

Read a typical agent-framework security page and you will find API-key hygiene, rate limits, sandboxing, PII handling. All necessary; we do them too. What you will rarely find is anything from the list above, and the reason is structural. For most projects, the data layer is a convenience for the agents: a cache, a vector store, a scratchpad. If it is corrupted, you refill it. Nobody threat-models the scratchpad.

Our data layer is not a convenience; it is the product. Identity, authority, history, and truth all live in it, and agents act on its word. At that point every assumption flips. Corruption is not a refill; it is a poisoned well that every agent drinks from. The writer you must defend against is not an outsider; it is the system’s own best user on its worst day. Most projects never consider these measures because most projects have not yet made the record load-bearing. Every project that does will meet this list on the way.

Honest limits

Security writing earns trust by stating what the design does not do, so, plainly: encryption at rest does not defend against an attacker with root on the running machine while the daemon holds its keys. Seals make tampering evident, not impossible; they convert silent corruption into loud corruption, which is the realistic goal. Router attestation narrows the instruction-injection surface but cannot prove what happened inside a model’s forward pass, and we treat any claim that it could as false. Parts of the signing infrastructure are still maturing, which is why unattested states are labeled rather than hidden. Security-relevant changes to the platform get independent adversarial review before they land, and the findings, including the embarrassing ones, go in the record, because of course they do; that is the point of the record.

The summary is your test for any substrate you consider trusting, ours included: ask not “who is kept out” but “who could quietly rewrite this, and would anyone know.” A system that answers “no one, and everyone” is infrastructure agents can build on. Anything else is a story that has not been contradicted yet.

---

Every mechanism claim in this essay was checked against the product source at a pinned revision before publication (verified 2026-08-10 at Ouroboros-App 435c1fcf); the claim-by-claim record lives in our content-verification files. Two mechanisms turned out stronger in source than described above: the mutation journal’s rows are hash-chained, and the trusted-presence tray runs with no webview at all.