How Trace Handles Your Data

A penetration test gives Trace access to some of the most sensitive data your engineering org has, your source code and, when you connect it, your cloud configuration. This page covers the protections Trace applies to that data.

To request compliance attestations, audit reports, and policies, use our Trust Center.

Core principles

• Your code is treated as sensitive. Source code is the most sensitive asset most engineering teams have. Trace works with it only for the duration of an engagement and never repurposes it for anything else.
• Customer data is never used to train models. Trace's contracts with our LLM providers prohibit training on customer content, and the models we use are configured for zero data retention.
• Least privilege everywhere. From the GitHub App permissions Trace requests to the cross-account roles you grant for cloud integrations, every credential is scoped to the minimum surface needed to do the work.
• Encryption end-to-end. All data is encrypted in transit (TLS 1.2+) and at rest, and secrets and credentials are stored in a managed secret store with restricted access.
• Org-scoped isolation. Every customer's data lives behind an organization boundary enforced at the database layer, not just the application layer. Trace cannot accidentally show one customer another customer's findings.

Source code during an engagement

Trace clones your repository into an isolated, ephemeral environment for the duration of a penetration test and destroys it afterwards. We don't retain a standing copy of your source. What persists is the engagement output (the findings, the report, and any reproduction artifacts captured during testing), with just enough code context (a small snippet at the affected location) to make each finding actionable, never your full source.

When you've connected a cloud integration (AWS or Vercel), an engagement may use that read-only access to understand how the application is actually deployed. That access stays read-only and short-lived, scoped to the engagement and never used to modify your cloud.

Credentials you provide

To test an authenticated application, Trace needs credentials for the environment under test. These are stored in a managed secret store with restricted access, and are never written to logs, notifications, or audit trails. They're scoped to the environment you attach them to and used only to authenticate during an engagement.

Cloud data

For cloud integrations (AWS, Vercel), Trace inventories your resources and relationships using read-only access. We can list and describe; we cannot modify. Sensitive resource details are summarized and sanitized before being persisted; Trace doesn't warehouse raw provider responses.

How connections are established. AWS uses a cross-account IAM role you create from a CloudFormation template Trace generates, scoped to an external ID unique to your organization, so only Trace can assume it, and auditable before you deploy. Vercel uses its native integration framework, where you grant Trace read-only scopes. Disconnecting revokes Trace's access, and the inventory we built is deleted after a short grace period. See AWS and Vercel for the full setup.

Access on Trace's side

Internal access to customer data is restricted and audited. Trace engineers can access customer data only when required for troubleshooting, only with the customer's permission for anything beyond aggregate diagnostics, and every access is logged. The full access policy and the audit controls behind it are documented, and you can request both through the Trust Center.

Compliance posture

Trace's compliance status, certifications, audit reports, subprocessor list, and policies are available on request through our Trust Center. Tell us which documents you need and our team will follow up directly, including for NDA-gated artifacts.

Privacy and legal

For privacy policy, terms of service, and data-processing agreements:

• Privacy Policy
• Terms of Service
• DPAs and subprocessor lists are available through the Trust Center.