01 / IDENTITY
Authentication and sessions
Access is anchored to known accounts and organization membership, not generic public links.
Security posture
Operational trust starts with real boundaries.
BricDesk is built for data that should not leak across builders, projects, teams, or channel partner relationships. Security is part of the product model, not an afterthought.
How we approach it
Protect the records that move revenue.
- Tenant isolation: data access is bounded to the relevant organization and project context.
- Role-aware permissions: the builder, internal team, and channel partner have distinct capabilities.
- Controlled actions: high-consequence changes such as holds and approvals are tied to authorized workflows.
- Auditability: key operational changes should remain explainable after the immediate conversation ends.
- Secure delivery: production requests use strict transport, content controls, and other browser security headers.
Security questions are welcome before a pilot.
We would rather discuss the required access boundary, retention expectation, and data ownership before your project data enters the workflow.
What this means in practice
A CP can do useful work without receiving the builder's whole control plane.
The product should expose the minimum information needed for the job. That reduces accidental disclosure while keeping the selling workflow fast enough to use on site.
02 / DATA
Scoped records and uploads
Project data and file access are expected to follow the relevant ownership and role boundary.
03 / ACTIONS
Defensible decisions
Operationally sensitive actions should preserve who acted, what changed, and why it was permitted.
Security review
Bring your production requirements to the first working session.
We will discuss the real boundary: organizations, projects, CPs, high-risk actions, and support access.