DEV Community

zk_nd3r
zk_nd3r

Posted on

5 properties of agent custody

your AI agent can write code, book flights, manage a calendar. now hand it a wallet.

suddenly we are back to "trust me bro" with a hot key.

agent frameworks are everywhere. agent custody is nowhere. the gap between what agents can do and what agents can safely hold is the most dangerous problem in AI infrastructure right now.

here are five properties every agent wallet needs. if your agent is missing any of them, you do not have custody. you have a liability.

1. non-drainable

no single key compromise should drain the wallet.

most agent wallets today give the agent a private key. or they custody it on a server. either way, one compromise and the funds are gone.

the fix is threshold signing. split the key into shares. require 2 of 3 (or 3 of 5, or any t of n) to produce a valid signature. the agent holds one share. a policy service holds another. a recovery key sits in cold storage.

FROST is one way to do this. 2PC-MPC is another. the mechanism matters less than the property: no single point of failure drains funds.

2. policy-bound

spend limits, allowlists, and time locks must be enforced on chain. not in client code.

if your spending policy runs on the same server as your agent, the agent can modify the policy. or the server can be compromised and the policy disabled.

on-chain policy means the rules exist in a smart contract. the agent can request a transaction but the chain enforces the limits. the agent cannot override what the chain does not permit.

Sui Move is one approach. EVM modifiers are another. the key property: policy enforcement is independent of the agent runtime.

3. attested

every action the agent takes should produce a verifiable proof.

when your agent moves money, there should be a cryptographic commitment that says: this agent, at this time, took this action, with this result. anchored to a public ledger. independently verifiable.

this is not logging. logs are controlled by the operator. attestation is committed to a chain that the operator cannot alter after the fact.

ZAP1 is one implementation. any Merkle tree anchored to an immutable ledger achieves the property. the key: proof exists outside the system being proven.

4. remembering

the agent should carry context across sessions.

an agent that forgets what it did last session is an agent that repeats mistakes. custody requires memory. what positions are open. what policies were active. what decisions led to the current state.

this is not just a database. it is a knowledge graph that the agent can query semantically. "what happened last time volatility spiked" should return an answer, not a blank stare.

5. killable

a human or risk system must be able to halt the agent instantly. no override. no delay.

if your agent has a kill switch that the agent can disable, you do not have a kill switch. the halt mechanism must be external to the agent runtime and immediate.

file-based kill switches work. hardware dead man switches work. the property is: when the human says stop, the agent stops. before the next transaction. not after.

the test

for any agent wallet, ask five questions:

  1. can a single key compromise drain the funds?
  2. can the agent override its own spending policy?
  3. can the operator alter the action history after the fact?
  4. does the agent know what it did last session?
  5. can the agent prevent a human from shutting it down?

if any answer is "yes", you do not have agent custody. you have a hot wallet with a prayer.

reference implementation

we build open-source agent custody infrastructure on Zcash. FROST threshold signing, on-chain policy enforcement, Merkle-anchored attestation, semantic memory, hardware kill switches. privacy by default.

all of it is open source, MIT licensed, and verifiable.

  • npm: npmjs.com/package/@frontiercompute/zcash-ika
  • github: github.com/Frontier-Compute
  • spec: github.com/zcash/zips/pull/1243
  • awesome-agent-wallets: github.com/Zk-nd3r/awesome-agent-wallets

Top comments (0)