Security at Assert

• •Encryption in transit and at rest: TLS for every connection to Assert, and encrypted managed databases and object storage in production so customer code and metadata are protected at rest in our cloud environment.
• •Tenant isolation is built into how we store and serve data: strong boundaries between customers, least-privilege access inside our systems, and continuous monitoring of production.
• •Your code and review content are not used to train Assert's own models for general-purpose improvement. Third-party inference is governed by our zero-data-retention agreements with model providers — see Model and Inference Providers below.

Model-assisted features send only what is needed to complete a task. We maintain zero-data-retention (ZDR) agreements with every model provider we use today: they commit not to keep your prompts or outputs for model training or unrelated logging beyond what is required to return the API response. When our provider mix changes, we update subprocessors disclosures and hold new vendors to the same contractual standard.

Access:

• •For GitHub-backed repositories, Assert only fetches and shows content your GitHub user, app installation, or token can already access — repository access follows GitHub's permissions.
• •Production and customer data access is need-to-know and tied to role. We use role-based controls, require multi-factor authentication for administrative access, and follow least privilege.
• •Privileged access is reviewed on a cadence that matches risk.

Assurance:

• •We run recurring vulnerability assessments, engage independent firms for penetration testing on a cadence appropriate to our risk, and monitor production so anomalies show up early.
• •No security program is perfect; we combine tooling, review, and incident response to close gaps over time.
• •Security-relevant activity in production is logged for monitoring, troubleshooting, and incident response.

We run incidents with a clear playbook — detect, contain, recover, and learn — and when something may affect customers, we follow the notification commitments in our agreements and what the law requires. We maintain an inventory of critical third parties (including subprocessors such as hosting, models, and analytics), assess them before we rely on them, re-check material vendors on a schedule, and repeat risk assessments annually to close gaps between their security controls and ours, passing appropriate commitments through to customers where it matters.

We are undergoing a SOC 2 Type II examination with an independent auditing firm. For more information and to see a complete list of subprocessors, see our trust center. Separately, we regularly review how our program maps to other security and privacy expectations — including ISO 27001, ISO 42001, GDPR, and CCPA-style U.S. state privacy rules — so we can prioritize what matters for our customers and roadmap. Details of how we process personal data remain in our privacy policy.

Email security@assert.dev if you would like to report a security issue or need to reach us about Assert's security posture.