ARA runs on your infrastructure. Your data never leaves your perimeter. This page is an honest account of our current security posture, not a marketing document.
ARA runs entirely within your infrastructure. Decision data is persisted to local or network storage you control. There is no ARA cloud, no data lake, no telemetry pipeline that processes your entity data or feature values.
Community Edition does not currently encrypt data at rest. ARA persists decision state to local storage in its internal binary format. Encryption at rest is planned for a future Enterprise release. Use OS-level disk encryption (e.g., LUKS, dm-crypt) if your environment requires it.
Community Edition communicates over an unencrypted binary protocol (FlatBuffers over TCP) on ports 50051-50055. TLS termination can be added in front with a reverse proxy. TLS/mTLS on the data plane is planned for a future release.
Community Edition uses machine-based activation. There is no per-request authentication on the binary protocol - ARA is designed to run inside your trusted network perimeter. RBAC and SSO integration are planned for a future Enterprise release. Until then, network-level access control (firewall rules, private subnets) is the recommended perimeter.
Anonymous usage telemetry is on by default. It collects version, license tier, worker count, ops-rate ranges, uptime, and crash reports only - never entity IDs, feature values, or decision outputs. As of 1 July 2026 it is written to local stdout and an optional local log file only; no external transmission occurs. Disable anytime with ARA_TELEMETRY_DISABLE=1. This is disclosed in the EULA.
The decision log is append-only by design. Snapshots are written into sealed storage chunks, never modified after rotation, and each chunk carries a SHA-256 chained to the one before it - tampering with any sealed chunk breaks the chain from that point forward and is detectable. The guarantee is at chunk granularity (many entities/snapshots per chunk), not per individual snapshot. OS-level file integrity monitoring (e.g., auditd, inotify) is a useful additional control on top of this.
Each download is patched with your own license key, so it's a unique file rather than a copy of one generically published binary - there's no single checksum to publish per release. Its SHA-256 is computed client-side and shown on the confirmation page immediately after your download completes; verify with shasum -a 256 <downloaded-file> against that value.
We operate a responsible disclosure programme. Report vulnerabilities to security@aralabs.ai. We acknowledge reports within 48 hours, prioritise fixes by severity, and keep the reporter informed through assessment and remediation.
We respond to security inquiries within 48 hours. For regulated customers requiring a Data Processing Agreement (DPA) or penetration test approval, use the form and specify your requirement.
We acknowledge all security inquiries within 48 hours.