Last updated: May 17, 2026
Not A Number Labs Incorporated ("Chorus," "we," "us," "our") operates an information security program designed to identify, mitigate, and monitor risks to the confidentiality, integrity, and availability of customer data and our systems. This document describes the controls we operate today across the Chorus application, the agent runner platform, and supporting backend systems. Chorus is an early-stage company; this document describes what is operational, not what is aspirational.
Engineering leadership reviews material changes to our systems and to our threat model on an ongoing basis. Changes that introduce new risk include mitigations before they ship. Material incidents drive corresponding updates to this policy.
Our Chief Executive Officer is the executive owner of security at Chorus and is accountable for decisions about scope and investment. Day-to-day implementation is owned by engineering leadership.
Access to Chorus production systems is tied to named individual accounts. We use single sign-on with multi-factor authentication for our administrative consoles, source control, cloud provider accounts, and secrets store. Shared accounts are not used for production access.
Production access is granted on a need-to-know basis. Access is revoked promptly when personnel leave or change roles.
Customers authenticate to Chorus through Clerk, our identity provider. Customer sessions are bound to short-lived JWTs that are validated on every backend request. Embed surfaces that load inside the agent runner use scoped, single-purpose embed tokens issued by the backend rather than the customer's primary session.
All customer traffic to Chorus services is served over TLS, terminated by our cloud and edge providers. Calls between Chorus services and to third-party APIs use TLS.
Customer data stored in our managed Postgres database (Neon) and in object storage is encrypted at rest by the underlying provider.
Long-lived secrets — API keys, OAuth tokens, integration credentials — are stored in a managed secrets store and are not committed to source control. Production environment variables are injected at container startup from a managed configuration that is not part of the application source tree. When an agent's container starts, the credentials it needs are injected as environment variables; they are not written to a Chorus-managed durable disk for that agent. When the container exits, it is destroyed.
We collect only the personal information needed to operate the Services, as described in our Privacy Policy. We retain data only as long as necessary to provide the Services and meet legal obligations.
Each agent runs in its own dedicated runtime — a container with its own filesystem, network identity, and credentials. Agents do not share runtime state with one another.
Conversation transcripts, account metadata, and platform configuration are stored in our managed Postgres database (encrypted at rest, access-controlled). Per-agent runtime state — the agent's working filesystem, browser session, and ephemeral working files — lives on the agent's runtime and is destroyed when the runtime is torn down.
Agent calls to third-party APIs are mediated by an authenticated proxy (proxy.chorus.com) that injects credentials per request, so individual agent runtimes do not hold long-lived API keys for those services.
All changes to production systems are made through version-controlled pull requests reviewed before merge. Deployments to production are shipped via automated workflows from the main branch.
The Chorus codebase is written in TypeScript under strict compiler settings. Code review is required for every change. We maintain an automated test suite covering authentication, integration handlers, and agent lifecycle.
Third-party dependencies are pinned via lockfile and production builds are reproducible from source control.
Chorus runs on commercial cloud infrastructure providers whose data centers maintain controls including 24/7 staffing, multi-factor physical access controls, video surveillance, and environmental protections. We rely on these providers' published attestations (SOC 2, ISO 27001) for physical-layer assurance.
Workforce laptops are required to use full-disk encryption and screen lock.
Application logs from production services are collected and queryable by engineering. Security-relevant events — authentication failures, infrastructure changes, anomalous errors — are surfaced to engineering.
If we identify a security incident, the engineering team triages, contains, and remediates it. If a confirmed incident affects customer data, we will notify affected customers without undue delay and in accordance with applicable law. We document material incidents and the corrective actions taken.
We welcome reports of suspected vulnerabilities from researchers and customers. Please contact us at support@chorus.com. We will acknowledge receipt and investigate in good faith.
Our production database is backed up by the managed provider. Application services are deployed from version-controlled source and can be rebuilt deterministically.
This policy is reviewed when we ship material changes to our systems, our threat model, or applicable law. The "Last updated" date at the top of this page indicates the most recent revision.
For security questions or vulnerability reports, please contact:
Not A Number Labs Incorporated Email: support@chorus.com