Security

Secrets and sandbox isolation

Saved secrets are encrypted using AES-256-GCM with the instance master key, injected as environment variables, and redacted from agent-visible output. Passwords are bcrypt-hashed. API keys are stored hashed.

Container-backed sessions have separate workspaces and sandboxes. Docker and Cloudflare sandbox backends are supported; local-process mode is also available and does not provide container isolation. Isolation depends on the selected backend.

Identity and access

Organizations have owner, admin and member roles. Sessions are private to their creator. OpenID Connect SSO uses authorization code flow with PKCE, state and nonce checks; organizations can require SSO. TOTP MFA can be required for members. SCIM 2.0 supports user provisioning and deactivation, not group synchronization.

Sign-in uses HTTP-only, SameSite cookies, marked Secure over HTTPS. Failed-login lockout and API rate limits help limit abuse.

Audit and request protections

Admins can review and export the audit log in Settings → Security & audit. It records authentication, policy changes and state-changing API calls without recording request bodies. Default audit retention is 365 days.

Responses include CSP for web pages, frame denial, nosniff and referrer restrictions, with HSTS over HTTPS. Cookie-authenticated changes with an Origin or Referer are checked against the instance host and configured allowed origins. Requests without those headers are permitted; bearer-authenticated requests are exempt from that origin check.

Sharing and retention

Public session links are read-only, revocable and expire after 30 days by default. Shared views exclude raw terminal output, memory and secret values. Admins can disable sharing and revoke existing organization links.

Admins can set retention_days for inactive sessions. Users can export data and delete accounts through Settings → Account security. See Privacy for details and backup retention.

Incident notification

Operator incident-response commitment: notify the affected customer/controller without undue delay and within 72 hours of becoming aware of a personal data breach. This is an operational commitment, not an automated notification feature.

Report a vulnerability

Reports go to the operator’s security contact. Placeholder — operator security contact: [TO BE PROVIDED BY OPERATOR]. No dedicated security email is published here yet.

Provide affected URLs or versions, a description, reproduction steps and potential impact through your established operator contact. Do not send credentials or unnecessary personal data. Do not access other customers’ data or disrupt service.