# SquidShell agent security design status

This page distinguishes implemented work from the proposed vault design. It is not a claim of 1Password-equivalent security or an external security audit.

## Current production

Desktop 1.0.39 and later on macOS handle expired authentication sessions and inactive accounts by signing out and closing connections. Temporary network failures and ordinary permission errors do not erase the login session. The public release is signed and notarized.

## Agent identity — beta

- Random 256-bit API-key secrets; SHA-256 hashes are retained instead of raw tokens.
- Per-agent names, expiry, explicit vault grants and read/write scopes.
- Immediate revocation on subsequent requests and active-account checks.
- Agent authentication is isolated from account management and legacy desktop credential APIs.
- Authentication and management responses use `Cache-Control: no-store, private`.
- Activity events contain identifiers, actions and timestamps, never secret values or raw API keys.
- Key issuance requires the existing TOTP code when account 2FA is enabled.

## Selected model: end-to-end encryption — beta

The user selected end-to-end encryption. A random 256-bit vault key stays on the client. The Node SDK encrypts the complete snapshot (including entry names and values) with AES-256-GCM before transmission. Vault ID, revision and key identifier are authenticated. The server has no decryption-key fields or decryption code.

The CLI stores the local vault key in a password-encrypted file (scrypt N=131072, r=8, p=1; AES-256-GCM), and supports stdin ingestion, explicit plaintext output, direct environment injection, and atomic snapshot rotation. API credentials are independent of encryption keys. A read/write key may replace or rotate its granted vault. The server enforces scope, vault grants, revision preconditions, payload limits and nonce-reuse checks. Clients reject failed integrity checks, redirects and older revisions observed within the client's lifetime.

The display name of a vault, owner, size, revision, key identifier, timestamps and access metadata remain visible to the server. API revocation cannot erase data already copied by an agent. Old ciphertext plus the old key remains decryptable after rotation. A fresh client without a trusted revision checkpoint cannot detect replay of an older valid snapshot. The first version uses out-of-band encrypted key-file distribution; automatic device pairing and multi-device anti-rollback are not implemented. Backup of the encrypted local key file and its password is required: there is no server recovery/backdoor.

Dashboard documents exclude analytics and payment scripts, enforce a script CSP and reload at public/payment document boundaries before rendering credentials. Existing web login tokens are still stored in localStorage; this is not a complete defense against same-origin compromise. The vault decryption key and contents are never entered into these pages. Existing desktop SSH credentials retain their previous server-managed storage model.

See [the SDK/CLI guide](./e2ee.md) for the exact protocol and recovery limitations. The beta is deployed. Automated checks and deployment verification are not a third-party security audit.

Cloudflare WAF, API schema validation, rate limits and private origin connectivity can protect the request path. They do not replace encryption or authorization. API routes must remain usable by non-browser clients and must never cache secret responses.

## References

- https://support.1password.com/secure-by-design/
- https://www.1password.dev/service-accounts
- https://www.1password.dev/connect/security
- https://developers.cloudflare.com/api-shield/security/schema-validation/