Red-team rules of engagement (defensive-only)

Reference (canonical policy) · Audience: Red-team developers and evaluators, read this before running or extending any bundled attack tooling.

Defensive, local-only, self-target-only, educational. The bundled Red tooling exercises your own detector’s test catalog on your own loopback interface. It teaches you to understand and extend the detection engine you run — never to evade a third party. Point every tool at a host you operate; keep it on 127.0.0.1. If a check reveals a coverage gap, report it to the maintainers — never optimize it into an evasion.

This is the one page every advanced Red document links to for its safety framing, so that framing cannot drift. It states the scope, the boundary, the difference between a structural loopback lock and an advisory default, the honest ceilings to repeat when you report, and the good-faith safe-harbor pointer with its hard limit. It ends with a copy-paste guardrail preamble block that the advanced Red how-to pages embed verbatim at the top.

Scope

This tooling exercises your own detector’s test catalog on your own loopback — the standalone detection engine on 127.0.0.1:8443. It is a way to confirm that your detector fires the verdicts and hard rules you expect against known-automated samples, and to measure your own honest-human false-positive picture before you enforce anything.

It is not evasion guidance against any third party. Nothing here tells you how to defeat someone else’s deployment, and the Red profiles reproduce tells an automated client leaves for your engine to catch — they are not a toolkit aimed outward. For what the catalog is and how it is wired, see Red-team catalog and Red catalog architecture.

The three-line boundary

Repeat these three lines on every advanced Red page and hold to them:

  1. Target only hosts you operate. The tooling runs against the standalone detection engine on your own loopback (127.0.0.1:8443).
  2. Never point any tool at a domain, IP, or deployment you do not run. No exceptions for “just testing”, “it’s only one request”, or “I have permission verbally”. Written authorization for a system you do not operate is required, and even then this tooling is not the vehicle for it (see the safe-harbor limit below).
  3. Findings about coverage go to the maintainers — never optimized into an evasion. A gap you discover in your own detector is a maintenance signal for the detection engine, not a recipe to publish or aim at anyone.

Structural locks vs advisory defaults

Not every safety property is enforced the same way. Know which is which before you run anything, because the difference decides how much of the responsibility is yours.

Structurally loopback-locked — the Detection Observatory launcher

The Observatory launcher is locked by construction; the target cannot be redirected off your box:

  • The launch target is hard-coded to 127.0.0.1:8443 — there is no target field to set.
  • Any host, url, or upstream key in a launch request is rejected with HTTP 400.
  • Each launch requires a single-use nonce.
  • A cross-origin Origin on launch is refused.
  • run-one.mjs performs its own loopback check and rejects a non-loopback base and path-traversal profile names.
  • A per-request Host loopback check re-validates on every request (a DNS-rebinding defense beyond the bind-time check), and startup is fail-closed — the engine refuses a non-loopback -addr.

These are enforcement points, not conventions. See Detection Observatory and Observatory architecture.

Advisory only — cmd/redteam -host

One tool is different. The Go attack CLI cmd/redteam takes a -host flag that defaults to 127.0.0.1:8443, but that default enforces nothing — the CLI connects to whatever host:port you pass it.

Warning: On cmd/redteam there is no structural lock. Keeping the target on your own box is the operator’s responsibility, not the tool’s. Do not pass a -host you do not operate. (The binary’s own -attack flag help is currently stale; the real attack values are documented in Red-team catalog.)

Honest ceilings — repeat these when you report

Detection is bounded and heuristic. When you report a result, carry these limits with the number so no reader mistakes a measurement for a guarantee:

  • The T4 boundary is not solved. Anti-detect tooling combined with real-human click-farms is a design boundary that is mitigated by rate and reputation, not solved. A pass or a block against a T4-style sample does not close that gap.
  • HR-11, HR-12, and HR-17 are heuristics that can challenge real humans. HR-11 (a consistent browser from a datacenter ASN), HR-12 (zero interaction over the observation window), and HR-17 (a replayed or absent RIT token on an API call) issue CHALLENGE, not DENY, and can catch some genuine people. Do not report them as clean bot-only signals.
  • Every number is reference-measured on your machine. A detection rate or false-positive rate describes that run on your box — it is not a promise about live traffic. Inspect the honest-human baseline’s challenge-rate separately; a human CHALLENGE is scored as a true negative, so a DENY-only false-positive rate under-reports human friction.

For the verdict thresholds and the full HR-1..HR-21 table, see Hard rules, verdicts and signal-ID reference.

Good-faith safe harbor — and its hard limit

Testing conducted in good faith against systems you operate, or a deployment you are explicitly authorized in writing to test, is welcomed under the coordinated-disclosure policy.

Warning: The safe harbor is not authorization to test anything you neither operate nor are authorized in writing to test. This is a defensive product; its Red-team and self-validation tooling targets your own deployment only. Testing an instance you do not run and do not have written permission to test is outside the policy, is not authorized, and may be unlawful.

Read the full policy — scope, how to report, out-of-scope items, and the safe-harbor wording — in Security vulnerability disclosure policy. To actually run the self-validation exercise on your own install, follow Self-validation: red-team your own Gate deployment.

Guardrail preamble block (embed verbatim)

Every advanced Red how-to page opens with the block below. Copy it verbatim to the top of the page, immediately after the title and the Diátaxis/audience line, so the framing stays identical across the docs set.

> **Defensive, local-only, self-target-only, educational.** This page helps you
> understand and extend **your own** detector's test catalog on **your own**
> loopback (`127.0.0.1:8443`). It is not evasion guidance against any third
> party. Target only hosts you operate; never point any tool at a domain, IP, or
> deployment you do not run; report coverage gaps to the maintainers rather than
> optimizing them into an evasion. Honest ceilings apply: the T4 boundary
> (anti-detect tooling plus real-human click-farms) is rate/reputation-mitigated,
> not solved; HR-11 / HR-12 / HR-17 are heuristics that can challenge real
> humans; every number is reference-measured on your machine, not a guarantee.
> The Observatory launcher is structurally loopback-locked, but `cmd/redteam
> -host` enforces nothing — keeping that target on your own box is your
> responsibility. See the full
> [Red-team rules of engagement](/reference/red-team-rules-of-engagement.html)
> and the [security disclosure policy](/reference/security-disclosure.html).

Note: The relative links inside the preamble (../reference/…) are written for a page in docs/how-to/ or docs/explanation/. Adjust the path depth if you embed the block at a different directory level.