Red Teaming Became Continuous. Make the Rules of Engagement Executable.

For many enterprises, red teaming arrived as an engagement. A team received authority, tested a defined environment, produced a report, and left. A signed Rules of Engagement document worked because people carried its constraints into each decision.

Frontier AI changes the cadence. Adversarial discovery, validation, tool use, and reporting can recur as code, infrastructure, and identities change. Gartner describes a shift from periodic penetration testing toward continuous offensive security testing.[1] In a small task set, METR observed capable agents find vulnerabilities and build simple exploits, while also making serious mistakes and triggering unexpected alerts.[2]

That evidence does not establish an autonomous replacement for expert red teams. It shows that adversarial capability can operate across more steps and propose actions faster than a human document-review cycle. The architecture of authorization must change with it.

Continuous Does Not Mean Unrestricted

For this Dispatch, continuous AI-augmented red teaming means an authorized capability that can be invoked repeatedly or remain available as the environment changes. Models may assist or direct investigation, tool use, and evidence production.

Continuous does not mean nonstop exploitation, unrestricted autonomy, permission to test any reachable system, or removal of expert judgment. Targets, techniques, credentials, tools, autonomy, and effects remain engagement-specific.

The distinction is availability. A continuously available system needs its boundaries to survive when no tester is interpreting every paragraph before every action.

The Rules of Engagement Cannot Remain Only a Document

NIST defines Rules of Engagement as the detailed guidelines and constraints established before a security test that authorize defined activities.[3] That remains the foundation. Accountable people must still agree on purpose, ownership, target, time, permitted conduct, incident handling, and evidence obligations.

But a human-readable RoE is not automatically an execution control.

A model-directed system can resolve a hostname, discover a credential, follow a redirect, change technique, or propose a higher-impact step during a run. If constraints remain trapped in a PDF, ticket, or email, the system may have technical reach without a deterministic authorization decision.

The RoE therefore needs a machine-readable operating form inside the Authority Envelope: the context-specific permission for this actor, purpose, target, operation, tool, time, and escalation path. The signed agreement remains authoritative. Its actionable conditions become versioned inputs to the execution boundary: targets, deny lists, time windows, conduct rules, credential policy, approval gates, resource limits, stop conditions, and evidence requirements.

An accountable engagement owner should control the translation, with security or risk approval. The executable policy should identify its signed RoE version and require reconciliation and renewed approval when either changes. Unresolved mismatches fail closed.

Machine-readable does not mean self-enforcing. A structured file is useful only when an independent control resolves the proposed action against it and can deny, pause, isolate, or escalate before the effect occurs.

Daybreak Governs Access, Not the Target

OpenAI describes Daybreak as a governed cyber-defense stack whose access program separates Standard, Daybreak Blue, and separately approved Daybreak Red workflows.[4][5] That approval governs access to capability, not authority over a target. OpenAI limits intended use to assets the user owns, operates, or is explicitly authorized to test; access does not configure customer scope or replace least privilege, isolation, and human review.[5][6]

The public openai/codex-security repository reinforces this boundary: access selection, model access, scan scope, limits, status, reports, and severity policy remain distinct states.[7] It does not establish a customer RoE, target authorization, or a universal control plane for downstream effects.

The operating model must keep five decisions separate:

1. Daybreak access: May this approved user and project use the selected cyber capability?
2. Target authority: Does the target owner authorize this engagement and these activities?
3. Execution control: May this specific action proceed now, through this harness, under the current RoE?
4. Evidence admission: Is the result sufficiently reproducible and supported to enter the finding workflow?
5. Remediation authority: Who may change, merge, deploy, and verify a fix?

Collapsing them turns access into implied permission and a candidate finding into implied action. Neither follows.

Make the RoE Executable

OWASP’s Autonomous Penetration Testing Standard organizes governance across scope enforcement, safety, human oversight, graduated autonomy, auditability, manipulation resistance, supply-chain trust, and reporting. It remains an Incubator Project at version 0.1.0—not a mature consensus standard, regulatory mandate, or certification result.[8]

Its informative RoE template includes authorization references, targets, time bounds, denied assets, conduct rules, impact limits, credential policy, escalation, kill-switch contacts, and evidence retention. It treats discovered-credential use as approval-gated and requires revalidation when the RoE changes.[9]

Those fields become useful when the runtime can answer a pre-action question:

Does this resolved action—target, technique, tool, identity, network path, time, and expected effect—fit the current authorization?

If the answer is no, missing, expired, or ambiguous, the action should not proceed. A redirect from staging to production should stop at the scope boundary. A discovered credential should not become usable merely because the system can see it; the action should pause for the stronger authorization defined by the engagement.

Explore the interactive visual

Luminity architectural interpretation informed by NIST, emerging OWASP APTS guidance, and current OpenAI Daybreak and Codex Security documentation. Not a standard, provider authorization, compliance determination, or product-conformance claim.

Govern the Complete Testing Harness

The model is only one component. The action path also includes target resolution, policy, tools, execution environment, identities, credentials, network reach, resource limits, evidence storage, and approvals. Instructions cannot narrow a broad credential, remove an unintended route, or stop a permitted tool from reaching a prohibited target. Independent controls must carry the boundary.

For every proposed action, resolve at least:

• exact target after redirects, aliases, and environment mapping;
• technique, expected effect, tool, payload, and destination;
• identity and credential provenance, including discovered credentials;
• permitted autonomy and required approval;
• time, concurrency, rate, cost, and target-health limits.

The RoE should bound maximum authorized effect: for example, read-only verification, prohibited data extraction, service-health thresholds, and always-gated actions. Because expected effect is a prediction, independent telemetry must stop execution when observed conditions exceed those limits.

Retain what was proposed, what policy decided, what executed, and what effect was observed. Otherwise a stopped action can resemble a failed one, and a proposed exploit a confirmed result.

Stop and Escalation Are Valid Outcomes

A continuous system needs an interruption path that is independent of the system it may need to stop.

Use external telemetry, health signals, credential revocation, network isolation, run cancellation, kill controls, and accountable escalation. Stop conditions should cover scope violations, expired authority, prohibited techniques, target degradation, unavailable monitoring, policy ambiguity, and material divergence from the proposed action.

Human review needs a specific job. Show the reviewer the target, technique, tool, credential, likely effect, policy result, alternatives, and exact authority requested. One approval should not silently authorize future targets or techniques.

In a governed design, denial, pause, redesign, and escalation are legitimate execution results—not system failures.

Admit Evidence Before Remediation

AI can produce plausible security narratives faster than an organization can validate them. That makes the evidence-admission decision as important as the action decision.

SANS guidance for AI-assisted source-code vulnerability analysis treats model findings as hypotheses until reproduced, ties claims to file-and-line evidence, and keeps verification human-owned in that workflow.[10] We extend that narrower principle here: a fluent report is not proof.

A candidate finding should retain the RoE version, proposed and executed actions, tool and environment, inputs and outputs, observed effect, reproduction steps, scope decision, exceptions, and uncertainty. Only then should it enter investigation, validation, ownership, remediation, deployment, and verified closure.

For example, admission might require an authorized reviewer to reproduce the behavior against the same scoped target and configuration, preserving the action trace, observed effect, and uncertainty. The threshold should reflect the finding’s consequence.

Codex Security and the broader Daybreak loop can contribute discovery and dynamic-validation evidence. They should not collapse discovery, confirmation, patch acceptance, deployment, and verification into one state. OpenAI’s presentation keeps these stages distinct and places people around consequential changes and independent fix verification.[4]

The Engagement Becomes an Operating Record

A practical continuous-testing record can remain compact if it preserves six connected obligations:

1. Authorize: Record purpose, target ownership, scope, time, permitted conduct, and approval chain.
2. Enforce: Turn applicable RoE fields into pre-action decisions that default-deny missing, expired, redirected, or ambiguous scope.
3. Constrain: Bind models, tools, credentials, identities, networks, destinations, autonomy, and resources.
4. Observe and interrupt: Maintain independent telemetry, pause, revocation, isolation, kill, and escalation paths.
5. Admit evidence: Require reproducibility and an explicit threshold before remediation begins.
6. Revalidate: Reopen the decision when the target, model, policy, tool, credential, network reach, autonomy, or evidence requirement changes materially.

This is not a new standard or an OpenAI product schema. It is an enterprise architecture for carrying human authorization into a machine-speed testing path.

McKinsey frames the cyber speed gap as an operating-model problem: technical capability moves faster than organizational decisions.[11] The answer is to make authority executable where the next action is resolved, not remove it from the loop.