Deploying agents for blockchain autonomy

Context

Software licensing usually means a key server and a subscription table you defend forever. If the customer holds a token you issued, the token can be the licence instead — and unlike a licence key, it is theirs, transferable, and checkable by anyone. But only if you ask the chain at the moment of use. A cached answer is just a subscription record in a costume.

Decision

Give the agents everything measurable and reversible. Keep two actions human. Then build so that no agent capability, and no single compromised component, can reach those two.

Approach

• Ownership is re-read on chain at every protected request, across two independent providers. Sell the token and access ends on the next call — there is nothing to revoke.
• A licence activates only after the mint event is pulled from the transaction receipt. An operator saying it happened is not evidence.
• Delivery credentials never reach the cloud. The coordinating service holds an opaque identifier and nothing else.
• The delivery host authenticates the holder itself, with its own challenge and its own ownership check, so compromising the cloud side yields nothing downloadable.
• Each half of a delivery needs its own separate proof, and no response ever carries both.
• Delivery hands over a packaged MCP app — the thing the holder actually runs — built on demand and revocable, never a static link sitting in an inbox.
• Updates and upgrades are the same mechanism, not a second system. A new version is a catalogue entry; the holder requests it and the chain is asked again. Entitlement is continuous, so access ends the moment the token moves.
• The catalogue is data rather than code, so publishing another app or another version is a configuration line — and the published version always wins over whatever a caller asks for.

Outcomes

• Two licences issued end to end on a live network, each activated only against a mint confirmed independently.
• The pre-fix build was shown handing over delivery credentials to cloud-side secrets alone; the hardened build refuses. Proven against the old code, not asserted.
• Adding a product became one configuration line. The publisher's version always wins over whatever a caller asks for.
• Two human decisions per licence. Everything else reconciles itself from public chain evidence.
• One token covers the catalogue: the app, and every later version of it, without issuing anything new or tracking a subscription.

Control boundary

No agent signs or broadcasts. No automated step grants access to a wallet that does not hold a token. Approve and decline undo each other. Activation is gated on a public event anyone can re-derive. If it is unclear whether a transaction took effect, that is an incident — never a retry.

What this taught me

The governance problem turned out to be the whole problem. Agents can run the pipeline end to end only because the two actions that confer authority — approving a request, signing the mint — sit where no agent capability reaches, and because every check is re-derived from the chain rather than remembered. Every bug was the same bug in different clothes: something cheap standing in for the chain, then trusted long after it was read. Making the real answer cheap enough to ask every time is what turns a token from a receipt into a licence for a running app and every version after it. What is still open is transferability — today the elegant part, since selling the token ends access with nothing to revoke, and equally the leak, since a licence resells as easily as it was bought. The next version is a minimal transfer policy, or a soulbound token with a contract burn option so a holder can still exit and a publisher can still retire a licence.