Research noteAutonomous systems
Agents need keys that can spend without owning
Most agents run on a borrowed human account with all of its authority. Privacy protocols already separate the key that spends from the key that owns, and the key that reads from the key that acts. Agent infrastructure can borrow that design.
The problem
An agent that books travel, pays invoices or rebalances a treasury usually holds one of two things: a person’s own wallet, or an API key with the same reach. Either way it carries the full authority of the account. If the agent is wrong, or someone gets into its instructions, the loss is bounded only by the balance.
A person approving every step fixes that and removes the reason to have an agent. The useful middle is an agent that acts on its own inside limits someone else set, and leaves a record of what it did.
What privacy systems already separate
Privacy systems keep returning to one idea: the right to read is handed out separately from the right to spend, and in some ledgers the key that authorizes a spend is kept apart from the key that owns the coin.
- DarkFi’s burn circuit takes the signature secret as a separate witness from the coin secret, so the key that appears with a spend cannot be matched to the key in the coin’s commitment.
- Penumbra publishes a randomized verification key for every spend. Its key tree runs from a spend key to full, incoming and outgoing viewing keys, and each can go to a different party: an auditor, a view server, a detector.
- Namada lets a user hand out viewing keys “for accounting or compliance”, with a birthday height that limits how far back the holder can scan.
- DarkFi’s DAO splits authority into six keys: view notes, propose, view proposals, view votes, execute and early execute. A founder can give each one to a different holder.
None of this was designed for agents. It was designed so that disclosure and authority can be handed out in narrow pieces, which is exactly what an agent needs.
What an agent account needs
- A spend key that cannot move the principal. It pays from a budget, up to a limit, until a date, and then it stops working.
- A read key that sees only what the task needs, so a model provider or a tool does not learn the whole balance sheet.
- An audit trail that the owner and a third party can both check afterwards, without the agent’s cooperation.
- Revocation that works while the agent misbehaves, which means it cannot depend on the agent.
Where I would look
Session and budget keys, policy engines that sit between a model and a signer, and payment rails where a merchant can tell an agent with a mandate from an agent with a stolen key. Teams that build these as their main product, with the wallet as a detail, interest me more than wallets adding an agent feature.
I would also watch the opposite failure: delegation schemes so flexible that nobody outside can say what an agent was allowed to do. A permission nobody can read is only slightly better than no permission.
What would change my mind
If agents keep moving real money through borrowed human accounts for years without a serious loss, the market for narrow permissions is smaller than I think. So far the evidence is thin in both directions.
Sources
- DarkFi:
src/contract/money/proof/burn_v1.zkanddoc/src/arch/dao.mdin the DarkFi repository. - Penumbra:
SPEC/addresses_keys/viewing_keys.mdandSPEC/crypto/decaf377-rdsa.mdin the Penumbra repository. - Namada:
docs/users/addresses.mdxanddocs/users/shielded-accounts/masp-keys.mdxin the Namada docs.