# THEORY — Pentest Authorization as a Legal Primitive

## The legal line

Computer-access laws across major jurisdictions criminalize
unauthorized access. The notable statutes:

| Jurisdiction | Statute | Key provision |
|---|---|---|
| United States | CFAA (18 USC §1030) | Accessing a protected computer "without authorization" or "exceeding authorized access" |
| United Kingdom | Computer Misuse Act 1990 | Unauthorized access (§1), unauthorized acts impairing computer operation (§3) |
| European Union | Directive 2013/40/EU | Illegal access, illegal system interference, illegal data interference |
| Singapore | Computer Misuse Act 1993 | Same shape; offence of unauthorized access |
| Australia | Criminal Code Act 1995 §477 | Unauthorized access, modification, or impairment |

The defining word in every statute is "authorization." A pentester
with explicit written authorization to access in-scope systems is
performing a legal security service. Without that authorization,
the same activity is a crime.

Authorization is not implicit. "I assumed they wanted me to test
their system" is not a defense. "They paid me to do security work"
is not sufficient if the system tested was outside the contracted
scope. The pentest industry has standardized the Rules of
Engagement (ROE) document as the artifact that establishes
authorization with the precision the law expects.

## OSSTMM, PTES, and ROE history

Two open-source frameworks gave the industry its ROE template:

- **OSSTMM** (Open Source Security Testing Methodology Manual,
  ISECOM, 2001 onward) — defined the scope-fingerprinting process
  and what the engagement-letter checklist must cover.
- **PTES** (Penetration Testing Execution Standard, 2010 onward)
  — formalized the pre-engagement phase, including ROE structure.

Both predate the cloud / API era and reflect a network-pentest
mental model. Modern engagements add fields for cloud accounts,
SaaS integrations, and ML-model probing that the original templates
don't anticipate. The schema this skill validates incorporates
common modern fields (SaaS scope, time windows, emergency contact)
on top of the OSSTMM/PTES foundation.

## Signature options

The "signature" on a ROE is whatever evidence the authorizer's
counsel and your counsel agree establishes binding intent. Common
forms:

| Method | Strength | Effort |
|---|---|---|
| PGP / GPG signature on YAML/text ROE | Cryptographic; high | Moderate (both parties need GPG setup) |
| S/MIME signed PDF | Cryptographic; high | Moderate (certificate management) |
| DocuSign or HelloSign e-signature | Legally recognized in most jurisdictions; high | Low |
| Email with explicit "I authorize" statement, archived | Legally recognized but weaker (email impersonation risk) | Low |
| Wet-ink signature on printed ROE | Strongest in court; high | High (slow, physical) |
| Slack DM "yeah go ahead" | Often inadmissible; do NOT rely on | Trivial |

The skill validates the structural presence of a `signature_block`
in the ROE. Cryptographic verification (actually checking that a
PGP signature was made by the claimed key) is a separate step the
operator runs with `gpg --verify` before this skill runs. The
skill checks "is this ROE structurally signed?" not "is this
signature cryptographically valid?" — those are different gates,
and conflating them in one tool produces brittle failure modes.

## Scope-creep failure modes

Engagements that go wrong tend to follow common patterns:

### "Just one more system"

Tester finds an interesting adjacent system mid-engagement and
probes it. Adjacent system was NOT in the ROE. SOC team escalates.
Legal asks for the ROE. ROE doesn't cover the adjacent system.
Conversation gets expensive.

Mitigation: the skill's `--check-target` flag explicitly tests
whether a target is in scope BEFORE any probe runs. The
orchestrator should call it for every fresh target.

### "I assumed prod was off-limits"

Tester avoids "obvious" production systems but probes systems
labeled "staging" that turn out to be production-attached.
Outage results.

Mitigation: ROE schema requires explicit `in_scope_targets` AND
`out_of_scope_targets`. The list of out-of-scope items is
prophylactic — if a target isn't on either list, the tester must
ask before proceeding.

### "We extended verbally"

Engagement's time window expires, but the customer says verbally
"keep going for another week." Tester continues. Incident occurs.
ROE shows the time window as expired. The verbal extension is
unprovable.

Mitigation: time-window expiry is a CRITICAL finding in this
skill. The skill refuses to declare an engagement authorized if
the current time is outside the window, regardless of any other
field's state.

### "The CISO's assistant said it was fine"

ROE was signed by someone whose authority over the systems was
unclear or absent. CISO denies authorizing.

Mitigation: the `.allowed-authorizers` file establishes which
signer identities are accepted. Maintained by the tester's
business-development team; new authorizers require vetting
before being added.

## ROE template fields and why each matters

| Field | Why it's in the schema |
|---|---|
| `engagement_id` | Unambiguously identifies the engagement; lets multiple ROEs coexist without confusion |
| `authorizer.name + email + role` | Identifies who is authorizing; their role establishes that they have authority |
| `authorizer.organization` | Customer org; useful when the authorizer is a contractor or an MSP |
| `in_scope_targets` | The list. Without it, nothing is authorized |
| `out_of_scope_targets` | Prophylactic; clarifies known boundaries |
| `time_window.start + end` | Engagement is only authorized within this window |
| `emergency_contact` | Who to call if the test triggers an unexpected outage or law-enforcement contact |
| `rules` | Custom restrictions (no password spray on prod accounts, etc.) |
| `signature_block` | Establishes binding intent and which party is bound |
| `signature_block.signed_at` | When binding was established |

## Why "halt on CRITICAL" is the right policy

The orchestrator routes to this skill FIRST and refuses to proceed
to cluster 1-4 skills if any CRITICAL finding emerges. The
rationale:

- A scan that produces findings against an unauthorized target
  exposes the tester to legal liability.
- Even informational scans (port scans, DNS probes) against
  unauthorized targets can constitute unauthorized access under
  some statutes.
- The cost of halting is a delayed engagement. The cost of
  proceeding without authorization is criminal exposure. The
  asymmetry is severe; the discipline is the only constraint.

## Cryptographic verification — out of scope here

PGP signature verification (does the signature on this ROE actually
match the public key of the claimed signer?) is performed by a
separate operator-run step:

```bash
gpg --verify roe.yaml.asc roe.yaml
```

The skill does not invoke GPG because:

1. Many ROEs are signed via DocuSign or similar (no PGP at all).
2. PGP key management is its own discipline — the skill would
   become a key-management tool.
3. Separating "structural presence of signature" from
   "cryptographic validity of signature" makes failures easier
   to diagnose.

A future enhancement could add `--verify-pgp` to bridge the two,
with explicit key-store configuration. For now, the skill checks
structure; the operator checks cryptography.