Security Practices

Security Model

ARX is the control plane for enterprise AI. The security model is written for defense, financial services, and healthcare first. If a control does not meet that bar, it does not ship. Zero trust, FIPS 140-3 via aws-lc-rs (CMVP 4631), CMEK on every storage layer, per-tenant isolation. PQC roadmap to ML-KEM-1024 and ML-DSA-87 per CNSA 2.0.

Infrastructure Security

Cloud-Agnostic Architecture

ARX deploys cloud-agnostic. Production runs in the customer’s cloud of choice (AWS, GCP, or Azure) via Helm charts and Terraform adapters per cloud. The data, the keys, and the audit trail stay inside the customer perimeter. ARX runs the control plane; the customer runs the substrate.

• Compute: Containerized services deployed via Helm to the customer’s Kubernetes (EKS / GKE / AKS) or managed runtime (Cloud Run / Container Apps). Per-tenant isolation at the workload boundary.
• Database: Customer-managed Postgres 16 + pgvector with HNSW indexing. AWS RDS, GCP AlloyDB, or Azure Database for PostgreSQL Flex. Encryption at rest via the customer’s KMS.
• Cache: Customer-managed Redis (AWS ElastiCache, GCP Memorystore, or Azure Cache for Redis).
• AI/ML providers: Provider-agnostic router across Anthropic, OpenAI, Google Vertex, Mistral, and Groq. The router is constrained by per-call policy; no model traffic leaves the route the customer authorized.
• Edge security: Cloudflare Business in front of the public surfaces with managed WAF, DNSSEC, DDoS protection, bot management, and rate limiting.

Network Security

• TLS 1.2 RESTRICTED baseline for all data in transit, with strong cipher suites only.
• Internal service-to-service communication uses mutual TLS (mTLS).
• Per-cloud VPC isolation with default-deny egress and explicit allowlists.
• WAF rules cover the OWASP Top 10 plus rate limiting and bot detection at the edge.
• Geo-blocking and jurisdictional routing available for customers with restricted-country requirements.

Data Protection

Customer data, customer keys, customer perimeter. Every layer of the data path is encrypted with customer-managed keys, and ARX never holds material the customer would not authorize an auditor to inspect.

Encryption

• In transit: TLS 1.2 RESTRICTED for all external connections; mTLS for internal services.
• At rest: AES-256-GCM for all stored data. Customer-managed encryption keys (CMEK) on every storage layer via the customer’s KMS (AWS KMS, GCP KMS, or Azure Key Vault).
• Cryptographic module: FIPS 140-3 process-wide via aws-lc-rs (CMVP certificate #4631). AES-256-GCM, SHA-3, HKDF-SHA-256. Post-quantum migration roadmap to ML-KEM-1024 and ML-DSA-87 per CNSA 2.0 (January 2027 deadline).
• Secrets management: Per-cloud secret manager (AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault). Per-service IAM bindings; no shared service accounts.

Data Isolation

• Logical tenant isolation ensures customer data is segregated at the application layer
• Enterprise customers may request dedicated infrastructure for additional isolation
• No customer data is used for model training without explicit, documented consent

Data Retention and Deletion

• Data retention periods are defined by service tier and documented in our Privacy Policy
• Customer data is deleted within 30 days of account termination unless legally required to retain
• Deletion requests are processed and verified with written certification available upon request

Access Controls

Authorization is deterministic, version-controlled, and re-verifiable without rerunning the model. Every request passes through the same policy engine; no shadow paths.

• Authentication: OIDC-compliant SSO with SAML 2.0 / OAuth 2.0, plus SCIM provisioning and MFA enforcement. Defense-track customers may require CAC/PIV.
• Authorization: Policy-as-code evaluated on every request. Deterministic authorization with auditable policy decisions; no opaque heuristics.
• RBAC and tenancy: Granular role-based access with per-tenant isolation. Org and team hierarchies enforced through the same policy engine.
• Principle of least privilege: Internal access restricted to the minimum necessary; admin access is MFA-gated and logged.
• Session management: Server-side signed sessions with configurable expiry, automatic timeout, and revocation.

Application Security

Security review is part of the development lifecycle, not a stage at the end. The dependencies are scanned, the inputs are validated, the boundaries are tested.

• Secure Development: Security reviews are integrated into our development lifecycle
• Dependency Management: Automated vulnerability scanning for all dependencies
• Input Validation: All user inputs are validated and sanitized to prevent injection attacks
• CSRF Protection: Cross-site request forgery tokens on all state-changing operations
• Content Security Policy: Strict CSP headers to mitigate XSS attacks
• API Security: Rate limiting, authentication, and input validation on all API endpoints

Monitoring and Incident Response

The audit trail is the runtime, not a parallel reconstruction. When something goes wrong, the evidence is already there; recovery is engineered, not improvised.

Observability

• OpenTelemetry instrumentation across the gateway, with dashboards and alerts deployed per-cloud via Terraform.
• Append-only audit log via CloudEvents v1.0; 21 event types; Blake3 hash chain; cryptographically signed fidelity certificates.
• SIEM integration: Microsoft Sentinel as default; AWS Security Hub or GCP Security Command Center optional per customer.
• Anomaly detection on access patterns and on cost-attribution outliers; alerts route to the customer’s on-call.

Incident Response

• Documented incident response plan with defined severity levels and escalation paths
• Security incidents are triaged, investigated, and remediated with root cause analysis
• Affected customers are notified within 72 hours of a confirmed data breach, in compliance with GDPR and applicable state breach notification laws
• Post-incident reviews are conducted to identify and implement preventive measures

Compliance and Certifications

Responsible Disclosure

We welcome security researchers to responsibly report vulnerabilities. If you discover a security issue, please contact us:

We ask that you act in good faith, avoid accessing or modifying other users’ data, and give us a reasonable opportunity to address the issue before public disclosure.