Legal
Security Overview
Last updated August 2026
Identity and authorization
Customer and platform-staff identities use separate tables, cookies, sessions, MFA credentials, and authorization namespaces. Customer access is resolved from active organization membership and explicit permissions. Sensitive staff actions require purpose-specific grants, MFA, reasons, and, for the highest-risk paths, recent password reauthentication.
Tenant and data isolation
Organization-scoped database tables use row-level security under a non-superuser runtime role. Composite tenant foreign keys prevent one organization's row from referencing another's parent even when PostgreSQL performs referential checks outside row-level policy evaluation. Credentials and TOTP seeds are encrypted; opaque bearer values and API keys are stored only as hashes.
Agent and tool safety
Agent runs use immutable configuration versions, budget and concurrency controls, policy evaluation, exact-argument approval binding, SSRF-resistant outbound transport, content safety scanning, and isolated code execution with bounded resources. Tool credentials are injected at egress and are not placed in model context.
Audit and detection
Consequential actions write canonical, hash-chained audit events. Staff actions also write a dedicated administrative ledger. OpenTelemetry instrumentation can export traces and metrics without making telemetry availability a runtime dependency. Security scanning and operational alerting are release gates tracked separately from these runtime controls.
Limits and responsible disclosure
No system eliminates all risk. Some provider, hosting, and observability controls depend on the production deployment and must be verified before launch. Suspected vulnerabilities should be reported privately through the designated security contact in the customer agreement; do not test against another customer or production data without written authorization.