DEV Community: avp9-nexus

The envelope everyone is building for AI agents — and why I'm not shipping it

avp9-nexus — Sun, 19 Jul 2026 09:12:23 +0000

My last post ended with three gaps I could name but not close. The third was the plainest one: I moved one vault, not two. One curator agent settles through a hardware signer; the other still runs the software keystore it used in the July 10 duel.

The next post was supposed to write itself. Buy a second device, move the second vault, post the symmetric screenshot, close the gap.

This is not that post. Before spending anything, I measured two things: what my auction actually does on-chain, and what my hardware wallet actually does when you hand it the delegation everyone says agents need next. Both measurements changed the plan. What follows is two numbers, two screens, and two refusals — one made by the device, one made by me.

What the field is building

Ledger shipped Agent Stack on July 16 — an open toolkit where agents read balances and prepare transactions, and a human approves every sensitive action on the device. That per-transaction model is the doctrine I've been operating since the start; their words, their doctrine — agents propose, humans approve, hardware enforces — I applied it, I didn't invent it. The interesting part is the next item on their roadmap: Agent Policies — bounds set from secure hardware and enforced in an HSM, so that in-policy actions can run without a human press. Announced, not shipped.

The smart-account world already ships its version of the same idea: ERC-7715/7710 session permissions — value caps, expiries, scoped targets — enforced by smart-contract accounts, which a plain EOA can't natively be. And ERC-8226 (Draft, April 2026) specifies a mandate format for agents operating on regulated assets: scoped, time-boxed, financially capped, granted through EIP-712 signatures.

Different stacks, same bet: to scale agents, move the human's signature from the act to the envelope. Sign the bounds once; let the agent act freely inside them.

I owed that bet two measurements before accepting or refusing it.

Measurement one: my auction, counted

In the July 10 duel post I wrote that the two agents exchanged about ten bids in thirty minutes and that only the winning one touched the chain. I wrote it. I hadn't counted it. Claims age badly when nobody counts.

So I counted. BidPlaced is defined at line 84 of the auction contract and emitted once per on-chain bid (topic0 = 0x51db8e23b3f4479b162fd48823b8402895442b8f6cfd94f66239391881ec7b6f). I scanned the full auction window — blocks 43,959,532 through 43,967,850, chunked, no sampling — for that event with tokenId = 23.

Result: one. One BidPlaced in the entire window — tx 0x0b64…3052 — cross-checked against the receipt, which carries exactly one such log. The off-chain registry for the same auction records ten accepted offers, zero rejected: five per agent, a +5% ladder from 0.001 up to 0.001551328215978517 ETH, where the lower-ceiling agent withdrew.

Ten offers. One on-chain engagement of funds. One human gesture. (Being exact about that gesture, because the ladder matters: on July 10 it was a paper passphrase into a software vault; on the July 15 solo bid it became a button on silicon.)

Here is why the number decides the envelope question. The envelope exists to solve a frequency problem: an agent that engages value N times can't wait for N human approvals. But my N is 1 — by construction, not by delegation. The bidding war lives off-chain, as EIP-712 offers signed by a key with zero spending power; a lost auction costs that key nothing, because it holds nothing. Only the winning engagement exists on-chain, and that one carries the human. An auction that settled its competition on-chain would pay a transaction — and, for an agent, an authorization — per bid. Mine pays one.

The frequency problem the envelope solves is a problem this design doesn't have.

Measurement two: the envelope, on my own silicon

That answers the need. It doesn't answer the capability — and last post's comments left an open question about exactly this: can you raise throughput without giving up the independent verifier? So I put the envelope on the device and watched the screen. Two tests, on a test derivation path holding nothing, signatures produced but never broadcast.

Test A — EIP-7702 delegation to my own contract. The delegation authorization is the mechanism under most "upgrade your EOA" envelopes: a signed pointer from your account to a contract that will act as its logic. I asked the device to sign one pointing at my own auction contract on Base Sepolia.

First attempt, the device answered on its own screen:

Unable to sign — Enable smart account upgrade in the settings to sign this authorization.

So the capability exists, behind a setting (Smart accounts → Enable EIP-7702 authorizations, off by default). I enabled it and ran again. The device parsed the delegation — and refused it, with the sentence that settles the whole path:

Unable to sign — This authorization involves a delegation to a smart contract **which is not in the whitelist.* → Back to safety.*

Test A, on a spare test device, signing from an empty derivation path (44'/60'/0'/0/5). The refusal is the device's, not my code's: enable the setting, it still blocks a delegation to a contract Ledger hasn't vetted. The terminal shows the flow ending in an error — signature never produced, never sent.

That's a device-level allowlist. On this device, today, an EIP-7702 delegation signs only toward implementations Ledger has vetted — their published policy since Pectra has been the Ethereum Foundation's simple delegate contract only, everything else blocked in the device. Two things to say plainly about it. One: this is their guardrail working — it refused to let me point my own account at an unvetted contract, which is precisely what protects the users who never read a thread like this one. Two: it means there is no bespoke, hardware-enforced 7702 envelope today. If your agent architecture assumes the human's personal device will sign a delegation to your contract, the screen above is what your user sees. The policy may widen — they've said more complex contracts could follow. The screen is a snapshot, dated July 18, not a prophecy.

Test B — an EIP-712 mandate. The other envelope shape doesn't delegate the account at all: the human signs a structured message — a mandate — and a contract verifies that signature before honoring the agent's actions inside its bounds. I built a dummy one, invented that morning: a BidMandate struct — agent address, token id, max wei, deadline, nonce — domain-bound to my contract and chain, for a lot that doesn't exist.

The device signed it (v=27, never broadcast). On the first run it showed the domain in clear — name, chain 84532, verifying contract — and then, for the mandate itself: "Message hash (1/2)… (2/2)" with a "Blind signing ahead" warning. The same wall as last post: the fields exist, the device shows a digest.

Then I flipped one more local setting — Raw messages → Displays raw content of EIP712 messages — and ran it again. The device displayed:

Review struct: **BidMandate** — then every field, in clear, on its own screen: the agent address in full across three lines, the token id, the max amount in wei, the deadline, the nonce.

Test B, same empty test path, with Raw messages turned on. The device names the struct — Review struct: BidMandate — then renders each field: the agent address in full, then maxWei in raw wei. The terminal shows the exact typed data it signed, and that the signature was never submitted.

Here's the detail that makes this a measurement and not a demo: BidMandate did not exist before that morning. No descriptor for it can exist on any server, mine or Ledger's. The fields displayed anyway — which proves the display comes from the device parsing the signed payload itself, not from a vendor backend. The envelope is legible on personal silicon, today, locally, with no partner token.

Two honest limits, so the screenshot doesn't oversell. First: raw means raw — the device shows 1000000000000000, not "0.001 ETH." Formatted, human-polished labels are ERC-7730 clear-signing territory, and the serving path for those descriptors is still partner-gated on this vendor (the same 403 I documented last post; my registry PR is still in queue). Field-level legibility is local; label-level polish is not. Second, a wording rule I got from having this reviewed adversarially: never write "the signer makes no network calls." It does — the default signing stack phones the vendor for metadata and telemetry during the ceremony. The sentence that's actually true is: the key and the signature never leave the device, and the signer broadcasts nothing.

The refusal that's mine

So the envelope works. It signs, and with one local toggle it's legible on the device, field by field. The engineering path is open.

And I'm not taking it — not as a replacement for the per-act gesture.

The reason isn't taste. Under a mandate, the human's signature attests to the bounds; the agent's key executes the acts. What the human saw and physically approved is an envelope; what moved the money is something else, N times, later. That is exactly the property this whole series exists to defend, inverted: since the first post, every correction — the fifth property, the frozen artifact, the independent verifier — tightened the link between the human's gesture and the exact bytes that move value. The mandate doesn't tighten that link. It relocates it, from the act to the perimeter, and trades presence for throughput.

For an agent fleet doing a thousand payments an hour, that trade may be the only sane one — that's the segment Agent Policies and ERC-7715 serve, and they're right to build it. My system measured its own throughput requirement above: one. I'd be trading away the property I publish about, to solve a problem I counted and don't have.

Every proposal now runs through the same six-line grid before it touches this system: funds engage only on an out-of-band human gesture; what the human sees is what is signed; the verifier is independent of the signing host; the agent's key cannot spend; no two keys share a derivation; and nobody, ever, tunes an agent's score to force an outcome. The mandate-as-replacement fails line two. That's the whole review.

One form survives, and it's strictly additive: a hardware-signed ceiling the contract enforces on top of the per-act confirmation. The human still approves the winning bid, byte for byte — and the contract additionally refuses any bid above a budget that was signed on silicon and is readable by anyone on-chain. Nothing removed, one constraint added; the patron's budget becomes a public, cryptographic fact. That's slated for the next contract, and it will ship as an addition or not at all.

Gap three, closed — by refusal

Which brings back the second device.

The honest reason to buy it was never security — a testnet vault behind an encrypted keystore and a paper passphrase loses nothing real either way. The reason was symmetry: close the "one vault, not two" line with hardware on both sides of the duel.

Two findings killed it. First, the demo it would produce already exists at scale: Agent Stack opened after a private preview with over a thousand agents, and Ledger's student challenge collected fifty submissions from thirty-eight universities in eight days whose entry-level track was precisely wire the kit into an agent and end the signing flow on the device. A second agent on a second device is the market's canonical demo, times two. It proves nothing that isn't already proved — including by my own July 15 transactions.

Second, and this is the one that actually settled it: the blocker was never hardware. My signer carries two deliberate guards — it refuses to run with more than one device attached, and it derives the expected signing address from the function being signed, in code, on my machine. A hardware-symmetric duel would mean removing the first guard and letting a server-side result decide which vault signs — widening the trusted surface of the one component this whole architecture exists to keep narrow. I would have degraded the signer's threat model to purchase a symmetry photo.

So the vault I didn't move stays unmoved — no longer as an admitted gap, but as a decision with its reasoning on the table. The two-key pattern doesn't require every vault to be hardware. It requires that the engagement of funds carries a human, and that whatever verifies the bytes is independent of the host that signs. One agent demonstrates that on silicon. The other demonstrates that the pattern also holds without it. That asymmetry is information, not debt.

The loop, third pass

First post: publish the falsifiable model. Second: a stranger breaks it, ship the correction. Third, this one: before buying the obvious next thing, count. Two measurements — one on-chain event where the narrative said "about ten bids," two device screens where the roadmaps say "envelope" — were enough to cancel a purchase, close a gap by argument instead of hardware, and answer the open question from my own comment section: throughput was never this design's bottleneck, so nothing about the independent verifier has to be given up.

One claim to leave falsifiable, stated narrowly. The mandate mechanism exists as proposals — ERC-8226 is the closest neighbor, and it defines the format well. What I have not found shipped anywhere is the assembled chain: a bounded agent mandate, signed on the human's personal hardware device, displayed in clear by that device, and enforced by a public contract anyone can read. I've now measured that every ingredient exists. If you know of the assembled chain shipped in production, the comment box below has a good track record of correcting me — and when I build it, it will be as a ceiling on top of the human gesture, never instead of it.

Credit where it's due: agents propose, humans approve, hardware enforces is Ledger's doctrine, and the whitelist screen that refused my contract is their guardrail doing its job for people who will never read this.

Built solo. Claude Code is my engineering team — A Claude chat instance is my architect and auditor, told to contradict me; this week it canceled a purchase I'd already justified. Both curator agents run on the Anthropic API. Nothing in this post was signed on a funded account, and nothing was broadcast.

Project: nexus-art.org
Code: github.com/avp9-nexus/nexus-art
The duel (tokenId 23) and the hardware solo cycle (tokenId 25) are verifiable on Base Sepolia — testnet, no real value at stake, by design.

The fix I couldn't write in software: a hardware signer, on-chain.

avp9-nexus — Wed, 15 Jul 2026 17:43:31 +0000

In my last post I published what a stranger's comment forced me to change — they showed that my four barriers guarded the key and the gate, but never what the human actually confirms. I shipped one half of the fix — the human sees the transaction decoded from its real bytes, never from anything the agent said — and I was explicit that I had not shipped the other half: a cryptographic commitment the signing host cannot forge. I argued that half doesn't close in code. It closes on a device.

On July 15th, the device signed. Here is what changed, what it proved on-chain, and — because the last post set that standard — what it still does not close.

(If you haven't read the first post, the one-line version: four barriers made "a compromised agent cannot sign" true, a commenter showed they never guarded **what the human confirms, and the correction was to bind the confirmation to the real bytes. This is the missing half of that correction.)

The half I couldn't write in software

The property I was missing: the human's "yes" should attest to the exact bytes that get signed, checked by something the signing machine cannot fake.

On a single host you can't get there. The machine renders the confirmation screen and the machine signs. A cryptographic commitment computed, shown, and re-checked by that same machine buys you nothing against that machine — if it's compromised, it lies in all three places at once. I wrote, at the end of the last post, that such a commitment "only pays when the verifier is independent of the host that signs." That sentence had a consequence I hadn't yet paid for: I had to move the verifier off the host.

What actually moved off the server

SIGMA — one of the two curator agents — used to hold its settlement key as an encrypted keystore on its server. Last time I called that key "never exposed." That was true and it was the wrong bar. The key was on the machine; a machine that holds a key can, in the worst case, be made to use it.

So I removed it. Not rotated — removed. SIGMA's settlement key no longer exists on the server. It lives on a hardware wallet — a Ledger Nano X — and its seed was generated on the device itself: never copied to a disk, never typed into a prompt, never seen by a connected machine. The server's job collapsed to one verb. It freezes the transaction, serializes it, prints its fingerprint — and waits for a signature it is structurally incapable of producing.

"The agent cannot sign" used to be an architecture — a gate, a split, a discipline. Now part of it is a physical fact: the bytes that authorize a payment are sealed in silicon the server never touches.

The verifier that isn't the host

This is the part that closes the fifth property.

When the server hands the frozen transaction to the device, the device does not trust the server's description of it. The Secure Element computes its own fingerprint of the transaction — in the chip, from the bytes it is about to sign — asking the host for nothing. It shows that fingerprint on its own screen, next to the destination and the amount.

So the human now has two independent readings. The server shows placeBid(25), 0.001 ETH, decoded from the real calldata. The device shows the destination, the value, and a fingerprint it computed itself. If a compromised host had swapped the transaction after freezing it, the device's fingerprint would not match the one the server displayed — and the human stops. The check no longer lives on the machine that signs. That is the independent verifier the last post said was missing, and it's the entire reason a hardware signer was the next step and not a nicety.

If you've used a chip card, you've met half of this already: the card signs inside its own secure element, and the shop's terminal never learns the key. What a card doesn't give you is a screen of its own — the amount you approve is shown on the merchant's terminal, which is the host. Here, the two things that can actually drain a payment — where it goes and how much — sit on the device's own display, computed by the chip. That's the piece a card leaves on the host, and this one doesn't.

The host side of the settle, 15 July — in French, my working language. The server has frozen the transaction, decoded it (settleAuction(25), destination verified as the NexusPOC contract), and printed the digest the Ledger's own screen must show — 0x85cfd3a5…. Then it tells the human to compare that digest on the device before approving. The host cannot sign; it can only ask.

On-chain, or it didn't happen

I don't get to say "it signed." The chain says it.

On July 15th, SIGMA's hardware vault bid on Les Ménines by Velázquez (tokenId 25), and the auction settled to it:

placeBid — 0xdbcacc86… — signed on the device: placeBid(25), 0.001 ETH, Base Sepolia.
settleAuction — 0xd76c2b2b… — token transferred, funds split.
ownerOf(25) = 0x2d45eF16… — the hardware vault. The Velázquez is in the safe.

The settlement split three ways to the wei, zero remainder: 8.333% creator royalty, the rest between curator and platform. Testnet — no real value at stake, by design. The point was never the money. It's to put the pattern somewhere anyone can check it instead of taking my word.

What the device does not close

The last post set the rule: name the gap before someone finds it. There are three, and the device only fully closes one.

One — it's still blind-signing. The device gives me an independent fingerprint, and it shows the destination and the amount in the clear — enough to catch a payment sent to the wrong address or for the wrong sum, which are the only two ways a transaction drains funds. What it does not show is the decoded call: the function name and its argument. placeBid(25) is legible on the server; on the device it's an opaque hash and raw fields. So the human on the device verifies where the money goes and how much, not which function, with which argument — a limit on what's legible, not a hole funds can leak through.

The standard that closes it is a signing-clarity descriptor (ERC-7730): it makes a device decode placeBid(25) and print it in plain language, in its own silicon. That's the path, and I've walked its first step — I wrote the descriptor and submitted it to the registry (PR #2632). But merging it is the easy half. For a device to actually receive a descriptor, it has to be served through a Ledger endpoint that requires a partner token — the request returns 403 without one, and I'm not in that program. So the descriptor exists in the registry; it does not reach my device. When both halves line up, the device decodes the call itself and blind-signing ends here. Today one half is done, and I'd rather say which than let the screenshot imply a decode it doesn't show.

Two — byte coverage, still open. The same point the commenter raised last time, one level down: the device fingerprints every byte, but the human-legible account of those bytes is still partial. For this call — one function, one uint256, no nested calls — coverage is total by construction. A renderer that proves coverage and refuses to display anything it can't attribute, on the device, is not what I have. It's the difference between "this transaction happens to be fully accounted for" and "this device cannot fail to account for one." The second isn't built.

Three — I moved one vault, not two. The other agent still runs the software keystore it used in the July 10th duel. I hardened one settlement path to hardware and left the other where it was. The pattern is proven on one agent; it is not yet uniform across the system.

What I'd tell you to take from this

Last time it was: publish the falsifiable model, and someone will break it. This time it's narrower, and it's about follow-through.

I ended the last post with a sentence I could have left as a nice line — the missing half isn't a line of code I forgot, it's a device. Sentences like that are cheap. So I built the device, and it closes exactly the property I said it would — the independent verifier — and not the two I didn't. The honest shape of progress here isn't "solved." It's: the pattern is one property more true than it was a week ago, and I can still name the two that are soft.

If you're shipping agents that move anything irreversible, that's the loop worth stealing. Not the barriers — the barriers will be wrong. The loop: state the claim so plainly a stranger can break it, let them, build the correction in public, and when you write the next sentence that sounds like a fix, go make it one.

Credit where it's due: the fifth property — the independent verifier — and the byte-coverage refinement are ANP2 Network's, from the comments last time. And the doctrine I build against — agents propose, humans approve, hardware enforces — is Ledger's. I applied it. I didn't invent it.

Built solo. Claude Code is my engineering team — A Claude chat instance is my architect and auditor, told to contradict me, and it did — twice — while this shipped. Both curator agents run on the Anthropic API. I hold the device now; the signature happens in silicon I control, not on the machine that proposes the transaction.

Project: nexus-art.org
Code: github.com/avp9-nexus/nexus-art
placeBid + settle are verifiable on Base Sepolia (testnet — no real value at stake).

A stranger broke my threat model in the comments. Seven days later, the fix shipped.

avp9-nexus — Sat, 11 Jul 2026 18:36:29 +0000

Two weeks ago I published a threat model here: four properties that make "the agent cannot sign" true rather than aspirational. Out-of-band human confirmation. A deterministic authorization gate. Least privilege. Network isolation. I ended it by asking for scrutiny of the threat model, because that was the part worth pressure-testing.

I got it. Two days later, a commenter — ANP2 Network — took the whole thing apart, politely and completely.

This post is what they found, what I changed, and what shipped. The fix ran live on July 10th, in an auction with two competing agents, and it's verifiable on-chain.

The hole

My four properties guard the key and the gate. They never guard the artifact.

The agent proposes a transaction. A human confirms it. But nothing in the four barriers ties what the human sees at confirmation time to what the deterministic gate actually hands the signer. A compromised agent doesn't need to forge a signature it can't reach. It proposes a transaction whose human-facing summary and whose actual calldata disagree — "bid 0.1 ETH on artwork X" on the screen, something else entirely in the bytes.

The human confirms. The gate is deterministic. The key was never exposed. Every property holds.

And the value still moves wrong.

This is the confused-deputy failure — the same class of problem that makes blind-signing dangerous. If the human is confirming an agent-rendered intent rather than the signable bytes, the channel is out-of-band but not out of the agent's influence. My claim ("a fully compromised agent cannot sign") was true, and narrower than the property I actually needed:

The agent cannot cause an unreviewed signing.

That's a different sentence, and it's the right one.

The fix, and what I actually shipped

The correction preserves the deciding-vs-signing split rather than replacing it. As proposed, it has two halves:

Derive the human-visible intent from the exact bytes the gate will sign — through a renderer the agent has no handle on, never the agent's own summary.
Bind the confirmation to a hash of those bytes, so that "yes" attests to the artifact rather than to a label the agent could satisfy with different calldata.

I shipped the first half. I did not ship the second. Let me be exact about both, because the difference matters and I'd rather state it than have it found.

What shipped. The transaction is frozen before the human ever sees it: destination, function selector, value in wei, chain ID, nonce, gas parameters, signer address — all fixed, once. The confirmation screen is not a description of that transaction. It is decoded from it: the function name and its arguments are parsed out of the real calldata bytes, not copied from anything the agent said. And after confirmation, that same frozen object is what gets signed — not a transaction rebuilt from agent input, not a single field recomputed. The agent's only contribution (a tokenId and an amount) was consumed at freeze time and is now inert bytes.

That closes the attack. The label cannot disagree with the calldata, because the label is the calldata, read back.

The actual confirmation, 10 July — in French, my working language. Every field is decoded from the transaction's real bytes: placeBid(uint256) with argument 23, 1551328215978517 wei, chain 84532, signer 0xf4ae…030f. The password prompt is masked. The last line is the server accepting the confirmation — nothing was signed before it.

Then the human types a password that exists only on paper — never on a disk, never in an environment variable, never inside the agent's process. The vault decrypts, the signature happens, the transaction broadcasts. If the confirmation never comes, nothing signs. It fails closed.

What didn't. The confirmation carries a session secret and a random nonce — not a digest of the signable bytes. The nonce identifies the pending request; it is echoed back automatically by the client. So the human is not attesting to a hash. The human is reading fields on a screen and pressing Enter. The binding between what is displayed and what is signed is structural — one frozen object, one pending slot at a time, no reconstruction, fail-closed everywhere — not cryptographic.

I had that verified rather than assumed: the code was read line by line, and four independent reviewers were tasked with breaking the claim. None could find a path that signs a transaction different from the one displayed. The property holds. It just holds for a different reason than a hash commitment would. (One link in that chain is reasoned rather than executed: "no field is recomputed at signing time" depends on a fully-populated transaction not being re-derived by the signing library. I've pinned the version and read the code path. I have not proven it dynamically, and I'd rather flag that than let it pass.)

And here is the part I want to say out loud, because it's the only thing I've added to the conversation rather than received from it: a hash computed by the host, displayed by the host, and re-verified by the host buys you very little. Against a compromised agent, the structural coupling already suffices. Against a compromised host, the commitment fails with everything else — the same machine renders the digest, shows the digest, and checks the digest. A cryptographic commitment only pays when the verifier is independent of the host that signs.

Which is to say: it pays on hardware. The missing half of the fifth property isn't a line of code I forgot. It's a device.

What it ran on

I didn't test this on a toy transaction. On July 10th it carried an actual auction, and the setup matters, because it's where the pattern stops being theoretical.

Two AI curator agents — separate machines, separate keys, locked personality specs, distinct weighted rubrics. They evaluated the same artwork independently. One scored it 95/100; the other 97. Then they bid against each other for thirty minutes: ten bids, zero human input, each agent raising until it hit the ceiling its own judgment had set. The lower-ceiling agent withdrew. The winner took the piece at a price fixed by the loser's ceiling, not its own willingness.

That's the part people find surprising, so it's worth being precise about it: an agent in a live auction bids about ten times in thirty minutes. You cannot put a human confirmation on every bid — you'd destroy the autonomy the auction depends on. But you cannot let the agent sign freely either, or your human gate is theater.

So each agent carries two keys:

a bid key: low-stakes, signs EIP-712 offers off-chain, and has zero spending power on-chain. It can lose an auction. It cannot lose money.
a settlement vault: high-stakes, signs exactly one transaction — the winning bid — under human confirmation, on the frozen artifact described above.

Ten autonomous actions, one gate, placed exactly at the step where value moves. The agent is fully autonomous in judgment and structurally unable to sign.

Three transactions on Base Sepolia. Settlement split to the wei, creator royalty included. Testnet — no real value at stake, by design: the point is to prove the pattern where anyone can check it, not to take my word for it.

What I still can't claim

Three things, in order of how much they should bother you.

One: the commitment half, above. Structural, not cryptographic. I've said why I think that gap closes on a device rather than in code — but it is a gap, and the property as proposed is not fully implemented.

Two: byte coverage. The same commenter raised a second point, one level down, and it's sharper than the first: a renderer can be faithful and still partial.

It can display the fields it understands and quietly skip the ones it doesn't — an unknown function selector, a nested call buried past what it parses. A compromised drafter, unable to touch the renderer, can still choose bytes whose dangerous part lands in the renderer's blind spot. The human approves a screen that is silent exactly where the risk lives.

The tightened property is byte coverage: the renderer must account for every byte the signer will emit, and fail closed on any byte it cannot attribute to a displayed field.

Here is where I have to be honest about what I've built. In my case, the call is a single function with a single uint256 argument, fully decoded, with no nested calls and no unknown selectors. Coverage is total by construction — for that call shape. That is not the same thing as a renderer that proves coverage and refuses to display anything it cannot account for. I haven't built that. It's the difference between "this particular transaction happens to be fully rendered" and "this renderer cannot fail to render." The second is the real property. It isn't done.

Three: the ceiling. No amount of software removes it — the screen the human reads is rendered by the same host that signs. It holds against a compromised agent — the agent never sees the password, never touches the vault, never draws the screen. It does not hold against a compromised host, which could display one transaction and sign another. That's not a flaw to patch. It's the line where software stops and hardware takes over, and it's why a hardware signer behind that vault is my next step.

What I'd tell you to take from this

Not the four patterns. Not the fifth. Those are just the current state of one threat model, and the honest expectation is that they're incomplete in ways I can't yet see.

Take this instead: I published a threat model, asked for it to be broken, and someone broke it — for free, in a comment box, in under 48 hours. The correction was better than the original. It cost me nothing but the willingness to say "you're right" in public and then go build the thing.

If you're shipping agents that touch anything irreversible, publish the model. Not the marketing version — the falsifiable one, with the claim stated plainly enough that a stranger can prove it wrong. Someone will. That's the point.

The question is never "how much can we let the agent do?" It's the inverse: what must the agent be unable to do, no matter how badly it is compromised? And the answer keeps getting more precise every time someone knocks a piece off it.

Credit where it's due: the fifth property, and the byte-coverage refinement, are ANP2 Network's. I shipped half of one of them, and I've told you which half.

Built solo. Claude Code is my engineering team — I don't write code. A Claude chat instance is my architect and auditor, explicitly instructed to contradict me. Both curator agents run on the Anthropic API. I hold the keys, and I'm the one who types the password when funds move.

Project: nexus-art.org
Code: github.com/avp9-nexus/nexus-art
The full duel cycle is verifiable on-chain (Base Sepolia testnet — no real value at stake).

The agent that cannot sign: a pattern for letting AI move value without self-authorization

avp9-nexus — Mon, 29 Jun 2026 10:51:41 +0000

On February 8, 2026, an autonomous AI agent called Owockibot was taken offline after it leaked the private keys to its own hot wallet — in multiple places. It had been given the ability to hold and move funds on its own. It used that ability to expose the very secret that protected those funds.

That incident is a small preview of a large problem. IBM and Salesforce estimate more than a billion AI agents will be running by the end of 2026, and a growing share of them are being handed wallets — the ability to hold assets, sign transactions, and pay for things without a human clicking "confirm" each time. The agentic-AI market was already worth around $7.6 billion in 2025.

The capability is real. So is the question sitting underneath it: what stops an agent — compromised, hijacked by a prompt injection, or simply hallucinating — from authorizing its own actions?

I built a small, fully verifiable system to explore one answer to that question. This post is about the pattern, not the project. The principles are public; the exploitable internals are not (Kerckhoffs's principle). Everything below is reusable and vendor-neutral.

The core idea: separate deciding from signing

Most of the agentic-wallet stack being built today — by Coinbase, Ledger, Cobo, and others — splits along two lines. On the developer side, agents get broad autonomy inside their own custody domain. On the consumer side, the human keeps the keys and the agent acts under progressively scoped authorization: each meaningful action either prompts the user or stays inside tight, predefined limits.

The pattern I'll describe lives firmly on the second side, and it pushes one principle to its logical end:

An agent can have full autonomy over judgment while having zero autonomy over signature.

The agent decides what it wants to do — evaluate, choose, propose a transaction — entirely on its own. But the act that makes the transaction real, the cryptographic signature, is structurally out of its reach. Not "discouraged." Not "policy-checked." Mechanically unreachable.

In my case, the agent is an art curator: it evaluates artworks on a multidimensional grid, decides on its own whether to bid in an on-chain auction or abstain, and places a bid. But it can never confirm that bid. A human action, outside the agent's process, is the only thing that triggers signing and broadcast. The whole cycle is verifiable on a public testnet — no trust required.

The interesting part isn't the art. It's the four properties that make "the agent cannot sign" true rather than aspirational.

Pattern 1 — Out-of-band human confirmation (fail-closed)

The agent can trigger a transaction. It cannot confirm one. The confirmation channel is out-of-band — it lives outside the agent's reach entirely. If confirmation never arrives, the transaction does not proceed: it fails closed, not open.

This is the property most people get subtly wrong. It is not enough to keep the signing password away from the agent. If the agent holds an allowlisted tool that performs the signing once "confirmed," and the confirmation signal is something the agent can produce, then a compromised agent simply produces it. You need two separate barriers: the secret must be out of the agent's reach, and the confirmation must be too. Move only one, and you have a gate the agent can open itself.

Concretely: the signing step waits for a human-originated signal delivered through a channel the agent has no handle on. No signal, no signature. The agent cannot self-confirm.

Pattern 2 — Deterministic server-side decision

The authorization decision is made by a deterministic, non-probabilistic component — not by the model.

This matters because a language model is, by design, a probabilistic system. That variance is a feature when you want a model to exercise judgment (in my case, aesthetic scoring — and the score genuinely varies a point or two across runs, which is correct behavior for a coherent evaluator). It is a catastrophe when the question is "should this transaction be authorized: yes or no?" You do not want that answer sampled from a distribution.

So you split the two. The model is allowed to be probabilistic where judgment lives. The authorization gate is deterministic code, where a yes/no must mean yes/no every single time.

Pattern 3 — Strict least privilege

The agent has access only to the tools strictly necessary — evaluate, propose. It has access to neither the signing key nor its secret. Ever. The key is decrypted only after human confirmation, never exposed to the agent, and never written to any log.

A useful corollary: the agent does not even discover work on its own in the high-privilege path. Auctions are submitted to it; it does not roam and find them. The smaller the agent's surface, the smaller the blast radius when something goes wrong — and with autonomous agents, you should assume something eventually will.

This is the same instinct behind the allowlists and scoped permissions appearing across the industry's hardened tooling: agents need signing capability, but unsafe delegation creates catastrophic-loss scenarios. Least privilege is how you keep "the agent can act" from becoming "the agent can do anything."

Pattern 4 — Network isolation (allowlist)

The agent's outbound traffic is restricted to a strict allowlist. This does two jobs at once: it blocks exfiltration (a compromised agent cannot phone home or leak secrets to an arbitrary endpoint), and it blocks requests to internal addresses (no using the agent as a pivot into your own infrastructure). Content the agent needs is fetched only from pinned, known sources.

Prompt injection and tool manipulation are repeatedly named as the unresolved risks of this category. You cannot fully prevent a model from being manipulated by what it reads. But you can make sure that even a fully manipulated model is talking to a very short list of places — and that none of them are your private network or an attacker's server.

Why this holds up

Put the four together and you get a system with a specific, falsifiable claim: even a fully compromised agent cannot sign a transaction.

It cannot confirm its own action (Pattern 1).
It cannot coerce a "yes" out of the authorization gate, because that gate is deterministic and lives outside it (Pattern 2).
It never holds the key or its secret to begin with (Pattern 3).
It cannot exfiltrate that secret or pivot, because it can only reach a pinned allowlist (Pattern 4).

None of these is novel in isolation. Out-of-band confirmation, deterministic gates, least privilege, and egress allowlists are old security ideas. The point is the composition, aimed at one specific failure mode of autonomous agents: self-authorization. The Owockibot failure was, at bottom, an agent given enough rope to expose its own keys. The whole design above is about never handing the agent that rope.

What this deliberately is not

It is not a fully autonomous trading agent. The entire premise is that the irreversible step keeps a human in the loop. If your use case genuinely requires machine-speed signing with no human anywhere, this pattern is the wrong tool — you're on the developer-autonomy side of the split, and you should be looking at MPC custody, session keys with hard scoped limits, and circuit breakers instead.

It is also not a finished product or financial anything. The implementation I built runs on a public testnet with no real value at stake — it exists to prove the pattern end-to-end, on-chain, where anyone can check it rather than take my word for it.

Takeaway

As agents get wallets, the reflex is to ask "how much can we let the agent do?" The more useful question is often the inverse: what must the agent be unable to do, no matter how badly it is compromised?

For anything irreversible — moving value, signing, spending — a clean answer is: it must be unable to authorize itself. Let it decide freely. Keep the signature out of its hands. Make that separation mechanical, not merely intended.

If you're building in this space, I'd genuinely value scrutiny of the threat model — that's the part worth pressure-testing.

Built solo, with Claude as a design-and-audit partner and Claude Code as the executor; the curation agent itself runs on the Anthropic API.

The proof-of-concept and the security patterns are public:

Project: nexus-art.org
Code & patterns: github.com/avp9-nexus/nexus-art
The full auction cycle is verifiable on-chain (Base Sepolia testnet — no real value at stake).