Trust & Security

Security architecture

The structural guarantees: isolation, a single enforcement point, and identity that can't be spoofed.

The platform's security posture rests on a small number of structural decisions — properties of how the system is built, not policies someone must remember to apply.

Isolation by construction

Every application gets physically separate databases for live data, audit history, and AI. Tenant data within an application is partitioned by the permission model on every read. There is no shared table where a filter mistake could leak one customer's data to another's application.

One enforcement point

Tenant record access uses the shared account, DataRole, Location, and record-permission model. Each route must also verify its credential, scope, and action permissions. New features must use these controls and pass isolation tests; a shared security model does not remove the need to test each integration.

Identity is server-derived

The server establishes the calling principal from a verified session or API credential. Requests can include app, account, user, and record IDs as targets, but those IDs are not authorization proof. The server checks that every target belongs within the caller's permitted scope.

Presentation can't grant access

Page layouts and AI features consume data after permission filtering. Changing what a page shows, or what an assistant is asked, can narrow what appears — never widen it.

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.