Skip to main content

​
How do I keep secrets from leaking into scenarios and findings?

Do not put secrets directly in scenarios, chats, findings, memory, or docs. Store credentials in environments and auth profiles, then reference them with variables. Qodex substitutes the real values only when a test runs.

​
Use variables in scenarios

Use variables such as ${API_BASE_URL}, ${AUTH_TOKEN}, ${AUTH_EMAIL}, and ${AUTH_PASSWORD} instead of literal credentials. 
{
  "method": "POST",
  "target": "${API_BASE_URL}/login",
  "body": {
    "email": "${AUTH_EMAIL}",
    "password": "${AUTH_PASSWORD}"
  }
}
The saved scenario stays portable and does not contain the secret value.

​
Store credentials in the right place

Use:
  • Environments for base URLs and target-specific values.
  • Auth profiles for login credentials, tokens, and OAuth details.
  • BYOK settings for provider API keys.
Sensitive values are encrypted at rest before persistence. In the UI, saved secrets should appear masked instead of plaintext.

​
Redaction is a safety net

Qodex redacts common secret shapes from captured evidence, including bearer tokens, JWT-like strings, GitHub tokens, AWS-style keys, and high-entropy values. Redaction helps when a response accidentally echoes a secret. It should not be your first line of defense.

​
Avoid secrets in these places

  • Scenario JSON.
  • Finding titles or descriptions.
  • Chat messages.
  • Memory files.
  • Documentation examples.
  • PR comments.

​
Self-hosted note

In self-hosted deployments, encrypted credentials depend on QODECLAW_SECRET_KEY. If you lose that key, encrypted secrets cannot be recovered and must be re-entered.

​
Next steps

Secret management

Understand encryption at rest.

Auth profiles

Store reusable login credentials.

Environment variables

Configure self-hosted secrets safely.

Sensitive endpoints

Handle risky routes carefully.