What we do with your code, and what we do not.
Last updated 29 September 2026
This page describes how TraceGuard processes customer data in technical terms rather than legal boilerplate. If your security team needs a formal Data Processing Agreement, ask and we will sign one.
1. Two ways to run it
TraceGuard runs in one of two modes, chosen per repository. What we can see depends on the mode, so this page describes both.
- In your CI (the default for pilots). The check runs on your own CI runner. The diff is computed there from your checkout and sent only to the model endpoint you configure: your own Anthropic account, Azure OpenAI, or a model you host. Your source code never reaches TraceGuard. Section 2.
- With the GitHub App. Our server reads the diff of each change with read-only access and sends it to our language model provider for analysis. Sections 3 and 4.
2. In your CI: what reaches us
Nothing, unless you turn on the pilot dashboard. If you do, the runner sends one report per run over HTTPS, authenticated with a delivery token that you create in your portal and can revoke at any moment. We store only a hash of that token, never the token itself.
By default that report is a summary: the repository name and commit identifiers, the version of your rule document, the model used, the verdict and, for each finding, the rule ID and title, the file path, the line number and the severity. It carries the SHA-256 of the full report, which stays in your CI, so anything shown in your dashboard can be matched against it later. It contains no code, no quoted evidence and no model reasoning about your code.
If you choose to share full reports instead, they also carry the quoted evidence and the reasoning. That evidence is handled exactly like evidence in App mode: kept for the window you set, then deleted (section 3).
The check itself ships as a single JavaScript file with no dependencies, published with its SHA-256, so your security team can read what runs on your runner and pin that exact version.
3. With the GitHub App: source code handling
In this mode TraceGuard is a pipeline, not a repository. When a commit is pushed, the system requests the diff of that change from your Git provider, holds it in memory for the duration of the analysis, and discards it when the analysis completes. We do not clone, mirror or store your repository. Full file contents are not persisted at any point.
One thing is deliberately retained: the specific fragment of the diff that supports a finding. A compliance ticket claiming that a rule was breached without showing the line that breached it is worthless to an auditor, and inventing that evidence later would be worse. So the quoted fragment is stored alongside the verdict, and nothing else is.
That retention window is yours to set. After it expires, the evidence is deleted and the audit trail survives without it: which change was evaluated, against which version of your rule document, what was decided and when. If you prefer no retention beyond the open ticket, that is a configuration value, not a special arrangement.
Commit diffs are transmitted to our language model provider for analysis under a commercial agreement. Your code is never used to train models.
4. Repository access
In CI mode we get no access to your repository at all: the job runs with your own CI credentials and needs contents: read and nothing else.
The GitHub App requests the minimum permissions the product needs:
- Contents: read-only, to read the diff of a change and the files it touches at that revision, including your rule document.
- Issues: read and write, to open a ticket and annotate existing ones. Not needed at all if findings go to your own Jira instead.
No organisation-wide access, no administration permissions, no write access to code, no ability to create branches or pull requests. The App is installed only on the repositories you select, and each customer operates with an installation token issued by GitHub for their own installation, so isolation between customers is enforced by GitHub, not by our code.
You can uninstall the App from your organisation settings at any moment, without notifying us and without our cooperation.
5. Data residency and storage
All our infrastructure runs inside the European Union. Application compute is hosted on Vercel in the Frankfurt region (eu-central); the database is hosted on Supabase, also in Frankfurt. The database is not replicated outside the EU. In CI mode your code stays wherever your runner and your model endpoint are. In App mode, diff content sent to our language model provider for analysis (section 3) may be processed outside the EU under that provider's commercial terms.
Database isolation is enforced at the engine level: row-level security is enabled with no policies on every operational table, so the tables are unreachable by anything other than the server's own service credentials. Every record carries the identity of the customer it belongs to.
Customer credentials, such as a Jira API token, are encrypted with AES-256-GCM before they reach the database, using a key derived per secret and held in the server environment. The database never sees plaintext, including in a backup.
6. Your team's portal
People from your team sign in to their portal with a one-time link sent by email; there are no passwords. For each person we store the email address, a name if you give one, their role (viewer or approver) and when they last signed in. You decide who has access, and access can be removed at any moment.
Decisions recorded on findings (fixed in which commit, risk accepted with a reason, or false positive) are append-only: a new decision supersedes the previous one and both stay on record, with who made them and when. That history is what the release report is built from.
7. Offboarding
If you stop using TraceGuard, your complete analysis history is exported and handed to you, then deleted in a single cascading transaction covering the account, its repositories, its delivery tokens, its encrypted credentials and its records. We will show you the exact statement that performs it before running it.
8. Cookies on this website
This page sets no cookies at all. There are no analytics, no third-party trackers, no advertising pixels, no session recording and no fingerprinting scripts. The page loads no external resources of any kind: no fonts, no stylesheets, no scripts from other domains.
If you submit the contact form, the details you type are transmitted to our server and stored so that a person can reply. That is the only data this site collects, and only when you choose to send it.
The product dashboard and your team's portal, which are not part of this website and are reachable only after signing in, each set a single HttpOnly session cookie required for authentication. They carry no tracking information.
9. Your rights
Under the GDPR you may request access to, correction of, or deletion of personal data we hold, and you may object to its processing. Write to diego.macias@traceguard.eu and we will respond within thirty days. In the contractual relationship, the customer is the data controller and TraceGuard is the processor.
10. What this page is not
TraceGuard supports the detection of engineering changes that affect regulatory requirements. It does not certify conformity: that is assessed by the manufacturer or, where the law requires it, by a notified body. No system connected to the internet is impenetrable, and we will not claim otherwise. We will tell you which attack vectors we have closed and which remain open, before you ask.