Security at expacti

Security is not a feature we added — it's the reason expacti exists. Here's how we think about it and what we do to keep your data and commands safe.

Threat model

1. Compromised proxy server

If the expacti proxy is compromised, commands could execute without approval. Mitigations: the approval queue is stateless in memory (not persisted in a way an attacker can modify without detection), the whitelist is stored in a separate DB, and the audit log is append-only with hash chaining.

2. Compromised reviewer account

A rogue reviewer could approve malicious commands. Mitigations: TOTP 2FA required for reviewer accounts, multi-party approval policies available (require N reviewers to approve), session recording with playback, and full audit trail showing who approved what.

3. Command replay attacks

An approved command ID cannot be replayed — each command has a unique UUID and TTL. Once approved or denied, the decision is final and re-submission creates a new command ID.

4. Man-in-the-middle on the reviewer connection

All connections use TLS (HTTPS/WSS). We use Cloudflare for TLS termination with Full Strict mode. For self-hosted deployments, we recommend mutual TLS.

End-to-end encryption

For environments where even the backend operator should not see command content, expacti supports E2EE mode:

• The shell agent encrypts each command using RSA-OAEP + AES-256-GCM before sending
• The backend is a pure relay — it sees only ciphertext
• The reviewer's browser decrypts commands client-side using the Web Crypto API
• Encrypted commands display a 🔒 badge in the reviewer UI

Data handling

• Commands: stored in SQLite (self-hosted) or PostgreSQL. Encrypted at rest on managed deployments.
• Session recordings: asciinema format, stored locally or in S3-compatible storage configured by you.
• Passwords: bcrypt-hashed, never stored in plaintext.
• API keys: stored as SHA-256 hashes only; shown to the user once at creation time.
• Audit log: append-only with hash chaining. Records cannot be modified or deleted through the API.

Authentication

• Email + password with bcrypt
• TOTP 2FA (RFC 6238, 30s window, backup codes)
• OIDC: Google, GitHub, Microsoft
• SAML 2.0 SP for enterprise SSO
• API keys with optional expiry
• JWT tokens with short TTLs

Responsible disclosure