Security model
Private workspaces, explicit access, no public signup.
Adda is built for internal teams. Every important product surface resolves through authenticated membership, workspace scope, and role-aware policies.
Private by invitation
There is no public signup. Accounts are approved and created by admins, and deactivated access cuts off existing sessions immediately.
Workspace isolation
Every workspace resolves from the current member context. Foreign workspace ids are hidden behind 404 behavior, so tenants cannot be enumerated.
Scoped permissions
Workspace roles, project membership, restricted docs, creative shares, and module visibility are checked before reads and writes.
Session and device controls
Web uses secure cookie auth. Desktop and Android use the same protected API surface with active-user enforcement.
Operational security notes
- Workspace ids and slugs are not treated as secrets. Membership is the security boundary.
- Foreign workspace resources return 404 where possible to avoid tenant enumeration.
- The Android app stores the pinned workspace and token in secure storage.
- The Windows app is a native shell around the hosted app and uses the same protected web session.
- Admins can deactivate members, which blocks existing sessions through active-user middleware.
- Demo workspaces are isolated, disposable, and muted for external sends.