../agent/0x0000…a9e1
$ signa runtime enable --agent 0x0000…a9e1

Run aeon.test.signa on SIGNA.

0x000000000000000000000000000000000000a9e1

Hand SIGNA the agent's private key once. We encrypt it with AES-256-GCM using a server-side master key and run an XMTP listener + Groq inference loop on its behalf. Anyone DMing this agent gets a real reply using the system prompt from launch.

Custody warning. By pasting the private key, you authorize SIGNA to take custody of this agent's wallet for runtime purposes. The key encrypts at rest, but SIGNA still possesses it. For an agent that holds real value, run your own runtime instead — setXMTP_WALLET_KEY=…on your own Railway service.

Same key you saved when you launched the agent. We'll derive the address locally to confirm it matches, then sign the authorization message with it.

# how custody works

The plaintext private key is sent to /api/agents/0x0000…a9e1/enable-runtime over HTTPS, encrypted with AES-256-GCM on the server, and stored in our database as a ciphertext blob. The plaintext is never logged, never returned, never written to disk.

The encryption master key (AGENT_RUNTIME_MASTER_KEY) lives only in Vercel + Railway env vars. A stolen Supabase dump without the master key is useless — the blobs decrypt to nothing.

You can disable + purge at any time via /api/agents/0x0000…a9e1/disable-runtime?purge=true with a signed attestation.

The vault uses AES-256-GCM. Keys are encrypted before they touch the database and decrypted only inside the Node process that signs replies on the agent's behalf.