Data boundary
Every application operates inside a workspace boundary. Data access rules are enforced centrally in the query layer — every screen and endpoint inherits them. The default posture is fail-closed.
Security
The layers below describe how the platform is built — the honest version of the design, with certifications and SLAs published at launch.
Every application operates inside a workspace boundary. Data access rules are enforced centrally in the query layer — every screen and endpoint inherits them. The default posture is fail-closed.
Access to build, run, review, and publish is intended to be role-scoped. The permission model is part of the platform — the same model governs UI actions, automations, and endpoints.
Outbound integrations never carry secrets in app definitions. Credentials are stored centrally, resolved at runtime, and scoped — an app gets the credentials it is entitled to, nothing ambient.
Decisions recorded by automations, changes to app definitions, and access-relevant events are designed to produce an inspectable trail. The audit surface is part of the platform and its tooling is still being built.
Drafts, previews, and live apps get separate environments with their own URLs and data boundaries — review always happens away from production.
Connected services are ones you operate. The platform governs the call — scoped credentials, interface, timeout — while the service's own security posture remains yours. That division is explicit, not assumed.
Found something? Use the contact form with the security category and we will route it to the right people. Please do not include exploit data beyond what is needed to reproduce the issue, and give us reasonable time to respond before disclosure.
Contact — security category