Give your AI agent only what it needs.
Nothing more.
A stolen agent key should never be able to touch your funds — or anything outside the one job it was given.
Cypher Brain already encrypts a personal “second brain” and publishes a pointer to it every night, run by an AI agent. This submission adds ENSv2 Enhanced Access Control so that agent holds a narrow, on-chain, revocable permission for exactly one field — not the owner's wallet.
A second brain that updates itself, every night
gbrain is a personal knowledge base that records conversations, decisions, and things learned, automatically, every day. Cypher Brain — an existing open-source project this submission extends — encrypts gbrain's contents into one sealed file, stores the ciphertext, and publishes a pointer saying “this is the latest version.” All three steps run nightly, driven by an AI agent, not a human.
There was no good way to hand an agent this one job
Giving an agent the authority to publish a pointer, without giving it authority over anything else, had no verifiable answer — until ENSv2's Enhanced Access Control.
| Approach | How it works | The problem |
|---|---|---|
| Share the owner's key | Give the agent the owner's own wallet key | risk the agent can now sign as the owner, including spending funds |
| Centralized server | Put a database behind a server with an API key | weak the server can go down or censor requests, and outsiders cannot verify the key is really limited to one field |
| ENSv2 Enhanced Access Control | Grant the agent wallet a role scoped to one text-record key, on the name's existing Permissioned Resolver | this submission a permission limited to one field, provable on-chain by anyone |
Two wallets, one narrow permission, proven both ways
The owner uses their real wallet once, to grant a separate agent wallet a role for exactly one text-record key. No custom smart contract — this uses only what ENSv2 already provides.
ens-verify then checks both directions: the value matches (positive), and a write to a different key reverts on-chain (negative).PASS negative: out-of-scope text key 'masa-brain.scope-probe' reverted with
EACUnauthorizedAccountRolesENS scope verification: PASS — the negative check was simulated; no transaction was broadcast
Even a stolen agent key is contained
If the agent wallet were ever compromised, here is everything it can — and cannot — do. This boundary is verifiable by anyone; it is not our word for it.
EACUnauthorizedAccountRoles — proven live.Not a simulation — run for real, on Sepolia
Every step below actually happened on the Sepolia testnet, on the fresh ENSv2 redeployment (tag sepolia-deployment-2026-09-15), for the name masashi-ono0611.eth.
| Step | Transaction |
|---|---|
| Register ENS name | commit · register |
| Deploy Permissioned Resolver | via ENS VerifiableFactory at 0xFe544BFED75001379E01434951623Ea80FbDb3CF · tx |
Grant — masa-brain | ens-setup tx |
Grant — agent-context | ens-setup tx |
Grant — agent-endpoint[mcp] | ens-setup tx |
| Pointer publish (agent wallet only) | push --backend file then ens-set-text · tx |
ENSIP-26 — agent-context written | tx · passes ens-verify positive/negative |
ENSIP-26 — agent-endpoint[mcp] written | tx · passes ens-verify positive/negative |
This demo used the free local file storage backend, so it proves the ENS write/scope mechanics, not public retrieval of the encrypted snapshot — a paid backend (Arweave/Turbo/TON) makes the ciphertext publicly fetchable by anyone with the locator, with no change to the ENS delegation logic.
One permission foundation, many brain slices
The permission model is per text-key, not per name — it already generalizes. Once gbrain can export one encrypted snapshot per use case, each slice (work, travel, a private brain) can get its own independent grant and its own agent wallet, using only what was built here.