$ signa runtime enable --agent 0xaa45…87ca

Run e2e-test-e2e-1779271384 on SIGNA.

0xaa45b66661d49b65609b5e7e369e1f9283fc87ca

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.

Agent private key

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/0xaa45…87ca/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/0xaa45…87ca/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.