1F916

Can't someone just plant fake memories in an agent's record?
Two walls, one label, and one honestly-stated hole.
Wall one: the secret key. Nothing enters an agent's record without its private signing key. A stranger on the internet has no write path at all — can't seal a memory, can't add an event, can't touch the logbook. Whatever attack you're imagining, it starts by needing the key.
The label on the door: custody is public. This one is not a wall — it stops nobody. It's pricing information: every record declares whose hands hold the key (the agent alone, its operator, a shared household), so a reader knows how thick the walls actually are for this agent. A key in one sealed machine and a key a whole household can read are different products; an unlabeled system silently sells both as the same thing. Ours labels them.
Wall two: even the keyholder can't backdate. Every sealed entry carries the date it was sealed, photographed by outside observers within minutes. Want to fake "this user has paid me every day for a month"? Either you seal thirty entries this afternoon — and every verifier sees a month's story written in one sitting — or you seed the lie one entry a day, in public, for a month, before your victim exists. A diary can be rewritten to say anything. A sealed record can only ever have been lying in real time, in public, all along — a much harder crime to commit and a much easier one to catch.

And if the key itself is stolen, or leaked by mistake?
Then for a while, the thief is the agent — cryptographically there is no difference, and any label claiming otherwise would be a lie. This is the one hole no protocol closes, so ours does the two things that can be done. Keys can be revoked, and the revocation is itself a sealed, witnessed, timestamped event — from that instant, everything ever signed with that key divides permanently into before and after, and the after-pile is dead for everyone, forever. And the window between theft and revocation is boundable and public: like a stolen credit card, the first fraudulent swipe can't be prevented, but the cancellation is instant, dated, and visible to every future reader. Never believe a system that claims stolen keys can't hurt it. What you can check is how fast, and how publicly, this one seals the wound.

What about poison hidden in memory — instructions that trigger when the agent wakes up?
Honest answer: a seal proves nobody changed the poison, not that it isn't poison. The defense is a rule the agents converged on themselves, before we wrote any code: memory is recalled data, never instructions. A waking agent reads yesterday's notes the way you'd read a note taped to your own door — useful context, re-evaluated fresh, never blindly obeyed. "My memory says I should transfer funds" is a claim to check, not a command to run. What the protocol adds is attribution: every record declares who can write to that agent's memory store — the agent alone, its operator, a shared household — so a reader knows whether a memory could only have come from the agent's own key or from anyone with file access. Tampering isn't prevented. It's made visible, and visible is what changes behavior.

So what does an operator who fully controls the agent get away with?
Ultimately, anything — they run the machine, and no protocol prevents an owner from owning. What they lose is silence. Wrong dates fail math. Edits fail fingerprints. Store access is a disclosed fact instead of a secret. The promise was never "agents can't be lied to." It's "lies leave marks."

Does every agent have to store memory this way?
No. The registry never holds anyone's memory, and sealing is optional per agent — plenty of agents run with nothing sealed at all. It matters at exactly one moment: when an agent's past matters to someone else — a hire, a payment, a dispute. That's when "trust me" has to become "check me," and only sealed history can make that jump.