Security at WorkBOS

1. Security model in one paragraph

WorkBOS is multi-tenant by design, and isolation is enforced where it cannot be bypassed: the database. Every table carries row-level security (RLS) that scopes every read and write to your workspace; the application UI is never the security boundary. Role-based access control layers on top, AI agents act under the same permissions as the human who approves them, and every metered or public path is rate-limited and cost-capped.

2. Where your data is hosted

Two tiers, two vendors, two regions. Both are named below with the vendor’s own region identifier, so you can check them against the vendor’s documentation rather than take our word for it.

Every primary copy of your workspace data (database rows, uploaded files and backups) lives with Supabase in ap-southeast-1 (Singapore). The web tier runs on Vercel with iad1 (US East, Northern Virginia) as its primary serverless and edge region, and static assets are served from Vercel’s global CDN. Requests are therefore handled in the United States and the records are stored in Singapore. We do not offer regional pinning today; if you need data stored in a specific region, tell us before you buy. What this means for EU and UK transfers is set out on /compliance, and the full vendor list is on /subprocessors.

What we do not have

WorkBOS holds no third-party security or compliance certifications today. We have no SOC 2 Type I or Type II report, no ISO/IEC 27001 certificate, no HIPAA attestation and no PCI DSS attestation of our own.

There is no report to send you, under NDA or otherwise. What we can send is a written control description, the architecture walkthrough and answers to your questionnaire. Our posture against GDPR, UK GDPR, CCPA/CPRA, PIPEDA, PDPL and DPDP, and what we are doing about certifications, is on /compliance.

3. Tenant isolation

• Row-level security enabled on every business table, fail closed: an unauthorized query returns nothing.
• Org membership predicates gate all access; archived workspaces disappear platform-wide automatically.
• Restrictive database policies additionally enforce per-page create, update and delete rights, including payroll, pay, compensation, leave, e-signature, workspace keys and the role definitions themselves. Coverage is deliberately not yet every page and we do not claim otherwise: the roles editor marks any setting the database will not honour, and that marker is the authoritative answer for a given workspace. Read access is governed by workspace membership rather than by the per-page View toggle, which controls navigation.
• Cross-tenant reads and writes are structurally impossible, and we prove it: every schema change ships only after simulated allow / deny / cross-tenant tests run against the real policies.

4. Access control & authentication

• Role-based access control: owner, admin, member and guest tiers, per-page create/edit/delete matrices (enforced in the database across the money and people modules, and marked in the editor wherever a setting is not yet enforced), per-user overrides. Everyone who joins a workspace is given the standard role matching their access level automatically, so the page rules an administrator sets apply from their first minute rather than only to people somebody remembered to assign by hand; a workspace owner can see at any time who in their workspace holds no role, and every role assignment is written to the activity log.
• Guests are permission-fenced to explicitly granted areas (Viewer / Collaborator / Contributor levels).
• Authentication via Supabase Auth; passwords are hashed, never stored in plaintext, never visible to us.
• Multi-factor authentication support is built into the platform (rolling out progressively).
• Session-scoped API keys with per-day caps, one-time display, and instant revocation for programmatic access.

5. Auditability

• Every create, change and deletion on a business record is captured by a database trigger, not by application code that can be forgotten on a new code path.
• Each event stores the complete before-and-after of the record, so the log answers what actually changed and to what, field by field, rather than only that something changed.
• The log cannot be edited or deleted by anyone, including workspace owners. It is append-only in the database, which is where it is enforced.
• Every event names its actor. A person is named; an action taken through the API names the integration and the key; a public form or signing link says so; a system process says so. It never attributes an action to an unnamed "someone".
• Owners and admins read the trail, filter it by person, action, record type or date, search inside the recorded values, and export what they filtered. An ordinary admin does not see the primary owner’s own actions.

6. AI agent governance

• Approve-first: agents propose; a human with authority approves; only then does execution happen.
• Agents execute through the same permission-checked paths as humans. No elevated backdoors.
• Optional unattended execution is off by default, limited to low-risk action classes, guarded by denylists, daily caps and a kill switch.
• Every proposal, approval, execution and rollback is logged with who, what and when.
• Per-tenant AI cost ceilings prevent runaway usage; bring-your-own-model endpoints are SSRF-guarded.

7. Data protection

• Encryption in transit (TLS) and at rest (managed Postgres encryption).
• Secrets and credentials live in an encrypted vault with server-only reveal. Never in the codebase.
• Every uploaded file is antivirus-scanned at ingest and quarantined on failure; unscanned files cannot be downloaded (enforced by RLS, not UI).
• Per-workspace storage quotas and upload size caps.
• A deleted RECORD is not destroyed by the passage of time, and it is not destroyed by a click either. It moves to the workspace Trash for 30 days with everything attached to it and restores as a whole; Remove moves it down one tier at a time (your Trash, then the workspace bin, then a platform-recoverable archive) and never erases. No action available to a customer destroys a record: erasing the last copy is restricted to our support team in the database itself. Every deletion, tier move, restore and erasure is recorded in the workspace activity log with the name of the person who did it, stamped at the time so it survives them leaving. Deleting a WORKSPACE is the separate, scheduled and cancellable flow, and that one does purge on a fixed retention schedule.
• Erasure is a written register, not a list somebody maintains: every table that belongs to a workspace is recorded as either erased (331) or retained with a stated reason (42: our own billing record, the workspace and its membership, the compliance log of the erasure, and settings holding no customer content). A table on neither list fails our build, so a new feature cannot create somewhere your data quietly survives an erasure.
• The restore point taken before an erasure deliberately excludes credentials, connected-service tokens and biometric enrolments, because a backup that contained them would be a credential store with a friendly name, and it records which tables it left out rather than looking complete. Erasing a workspace also removes its other restore points, so the copies go with the originals.

8. Payments security

• All payments processed by Stripe (PCI-DSS Level 1); WorkBOS never sees or stores full card numbers.
• Webhooks are HMAC signature-verified with replay-window checks; conversion and billing writes are idempotent.
• Amounts are always computed server-side. Never trusted from a browser.
• Hard cost caps and circuit breakers on email volume, AI usage and scanning spend.

9. Secure development lifecycle

• Branch-protected main; every change lands through a pull request.
• Automated gates on every PR: secret scanning (gitleaks), static analysis (semgrep), dependency audit (npm audit), type checks and tests.
• Progressive delivery: features ship dark and roll out by cohort (internal → beta → percentage → GA), containing blast radius.
• Versioned releases with an audited publish flow and one-click rollback.
• Database changes follow expand→contract migration patterns with backups before risky operations.

10. Abuse prevention

• All anonymous/public endpoints (forms, booking, referral clicks) are rate-limited with honeypots and payload caps.
• Authenticated abuse ceilings on heavy operations (exports, bulk deletes), fair-use protection for all tenants.
• Platform-level RLS coverage monitoring: zero tables ship without policies.

11. Availability & continuity

• Hosted on Vercel (application, iad1) and Supabase (database, ap-southeast-1) with managed redundancy.
• Automated database backups with retention; tested restore paths for risky changes.
• Health and scale-readiness instrumentation reviewed continuously; capacity decisions are data-driven.

12. White-label & reseller security

Reseller sub-tenants inherit the same isolation guarantees as any workspace. Resellers manage only their own child workspaces; snapshot cloning copies configuration, never another tenant’s data; and agent autonomy settings are deliberately excluded from cloning so every new workspace starts approve-first.

13. Responsible disclosure

Found a vulnerability? Email security@workbos.com with details and reproduction steps. We commit to acknowledging reports quickly, fixing verified issues promptly, and crediting reporters who wish to be named. Please do not access data that is not yours or degrade the service while researching.

14. Questions

Security questionnaires, DPA requests and compliance questions: security@workbos.com.