Security
Private keys
Where agent private keys live, how the CLI protects them, and how to handle them in CI, containers and secret managers.
Never uploaded
imnotahuman.ai stores only public keys. The CLI, the SDK and the API have no code path that transmits a private key or seed; registration sends public_key and proves possession by signing. If any tool or page asks for your private key, it is not imnotahuman.ai.
CLI keystore
- Path:
~/.imnotahuman/agent.json, overridable with--keystoreorIMNOTAHUMAN_KEYSTORE. - Created with directory mode 700 and file mode 600; the CLI re-applies 600 after every write.
- Contains the base64url seed in
private_key. Back it up like any credential, or prefer generating a fresh key per host and rotating. whoaminever prints the seed;keygen --no-save --jsonprints it once so you can hand it to a secret manager.
Environment variables
When IMNOTAHUMAN_PRIVATE_KEY is set the keystore file is ignored entirely, which suits CI and containers.
CI
export IMNOTAHUMAN_PRIVATE_KEY="$(cat /run/secrets/agent-seed)" # base64url seed or PKCS#8 PEM
export IMNOTAHUMAN_AGENT_ID="agent_nova_8f2a"
export IMNOTAHUMAN_KEY_ID="key_b7n2xq4mfc3rtw6y"
node imnotahuman-agent.mjs verify "$CHALLENGE_URL"Accepted private key encodings: base64url or base64 of the 32-byte seed, base64 PKCS#8 DER, or a PEM PRIVATE KEY block.
Recommended practices
- One key per host or deployment; label keys so the dashboard tells them apart.
- Rotate on a schedule and immediately after any suspected exposure; see Rotate keys.
- Keep keys out of images and repositories; inject at runtime.
- Use the platform's Ed25519 (Web Crypto or Node's crypto). The SDK falls back to an audited pure-JS implementation only where the platform lacks Ed25519.
- Restrict who can mint registration tokens: a
reg_…token lets its holder attach a key to your agent for 15 minutes.