Security & Trust
Security built into every workspace.
Zondra protects organization data, shared context, and day-to-day collaboration through authenticated sessions, role-based permissions, and workspace boundaries — without extra process for your team.
Principles
How Zondra approaches security.
These are product behaviors enforced in the product today.
Least privilege
Server checks role and permission before data is read or changed. Users receive only the access their role allows.
Workspace isolation
Requests are scoped to the organization and workspace the member belongs to. One tenant’s data is never served as another’s.
Authenticated sessions
Product workspaces require a verified session. Unauthenticated visitors cannot open product routes.
Transparent permissions
Access is checked on the server — not only hidden in the interface.
Separated demo
The public demo runs in the browser on a static seed dataset. It does not write to customer data.
Privacy documentation
Collection, cookies, AI use, and processing terms are published on dedicated legal pages.
Workspace isolation
Each company works inside its own boundary.
Zondra is multi-tenant. Isolation is logical: organization and workspace identifiers travel with every authenticated request, and server handlers refuse mismatches. Users only see workspaces they belong to.
The public demo is a separate path. It uses an in-browser seed dataset and does not share storage with signed-in product workspaces.
- 01
Organization
Membership is required. API context resolves the caller’s organization from an active membership record.
- 02
Workspace
Workspaces belong to an organization. Requests verify that the selected workspace matches that organization.
- 03
Records
Module data (CRM, tasks, meetings, documents, and more) is stored and queried with organization and workspace identifiers.
Client Firestore and Storage rules also require organization membership for direct client access. Product APIs apply the same membership checks.
Authentication & authorization
Who can sign in — and what they can do.
Access control is enforced on the server. UI may hide actions, but permissions are checked again when APIs run.
Authentication
Sign-in methods
Email and password, and Google sign-in via Firebase Authentication. Password reset is available from the forgot-password flow.
Session cookies
After sign-in, Zondra exchanges a Firebase ID token for an HTTP-only session cookie verified on the server. Signing out clears the cookie.
Route protection
Middleware requires a session cookie for /app, onboarding, invites, and internal tools. Public marketing, auth, and /demo routes stay open.
Roles in use today
Membership roles map to a fixed permission matrix. Custom policy experiments may exist in admin tooling, but day-to-day access follows these system roles.
- OwnerFull organization control, including destructive organization actions and billing where applicable.
- AdminBroad administration without organization deletion or billing management.
- ManagerOperational leadership across modules, including invites and audit log read access.
- MemberDay-to-day create and update access across core modules.
- ContributorCreate and update access with a narrower permission set than Member.
- ViewerRead-focused access to organization and workspace content.
- GuestMinimal organization and workspace visibility.
- Billing adminOrganization read plus billing management.
Data
Where company information lives.
Zondra runs on Firebase / Google Cloud. Platform storage provides infrastructure-level encryption at rest; Zondra adds application encryption for integration tokens.
Application data
Organization records — CRM, tasks, meetings, knowledge, communication, automation, and related metadata — are stored in Cloud Firestore.
Files
Document binaries live in Firebase Storage under organization-scoped paths. Access rules require membership in that organization.
Integration secrets
OAuth tokens for connected services are encrypted at the application layer (AES-256-GCM) before storage, using a dedicated encryption key.
Transport
Traffic to Zondra is served over HTTPS (TLS). Session cookies are set as HTTP-only.
Privacy
Published policies.
We publish how personal data is collected, how cookies work, how AI features use context, and how processing is described for customers. Organization admins can also initiate compliance workflows from product settings where enabled — including data export requests.
Account and organization deletion follow the processes described in the Privacy Policy and product tooling. If you need a formal request, use the contact channels listed there.
Public demo
Evaluate the product without touching real workspaces.
The demo exists so your team can inspect flows before committing company data. It is intentionally isolated from authenticated product environments.
No login
/demo is a public route. You can explore without creating an account.
No customer data
The demo loads a static Acme Corp seed dataset. It is not connected to production tenant data.
Browser-only storage
Demo state lives in sessionStorage in your browser — not in your organization’s Firestore.
Temporary changes
You can click around and mutate demo state in-session. A refresh reseeds the workspace from the static dataset.
Reliability controls
What we operate today.
We document engineering controls that already ship — not uptime SLAs we have not published.
Input validation
API payloads are validated with shared schemas before business logic runs.
Consistent errors
Server handlers map failures to structured application errors instead of leaking raw internals to clients.
Audit logging
Many administrative and mutation paths write audit log entries scoped to the organization.
Health checks
Public health endpoints support basic uptime monitoring of the web application.
Planned
On the roadmap — not claimed as live.
Some enterprise controls exist as early APIs or settings drafts. Until they are enforced end-to-end, they belong here.
Enterprise SSO
PlannedProduction-ready SAML / OIDC sign-in with verified IdP assertions.
Enforced MFA policies
PlannedOrganization-level multi-factor requirements applied at authentication time.
SCIM provisioning
PlannedAutomated user lifecycle sync from identity providers.
Stronger session controls
PlannedDevice trust, concurrent session limits, and revocation that terminates Firebase sessions end-to-end.
IP allowlisting enforcement
PlannedOrganization IP policies applied on the request path — not only stored as configuration.
Independent assurance
PlannedSOC 2 and similar assurance when controls are ready for audit.
FAQ
Direct answers for your team.
- How are workspaces isolated?
- Authenticated requests resolve the caller’s organization membership and verify that the workspace belongs to that organization. Records are stored and queried with those identifiers. A member cannot open another company’s workspace through the product APIs.
- Can I explore the product without creating an account?
- Yes. The public /demo route does not require login. It loads a static seed dataset in the browser so you can inspect flows without connecting company data.
- Does the demo use production data?
- No. The demo uses a generated Acme Corp dataset in sessionStorage. It does not read or write customer Firestore tenants.
- Can users access other workspaces?
- Only workspaces they belong to. Middleware blocks unauthenticated access to /app, and server handlers enforce membership plus organization/workspace scope on data operations.
- How are permissions handled?
- Each membership has a system role (owner, admin, manager, member, contributor, viewer, guest, or billing admin). Roles map to a server-side permission matrix checked by API handlers.
- Where can I read the privacy policy?
- The Privacy Policy is published at /privacy. Related documents cover cookies, data processing, AI disclosure, and terms.
Security reports and vulnerability notes: security@zondrabrain.com. General contact: Contact.
Review the product, then start with real company data when ready.
Explore the demo, or request access when you are ready to bring company context online.