Security & Trust
Security is the product.
Arbitex was built as a governance layer. Every architectural decision reflects that. This page documents what we control, how we protect it, and where you can verify it.
DLP: 12 Compliance Frameworks
Audit: Tamper-proof Immutable Logs
Deployment: Hybrid Outpost
Identity: SAML + SCIM + WebAuthn
Security Architecture
Built security-first, not bolted on.
Three architectural decisions define Arbitex security: how data is inspected, how it travels, and how every decision is recorded.
3-Tier DLP Pipeline
Regex (80+ pattern detectors) → Named Entity Recognition (40 ML/NER entity recognizers) → Compliance bundles — every AI request inspected at all 3 tiers. Block, redact, or log on both input and output.
mTLS + TLS 1.3 — Enforced at Startup
All data in transit over TLS 1.3 minimum. mTLS for Hybrid Outpost data plane connections, with full certificate chain verification and CA pinning. Startup validators reject plaintext connections to Redis, telemetry endpoints, and model providers — the gateway refuses to start if any cleartext path exists in production. HSTS enforced. No unencrypted paths. No silent fallbacks.
Tamper-proof Audit Trail
Every request generates an tamper-proof log entry — tamper-evident by construction. Each entry is cryptographically linked to the prior, making undetected modification computationally infeasible. Chain integrity is verified on read — any break in the sequence is flagged immediately. Signed audit exports are available for external forensic review.
Fail-Closed Inference
If DLP inference becomes unavailable, requests are blocked — not passed through. The platform defaults to the conservative path in every failure mode. No silent degradation.
How It Protects You
What the platform does for users
Arbitex is infrastructure, not a dashboard you open. Here is what it does for the people who depend on it every day.
Routing
Your AI requests reach the right model, reliably — and only with permission.
- Requests are routed based on policies your organization sets — not arbitrary platform decisions. You can see which models are available to you and why.
- If a provider goes down or behaves unexpectedly, automatic health monitoring detects it and reroutes your request to a healthy alternative. You stay unaffected.
- Platform operators can block any model or provider instantly. If something looks wrong, access is cut before it becomes an incident.
- Every routing decision is logged — who made the request, which model responded, and whether any policy was applied.
Protection
Sensitive data is blocked or removed before it reaches any AI model.
- Every request you send is checked for sensitive information — card numbers, government IDs, personal details, and confidential credentials — before it ever leaves your environment.
- If sensitive data is detected, it is blocked or automatically redacted. You receive a clear response indicating what was caught and why, not a silent failure.
- The same inspection applies to what the AI sends back. Responses are checked before they reach you, not just requests going out.
- Your data is never used to train any AI model — ours or any third party's. Inspection happens in real time and nothing is retained without your explicit configuration.
Visibility
Everything that happens with your AI usage is recorded and auditable.
- Every request, every policy decision, and every blocked item is written to an audit log that cannot be modified — not even by account administrators.
- Security teams can see exactly what AI is being used for, which users are sending what kinds of requests, and whether any policy violations occurred.
- You can export signed audit records for external review, generate compliance reports on demand, and configure how long records are retained to meet your regulatory requirements.
- Real-time dashboards show request volume, costs by team, policy trigger rates, and provider health — everything needed to verify that governance is working.
Compliance
Designed for regulated environments
Arbitex is designed for regulated enterprises. Every framework listed below maps to enforcement rules in the gateway — not aspirational commitments.
SOC 2 (Designed for — not currently certified)
- tamper-proof audit logs with on-demand compliance report generation
- Audit anomaly detection with automated alerting included
- Controls: Security, Availability, Confidentiality
HIPAA
- PHI detection via named entity recognition in the DLP pipeline
- HIPAA compliance bundle in DLP layer
- Business Associate Agreement (BAA) available
- Audit log retention meets 45 CFR §164.312
GDPR
- GDPR compliance bundle in DLP layer
- CCPA mapped. Data subject rights workflows supported.
- Data Processing Agreement (DPA) available. Subprocessor list available on request.
- Data residency: US (SaaS) or customer environment (Hybrid Outpost)
PCI-DSS
Designed for- PCI-DSS compliance bundle in DLP layer
- Luhn-validated card number detection in regex pipeline
- In scope for Hybrid Outpost deployments
- Documented scope boundary available on request
Financial Regulations
Designed for- SOX — financial data controls and audit trail
- GLBA — financial privacy and safeguards rule
- BSA/AML — transaction monitoring compliance bundle
- SEC Reg FD — immutable record retention for broker-dealers
Audit Infrastructure
Active- Immutable, tamper-proof audit logs — tamper-evident by construction
- On-demand gateway activity evidence export for SOC 2 audit preparation
- Signed audit exports for external review
- Configurable retention: 30 days, 90 days, or 1 year+
Data & Privacy
How customer data is handled
Arbitex is a data processor. The customer is the data controller. Every decision about data handling reflects that boundary.
| Control | Implementation | Status |
|---|---|---|
| Data in transit | TLS 1.3 minimum with HSTS enforced (max-age=31536000). mTLS with CA pinning for Hybrid Outpost data plane ↔ control plane. Startup validators enforce encrypted connections — plaintext URLs rejected at process start in production mode. | OK |
| DLP pipeline | Multi-layer content inspection: regex (80+ pattern detectors, with checksum validation where applicable — IBAN, ABA routing, NPI, DEA, ITIN, EIN, and similar regulated identifiers), AI-powered entity recognition (40+ entity types with contextual validation), compliance bundles (PCI-DSS, HIPAA, GDPR, GLBA, SOX, CCPA, BSA/AML, SEC Reg FD, FERPA, EU AI Act, NIST AI RMF, ISO/IEC 42001). Block/redact/log on input and output. | OK |
| Audit log integrity | Immutable, tamper-proof logs — each entry cryptographically linked to its predecessor for tamper-evidence. Chain breaks are detected on read and flagged immediately. Signed audit exports with verification checksums available for external forensic review. Gateway activity evidence packages generated on demand for SOC 2 audit preparation. Retention: 30d / 90d / 1yr+ (configurable). | OK |
| Data at rest | Infrastructure-layer disk encryption at storage layer; AES encryption at rest at application layer for SIEM credentials, file attachments, and API keys. Secrets backend (Azure Key Vault or HashiCorp Vault) enforced in production — startup validators reject plain environment variable backends. | OK |
| Log data handling | Prompt and response content encrypted at rest. Access to log data requires explicit IAM grant and is audit-logged. Retention configurable: 30d / 90d / 1yr+. | OK |
| Data residency | Data residency: US (SaaS) or customer environment (Hybrid Outpost). Data does not cross region boundaries without explicit configuration. | OK |
| Data processing role | Arbitex is a processor. Customer is controller. Data Processing Agreement (DPA) governs the relationship. DPA available on request. | OK |
| AI training use | Customer data is never used to train models — ours or any third-party. Zero retention by default on the AI provider side is enforced through provider agreements. | OK |
| Sub-processors | Subprocessor list available on request — contact [email protected]. Customers receive advance notice of material changes. DPA includes objection rights. | OK |
| Data deletion | On account termination, all customer data deleted within 30 days. Deletion certificates available on request. Log archives purged per retention policy. | OK |
Infrastructure
Infrastructure security
Controls applied to the systems that run Arbitex — network, secrets management, supply chain, and external validation.
Deployment Topology
- Multi-tenant SaaS — Deployed in your region. Tenant isolation enforced at the API and data layers.
- Hybrid Outpost (Enterprise) — Data plane runs in customer VPC or on-prem. Prompts and responses never leave customer infrastructure. SaaS control plane connects via outbound-only HTTPS — no inbound exposure.
- Air-gap Outpost — For fully disconnected networks: DLP inference runs locally via offline inference, policy packs are loaded offline, and audit logs are written to local storage. No data leaves the premises — no cloud calls, no telemetry egress, no external model APIs.
- Containerized: All services run as Docker containers. Helm charts available for Enterprise Hybrid Outpost deployments. Bare metal deployment available for air-gap environments.
- Scale-to-zero ready: Stateless gateway design supports scale-to-zero for cost-optimized deployments.
Network Controls
- WAF — Web Application Firewall on all public-facing endpoints. OWASP Top 10 rule sets active.
- DDoS protection — Layer 3/4 and Layer 7 DDoS protection. Automatic traffic scrubbing.
- Private peering — PrivateLink/VPC peering available for Hybrid Outpost. Control plane communicates via outbound-only HTTPS — no inbound ports required.
Secrets Management
- Secrets management — API keys, DB credentials, and signing keys stored in dedicated secrets backend. Azure Key Vault integration supported.
- No credentials in code — Pre-commit hooks block credential patterns. Periodic secret scanning via Trufflehog.
- No credentials in logs — Log sanitization pipeline strips credential patterns before write.
Supply Chain Security
- SBOM — Software Bill of Materials generated per release. Available to Enterprise customers on request.
- Trivy container scanning — Daily CVE scans of all container images. GitHub Actions CI/CD with automated security gates.
- Test coverage — Extensive automated test suite across backend and frontend. Docker E2E suite covers multi-provider, file upload, webhooks, and admin flows.
External Validation
- Penetration testing — Independent third-party penetration testing is part of our security program. Executive summaries available under NDA to Enterprise customers.
- Red team exercises — Periodic internal red team exercises targeting the gateway data path and admin surfaces.
- CVE disclosure process — Confirmed vulnerabilities receive a CVE identifier, a published advisory describing impact and affected versions, and a patched release. Customers are notified directly before public disclosure.
- Coordinated disclosure — [email protected]. Reports are acknowledged promptly, triaged by severity, and tracked to resolution.
Monitoring & Detection
- SIEM — All infrastructure logs aggregated, normalized, and correlated in real time.
- Anomaly detection — Alert rules on unusual access patterns, privilege escalation, and data volume anomalies.
- Engineering response — On-call escalation process. Incident response SLA available under Enterprise MSA.
Application Security
- OWASP LLM Top 10 — Hardened against the full OWASP LLM Top 10 threat model, including prompt injection and model denial-of-service.
- Input/output controls — Prompt injection defenses. SSRF protection. MIME-type validation. XSS protection. Credential scrubbing from LLM responses.
- Runtime controls — Per-endpoint rate limiting. Security headers enforced on all surfaces.
Session Integrity — Redis-Backed CSRF
- CSRF tokens are stored in Redis across all authentication flows — OAuth and SAML. If the session store is unavailable, requests fail closed. No in-process state that a single node failure could corrupt.
Access Control
Identity & access management
Every human and machine access point to Arbitex is governed by explicit controls.
Authentication
| Control | Implementation | Status |
|---|---|---|
| SSO | SAML 2.0 SP with Single Logout support (Team+). OIDC also supported. Verified integrations: Okta, Azure AD, Google Workspace. | OK |
| SCIM 2.0 | Automated user provisioning and deprovisioning (Enterprise). Syncs group membership to RBAC roles. | OK |
| SCIM per-org token rotation | Each organization's provisioning token is independently rotatable. Rotating one organization's token does not affect others — tenant isolation is enforced at the token level. | OK |
| MFA | TOTP-based with backup codes. Enforced for all human access to production infrastructure. | OK |
| WebAuthn / FIDO2 | Passwordless passkey authentication (Enterprise). Hardware security key support. | OK |
| API keys | Scoped keys for service-to-service auth. Each key is assigned granular permission scopes (read, write, admin) and a mandatory expiry date. Keys are displayed once at creation and never again — single-reveal only. No long-lived root keys. Key rotation with zero-downtime overlap supported. | OK |
| IP allowlisting | Per-tenant network restrictions (SMB and above). Restrict access to approved IP ranges. | OK |
| Session management | Active session monitoring and revocation. View and terminate all active sessions from the admin console. | OK |
RBAC Roles
| Role | Scope |
|---|---|
| Owner | Full account. Billing. Destroy. |
| Admin | Policies, users, integrations. |
| Analyst | Logs, dashboards, read-only config. |
| Read-only | Audit log access only. |
Admin Audit Trail
Every administrative action is logged with: actor identity, timestamp (UTC), source IP, action type, and a complete before/after change delta. Logs are immutable and cannot be deleted by any user, including Owner-role accounts.
Incident Response
When something goes wrong
Commitments are only useful when tested. These are our documented obligations, not aspirations.
EnterpriseIncident responseSLA terms defined in Enterprise MSA agreement.
24 hrBreach notificationCustomers notified within 24 hours of confirmed breach affecting their data.
5 daysPost-mortem publishedWithin 5 business days of incident resolution. Shared with affected customers.
Incident Severity Classification
| Severity | Name | Criteria | Response |
|---|---|---|---|
| P0 | Critical | Complete service outage, confirmed breach, data exfiltration in progress. | Immediate all-hands. Customer notification within 1 hour if data affected. |
| P1 | High | Significant degradation, security anomaly detected, partial outage. | On-call engaged promptly. Status page updated. |
| P2 | Medium | Performance degradation, non-critical feature unavailable. | Acknowledged within 2 hours during business hours. |
| P3 | Low | Minor issues, cosmetic bugs, non-impacting anomalies. | Triaged next business day. |
Responsible Disclosure
Found a vulnerability?
We operate a coordinated disclosure program. We take all reports seriously, respond promptly, and do not pursue legal action against good-faith researchers.
| Contact | [email protected] |
| PGP key | PGP public key — coming soon |
| Response | We aim to acknowledge reports promptly |
| Scope | All Arbitex-owned infrastructure. Excludes third-party services. |
| What we ask | Do not access or modify customer data. Do not perform DoS testing. Report before disclosure. |
| What we commit | Prompt response. Credit (if desired). No legal action for good-faith reports. |
Questions about our security posture?
Review our compliance documentation, request a DPA, or talk to our team about your specific requirements.