Trust

Security at Arc Labs.

An honest snapshot of where we are. Each section labeled shipped, in progress, or planned. We update this page as our posture changes.

Last updated: 2026-05-02

Overview

In progress

Brain is open source and pre-release (v0.1). Today it ships self-hosted: you run the Brain server — a single Rust binary with its built-in storage engine, no external database to operate. A managed cloud (where we would operate the infrastructure on your behalf) is planned but not yet available; there are no external users or live production infrastructure at this stage. Sections below marked planned describe the intended posture of that forthcoming managed offering rather than a service running today.

We design memory systems to handle data we'd be uncomfortable losing or leaking, and this page describes the architecture we're building toward — labeled honestly by what's shipped versus intended.

Encryption

Planned

In transit. This site is served over TLS. The planned managed cloud will require TLS 1.3 on all API endpoints, with HSTS on production domains and mTLS as an option for enterprise deployments.

At rest. The managed cloud is designed to encrypt database storage with AES-256-GCM at the volume layer and to encrypt backups with separate keys, rotated on a fixed schedule. This is the intended design, not yet an operating service.

Embeddings and metadata are treated identically — both are user-derived data and are intended to be encrypted the same way.

Tenant isolation

Shipped

Multi-tenant deployments enforce per-(namespace, agent) isolation in the storage engine across every layer — memory, entity, statement, relation, and index — and at the query layer (every memory query must include a scope; queries without scope are rejected at the API).

For higher-isolation workloads, the planned managed cloud intends to offer dedicated-cluster deployment — one Brain instance per customer, one HNSW index per customer. (Self-hosting already gives you a single-tenant instance today.)

Key management

Planned

The planned managed cloud is designed to hold production keys in a managed KMS (the specific provider will be chosen when the cloud is built), so application code never sees raw key material and envelope encryption protects tenant-scoped data keys.

For self-hosted deployments, we document key handling but do not manage keys on your behalf.

Data handling & deletion

In progress

Deletion is hard-delete by default. When a user or tenant requests deletion, the engine removes memories from primary storage and all secondary indexes (vector, lexical, graph). The audit ledger retains a tombstone (memory ID, deletion timestamp, requester) but not memory content. This hard-delete + tombstone model is implemented in the engine today.

PII minimization. Automatic detection and dropping of sensitive identifiers (e.g. SSN, payment-card numbers) at write time is a planned pipeline feature, not yet implemented.

Data residency. Region selection (e.g. US, EU, or India) and opt-in cross-region data movement are planned for the forthcoming managed cloud.

Compliance & certifications

In progress

SOC 2 Type II: in progress — audit window opens Q3 2026, expected completion Q1 2027. We will share the report under NDA on request.

GDPR: our managed cloud is structured to support GDPR data subject rights (access, erasure, portability) via the Brain API. A standard DPA template is available.

HIPAA: not currently supported. Contact us if your deployment would require HIPAA compliance — we can scope a path forward.

ISO 27001: planned for 2027 once SOC 2 Type II completes.

Dependency security

In progress

We run dependency scans in CI (cargo-audit on the Rust core, with npm audit and pip-audit for the SDKs). We aim to patch critical and high CVEs quickly and to keep dependencies current; we haven't yet established a formal patch-time SLA.

We pin transitive dependencies and review every new direct dependency against a minimal list of allowed crates / packages.

Vulnerability disclosure

Shipped

We follow a responsible disclosure process. To report a vulnerability, email security@arc-labs.ai with details. We aim to acknowledge reports within 24 hours and to ship a fix within 14 days for critical issues.

We do not currently run a paid bug bounty program. We do credit reporters in release notes (with permission).

Incident response

Planned

We are establishing an incident response runbook covering detection, containment, eradication, recovery, and post-mortem. Once the managed cloud is operating, the intended policy is to:

  • Notify affected customers within 24 hours of a confirmed incident.
  • Publish a post-mortem within 14 days for incidents affecting multiple customers.
  • Run periodic tabletop exercises to test the runbook once the service is live.

Security contact

Shipped

Security questions, vulnerability reports, or compliance requests:

Updates from the lab.

Engineering notes, research drops, occasional product updates. Roughly monthly.