Security Trust Center

Arbitex is designed for organizations that process sensitive data through AI systems. This page provides the comprehensive security architecture reference for enterprise procurement, security review, and compliance assessment. For each security domain, it describes the controls in place and how they map to enterprise requirements.

Security architecture overview

Arbitex is designed as a secure proxy layer between your users and AI model providers. Every request passes through a multi-layer security pipeline before reaching an external model and after the model responds. No request bypasses enforcement.

User / Application
        │
        ▼
┌─────────────────────────────┐
│   Cloudflare Edge (WAF)     │  ← DDoS, rate limiting, bot mitigation
└─────────────┬───────────────┘
              │  TLS 1.2+
              ▼
┌─────────────────────────────┐
│   NGINX Ingress (AKS)       │  ← IP allowlist, TLS termination
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   Authentication Layer      │  ← API key / RS256 JWT / SAML SSO
│   (FastAPI middleware)       │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   Policy Engine             │  ← Policy packs, combining algorithm
│   (first_applicable)         │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   3-Tier DLP Pipeline       │  ← Regex → GLiNER NER → DeBERTa NLI
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   Audit Layer               │  ← HMAC-chained, append-only
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│   Provider Gateway          │  ← Routed to AI provider over TLS
└─────────────────────────────┘

The Arbitex Outpost extends this pipeline into your private network as a hybrid deployment option, running the same enforcement pipeline locally before any data leaves your environment.

Authentication and authorization

RS256 JWT (platform-0042)

Arbitex platform M2M tokens are now issued as RS256-signed JWTs. This upgrade (shipped in platform-0042) enables:

JWKS-based validation — token signature verifiable using the public JWKS endpoint without sharing secrets
Algorithm transparency — RS256 uses an asymmetric RSA key pair; the private key never leaves Arbitex infrastructure
kid rotation — tokens include a kid header referencing the signing key; key rotation is zero-downtime
Outpost compatibility — the outpost JWT validator accepts RS256/RS384/RS512 only; HS256 tokens are rejected at the algorithm check

The JWKS endpoint is published at https://api.arbitex.ai/.well-known/jwks.json.

During the migration window, HS256 tokens from existing OAuth clients continue to be verified against the stored secret. New OAuth clients receive RS256 by default.

See RS256 + JWKS guide for full integration details.

OAuth 2.0 M2M

Machine-to-machine authentication uses the OAuth 2.0 Client Credentials flow. Clients authenticate with client_id and client_secret (HTTP Basic or form body), receiving an RS256-signed JWT with configurable lifetime (up to 86,400 seconds). Six scopes are defined: api:read, api:write, admin:read, admin:write, audit:read, dlp:read.

See OAuth 2.0 M2M API.

SAML 2.0 SSO

Enterprise organizations can configure SAML 2.0 for SP-initiated and IdP-initiated flows. JIT provisioning creates users on first SAML login. Group membership from SAML claims maps to Arbitex groups, enabling policy-based access control without manual provisioning.

The SAML ACS URL is https://api.arbitex.ai/api/auth/saml/acs.

See SAML SSO admin guide.

SCIM 2.0 provisioning

Automated user and group lifecycle management via SCIM 2.0. Supports Users and Groups endpoints per RFC 7643/7644. SCIM bearer tokens are org-scoped and rotatable without service interruption.

See SCIM provisioning.

Multi-factor authentication

MFA type	Support
FIDO2 / WebAuthn hardware keys	Supported; required for Arbitex staff access
Authenticator app (TOTP)	Supported
SMS	Supported

Enterprise plans can enforce FIDO2 hardware keys as the only permitted MFA method.

API key authentication

API keys use the format arb_live_* (production) and arb_test_* (test). Keys are stored as SHA-256 hashes; plaintext is shown once at creation and cannot be retrieved thereafter. Keys are org-scoped and carry the permissions of the associated role.

3-tier DLP pipeline

Every prompt passes through three detection tiers in sequence. Each tier adds signal; downstream tiers run for high-confidence classification.

Tier	Technology	Function
Tier 1	Regex + Luhn checksum	Pattern matching for structured PII: PANs, SSNs, IBANs, phone numbers, emails
Tier 2	GLiNER NER (zero-shot)	Named entity recognition for unstructured PII: names, addresses, medical terms, organizational data
Tier 3	DeBERTa NLI validator	Intent classification and contextual validation; reduces false positives from Tiers 1–2

Detection runs before policy evaluation. Policy rules consume detection findings; enforcement actions (BLOCK, REDACT, CANCEL, ALLOW_WITH_OVERRIDE, PROMPT) are applied to the request based on policy chain evaluation.

The Outpost DeBERTa scanner runs Tier 3 locally — sensitive data is classified on-premises before any data leaves your network.

Data protection

Encryption in transit

All traffic to and from Arbitex uses TLS. No plaintext connections exist in production.

Segment	Protection
Client → `api.arbitex.ai`	TLS 1.2+ via Cloudflare edge
Cloudflare edge → AKS origin	Cloudflare Authenticated Origin Pulls (mTLS)
Outpost → Cloud control plane	Mutual TLS; client certificate verified against full chain
Internal service-to-service	TLS enforced on all private endpoints (PostgreSQL, Redis, Key Vault)

TLS 1.0 and 1.1 are disabled. Forward-secret cipher suites only on the customer-facing edge.

Encryption at rest

Data store	Storage-level encryption	Application-layer encryption
PostgreSQL	Azure Flexible Server (AES-256, platform-managed)	Fernet/AES-128 for SAML configs, webhook secrets
Redis	TLS in transit; no persistence to unencrypted disk	—
Azure Files (GeoIP, CredInt databases)	Azure Storage Service Encryption (AES-256)	—
Azure Key Vault	FIPS 140-2 Level 3 HSM-backed	—
Audit logs	Azure Log Analytics (Azure-managed AES-256)	HMAC chain for tamper evidence

Application-layer encryption: Arbitex uses Fernet (AES-128-CBC + HMAC-SHA256) for sensitive configuration values stored in the platform database — SAML IdP configurations, SIEM connector credentials, webhook secrets. The Fernet key is stored in Azure Key Vault and rotated on a scheduled basis.

Upgrade path: AES-256 application-layer encryption and BYOK (Bring Your Own Key) are planned under Epic H. The Fernet key abstraction layer is designed to support BYOK without requiring schema changes.

Audit trail and HMAC chain integrity

Every request produces an audit log entry. Audit entries are chained using HMAC-SHA256 signatures — each entry’s HMAC includes the previous entry’s HMAC, forming a tamper-evident chain. Modification, deletion, or reordering of entries is detectable.

Audit tier	Retention	Storage
Active (hot)	90 days	Azure Log Analytics
Archive	2 years	Azure Log Analytics archive tier

Audit events export to SIEM in OCSF v1.1 format (class 2001 — Security Finding for enforcement events).

See Audit chain integrity for the HMAC algorithm and verification API.

Infrastructure security

Containerized deployment (AKS)

Arbitex runs on Azure Kubernetes Service (AKS). Key security properties:

Non-root containers — all service containers run as non-root users (e.g., appuser UID 1000 for the backend)
Read-only root filesystems — containers cannot write to their filesystem outside designated volumes
Base images pinned by SHA256 digest — no floating tags in production
Trivy vulnerability scanning — all images scanned before deployment; critical/high findings block deployment
Pod Security Standards — restricted profile enforced on all namespaces; baseline profile on GPU inference namespace (CUDA requirement)
No curl in production images — health checks use Python stdlib; attack surface reduced

Network policies

Calico network policies enforce default-deny between all pods in the AKS cluster. Each service pair has an explicit allowlist policy. A compromised pod cannot reach unrelated services.

Perimeter defense (Cloudflare):

WAF — OWASP ruleset + custom rules for AI proxy traffic
DDoS protection — unmetered at network layer
Bot management — automated traffic filtering
Rate limiting — per-path limits at edge before origin

Private endpoints

All data services (PostgreSQL, Redis, Key Vault) are accessible only via Azure Private Endpoints. No public database or cache endpoints exist. Data traffic never traverses the public internet.

Secrets management

Azure Key Vault stores all secrets in production. Applications refuse to start if Key Vault is unreachable and insecure defaults are detected. SECRETS_BACKEND=env is blocked in production. No hard-coded credentials in production images.

CI/CD authentication

GitHub Actions authenticates to Azure via OIDC federation — no stored Azure credentials in GitHub. Trust relationship is defined at Azure and scoped to specific repository and workflow paths. Build and deployment pipelines require manual trigger; no automatic deployment on push.

Staff admin plane isolation

Internal staff tooling (int.arbitex.ai) is NS-delegated to a private RFC 1918 nameserver. The entire subtree is unreachable from the public internet — DNS resolution returns SERVFAIL externally. Access requires VPN or Cloudflare Zero Trust connector.

Credential Intelligence

The Arbitex Credential Intelligence system protects against credential-stuffing attacks and leaked-credential usage in AI interactions.

Property	Value
Breach corpus size	861M+ credential pairs
Detection method	Bloom filter + k-anonymity (SHA-1 prefix, 5-character)
Privacy guarantee	Plaintext credentials never transmitted to check; only a hash prefix is used
Local processing (Outpost)	Full bloom filter runs on-premises; no cloud round-trip required
Update mechanism	CDN-delivered bloom filter refreshes on a scheduled cadence

When a credential match is detected, the audit log records:

credint_hit — boolean match indicator
credint_bucket — hash prefix bucket (not the credential itself)
credint_confidence — confidence score from the filter

See Outpost Credential Intelligence guide for configuration and operational details.

IP allowlist

Per-organization IP allowlist enforcement is available for SaaS deployments. Supports three rule types:

Type	Format
Single IP	`203.0.113.42`
CIDR range	`10.0.0.0/8`
IP range	`192.168.1.1–192.168.1.254`

IP allowlists are checked before authentication. The allowlist cache refreshes on writes and has a 60-second TTL. Allowlisting is opt-in — organizations without configured rules pass all source IPs.

See IP Allowlist admin guide.

Compliance framework coverage

Arbitex ships 8 Compliance Bundles — pre-built Policy Packs mapped to regulatory frameworks. Bundles provide detection patterns and enforcement rules designed to support compliance programs.

Framework	Bundle ID	Policy focus
PCI-DSS	`pci_dss`	Cardholder data — PAN, CVV, expiration
HIPAA	`hipaa`	18 PHI Safe Harbor identifiers
GDPR	`gdpr`	EU personal data categories, special categories
GLBA	`glba`	Financial NPI — account numbers, SSNs, routing
SOX	`sox`	Financial reporting data, MNPI
BSA/AML	`bsa_aml`	Suspicious activity patterns, structuring indicators
CCPA	`ccpa`	California PI categories, CPRA sensitive PI
SEC 17a-4	`sec_17a4`	Broker-dealer business communications

Framing: Compliance Bundles are designed to support your compliance program. Arbitex is not certified under any of these frameworks. Your organization is responsible for demonstrating compliance to auditors.

See Compliance Frameworks for the full per-framework control mapping.

Three-tier PKI model

Arbitex uses a three-tier certificate authority hierarchy:

Root CA
  YubiHSM (offline hardware security module)
  Root key never leaves hardware
  Signs intermediate CA only
        │
        ▼
Intermediate CA
  Azure Key Vault (separate HSM)
  Issues leaf certificates via cert-manager (step-ca issuer)
  Online — used for certificate signing operations
        │
        ├── Service leaf certificates (internal mTLS)
        ├── Outpost client certificates (issued at registration)
        └── Cloudflare Origin CA certificate (edge ↔ origin mTLS)

The offline root ensures that a compromise of the online intermediate CA cannot forge a new root. Certificates are auto-renewed by cert-manager with expiry alerts at 14 days.

See Certificate management for the full CA lifecycle.