​

Security and data handling

This page explains what data Qodex accesses, where it lives, and the controls around it. It is aimed at the security review most teams run before adopting a testing tool.

​

What data Qodex touches

Qodex works with three kinds of data.

​

Source code access

GitHub. Qodex connects through the Qodex GitHub App and uses short-lived GitHub App installation tokens, not a personal access token. The App requests only the permissions review needs: Qodex cannot push arbitrary commits, change repository settings, or merge pull requests. Generated tests are written back to your repo only when you trigger the Sync to GitHub flow yourself. GitLab. Qodex connects to GitLab.com with OAuth or a token that carries the api scope, at the Maintainer role. Self-managed GitLab is not yet supported. Unlinking a project removes its association and drops the cached clone. When you unlink a repo, Qodex drops its cached clone. It does not delete your repository or uninstall the App.

​

Where your data is stored

Qodex separates relational data from files.

• Postgres holds product state: projects, users, scenarios, findings, runs, chats, and configuration.
• Blob storage holds artifacts created during testing: screenshots, videos, DOM snapshots, logs, and attachments.
• Secrets are encrypted at rest before they are written to Postgres. This covers BYOK provider keys, OAuth credentials, and sensitive auth values.

​

Keeping secrets out of saved content

Qodex is built to avoid capturing raw credentials into scenarios and findings:

• Auth values live in encrypted auth profiles and environment variables, referenced by name rather than pasted into a scenario.
• Evidence capture redacts sensitive values. See Prevent secrets in scenarios and findings.
• The MCP server never returns raw environment variables, bearer tokens, cookies, request or response bodies, headers, or logs to a connected coding agent. Protected evidence stays in the Qodex web app.

​

Testing your app safely

Per-environment constraints limit what a run may do against a target. You can mark an environment read-only, cap request rate, and gate destructive or active security payloads. Safe checks can run against production while heavier probes stay on staging. See Sensitive endpoints and read-only environments.

​

Where LLM calls go

By default, Qodex uses a platform-funded provider key for agent reasoning. With BYOK, a project routes its LLM calls through your own provider account instead, so provider billing and usage visibility stay on your side. Qodex takes zero margin on BYOK usage. Note that saved scenarios replay deterministically with no LLM call at all. The LLM is involved when a test is authored or repaired, not on every run, so most test traffic never reaches a model.

​

Self-hosting for full control

Self-hosted Qodex runs the entire stack inside your own infrastructure: one Docker image, your Postgres, your blob storage, and your provider key. Code, artifacts, and LLM traffic stay within your environment. Choose this when data residency, private networking, or an internal compliance requirement rules out a shared cloud.

​

Compliance status

The Scale (Automation) and Enterprise (PR Review) plans add SSO and SAML, role-based access control, audit logs, advanced security and compliance controls, data redaction, mTLS, and custom data retention. Specifics are scoped per engagement; talk to the team for what applies to your account.

​

Related