Security model
AGENSAI's security posture rests on three layers of defense. Each layer's failure mode is bounded by the next.
- Storage. Where each key lives and what protects it.
- On-chain bounds. What each wallet is allowed to do, enforced by the validator.
- Revocation. How fast you can shut something down when it goes wrong.
Layer 1, Storage
| Key | Lives in | Protection |
|---|---|---|
| Main passkey | Hardware (Secure Enclave / TPM / Android Keystore), managed by JAW via keys.jaw.id | Hardware boundary; non-extractable; biometric per use |
| Orchestrator key | Plaintext file at ~/.agensai/orchestrator.key, mode 0600 | File-system permissions; readable only by processes running as you |
| Each child key | Plaintext file at ~/.agensai/agents/<name>.json, mode 0600 | Same |
The orchestrator and child keys use the same plaintext + mode-0600 pattern as JAW CLI's ~/.jaw/keystore.json. It's the same storage profile that any unix-style CLI tool uses for credentials.
No PRF, no cloud-encrypted backup, no encrypted bundle. The orchestrator is intentionally disposable; backing it up would add complexity that doesn't earn a security improvement, because:
- Funds are recoverable via the kill-switch (Layer 3).
- Identity is recoverable via ENS records (see Recovery).
- The orchestrator key itself isn't worth recovering; we rotate to a fresh one.
Layer 2, On-chain bounds
| Wallet | Authority | Bound |
|---|---|---|
| Main account | Full control by passkey holder | None, this is the sovereign tier |
| Orchestrator | Owns its pool; can grant permissions to children | Bounded by the kill-switch ERC-7715 grant to main account |
| Children | Spend from orchestrator's pool via ERC-7715 | Bounded by the explicit calls + spends + expiry of their grant |
The kill-switch grant is the architectural anchor. At orchestrator setup, the orchestrator's local key signs a grant from itself to your main account. The grant covers: every recoverable token, generous allowance, long expiry. Your main passkey can invoke it any time to sweep.
Children are bounded by ERC-7715 grants. Anything outside scope reverts at the validator. There's no AGENSAI middleware that could fail open.
Cite: permissions.md lines 131-157, account-api.md lines 142-154.
Layer 3, Revocation
| Action | Who signs | Tap count |
|---|---|---|
| Revoke one child | Orchestrator's local key | 0 |
| Re-scope one child (revoke + re-grant) | Orchestrator's local key | 0 |
| Sweep all funds back to main + retire orchestrator | Main passkey (kill-switch) | 1 |
Revocation is one on-chain transaction. Once landed, the validator rejects every subsequent call against the revoked permissionId. No grace period; no soft delete.
Cite: account-api.md line 198, permissions.md line 190: revocation is permanent.
Honest threat model
We name the actual risks. Where coverage is partial, we say so.
| Threat | Coverage |
|---|---|
Info-stealer malware scanning ~/.agensai/ | Real risk. Keys are in plaintext mode-0600 files. Damage bounded by the orchestrator's float. Main account is hardware-protected and unaffected. Same threat profile as JAW CLI's ~/.jaw/keystore.json. |
| Malicious npm package reading user-home | Same as above. Bounded by orchestrator float; main safe. |
| Sophisticated targeted attack on logged-in device | Bounded by orchestrator's float. Main account safe. Revoke + rotate completes in ~1 minute. |
| Stolen unlocked device | Bounded by orchestrator's float. Main passkey kill-switch + new orchestrator on new device recovers fleet identity. |
Phishing / curl ... | sh malware | Same as info-stealer, bounded by float. |
| AGENSAI / JustaLab breach | Zero impact on user funds. We hold no keys, no shares, no copies. The dashboard is static; the CLI is an npm package. There's no AGENSAI server to breach that has authority over your funds. |
| JAW or JustaName service outage | Cannot create new agents or update ENS records during the outage. Existing agents continue to operate (their permissions are on-chain). Main account access depends on keys.jaw.id for first-time device flows. |
Compromise of the JAW API key for agensai.eth namespace | Could be used to mint subnames under agensai.eth. Origin-enforced via JAW Dashboard (configuration.md line 88). Does not give authority over user funds or existing agents, only namespace issuance authority. |
What AGENSAI explicitly doesn't claim
We don't claim hardware-level security for the orchestrator. We claim bounded security: a compromise hurts only as much as the orchestrator's float, and recovery is fast.
We don't claim hardware-level security for child keys. We claim scoped security: a child compromise hurts only as much as that child's grant lets it.
We don't claim AGENSAI is a bank. The main account is the bank; the orchestrator is the working float; the children are scoped spenders. Treat each tier accordingly.
What AGENSAI does claim
- AGENSAI runs zero infrastructure for signing or custody. Static dashboard, npm CLI, no servers in the trust chain for keys.
- Every agent is bounded onchain. ERC-7715 grant verified by the standard ERC-1271 path. Validator-enforced, not middleware-enforced.
- Revocation is fast and permanent. One onchain transaction, no grace period.
- Recovery is decoupled from any AGENSAI server. Main = passkey + JAW. Fleet = ENS records. Both work without AGENSAI.
- Vertically integrated, not stack-glued. JustaLab owns JAW and the ENS service-provider relationship. No third-party AA vendor sits between you and the chain.
Cite
Every claim above ties back to one of these:
account-api.md,Account.create,Account.fromLocalAccount, revocation.permissions.md, ERC-7715 grant + spend bounds + revocation semantics.auth-modes.md,keys.jaw.idflow.gas-sponsoring.md, built-in ERC-20 gas; no AGENSAI paymaster relationship.configuration.md, JAW Dashboard origin enforcement for the API key.auto-mode.md, JAW CLI plaintext mode-0600 keystore pattern.