> ## Documentation Index
> Fetch the complete documentation index at: https://docs.astrobee.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Security & Access Control

> Multi-layer security model, zero-trust design, and compliance for the federated architecture

<Info>
  **Coming Soon** — This page describes an architecture that is currently in development and not yet generally available. [Contact us](mailto:hello@astrobee.ai) to learn more.
</Info>

The federated semantic layer is built on a **multi-layer security model** that ensures customer data is never exposed beyond the user's existing permissions — without AstroBee needing to replicate or manage those permissions.

## 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:

<Steps>
  <Step title="Initial Connection">
    User redirects to data source OAuth, grants scopes (read data, list tables/objects), receives access + refresh tokens.
  </Step>

  <Step title="Active Usage">
    Tokens used for queries (validity varies by provider).
  </Step>

  <Step title="Background Refresh">
    Before expiry, AstroBee uses the refresh token to get a new access token (transparent to user).
  </Step>

  <Step title="Expiry/Revocation">
    If refresh fails, the connection is marked as expired and the user is prompted to re-authenticate.
  </Step>

  <Step title="Deletion">
    User can disconnect a data source anytime — tokens are securely deleted.
  </Step>
</Steps>

## 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_customers` table"
* **Access reports** — "Which users accessed finance data in last 30 days?"
* **Compliance dashboards** — Track failed permission attempts, unusual query patterns

## Deployment: Customer Onboarding Flow

<Steps>
  <Step title="Admin setup">
    Organization admin connects data sources, defines ontology (business model).
  </Step>

  <Step title="User onboarding">
    Each team member authenticates individually with data sources (their own credentials).
  </Step>

  <Step title="Permission inheritance">
    Users automatically inherit their source system permissions in AstroBee.
  </Step>

  <Step title="Usage">
    Users ask questions, get insights respecting their access levels.
  </Step>
</Steps>

## Next Steps

<CardGroup cols={2}>
  <Card title="Federated Query Layer" icon="database" href="/architecture/federated-query-layer">
    Core architecture and credential delegation model
  </Card>

  <Card title="Architecture Overview" icon="layers" href="/architecture/overview">
    Back to the high-level architecture overview
  </Card>
</CardGroup>