● Trust
Trust center
Trevo writes code into your repository, so the sensible first question is what it can and cannot reach. Everything a security reviewer needs is on this page: the access model, the branch policy, what happens to your code after it is read, how long data is kept, and who on your team is allowed to approve a change. Last reviewed September 10, 2026.
The footprint, in two lists
Trevo is an agent with commit access to branches and nothing else. That boundary is enforced by the GitHub App’s permissions, not by our good intentions.
✓ What Trevo can do
Read the repositories you pick
Through a GitHub App you install and can revoke, scoped with GitHub’s “only select repositories” option.
Open pull requests on trevo/* branches
One PR to run an experiment, one to clean it up. Both go through your existing review.
Measure what you instrument
Exposure and conversion events from the Trevo SDK, or metrics from an analytics project you connect.
✕ What Trevo cannot do
Push to your default branch
Writes are confined to trevo/* branches. Your own branch protection enforces the same rule independently.
Merge or deploy anything
Trevo cannot merge its own pull requests and has no access to your deployment pipeline.
Hold a lasting copy of your repository
Reads run against a temporary clone that is discarded when the run ends. What persists is a structural analysis of routes, components and the events they fire — removed when you disconnect the repository.
Code access
Trevo reaches your code through a GitHub App you install into your own organization. It requests read access to the repositories you select and the ability to open branches and pull requests — nothing else. Scope it to a single repository during installation, and revoke it from GitHub at any time without contacting us. Analysis runs against a temporary clone that is discarded when the run finishes. What is stored afterward is a structural snapshot — the routes, components, and events the analysis found, keyed to the commit it read — plus the artifacts you can see: proposals in the dashboard and pull requests in your repository. Before a pull request is opened, a secret-scanning step blocks credentials and tokens from being written into it.
Branch policy
Every change Trevo makes lands on a trevo/* branch as a pull request with the agent’s name on the commit. It cannot write to your default branch and cannot merge its own work. An experiment arrives as one pull request and is removed by another when the experiment concludes — whether the variant won or lost. Your review is the only thing that moves code toward production, which means the same controls you already trust for human contributors apply here unchanged.
AI processing, and what is never used for training
Repository snapshots and analyzed pages are processed by large language models to produce observations, experiment proposals, and variant code. We send providers only what the analysis needs, under agreements that prohibit them from training on it. Your repository contents and your event data are never used to train machine-learning models — ours or anyone else’s. The current model provider is named in our privacy policy, and a full subprocessor list is available on request.
Data retention and deletion
Account and workspace data are kept while your account is active. Repository snapshots are refreshed as your code changes and removed when you disconnect the repository or delete the workspace. Event data is kept while the workspace is active so long-running experiments stay measurable. When you delete data or close your account, records are flagged as deleted immediately, purged from production systems on a scheduled basis, and then age out of backups. The one deliberate exception is the append-only record of who approved, shipped, and dismissed what: it is retained as an accountability measure, because a decision log you can edit is not a decision log.
Who is allowed to approve a change
Approving an experiment is the action that sends code toward your repository, so it is permission-gated rather than open to anyone with a login. Every member holds a role — owner, admin, developer, or member — and you can define custom roles from a catalog of individual permissions. Reviewing proposals and deciding a finished experiment are separate permissions, so approving an experiment and calling its winner can be held by different people. A member with no permissions granted can read the workspace and change nothing.
The audit trail
Every approval, dismissal, and ship-or-reject decision is written to an append-only audit log with the actor, the entity, and the timestamp — alongside the automated actions the agent takes on your behalf. The experiment page names who approved and who decided, and the whole trail can be read through the API or exported as CSV for an evidence pack. Audit rows are never edited or soft-deleted, and are scoped per workspace.
Tenant isolation and keys
Every query against customer data is scoped by workspace; a workspace is the data boundary, and an organization owns billing and membership above it. SDK keys are issued per workspace, stored only as SHA-256 hashes, validated on every ingestion request, and revocable from the dashboard. Dashboard sessions and keys are separate credentials with separate reach: an SDK key can send events to its workspace and fetch that workspace’s experiment configuration — the variant names and traffic splits the browser client needs — and can reach no dashboard data, no code, and no other workspace.
Infrastructure and security practices
Data is encrypted in transit. Access to production systems is restricted, logged, and scoped to what operating the service requires. We operate from the United States and process data there and in the regions our infrastructure providers use; subprocessors are bound by data protection terms, and transfers from the EEA, UK, and Switzerland rely on standard contractual clauses. If we learn of a breach affecting your data, we will notify you without undue delay.
Compliance status
We are not SOC 2 certified today, and we do not display a badge we have not earned. The Type II audit is planned to begin at general availability, and we will report its status here as it progresses rather than in a sales conversation. What exists now is what this page describes: a narrow, revocable GitHub App footprint, permission-gated approvals, an append-only audit trail you can export, and a privacy policy and terms that say the same things in contractual language. A data processing addendum and a subprocessor list are available on request.
Reporting a vulnerability
Send security reports to hello@trevosdk.com. We acknowledge reports and will keep you updated through remediation. If you are evaluating Trevo and need something this page does not cover — a security questionnaire, the subprocessor list, the DPA — ask, and we will send it rather than schedule a call about it.
Send this page to your security team.
If they come back with a question this page does not answer, we would rather fix the page than answer it once in an email.