Data Isolation Guide

Arbitex provides four levels of data isolation, from shared multi-tenant SaaS through fully air-gapped deployments where no data leaves your network. This guide explains the isolation model at each tier, what data flows where, and how to choose the right tier for your compliance posture.

---

Isolation tiers

Tier	Deployment	Prompt data	Metadata	Encryption	Plans
Shared SaaS	Arbitex-hosted	Processed on shared infrastructure	Stored in shared database (row-level isolation)	Platform-managed Fernet	DevFree, DevPro, Team, Enterprise SaaS
Hybrid Outpost	Customer-hosted Outpost + Arbitex Cloud	Stays in your infrastructure	Audit metadata synced to Cloud (configurable)	Operator-managed keys	Enterprise Outpost
Hybrid Air-Gap	Customer-hosted Outpost, periodic Cloud sync	Stays in your infrastructure	Synced only during manual reconnection windows	Operator-managed keys	Enterprise Outpost
Full Air-Gap	Customer-hosted, no Cloud connectivity	Stays in your infrastructure	Never leaves your network	Operator-managed keys	Enterprise Outpost

---

Shared SaaS isolation

All SaaS plans (DevFree, DevPro, Team, Enterprise SaaS) run on shared Arbitex infrastructure with row-level tenant isolation in a single PostgreSQL database.

How row-level isolation works

Every org-scoped table carries a tenant_id UUID column. All queries are filtered at the service layer:

SELECT * FROM audit_logs WHERE tenant_id = :current_tenant_id

This pattern applies to every tenant-scoped resource:

Resource	Isolation column	Notes
Users	tenant_id	Indexed; nullable for system users
API keys	tenant_id	Keys are scoped to a single org
Audit logs	tenant_id	Plus outpost_id for Outpost-synced events
DLP rules (platform)	tenant_id	Built-in rules shared; custom rules per-org
Org DLP rules	org_id	Custom patterns and default suppressions
Groups	tenant_id	Group names unique within tenant
Retention policies	tenant_id	Per-org data lifecycle
SIEM configs	org_id	Connector credentials Fernet-encrypted per row
Usage counters	org_id	One row per org; unique constraint
Enterprise entitlements	org_id	Custom limits for enterprise orgs

Identity boundary enforcement

The org boundary is enforced at the authentication layer, not at the URL level:

• Platform API: The tenant_id is extracted from the authenticated user’s record. Admin endpoints always filter by admin.tenant_id. An admin cannot query, modify, or even see resources belonging to another tenant.
• Cloud Portal: The org_id is extracted from the JWT sub claim — an immutable trust boundary. URL path parameters are validated against the JWT org context. Mismatches return 403 Forbidden.

Caution

The Cloud Portal enforces IDOR protection by validating that the org_id in the URL path matches the org_id in the JWT. This check is applied at the dependency injection layer, before any business logic runs. See RBAC and Portal Permissions for details.

What is shared in SaaS

• Compute: API request processing runs on shared infrastructure. All tenants share the same application servers and database cluster.
• DLP pipeline: The 5-tier DLP pipeline (TF-IDF, regex, NER, DeBERTa, CredInt) runs on shared compute. DLP rules are org-scoped, but the scanning infrastructure is shared.
• Provider routing: Outbound requests to AI providers (OpenAI, Anthropic, Google) are routed from Arbitex infrastructure.

What is isolated in SaaS

• Data at rest: Database rows are tagged with tenant_id and filtered in every customer-facing query. Cross-tenant joins are not used in application code. See the Known Gaps aside below for the current admin-API scoping exception.
• API keys: Scoped to a single org. Keys carry the owner’s identity for policy evaluation.
• DLP configuration: Each org can add custom regex patterns, suppress built-in detectors, and configure per-group DLP overrides independently.
• Audit trail: HMAC-chained per tenant. Each org’s audit chain is independent and tamper-evident. See Security Architecture for HMAC chain integrity details.
• Secrets: SIEM connector credentials are Fernet-encrypted at rest with a platform-managed key. Each row is encrypted independently.

Known gap — admin API tenant scoping

Tenant scoping is enforced uniformly on customer-facing routes (chat, audit read, policy evaluation) and on most admin routers. A subset of admin endpoints — retrieval sources, MCP server registrations, channel connectors, agent sessions, group feature/bundle operations, chains, SAML admin, and custom endpoint registrations — currently verify that the target object exists but do not strictly enforce a tenant_id predicate against the caller’s org. An authenticated admin with a known object UUID could in principle address an object owned by another tenant on those routes.

This gap is tracked as a P2 remediation item (CVP Track 14 audit finding #15) and will be closed by extending the tenant-scoping dependency to the affected routers. Until remediation lands, Tier 2+ customers are additionally protected by PostgreSQL Row-Level Security; Tier 1 customers should treat admin API credentials as privileged and audit access to shared admin endpoints.

---

Hybrid Outpost isolation

The Enterprise Outpost plan places a dedicated data plane in your infrastructure. The Outpost handles all prompt processing, DLP scanning, and provider routing locally. The Arbitex Cloud serves as a management plane only.

What stays in your network

Data type	Location	Notes
Prompt text	Customer infrastructure	Never routed through Arbitex Cloud or Platform
LLM responses	Customer infrastructure	Forwarded directly from provider to Outpost to client
DLP scan results	Local audit buffer	HMAC-chained JSONL on local filesystem
Policy bundle cache	Local filesystem	Refreshed via mTLS pull from management plane
Usage database	Local SQLite	Token counts, cost tracking
Audit queue	Local SQLite	Buffered during degradation; drains on reconnect

What leaves your network

Data type	Destination	Transport	Purpose
Audit log metadata	Platform via Cloud	mTLS, batches of 50	Centralized audit trail
Heartbeat telemetry	Cloud	mTLS	Policy version, DLP tier status, health metrics, cert expiry
Policy sync requests	Cloud → Platform	mTLS	Pull policy bundle for org

Note

Audit entries include prompt_text and response_text fields in the schema. Whether these fields are populated and synced to the Platform is a configuration decision. Organizations with strict data residency requirements can configure audit sync to send metadata only.

Network security

All management-plane communication uses mutual TLS (mTLS):

• Client certificate: Org-issued by Cloud’s PKI CA, stored at the Outpost
• Fail-fast: Policy sync never falls back to unverified connections. Missing or invalid certificates cause an immediate error, not a silent downgrade.
• TLS version: Configurable minimum (default TLSv1.2) and maximum (default TLSv1.3)
• IP allowlisting: Optional CIDR-based allowlist on the Outpost proxy port, with admin-port exemption

The Outpost’s /v1/internal/ routes on the Platform require mTLS client certificates. The middleware validates the full certificate chain (leaf → intermediate → root CA) and extracts the CN from the subject for audit attribution.

Provider API key protection

Provider API keys (OpenAI, Anthropic, etc.) are Fernet-encrypted in the policy bundle before transmission from the Cloud management plane. The Outpost holds the decryption key (PROVIDER_KEY_ENCRYPTION_KEY env var) locally — the management plane never sees the decrypted provider keys during transit.

Multi-org Outpost

A single Outpost instance can serve multiple organizations when MULTI_ORG_MODE=true:

• org_id is extracted from the JWT claim on each incoming request (priority: org_id claim → aud → sub)
• Per-org state is maintained independently: rate limit counters, audit events, policy bundle cache, circuit breakers
• Configurable maximum orgs per instance (MAX_ORGS_PER_OUTPOST, default 10)

In single-org mode, org_id is a static configuration value (ORG_ID env var).

---

Air-gap isolation

Air-gap mode (OUTPOST_AIRGAP=true) is a first-class operational mode for environments with no outbound network connectivity. The Outpost loads all configuration from local filesystem volumes instead of syncing via HTTP.

Configuration

OUTPOST_AIRGAP=true
AIRGAP_POLICY_PATH=/opt/arbitex/policies
AIRGAP_MODEL_PATH=/opt/arbitex/models

What changes in air-gap mode

Five platform services are disabled when OUTPOST_AIRGAP=true:

Service	Air-gap behavior
Certificate rotation	Disabled — manual cert provisioning required
Heartbeat	Disabled — no telemetry sent
Policy sync	Disabled — policy loaded from AIRGAP_POLICY_PATH
Certificate bundle download	Disabled — manual CA bundle provisioning
GeoIP database download	Disabled — uses bundled or volume-mounted MMDB

Policy distribution

In air-gap mode, policy bundles are distributed via a secure file-drop mechanism:

1. Export the policy bundle from the Cloud Portal or Platform API
2. Transfer to the air-gapped environment via approved media
3. Place at AIRGAP_POLICY_PATH/policy_bundle.json
4. Trigger hot-reload via POST /admin/api/policy/reload (air-gap only)

DeBERTa model provisioning

The Tier 3 DLP model (DeBERTa NER) must be provisioned locally:

1. Export the ONNX model from a connected environment
2. Transfer to AIRGAP_MODEL_PATH/
3. The Outpost loads the model at startup

Audit durability

In air-gap mode, audit events are written to the local SQLite queue and the HMAC-chained JSONL buffer. Events are never dropped. If the Outpost is later connected to the management plane, the queue drains automatically.

CredInt in air-gap

Credential Intelligence operates with a static bloom filter in air-gap mode. The CDN refresh is disabled (CREDINT_CDN_URL=""). Operators must manually replace the bloom filter file to update breach data.

Tip

For complete air-gap deployment procedures, see Air-Gap Deployment. For the step-by-step installer, see Air-Gap Deployment Guide.

---

Encryption at rest

Platform-managed encryption (SaaS)

Data	Method	Key management
SIEM connector credentials	Fernet (AES-128-CBC + HMAC-SHA256)	FERNET_KEY env var, operator-managed
Audit log integrity	HMAC-SHA256 chain	AUDIT_HMAC_KEY env var
Provider API keys in policy bundles	Fernet	PROVIDER_KEY_ENCRYPTION_KEY on Outpost
OAuth JWT signing	RS256 (RSA-2048) or Ed25519	OAUTH_JWT_PRIVATE_KEY env var

Secrets backends

The Platform supports three secrets backends, selected via the SECRETS_BACKEND env var:

Backend	Description	Use case
env (default)	Environment variables	Development, simple deployments
vault	Azure Key Vault via DefaultAzureCredential	Production SaaS, enterprise
file	JSON file on disk	Self-hosted, container secrets

BYOK roadmap

Bring-your-own-key (BYOK) for customer-managed encryption keys is planned for a future release (Epic H). Currently, all encryption keys are operator-managed — Arbitex (for SaaS) or the customer’s operations team (for Outpost deployments). BYOK will enable customers to provide their own AES-256 keys for data-at-rest encryption, with key rotation managed through the customer’s KMS.

---

Per-org resource scoping summary

Every customer-facing resource in Arbitex is scoped to a single organization. The table below lists the enforcement layer for each resource. See the Known Gaps aside under Shared SaaS isolation for admin endpoints where tenant_id enforcement is still being extended.

Resource	Platform column	Cloud column	Enforcement layer
Users	tenant_id	—	Service-layer WHERE clause
API keys	tenant_id	org_id FK	Service-layer WHERE clause
Groups	tenant_id	—	Service-layer WHERE clause
DLP rules	tenant_id / org_id	org_id FK	OrgDLPLayer class scoped by org_id
Audit logs	tenant_id	—	Service-layer WHERE clause
Policy chains	scope_id = tenant_id	—	Policy engine evaluates org chain only
SIEM config	org_id	—	Service-layer WHERE clause
Usage counters	org_id (unique)	—	One row per org
Entitlements	org_id (PK)	—	Primary key constraint
IP allowlist	org_id	allowed_ip_ranges	Middleware layer 9
MFA policy	org_id (unique)	—	Middleware layer 8, 60s cache
Passkey policy	org_id (unique)	—	Auth enforcement
Recovery policy	org_id	—	Recovery flow
SAML IdP config	tenant_id	—	Per-org SSO
SCIM tokens	org_id	—	Per-org SCIM auth
Retention policies	tenant_id	—	Per-org data lifecycle

---

Choosing an isolation tier

Requirement	Shared SaaS	Hybrid Outpost	Hybrid Air-Gap	Full Air-Gap
No prompt data on Arbitex infrastructure	—	Yes	Yes	Yes
Data residency (prompts stay in-country)	—	Yes	Yes	Yes
Data residency (metadata stays in-country)	—	—	Partial	Yes
No outbound network from data plane	—	—	Periodic	Yes
On-prem compliance audit trail	—	Yes	Yes	Yes
Dedicated compute	—	Yes	Yes	Yes
Managed DLP model updates	Yes	Yes	Periodic	Manual
Managed policy updates	Yes	Yes	Periodic	Manual
Credential Intelligence (live)	Yes	Yes	—	—
Credential Intelligence (static)	—	—	Yes	Yes

For a detailed comparison of deployment modes and topology diagrams, see Deployment Topologies.

---

See also

• Deployment Topologies — network diagrams and sizing for each deployment mode
• Security Architecture — authentication, HMAC chain integrity, middleware defence stack
• Air-Gap Deployment — operational reference for air-gapped Outpost configuration
• RBAC and Portal Permissions — Cloud Portal role model and IDOR protection
• Policy Configuration — org-scoped vs user-scoped policy chains