1. Threat model
Falcon Cortex protects three distinct trust boundaries: platform, tenant, and workspace. We treat cross-tenant read as the single most dangerous class of failure. Every table, every policy, and every server function is designed with the assumption that a compromised tenant admin must not be able to reach another tenant's data.
2. Row-level security
RLS is on for every table in the public schema. Policies are always tied to auth.uid(), a tenant_id, and where applicable a workspace_id. Role checks are routed through public.has_role(user, role) and private.* SECURITY DEFINER helpers to prevent recursive policy evaluation.
3. Audit evidence
Selected mutating workflows produce structured audit evidence with actor, scope, event, and sequence information where the control is implemented. Verification tooling is part of the engineering build; independent anchoring, lifecycle commitments, and production operation remain release gates.
4. Step-up and separation of duties
Selected high-risk workflows use step-up and independent-approval patterns where enabled. Coverage, approver counts, timing, and recovery behavior are validated per operation; no universal destructive-action guarantee is claimed here.
5. Identity & access
Identity capabilities including SSO, SCIM, MFA, session, and network policy are being integrated for tenant-configured UAT. Availability and enforcement depend on provider configuration and end-to-end validation; no universal plan or break-glass guarantee is claimed.
6. Data isolation
No shared caches across tenants. Materialised views are keyed by tenant_id. Background jobs re-authenticate under the least-privileged tenant service role before touching data.
7. Key management
Platform secrets remain server-side and use protected custody patterns with purpose-bound context. One-time-reveal credentials are designed so raw values are not returned by list or audit views. Key custody, rotation, and any customer-managed key integration require environment-specific validation; no provider or plan availability is claimed.
8. DSAR & erasure runbook
DSAR and erasure handling follows a documented process and applicable law. Sensitive actions use controlled approval where enabled; timing, scope, and deletion guarantees are customer- and jurisdiction-specific, and no universal response SLA is claimed.
9. Sub-processors
Current sub-processors and purposes are published at /legal/subprocessors. Notice and objection terms are governed by the applicable contract; no universal notice period is promised on this page.
10. Residency
Residency and transfer requirements are assessed for each engagement. No multi-region production availability, region-routing control, or cross-region blocking guarantee is claimed on this page.
11. Incident response
Incident response and customer communications are being prepared as part of the operational build. Response commitments, service levels, and post-incident reporting terms are contract- and environment-specific.
12. Coordinated disclosure
Send reports with clear reproduction steps to support@falconcortex.com. Do not include credentials, personal data, or another tenant's information. Receipt targets and safe-harbour terms will be published only after the formal programme is approved.
This engineering brief is maintained by Falcon Cortex and describes selected current design and implementation work. It is not a certification, audit report, legal commitment, or universal availability statement. Independent assurance has not been obtained for the claims on this page.