PATTERN Cited by 1 source
Continuous red-team validation¶
Intent¶
Verify that a layered security architecture actually constrains blast radius in practice — not just on a whiteboard — by testing it continuously from both attacker perspectives (outside and already-inside).
Problem¶
Security architectures look impenetrable in diagrams but fail in practice due to misconfigurations, implicit trust assumptions, and gaps between layers. Point-in-time penetration tests don't catch drift. Compliance checklists verify control existence, not control effectiveness.
Solution¶
Operate a red team that:
- At the perimeter: uses frontier AI models + manual techniques to probe newly launched surfaces, recently changed code, and likely first-target paths. Identifies what gets through.
- Inside the environment: starts from the assumption that the perimeter has already failed. Tests whether one compromised identity/path/credential can reach further than it should.
- Closes the loop: when a gap is found, the architecture is changed (not just a rule patched), and the red team re-tests the same scenario against the new version to confirm the gap is closed.
Key distinction¶
The test is "does the gap close?" — not "did we deploy a fix?" The red team validates architectural behaviour under failure, not rule existence.
Production example¶
Cloudflare's red team operates in both modes. When their perimeter tests use a frontier model as an adaptive attacker and it gets through, the process doesn't stop at writing a WAF rule — the architecture is modified and re-tested.
(Source: sources/2026-06-09-cloudflare-defend-against-frontier-cyber-models)