> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Security and data handling

> What data Qodex touches, where it is stored, how credentials are protected, and how BYOK and self-hosting change where your data and LLM calls go.

# 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.

| Data                        | When Qodex sees it                    | How it is used                                                                                   |
| --------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Repository code             | When you link a GitHub or GitLab repo | Cloned and analyzed to power PR review and to seed project memory with routes and structure.     |
| Your running app            | When a test or review runs            | Qodex calls your API and drives a real Chromium browser against the environment you point it at. |
| Test credentials and config | When you save an environment          | Base URLs, API keys, and auth profiles used to reach the app under test.                         |

## 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:

| Permission          | Why                                               |
| ------------------- | ------------------------------------------------- |
| Contents read       | Clone and inspect files.                          |
| Metadata read       | List and identify repositories.                   |
| Pull requests write | Post the walkthrough comment and inline findings. |
| Checks write        | Publish the Check Run used for merge gating.      |

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](/docs/syncing-tests-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](/docs/kb-avoiding-secret-leaks).
* The [MCP](/docs/integrations-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](/docs/security-testing-sensitive-endpoints).

## Where LLM calls go

By default, Qodex uses a platform-funded provider key for agent reasoning. With [BYOK](/docs/integrations-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](/docs/self-hosted) 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

<Note>
  For the current status of SOC 2 and other certifications, and for a data processing agreement, contact [sales@qodex.ai](mailto:sales@qodex.ai). This page does not assert a certification.
</Note>

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

<CardGroup cols={2}>
  <Card title="GitHub integration" icon="git-branch" href="/docs/integrations-github">
    App scopes, tokens, and what Qodex can and cannot do.
  </Card>

  <Card title="BYOK" icon="key" href="/docs/integrations-byok">
    Route LLM calls through your own provider account.
  </Card>

  <Card title="Self-hosted" icon="server" href="/docs/self-hosted">
    Keep everything inside your own infrastructure.
  </Card>

  <Card title="Prevent secret leaks" icon="lock" href="/docs/kb-avoiding-secret-leaks">
    How credentials stay out of saved content.
  </Card>
</CardGroup>
