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

# Adversarial Review

> Security audit findings, remediation status, and ongoing hardening for the Switchbord platform.

# Adversarial Review

This page documents the adversarial security audit performed across the Switchbord platform and the remediation program that followed. Detailed tracking lives in Linear (BORD-149 through BORD-176).

For a live implementation status table, see [Security Overview](/security/overview).

## Multi-Tenancy Audit (BORD-149 – BORD-176)

A structured adversarial review was performed against ISO 27001, GDPR, NIS2, HIPAA, and SOC 2 dimensions. The audit focused on five risk areas:

### 1. Workspace isolation and context resolution

**Finding:** Several API routes derived workspace context from environment variables (`readSingleWorkspace()`) rather than from the authenticated session. This pattern is incompatible with multi-tenancy — a single-tenant assumption would allow a crafted request to act as any workspace.

**Remediation:** `readSingleWorkspace()` was deprecated and removed from all production code paths. All routes now call `resolveCallerWorkspaceFromSupabase(userId)`, which resolves workspace context from `workspace_members` server-side. All 13 settings routes were audited and re-threaded with `requireSettingsAccess()` as the first operation.

See [Multi-Tenancy & Workspace Isolation](/security/multi-tenancy).

### 2. AI assistant auth gap

**Finding:** The `/api/ai-assistant` endpoint was reachable without authentication. Any unauthenticated caller could submit prompts processed with workspace LLM credentials.

**Remediation:** Auth guard added. Endpoint now requires a valid session and resolves workspace context before processing. AI context is scoped to contacts and conversations within the caller's workspace only.

### 3. Secret storage

**Finding:** Meta access tokens and webhook signing secrets were read from environment variables in some paths, creating a single-tenant assumption and preventing per-workspace secret rotation.

**Remediation:** All provider secrets (Meta tokens, webhook signing secrets, LLM API keys) are stored in Supabase Vault scoped per workspace, accessed via `workspace_secret_bindings`. Environment variable fallbacks are blocked in production.

See [Secrets Management & Encryption](/security/secrets-and-encryption).

### 4. Session and access lifecycle

**Finding:** Member removal did not revoke active sessions. A removed member could continue operating until their token expired.

**Remediation:** Member removal now calls `signOut` to revoke the active session immediately. Session policy enforces an 8-hour absolute timeout and 1-hour inactivity timeout.

See [Authentication & Access Control](/security/authentication).

### 5. GDPR compliance gaps

**Finding:** No data subject rights endpoints existed. Contact PII could be exported or erased only via direct database access.

**Remediation:** GDPR endpoints implemented:

* `GET /api/contacts/[id]/gdpr` — structured export (Art.15/20)
* `DELETE /api/contacts/[id]/gdpr` — anonymization in-place (Art.17)

Both operations write to `audit_logs`. Data retention policy (`data_retention_days`) is configurable per workspace.

See [Data Protection & GDPR](/security/data-protection).

## Remaining Planned Items

The following items from the audit remain in progress and are tracked in Linear:

| Item                                             | Ticket   |
| ------------------------------------------------ | -------- |
| Webhook-scoped phone\_number\_id routing         | BORD-157 |
| JWT workspace claims in Supabase auth            | BORD-155 |
| Edge middleware auth enforcement                 | BORD-156 |
| Rate limiting per workspace                      | BORD-162 |
| Read-access audit logging + tamper-evident chain | BORD-168 |
| Column-level PII encryption                      | BORD-171 |
| Incident detection and breach notification       | BORD-166 |
| SBOM and dependency scanning                     | BORD-170 |

## Ongoing Review Posture

Every major feature PR must include:

* adversarial checks section in the PR description
* identification of any new data access paths and whether they are workspace-scoped
* identification of any new secrets or credentials and whether they are Vault-stored
* rollback note

Hardening issues are tracked in `planning/linear/BACKLOG.yaml` and synced Linear issues. Do not carry open findings only in this doc.