Security & data handling
What we can read, keep, and never do.
You're handing an audit tool your unreleased contracts — you deserve the exact mechanics, not a reassurance. Everything below is a description of how the system is built, in the same plain terms we'd want from a vendor.
What we can read (and what we can't)
- Signing in reads your identity, never your code
- GitHub sign-in requests read:user and user:email — nothing else. Google sign-in requests openid, email, profile. Neither can see a single repository.
- Repository access is a separate, explicit step
- Code access goes through a GitHub App installation you trigger yourself after signing in, on the repositories you select — with read-only permissions (contents and metadata). No write access, ever.
- Access tokens are short-lived
- The audit worker fetches your repository with a short-lived installation token generated on demand for that run.
Your code's lifecycle
- During the audit
- Your repository is cloned at the pinned commit into an ephemeral, isolated job container. When the run ends — success or failure — the working clone is deleted and the container is destroyed.
- What we keep, and why
- After a completed audit we retain the audit artifacts in a private storage bucket: the findings with their evidence (including the relevant code snippets), the architecture artifacts, the report — and a snapshot of the audited source, so your report's evidence and future re-audit diffs keep resolving. Nothing about your audit is public unless you create a share link.
- Access control
- The storage bucket is private with uniform access control — no public access. Report and evidence downloads go through short-lived signed URLs (hours, not days).
- Deletion on request
- Want an audit's artifacts — including the source snapshot — gone? Message us in the chat and we'll delete them. Deleting the snapshot means that report's evidence links stop resolving; that's the trade, stated up front.
Which models see your code
- Which providers see your code
- A standard audit sends code to the commercial APIs of Cursor (Composer), Anthropic (Claude), and OpenAI. That list is current as of this page's last update; if it changes, this page changes.
- No training on your code
- Guardix does not train models on your code, and we call the providers above through their standard commercial APIs — not consumer products — solely to run the analysis.
Questions we haven't answered here
Organization-specific requirements — retention windows, a data-processing agreement, where your artifacts physically live — deserve a direct answer, not boilerplate. Message us in the chat (bottom-right corner); it reaches the founders directly.