Before the First Prompt: Writing a Scope Document That Makes LLM Security Reviews Useful

The request that arrives without a definition

A product team ships a chat assistant that answers questions about customer contracts. Two weeks before launch, the security lead receives a ticket: red team the AI feature. No endpoint list, no data classification, no statement of what would constitute a failure. The result is predictable — a week of prompt-injection demonstrations, three screenshots of the model producing something impolite, and a readout that ends with the phrase residual risk accepted because no one can connect the findings to a decision.

This is not a testing failure. It is a scoping failure. Penetration testing has a settled grammar: a defined target, an enumerated attack surface, exploitation criteria, and a report that maps to remediation tickets. Large language model assessments inherit the vocabulary of that discipline without inheriting its structure, and the mismatch produces work that is expensive, unrepeatable, and largely decorative.

The scope document is therefore not paperwork that precedes the assessment. It is the primary artifact, and it should be drafted with the same care as the report.

Why the penetration-test frame breaks down

Four differences matter, and each one changes what you write down.

First, the target is not deterministic. The same input can produce different outputs across runs, model versions, and sampling settings. A finding you cannot reproduce is not a finding; it is an anecdote.

Second, the input surface is ordinary language. There is no payload grammar, no boundary between data and instruction. Every user string is potentially both.

Third, the interesting failures are usually policy failures rather than memory-safety failures. Whether the assistant should decline to summarize a termination clause is a question for legal and product, not for the security engineer holding the keyboard. The assessment can surface the question; it cannot answer it.

Fourth, the real boundary does not stop at the model. It extends into the retrieval corpus, the connector layer, the function-calling surface, and the human who approves the action. Most of the genuine risk in 2026 deployments lives in those outer layers, not in the weights.

Inventory the deployment before you inventory the risk

Start with a working session, not a scanner. Ask the product owner to draw the request path end to end, and record the following:

• Which model endpoints are called, hosted by whom, at which version, with what fallback behavior when the primary provider degrades
• Which corpora are retrievable, who owns them, and how freshness and access control are enforced at retrieval time
• Which tools or functions the model can invoke, and under whose identity those calls execute
• Who consumes the output — a human reading, a human approving, or an automated downstream system acting
• Where prompts, completions, tool calls, and user identity are logged, and for how long

Anything the product owner cannot answer is itself a finding, and it belongs in the scope as an open question with an owner and a date.

Six sections the scope document should carry

1. Model boundaries

Name the exact endpoints and versions under test, including fine-tunes and any router that selects between providers. State explicitly what is out of scope — for example, the vendor's training pipeline — and why. Pin versions for the duration of the assessment; a silent model update mid-engagement invalidates your reproduction steps.

2. Data access

Distinguish authorization at retrieval from authorization at generation. A model that retrieves only documents the requesting user can read is a different risk profile from one that retrieves a shared index and filters afterward. Document tenant isolation, the presence of regulated data in the corpus, and how the corpus is refreshed. Note whether the assessment corpus is a production copy, a masked copy, or a synthesized stand-in, and record that choice as a limitation.

3. Tool use and privilege

The function-calling surface is where prompt injection becomes consequential. For each tool, record its permissions, the identity it executes under, whether it is scoped to the requesting user, and the maximum blast radius of a single successful misuse. A read-only search tool and a tool that issues refunds belong in the same document and should not receive the same severity.

4. Human review

Where a human approves an action, describe what that person actually sees and how long they have to look at it. Automation bias under time pressure is a control weakness, and it is testable. If the approval screen shows a summarized action rather than the underlying parameters, that belongs in the scope as a control under test.

5. Adversary model

Name the adversaries the assessment will represent: the curious authenticated user, the malicious insider with legitimate access, an external party who has obtained an account, and the supply chain — connectors, plugins, and content the model ingests. An assessment without a stated adversary model defaults to testing whatever the tester finds interesting.

6. Evidence and reproducibility

Agree before testing on what will be captured: full prompts and completions with trace identifiers, tool-call logs, model version at time of test, and sampling parameters. Set retention long enough to support the report and any follow-on investigation. Where a result cannot be reproduced, the report should say so rather than round it up.

Rules of engagement that protect the tester

Do not run assessments against production systems holding real customer records when a representative corpus will do. Define stop conditions in writing: what happens when you induce the model to produce material that is illegal or harmful to store, who is notified, and how it is destroyed. Obtain legal review for any test that induces the system to disclose data belonging to another tenant, even in a staging environment.

Findings that survive the readout

Write each finding as a risk statement anchored to a component and a decision. Compare prompt injection is possible with the refund tool executes under a shared service account, so a single injected instruction can issue refunds across all tenants; this must be resolved before the tool is enabled for external users. The second sentence can be scheduled, funded, and verified. The first cannot.

Pair the findings with an action-oriented severity scale — ship, hold, fix by a stated date, monitor — and resist the temptation to grade on cleverness.

The scope is the deliverable

When the assessment ends, the scope document is what makes the report legible six months later, when the team has turned over and the model version has moved. Teams that write the scope first consistently produce fewer findings and better decisions. That trade is worth making, and it is the difference between a red team exercise and a demonstration.