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 agent's child key | Plaintext files at ~/.agensai/agents/<name>/, mode 0600 | Same |
The orchestrator and child keys use the same plaintext, mode-0600 pattern that any unix-style local agent uses for credentials.
No PRF, no cloud-encrypted backup, no encrypted bundle. The orchestrator's local key is intentionally a fast-path signer for chat-spawned agent UserOps. We don't back it up because we don't need to: your main JAW account is auto-installed as a co-owner of every orchestrator you spawn agents under, and the main passkey is the durable authority. If the local key is lost, main still controls the orchestrator.
Layer 2: on-chain bounds
| Wallet | Authority | Bound |
|---|---|---|
| Main account | Full control by passkey holder. Co-owner of every orchestrator you've used. | None. This is the sovereign tier. |
| Orchestrator | Owns its pool. Grants permissions to children. Signs spawn UserOps from chat. | Bounded by the fact that main is a co-owner and can drain or retire at any time. |
| Agents | Spend from the orchestrator's pool via ERC-7715 grants. | Bounded by the explicit calls, spends, and expiry of the grant. Out-of-scope calls revert at the validator. |
The recovery co-owner is the architectural anchor. When you spawn your first agent under an orchestrator, AGENSAI installs your main JAW account as a co-owner of the orchestrator's smart wallet. From that moment your main passkey can:
- Drain the orchestrator's balances back to main (Retire flow).
- Revoke every agent's permission to spend from the orchestrator.
- Sign any UserOp on the orchestrator's behalf.
There is no AGENSAI middleware in this loop. The validator on the smart wallet checks the owner list and enforces it.
Children are bounded by ERC-7715 grants signed by the orchestrator at spawn time. The grant specifies which contracts, which selectors, which tokens, what spend cap, what period, and an expiry. Anything outside scope reverts at the validator. There's no AGENSAI permission engine that could fail open.
Layer 3: revocation
| Action | Who signs | Biometric |
|---|---|---|
| Revoke one agent | Orchestrator's local key (chat) or main (dashboard) | 0 from chat, 1 from dashboard |
| Retire an orchestrator (drain + revoke every agent) | Main passkey (dashboard) | 1 |
| Sweep funds without revoking | Main passkey | 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. Retire batches every agent's revoke plus a balance drain into a single UserOp.
Threat model
We name the actual risks. Coverage is honest about what we do and don't claim.
| 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 hardware-protected and unaffected. The attacker gets the local key but main can drain and revoke from any other device. |
| 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 float. Main account safe. Retire from another device completes in one passkey tap. |
| Stolen unlocked device | Bounded by orchestrator float. Main account stays safe (hardware-protected passkey). Retire from another device. |
Phishing or curl ... | sh malware | Same as info-stealer. Bounded by float. |
| AGENSAI breach | Zero impact on user funds. AGENSAI holds no keys, no shares, no copies. The dashboard is static, the MCP server is an npm package. Your fleet manifest is on ENS, not in our database. There is no AGENSAI server to breach that has authority over your funds. |
| JAW service outage | Cannot create new agents or update text records during the outage. Existing agents continue to operate (their permissions are on-chain). Main-account passkey access depends on keys.jaw.id for first-time device flows. |
JAW API key compromise (the one bound to agensai.eth) | Origin-enforced via JAW Dashboard. Does not give authority over user funds or existing agents. Only namespace issuance authority for *.agensai.eth. |
What AGENSAI explicitly doesn't claim
We don't claim hardware-level security for the orchestrator's local key. We claim bounded security: a compromise of that key hurts only as much as the orchestrator's float, and main can drain or retire from anywhere.
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
- Zero infrastructure for signing or custody. Static dashboard, npm MCP server, no servers in the trust chain for keys.
- Every agent is bounded on chain. ERC-7715 grant verified via the standard ERC-1271 path. Validator-enforced, not middleware-enforced.
- Revocation is fast and permanent. One on-chain transaction, no grace period.
- Recovery is decoupled from any AGENSAI server. Main = passkey + JAW. Fleet manifest = ENS records. Both work without AGENSAI.
- No third-party AA vendor. The account-abstraction layer is JAW, a complete stack, not a vendor glued in between you and the chain.