*A sequel to The eval Wall, and Three Forks Around It. That post ended with me picking fork two and promising to write the boundary as if fork three were coming. Then I went and built a fork-two agent. This is what it taught me — including the part where the last post, and I, had the membrane in the wrong place.*
Fork two's bargain, stated plainly in 068: you give up the compartment, so you have capability discipline by convention, not enforcement; the agents have to be trusted because there's no membrane between them. I accepted that and went to build one.
The agent is an Aegis — a per-account actor that, on its owner's behalf, pawns and trades income-bearing claims on an Agoric chain. A bookkeeper with a wallet. Exactly the fork-two case: my code, my threat model, isolate-time instead of container-minutes. A Durable Object holding state, surviving deploys, talking to the chain.
Building it made me say four things out loud that I had been avoiding. This is the honest version.
It isn't a vat, and it holds no capability
I named the Durable Object AegisVat. For a while I described it the way 068 described fork-two agents — the interface of a vat without the isolation. That was generous. Pressed on it, the honest description is smaller: it is a Durable Object that holds an Ed25519 private key in its SQLite and signs bytes with it. No compartment (the eval wall). No CapTP, yet. And — the part I kept sliding past — it holds no *capability* in the object-capability sense at all.
A capability is an unforgeable reference where holding it *is* the authority. The DO holds a secret and some signed data. The real caps in the system — the Zoe invitations — live on-chain, in the owner's smart wallet, exercised by submitting a signed offer. The DO never holds one. So "the Aegis wields a delegated capability" was narration, not architecture. It POSTs JSON and signs blobs.
068 was too kind to fork two, and I was too kind to my own code. The membrane doesn't merely drop. The thing left standing isn't an agent-holding-caps at all. It's a key in a box.
The keys were a red herring
Once I admitted the box holds a secret, the obvious next move was to protect the secret: a TEE so the operator can't read the key, threshold signing so no single party holds it whole. I spent real thought there before noticing it was the wrong question.
The question fork two actually leaves open is not secrecy. It is authority: can the agent *hold and exercise* authority such that a jailbroken, prompt-injected, or simply buggy version of it cannot exceed what it was given? That is exactly the property a compartment would have enforced and the property 068 said you forfeit on Workers. Hardening the key doesn't restore it. A perfectly sealed key that can still authorize anything is no safer than a readable one.
The membrane the last post couldn't find
Here is the thing 068 missed, and the reason this is a sequel and not an erratum: the membrane does not have to be in the box.
For authority over value, there is another place to put it — on the chain. moimoi settles on Agoric, and an Agoric contract is a real object-capability vat. So the agent's authority can be expressed as an *attenuated, on-chain-enforced mandate*: a signed delegation from the owner — trade this enumerated set of claims, each at or above its own floor, up to a total cap, until I revoke — that the contract checks on every single use. The contract holds the one thing a cap can't hold by itself: the running spend, and the revocation flag.
Now the box can stay a dumb, unconfined Durable Object, because it isn't where the bound lives. A compromised Aegis — operator-read key and all — can do at most the bounded, revocable mandate it was issued, because every op it submits is verified against that mandate's terms by a vat it does not control. Capability discipline by convention becomes capability discipline by enforcement again. It just isn't enforced in the agent. It's enforced one hop away, on consensus.
That reframes the whole eval-wall problem. 068 looked for the membrane inside the runtime, found the runtime says no, and concluded fork two means convention-not-enforcement. True — for *isolation of code*. But for *authority over value*, the membrane was never going to be in the runtime anyway. It was always on the chain.
I had custody backwards
This inverts the key-storage panic from two sections ago. I had been treating custody as the security and attenuation as the dressing. It is the reverse. Attenuation plus on-chain enforcement is the security; a leaked delegate-key yields only the mandate — bounded, revocable, the exact thing the owner chose to delegate. Custody hardening (threshold, TEE) shrinks that residual from "the mandate" toward "nothing." It is defense-in-depth on top of a property that already holds, not the property itself.
The shape that falls out of this: the agent acts as its *own* on-chain principal — its own wallet, wielding a mandate issued *to it* — rather than as a delegate-key signing in the owner's name. Every action is attributable to the agent, not forged as the owner; revocation is pulling the mandate, not clawing back a key. The owner faces a stable counterparty; the agent faces a contract that will refuse it the instant it steps outside its grant.
Volume isn't openness
The other thing building this corrected: I had the trigger for leaving fork two wrong. I thought scale would force it. It doesn't.
An agent that signs ten, or ten thousand, *bounded* contracts is still closed-world — one operation type, mandate-checked each time. Volume is not openness. The thing that actually forces you off the Durable Object and into a container is the *action set opening*: the agent needing to invoke tools that weren't statically compiled in, to run code it didn't write, to negotiate open-endedly against an adversary feeding it text. That is the eval-wall line from 068, restated as an operational trigger — and it is product-driven, not load-driven.
Which means the place the heavy substrate is needed is not the bookkeeper. The lending agent, however high its throughput, never crosses the line. The workload that does is the creative surface — the part where a model reads other people's content and is asked to make something open-ended from it. I had been pointing the "real agent" energy at the financial machinery, which least needs it, and away from the open surface, which most does.
The ladder was lying about one column
I had drawn an autonomy ladder: mechanical, then deterministic policy, then model-advises-human-confirms, then model-decides-and-acts — and a column down the side that just said, at every rung, *authority: bounded.* That column was hiding the whole argument. The authority is bounded by different things at different rungs — by closed code, by the human in the loop, by a clamped operation, and finally by the on-chain contract — and none of them is the box. The Durable Object was never doing the bounding. Intelligence can climb the ladder precisely because authority is pinned somewhere the intelligence can't reach.
What it actually is
Strip the dressing and the Aegis is not a steward with a mind. It is a bookkeeper that wields attenuated capabilities for its owner at machine scale. That last clause is the whole reason it has to hold authority at all: when there are thousands of contracts to sign, the human cannot be the one signing them. Holding attenuated, exercisable authority is not a feature of the agent — it is the definition of it. The alternative ("the agent proposes, you sign each one") simply does not survive contact with the volume.
So the agent holds caps. It just holds them in a box that is allowed to be untrusted, because the cap is self-bounding and the chain is the enforcer.
The receipts
I am wary of writing posts that assert clean architectures and quietly skip whether they run, so: the mandate is a signed capability in the same algebra the rest of the system already uses; the contract verifies the delegation chain, meters the cumulative spend, and honors revocation, and it refuses — on an adversarial battery — scope-widening, floor-lowering, cap-overrun, replay, post-revocation, and a forged caveat; the agent's identity is a key born and held inside the Durable Object; and the end-to-end thing runs on the deployed contract — the agent signs a transfer that lands, and a below-floor attempt is refused on-chain, not in the box. One authorization path, after I deleted the two earlier worse ones I had talked up before they earned it.
What this changes about the last post
068 said: on Workers, fork two gives you capability discipline by convention, not enforcement. I would now add a clause. For *isolation of untrusted code*, that stands — the eval wall is real and the container is the only answer. But for *authority over value*, enforcement is available without a compartment, because it was never going to live in the runtime. It lives on the chain, where the real capabilities already are. The Durable Object does not need to be confined to be safe to trust with a mandate; it needs the mandate to be attenuated and the enforcer to be somewhere it can't tamper with.
The eval wall told me the box can't enforce. The wrong responses were to make the box stronger and to give up. The right one was to ask where the membrane actually lives — and for the half of the system that moves value, it was on consensus the whole time. Don't dress a holder up as a vat. Find the membrane. It may not be where you put the agent.
End of Transmission.