Tenant isolation

Arbitex provides four distinct isolation tiers. Each tier increases the degree of data-plane separation between your organization and other tenants, at the cost of additional operational complexity and cost. Choose the tier that matches your compliance requirements, risk tolerance, and budget.

---

Isolation tiers at a glance

Tier	Name	Separation	Plan
1	Shared	Logical — org_id row scoping in a shared database	Team / SMB
2	Enhanced	Row-Level Security + BYOK encryption, per-org keys	Enterprise
3	Outpost	Dedicated data plane on customer infrastructure	Enterprise Premium
4	Air-gap	Zero-egress, offline Ed25519 key sync	Defense

---

Tier 1 — Shared (logical isolation)

All Tier 1 organizations share a single database cluster and a single application cluster. Isolation is enforced at the application layer: every query includes an org_id filter, and every API response is scoped to the requesting organization’s records.

Security properties

• Data segregation: Enforced by org_id column predicate on tenant-scoped tables. Customer-facing API endpoints (chat, audit read, DLP config read/write, group/user CRUD) apply the org_id filter on every query.
• Access control: API authentication validates that the requesting user belongs to the org before any data access occurs.
• Encryption at rest: AES-256 via cloud provider–managed keys (AWS KMS or Azure Key Vault). Keys are shared across all Tier 1 tenants.
• Encryption in transit: TLS 1.3 for all client-to-platform and platform-to-provider connections.
• Audit logging: Per-org audit trail stored in the shared audit log with org_id scoping. HMAC chain integrity verification available.

Operational characteristics

• No customer infrastructure to manage.
• SLA uptime covered by Arbitex.
• Data stored in Arbitex’s cloud region (see Data Residency documentation for region options).

Suitable for

Teams and small businesses without strict data residency or compliance requirements. General commercial SaaS use cases.

Known gap — admin API tenant scoping

Tier 1 logical isolation is enforced on customer-facing routes and the majority of admin endpoints. However, a subset of admin surfaces — retrieval sources, MCP server registrations, channel connectors, agent sessions, group feature/bundle operations, chains, SAML admin, and custom endpoint registrations — currently rely on object-existence checks rather than strict org_id predicates. An authenticated admin with a known object UUID could in principle address an object owned by another tenant on those routes.

Customers on Tier 2 or higher gain database-level RLS which prevents cross-tenant reads independent of the application layer. Tier 1 customers should treat admin API credentials as privileged and rotate them on role change. This gap is tracked as a P2 remediation item (CVP Track 14 audit finding #15) and will be closed by extending the tenant-scoping middleware to the affected routers.

---

Tier 2 — Enhanced (Row-Level Security + BYOK)

Tier 2 adds database-level enforcement and cryptographic key isolation on top of the Tier 1 logical model.

Row-Level Security (RLS)

PostgreSQL Row-Level Security policies are applied at the database level so that even if application-layer org_id filtering were bypassed, cross-tenant reads would be rejected by the database engine itself. RLS policies enforce that each database session can only SELECT, INSERT, UPDATE, and DELETE rows where org_id matches the session variable.

This provides a second enforcement layer independent of application code.

Bring Your Own Key (BYOK)

Tier 2 organizations can supply their own encryption master key, managed in their own AWS KMS or Azure Key Vault tenant. Arbitex uses the customer-managed key to encrypt per-org data encryption keys (DEKs). The DEKs are stored encrypted — Arbitex never has access to plaintext DEKs without the customer’s KMS authorization.

Key hierarchy:

Customer KMS Key (customer-owned, customer-controlled)
  └── Per-org DEK (encrypted with KMS key, stored by Arbitex)
        └── Per-record symmetric key (derived from DEK)
              └── Data encrypted at rest

Key revocation: revoking or rotating the customer KMS key renders all Tier 2 org data unreadable without re-encryption with the new key. Arbitex cannot decrypt your data after key revocation.

Security properties

All Tier 1 properties, plus:

• Database-level RLS: Cross-tenant reads blocked at the PostgreSQL engine, not just the application.
• BYOK: Customer controls encryption master keys. Arbitex cannot access data after key revocation.
• Per-org DEKs: Each organization’s data is encrypted with a distinct key. A KMS breach in one org’s key does not affect others.

Suitable for

Enterprise customers with compliance requirements (SOC 2 Type II, ISO 27001, HIPAA BAA, GDPR DPA) that require demonstrable key management controls and database-level isolation.

---

Tier 3 — Outpost (dedicated data plane)

The Outpost model deploys a dedicated data plane — the Arbitex Outpost proxy — inside the customer’s own network. AI traffic never leaves the customer’s network boundary to reach Arbitex’s shared infrastructure. The Outpost communicates with Arbitex’s control plane only for policy sync, audit sync, and telemetry.

Architecture

Customer Network
  ┌────────────────────────────────────────────────────────┐
  │  Client applications                                   │
  │       │                                                │
  │       ▼                                                │
  │  Arbitex Outpost  ←── policy bundle (sync on schedule) │
  │  (DLP + policy engine)                                 │
  │       │                                                │
  │       ▼                                                │
  │  AI Provider (direct or via customer VPN/proxy)        │
  └────────────────────────────────────────────────────────┘
           │ audit events, telemetry
           ▼
  Arbitex Control Plane (Arbitex-managed)

AI prompt text and model responses remain inside the customer network. The Outpost processes DLP and policy enforcement locally. Arbitex’s control plane receives audit event hashes and metadata but not prompt content (unless audit log forwarding is explicitly enabled by the customer).

Security properties

All Tier 2 properties, plus:

• Network-level isolation: Prompt text and model responses never traverse Arbitex’s infrastructure.
• Customer-managed deployment: Outpost runs on customer-controlled Kubernetes or VM infrastructure.
• Local DLP processing: All DLP scanning (Tier 1 pattern matching, NER, DeBERTa validation) runs inside the customer’s network.
• Local policy enforcement: Policy chain evaluation is performed by the Outpost without a network round-trip to Arbitex.
• Air-gap-compatible sync: Policy bundles can be applied via push from the control plane, schedule-based pull, or manual upload.
• Admin API: Full outpost management via the local admin API on :8301 (localhost-only by default). Outpost operation does not require connectivity to Arbitex’s control plane once the initial policy bundle is loaded.

Operational requirements

Component	Requirement
Kubernetes	1.24+ (or equivalent container runtime)
CPU	2+ vCPU per Outpost replica
Memory	4 GB minimum (8 GB recommended with GPU microservices)
Storage	1 GB for policy bundle + audit buffer
Network	Outbound HTTPS to AI provider; periodic outbound HTTPS to Arbitex control plane for sync
GPU (optional)	CUDA-capable GPU for NER and DeBERTa tiers (see DLP pipeline deep-dive)

Suitable for

Enterprise Premium customers with data residency requirements, regulated industries (healthcare, financial services, defense contractors), or customers who cannot permit AI prompts to leave their network boundary.

---

Tier 4 — Air-gap (zero egress)

The Air-gap tier is a specialized deployment for environments with no internet connectivity or strictly controlled egress. The Outpost operates in fully offline mode: no outbound connections to Arbitex’s control plane, no DNS lookups to external services, no telemetry.

How policy sync works without connectivity

Policy bundles are delivered via sneakernet: a signed JSON bundle is exported from the Arbitex control plane, transferred to the air-gapped environment on physical media, and imported manually via the Outpost admin CLI.

Bundle signing uses Ed25519 asymmetric signatures. The Outpost holds the Arbitex public key at deployment time and verifies the signature before applying any bundle update. A tampered or unsigned bundle is rejected.

Control plane (internet-connected)
  └── Export policy bundle
        └── Sign with Arbitex Ed25519 private key
              └── Transfer on physical media (USB, DVD, etc.)

Air-gapped Outpost
  └── Verify bundle signature with Arbitex Ed25519 public key
        └── If valid: apply bundle
        └── If invalid: reject, log tampering attempt

Audit log export

Audit events are accumulated in the Outpost’s local audit buffer with HMAC chain integrity. When network transfer is not possible, the audit log is exported to a structured JSON file and transferred to the review system via the same sneakernet channel.

Security properties

All Tier 3 properties, plus:

• Zero egress: No outbound network connections required or permitted after initial deployment.
• Cryptographic bundle verification: Ed25519 signature verification prevents unauthorized policy changes.
• Offline DLP: All pattern matching, NER, and DeBERTa validation run locally. No calls to external APIs.
• No telemetry: The Outpost does not attempt to send telemetry to Arbitex’s infrastructure.
• Local audit chain: Full HMAC audit chain operates offline; export on schedule via sneakernet.

Operational requirements

Air-gap deployments require a formal process for:

1. Policy bundle export from the control plane (internet-connected administrator)
2. Physical media transfer and chain-of-custody documentation
3. Bundle import via arbitex-outpost policy import CLI command
4. Audit log export and physical media transfer for review

Operational overhead

Air-gap deployment requires significant process discipline. Policy updates that take seconds in Tier 1–3 require a physical media transfer cycle. Ensure your operations team has documented procedures for each transfer step.

Suitable for

Defense, intelligence, critical infrastructure, and other customers operating under ITAR, CMMC Level 3+, or other frameworks that prohibit internet-connected data processing systems.

---

Plan mapping

Plan	Isolation tier	Key management	Data plane
Team	Tier 1 — Shared	Arbitex-managed	Shared Arbitex cloud
SMB	Tier 1 — Shared	Arbitex-managed	Shared Arbitex cloud
Enterprise	Tier 2 — Enhanced	BYOK (customer KMS)	Shared Arbitex cloud
Enterprise Premium	Tier 3 — Outpost	Customer-managed	Customer infrastructure
Defense	Tier 4 — Air-gap	Customer-managed (offline)	Customer infrastructure, no egress

Contact your Arbitex account team to discuss plan eligibility and migration between tiers.

---

Choosing between tiers

Requirement	Minimum tier
General SaaS compliance	Tier 1
SOC 2 Type II / ISO 27001	Tier 1
HIPAA BAA with key control	Tier 2
GDPR demonstrable key custody	Tier 2
Prompts must not leave network	Tier 3
Data residency (no cloud)	Tier 3
Zero-trust / no internet egress	Tier 4
CMMC Level 3 / ITAR	Tier 4
Classified environments	Tier 4

---

See also

• Outpost deployment — Kubernetes installation and configuration
• Air-gap deployment — Offline policy bundle workflow and sneakernet procedures
• DLP pipeline deep-dive — How DLP runs locally in Outpost and Air-gap tiers
• Encryption — AES-256 at rest, TLS in transit, and BYOK key hierarchy
• Compliance frameworks — HIPAA, PCI-DSS, GDPR, CMMC mapping