> ## 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.
# Sensitive endpoints
> Use environment constraints to control where Qodex can run destructive, invasive, or high-volume security tests.
# Sensitive endpoints
Security tests can be powerful. Some probes are safe to run almost anywhere, such as header checks. Others can create data, send attack payloads, or generate traffic bursts. Sensitive endpoint controls tell Qodex what it is allowed to do in each environment.
Use these controls to keep production safe while still getting meaningful security coverage in staging or preview environments.
## The three environment constraints
Each environment can define three constraints:
| Constraint | What it controls |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `read_only` | Blocks write verbs such as POST, PUT, PATCH, and DELETE when set to `true`. |
| `max_requests_per_second` | Caps how fast Qodex can send requests during a run. |
| `allow_destructive_tests` | Blocks destructive payloads such as data deletion, destructive SQL payloads, or account deactivation when set to `false`. |
The constraints combine. For example, a production environment can be read-only, rate-limited, and destructive-test disabled. A dedicated QA environment can allow broader probes.
## Example configuration
```json theme={null}
{
"name": "production",
"hosts": {
"api": "https://api.example.com",
"ui": "https://app.example.com"
},
"variables": {
"AUTH_EMAIL": "qa-bot@example.com"
},
"readOnly": true,
"maxRequestsPerSecond": 5,
"allowDestructiveTests": false
}
```
Qodex reads these settings before authoring and before execution. If a planned probe violates the environment, the agent skips it or rewrites it to the safe subset.
## Recommended defaults
| Environment | `read_only` | `max_requests_per_second` | `allow_destructive_tests` |
| ---------------------------- | ----------- | ------------------------- | ------------------------- |
| Production | `true` | `5` | `false` |
| Staging mirror of production | `true` | `5` | `false` |
| Dedicated QA staging | `false` | `20` | `true` |
| Local development | `false` | `50` | `true` |
| Preview deployment | `false` | `20` | `true` |
Production should usually receive safe checks such as security-header audits, cookie audits, TLS checks, and read-only authorization probes. Write-side IDOR, mass assignment, injection, and high-volume rate-limit tests belong on staging or preview environments.
## What happens when a probe is blocked
When constraints block a probe, Qodex handles it in one of three ways:
| Outcome | What Qodex does |
| ----------------------- | ----------------------------------------------------------- |
| Probe is allowed | Authors and runs the scenario normally. |
| Probe is partly allowed | Keeps the safe steps and skips unsafe steps. |
| Probe is fully blocked | Skips the scenario and notes the reason in the run summary. |
For example, on a `read_only: true` environment, a BOLA check can still test `GET /api/orders/{id}` with the wrong user token, but Qodex should skip the PUT and DELETE versions.
The runner also enforces rate limits, so a manually authored scenario cannot bypass the configured request ceiling.
## Checking constraints in chat
Before running a security sweep, you can ask:
```text theme={null}
What constraints are set on the production environment?
```
Qodex will report the active environment flags so you can decide whether to run the check there or switch to a less restricted target.
## When to tighten constraints
* The environment points to production or production data.
* The endpoint changes billing, permissions, users, or account state.
* The test includes brute-force, fuzzing, or burst behavior.
* The target is shared with customers or internal teams.
* You are not sure whether the endpoint has idempotent cleanup.
## Related
Learn how constraints shape the scenarios Qodex authors.
See which probes may need write access or higher rate limits.
Understand how security pass and fail states work.
Configure roles for BOLA, IDOR, and privilege-escalation tests.
## On the roadmap
A dedicated `allow_security_testing` flag is planned. It will let teams block active attack payloads independently from destructive tests, so production mirrors can still run hygiene checks without receiving injection or SSRF probes.