Encryption

Arbitex encrypts all data in transit using TLS and all data at rest using platform-managed encryption. This page describes both layers and the planned customer-managed key (BYOK) capability.

For the full security architecture including network isolation, PKI, and access controls, see Security Overview.

Encryption in transit

All connections to and from Arbitex use TLS. There are no plaintext fallbacks in production deployments.

Traffic segment	TLS configuration
Client → `api.arbitex.ai`	TLS 1.2+ via Cloudflare edge
Cloudflare edge → AKS origin	Cloudflare Authenticated Origin Pulls — cryptographic proof that traffic originates from Cloudflare, not arbitrary internet sources
Outpost → Cloud control plane (`/outpost/*`)	Mutual TLS; client certificate verified against full cryptographic chain
Internal service-to-service	TLS enforced on all private endpoints (PostgreSQL, Redis, Azure Key Vault)
AKS pod-to-pod	Calico network policy (default-deny); explicit allowlist per service pair

The Cloudflare Origin TLS certificate is issued by the Cloudflare Origin CA (1-year term, auto-renewed by cert-manager). The internal CA issues certificates for service-to-service communication and Outpost mTLS. See Certificate management for the CA hierarchy.

TLS version and cipher policy

Arbitex enforces TLS 1.2 as the minimum version. TLS 1.0 and 1.1 are disabled. Cipher suites are managed by Cloudflare’s default security policy (forward-secret ciphers only) on the customer-facing edge. Internal service TLS follows the Azure platform defaults.

Encryption at rest

All data stored by Arbitex is encrypted at rest using Azure platform-managed encryption.

Data store	Encryption
PostgreSQL (platform + cloud)	Azure Flexible Server — storage-level encryption enabled by default (AES-256)
Redis	TLS enforced in transit; no data persisted to unencrypted disk
Azure Files (GeoIP/CredInt databases)	Azure Storage Service Encryption (AES-256, platform-managed keys)
Azure Key Vault	FIPS 140-2 Level 3 HSM-backed key storage
Audit logs	Azure Log Analytics — Azure-managed encryption; 90-day active + 2-year archive

Application-layer encryption (Fernet)

For sensitive configuration data stored in the platform database — SAML IdP configurations, SCIM bearer tokens (hashed, not encrypted), and webhook secrets — Arbitex applies Fernet symmetric encryption as an application-layer protection on top of the database-level AES-256 encryption.

Fernet is a symmetric authenticated encryption scheme using AES-128-CBC with HMAC-SHA256 for authentication. It provides:

Confidentiality — data is encrypted before it reaches the database
Integrity — HMAC prevents tampered ciphertext from being silently decrypted
Authenticated encryption — decryption fails if ciphertext is modified

The Fernet key is provisioned as an environment secret, stored in Azure Key Vault, and rotated on a scheduled basis. Re-encryption of existing ciphertext is performed during key rotation without downtime.

What is NOT encrypted at the application layer

Prompt text and response text in audit log entries are stored in plaintext within the database (which itself is AES-256 encrypted at rest). These fields are only populated when explicit prompt retention is enabled for an org. By default, prompt and response content is not retained.

BYOK (Bring Your Own Key)

Customer-managed encryption keys (BYOK) are scoped under Epic H and are not yet available. The planned design:

Customers provide an Azure Key Vault key URL or AWS KMS key ARN
Arbitex uses the customer’s key for wrapping the Fernet data encryption key (key-wrapping architecture)
Key revocation immediately renders all Fernet-encrypted data inaccessible
Key rotation is customer-controlled and does not require Arbitex involvement

When BYOK ships, it will be documented in this guide. The current platform architecture is designed to support this extension — the Fernet key abstraction layer means BYOK only requires changing where the Fernet key is sourced from.