BondingAI

Identity and Access Architecture (WorkOS)

Why BondingAI uses WorkOS for authentication and authorization while keeping business data in customer cloud.

Executive Summary

BondingAI uses WorkOS exclusively for authentication and authorization.

The key architecture principle is strict separation between:

  • Identity traffic (authentication claims and access tokens)
  • Business data (chats, documents, embeddings, analytics, domain data)

Business data remains in the customer-controlled cloud environment.

Data Boundary: Identity vs Business Data

Authentication Flow

Data Classification

Data CategoryExamplesStorage LocationLeaves Customer Cloud
Chat ContentMessages, AI responses, conversation historyCustomer PostgreSQLNo
DocumentsUploaded files, PDFs, knowledge baseCustomer Azure BlobNo
EmbeddingsVector representations, RAG dataCustomer PGVectorNo
AnalyticsUsage metrics, KPIs, dashboardsCustomer PostgreSQLNo
Company DataOrganizations, domains, configurationsCustomer PostgreSQLNo
User IdentityEmail, name, org membershipWorkOSYes (auth only)
SSO ConfigSAML/OIDC provider settingsWorkOSYes (auth only)
Access TokensSession and authorization tokensWorkOSYes (auth only)

WorkOS Security and Compliance Posture

CertificationStatusDescription
SOC 2 Type 2CertifiedAudited controls for security, availability, confidentiality
GDPRCompliantEU data protection compliance
CCPACompliantCalifornia privacy compliance
HIPAABAA AvailableBusiness Associate Agreement available
PCI DSSCertifiedPayment security standard compliance

Operational security practices include encrypted transport, encrypted storage, third-party testing, and compliance documentation.

Why This Architecture Decision

This approach reduces time-to-value while preserving enterprise controls.

Decision DimensionWith WorkOSWithout WorkOS
Implementation speedFaster rolloutLonger custom build cycle
Admin experienceBuilt-in enterprise admin flowsCustom admin portal required
Directory syncBuilt-in supportAdditional build/licensing effort
Ongoing maintenanceManaged capabilityCustomer-owned auth lifecycle
Fine-grained authorizationNative WorkOS FGA pathMust build and operate

Risk Perspective

External authentication traffic is acceptable because only identity claims and tokens are exchanged, not business payloads.

  • Identity is validated through secure authentication channels.
  • Business operations execute in customer-controlled data systems.
  • Governance, monitoring, and policy controls remain enforced in platform workflows.

Summary

BondingAI keeps the security boundary clear:

  • Who the user is → handled by WorkOS
  • What the user does and accesses → executed against customer-controlled platform data

This preserves data sovereignty while maintaining enterprise-grade authentication and authorization capabilities.

On this page