Coming Soon — This page describes an architecture that is currently in development and not yet generally available. Contact us to learn more.
Multi-Layer Security
Layer 1: AstroBee Application Security
| Capability | Description |
|---|---|
| User Authentication | Email/Password + MFA |
| Organization Multi-Tenancy | Isolates org data |
| Role-Based Access Control | Admin/Editor/Viewer roles |
Layer 2: Credential Management
| Capability | Description |
|---|---|
| Encrypted Credential Storage | AES-256 at rest |
| Per-User Token Scoping | Never shared across users |
| Automatic Token Refresh | OAuth refresh flow |
Layer 3: Native Platform Security
Each connected data source enforces its own access control:| Platform | Security Model |
|---|---|
| Snowflake | RBAC with role hierarchies |
| Databricks | Unity Catalog with fine-grained access |
| Salesforce | Profiles with object/field permissions |
Layer 4: Audit & Compliance
| Capability | Description |
|---|---|
| Query Logging | User, SQL, timestamp |
| Access Audit Trail | Who accessed what |
| Compliance Reports | GDPR/HIPAA exports |
Zero-Trust Principle
AstroBee operates on a zero-trust model — it assumes it has no inherent rights to customer data and must prove authorization for every query.Comparison with Traditional Data Integration
| Aspect | Traditional (Service Account) | Zero-Ingestion (User Tokens) |
|---|---|---|
| Credentials | Single service account with broad access | Individual user OAuth tokens |
| Permission Model | Replicate warehouse permissions in AstroBee | Use warehouse permissions directly |
| Access Escalation Risk | High — service account is single point of failure | Low — compromising one user token exposes only their data |
| Audit Granularity | All queries appear as service account | Every query attributed to specific user |
| Compliance | Must maintain parallel access control system | Inherits compliance from warehouse (SOC2, ISO) |
Credential Lifecycle Management
Credentials go through a well-defined lifecycle:Initial Connection
User redirects to data source OAuth, grants scopes (read data, list tables/objects), receives access + refresh tokens.
Background Refresh
Before expiry, AstroBee uses the refresh token to get a new access token (transparent to user).
Expiry/Revocation
If refresh fails, the connection is marked as expired and the user is prompted to re-authenticate.
Compliance & Data Residency
Key Compliance Benefits
- Data Residency — Customer data never leaves their cloud region. If Snowflake is in EU, data stays in EU.
- GDPR Compliance — No data processing agreement needed (AstroBee doesn’t process personal data, just query results)
- HIPAA Compliance — PHI remains in customer’s BAA-covered warehouse. AstroBee only sees aggregated results.
- SOC2 Inheritance — Leverage data platform provider’s SOC2 certification (Snowflake, Databricks, Salesforce audited annually)
- Right to Deletion — Deleting data in source system immediately reflects in AstroBee queries (no stale copies)
Audit Capabilities
- Query logs — “Show all queries Bob ran against
sensitive_customerstable” - Access reports — “Which users accessed finance data in last 30 days?”
- Compliance dashboards — Track failed permission attempts, unusual query patterns
Deployment: Customer Onboarding Flow
User onboarding
Each team member authenticates individually with data sources (their own credentials).
Next Steps
Federated Query Layer
Core architecture and credential delegation model
Architecture Overview
Back to the high-level architecture overview