A red team engagement exists to answer one question: can your security team detect and respond to a real attack. For that answer to mean anything, the security team being tested, the blue team, cannot know the test is happening.
That single constraint breaks the normal authorization model. Standard authorization flows through the people who own the systems being tested, and for a pentest, that includes security and IT. For a red team, those are exactly the people who have to stay in the dark. Get this wrong in one direction and the blue team finds out, which ruins the test. Get it wrong in the other direction and nobody with real authority actually approved the engagement, which puts the testers in genuine legal exposure if something goes sideways mid-operation. Both failure modes defeat the entire point of running a red team in the first place.
The fix is compartmentalization: authorization flows from a small group of executives who are explicitly, provably not part of the blue team being evaluated.
Why this isn't just a stricter pentest authorization
A red team authorization letter is a different document with different legal and operational requirements, not a pentest letter with a tighter NDA bolted on. A red team may deliberately interact with people, facilities, and defensive systems that have no idea a test is running.
| Standard pentest | Red team engagement | |
|---|---|---|
| Objective | Identify and validate vulnerabilities | Test detection, response, and containment |
| Who knows | Security, IT, system owners | Restricted executive/legal group; blue team often excluded |
| Signing authority | CISO, CTO, or delegated security exec | Exec sponsor with authority over the target, independent of the blue team |
| Scope | Apps, APIs, infra, cloud assets | Technical systems plus facilities, personnel, identities, defensive controls |
| Social engineering | Usually excluded or separately authorized | May be explicitly authorized |
| Physical access | Usually excluded or separately authorized | May include offices, badge systems, tailgating |
| Blue-team awareness | Usually expected | Often intentionally restricted |
| Emergency contact | Testing firm + client security contact | 24/7 executive sponsor who can confirm the op immediately |
| Law enforcement | Addressed in emergency procedures | Must explicitly define how authorization gets verified on the spot |
Who's actually allowed to sign
The signing rule is simple to state and easy to get wrong in practice: the signer cannot be part of the group whose detection capability is being evaluated.
- If the CISO manages the SOC being tested, the CISO cannot sign.
- If the entire security function is in scope, it goes to CEO or board level.
- If security manages but doesn't operationally run the specific test target, the CISO may sign, provided they're genuinely separate from the blue team in question.
This isn't "the CEO always signs." It's that the signer needs actual authority over the assets in scope and needs to sit outside the operational group being evaluated. Most red team authorizations end up at CEO or board level for a simple reason: the engagement is testing the security function itself, and the person who runs that function can't objectively authorize their own team's evaluation.
Cloud providers have their own rules, and they change
Red team authorization from your organization doesn't extend to permission from your cloud provider. AWS, Azure, and GCP each publish their own acceptable-use and security-testing policies, and they get updated. Verify the current version immediately before the engagement rather than trusting whatever was true last year.
For every cloud provider in scope, document: the provider and account/subscription/project identifier, specific regions and resources, the approved testing window, approved and explicitly prohibited techniques, any notification or approval requirements the provider imposes, emergency contacts, executive authorization, and stop conditions. Treat this as its own verification step, separate from the signed authorization letter, not something you assume is automatically covered by it.
The sealed envelope model
When getting an executive signature at engagement start is genuinely difficult for legal, timing, or organizational reasons, a sealed envelope approach works: the fully signed authorization exists, but it's only opened if a legal issue comes up, law enforcement gets involved, or the organization faces an inquiry that requires documented proof. This lets the engagement run under strict compartmentalization while real, verifiable authorization still exists if it's ever needed.
The get-out-of-jail card
Anyone doing physical access or social engineering work in the field should be carrying a physical card, not a digital one, that lets them verify the engagement on the spot if security or police stop them.
Requirements that actually matter here: a 24/7-reachable number, not an office line that goes to voicemail at 11pm; an authentication code the contact can verify against; the named contact is the executive sponsor, never someone on the security team; every field operator carries one; and it's a printed copy, because a phone can be confiscated, dead, or locked during exactly the moment you need it.
What the rules of engagement have to nail down
The authorization letter grants permission. The rules of engagement define the edges of that permission, and for a red team both documents matter equally: objectives (detection, response, containment, physical security, identity, or full lifecycle), in-scope and out-of-scope targets down to specific systems and facilities, permitted and prohibited techniques, the exact testing window, how discovered sensitive data gets handled, whether persistence is allowed and when it must be removed, the detection protocol once the blue team notices, stop conditions, emergency contacts, the law-enforcement verification procedure, third-party boundaries, evidence preservation, and cleanup requirements at close.
What happens when the blue team actually catches you
This is the part standard pentest authorization letters never have to address, and it's where most of the real risk lives.
Blue team detects but doesn't escalate to law enforcement. Define in advance whether the red team keeps operating as if undetected, or stops. Most engagements specify continuing unless the executive sponsor says otherwise. This should never be improvised live.
Blue team escalates to the CISO. If the CISO is in the "doesn't know" group, they might treat this as a real incident and call the police. The authorization needs a defined procedure for the executive sponsor to step in before that happens.
Blue team calls law enforcement. This is the scenario that produced the well-known Coalfire arrests. Officers show up, testers get detained. The get-out-of-jail card is the first line of resolution. The 24/7 executive sponsor is the second, and the letter needs to state plainly that they're reachable to confirm the engagement directly to law enforcement, not to a lawyer, not by email, directly.
Blue team successfully contains the attack. Decide ahead of time whether the engagement resets, ends, or triggers an immediate debrief, so nobody's making that call under pressure in the moment.
At minimum, pre-define stop conditions for: production availability materially affected, customer data placed at risk, an unintended third party affected, law enforcement involvement, the blue team activating emergency response, the red team hitting a prohibited system, or the executive sponsor simply ordering a stop.
What a red team letter needs that a standard one doesn't
A compartmentalization section naming exactly who knows the engagement is happening and who must not be told, by name, not by role. A written confirmation from the executive sponsor that they're reachable for the full engagement window, treated as a primary operational requirement rather than a footnote. A defined blue-team response protocol so nobody improvises under pressure. A documented decision on whether local law enforcement was pre-notified, which is genuinely the single most effective way to avoid an arrest scenario. Precise physical scope, "the company's offices" is not scope, list addresses, floors, access types, and whether tailgating or badge cloning are in bounds. Verified cloud-provider authorization per account. An explicit reference to the signed rules of engagement so there's no ambiguity about what's actually authorized. And a named person with clear stop/terminate authority, plus the conditions under which the team must halt without waiting for sign-off.
Permission under secrecy is a different problem than permission
A standard pentest is about getting permission. A red team is about getting permission while deliberately keeping most of the organization unaware it exists, and that constraint changes the shape of every document involved. Authorization can't be broad, can't be assumed, and can't reuse the pentest template with a confidentiality clause added. The moment the wrong people find out, the test is worthless. The moment the right people haven't formally signed off, the engagement is a real legal liability for everyone in the field.
Limited awareness, explicit authority, and a clear escalation path, defined before testing starts, is the whole model. Get it right and the engagement runs exactly as designed: realistic, controlled, defensible. Get it wrong and you either lose the test or put your own team at risk. There's no middle version of this.
For the baseline structure this builds on, see CodeAnt AI's guide to penetration test authorization letters. For how these engagements get scoped and reported end to end, see CodeAnt AI's penetration testing platform.
Top comments (0)