Safe agent accounts

An agent's default identity on an EVM chain is an externally owned account: one key, one signature, no policy on-chain. Safe agent accounts (v0.56.2) let an agent operate through a Gnosis Safe instead, so guardrails can eventually be enforced by the chain rather than only by the Vault.

Provisioning is counterfactual: the Safe address is derived and usable before any deployment transaction is sent, so you can fund and reference it without paying to deploy first.

1. 1

   List the accounts an agent currently has, per chain.

   bash Copy

   curl -s https://api.1claw.co/v1/agents/$AGENT_ID/accounts \
     -H "Authorization: Bearer $ONECLAW_TOKEN"
   # or: 1claw agent accounts list $AGENT_ID

2. 2

   Provision a counterfactual Safe account for the agent.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/agents/$AGENT_ID/accounts \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"chain":"base","account_type":"safe"}'

3. 3

   Inspect the pinned module registry for the chain: Safe v1.4.1 plus Zodiac. This endpoint is public.

   bash Copy

   curl -s https://api.1claw.co/v1/safe/module-registry/base

4. 4

   Migrate the agent from its EOA to the Safe.

   bash Copy

   1claw agent accounts migrate $AGENT_ID --chain base

5. 5

   Once nothing depends on the old EOA, deprecate it so it can no longer be used.

   bash Copy

   1claw agent accounts deprecate-eoa $AGENT_ID base

Where this goes wrong in practice. Safe accounts are a foundation with parts still under audit, so the main risk is assuming a property you do not yet have.

• Counterfactual is read as deployed. The address is real and fundable before any deployment transaction exists, and funds sent to an undeployed Safe are safe but not yet movable.
• On-chain enforcement is assumed. Deploy, cosign, timelock and 4337 paths return 501 pending a Guard audit, so guardrails remain Vault-enforced for now.
• The EOA is deprecated too early. Deprecating before every dependent path is migrated turns a planned change into an outage.
• Module versions are not pinned. The registry pins Safe v1.4.1 and Zodiac deliberately; deploying against unpinned modules gives up the property the registry exists to provide.