LLM Penetration Testing: A Scope and Evidence Worksheet

Sources checked: 5 November 2026. FailSafe Research.

A useful LLM penetration test starts with a decision about an application boundary. The scope should identify the deployed system, what an attacker can influence, which actions are authorized for testing and what evidence would change the owner's decision. A list of prompt categories alone cannot describe those conditions.

Which system are you authorizing?

Use the AI assessment scope worksheet to inventory the application and its model integrations. Include retrieval stores, tools, MCP servers, background jobs and external processors. Record versions and owners. Identify which components are owned by the organization and which require a third party's permission before active testing.

Separate model behavior from application authority. A model may propose an operation while the application decides whether to execute it. An AI red-team exercise investigates the AI system's behavior and trust boundaries; agentic penetration testing describes using agents to assess authorized software. A project can include both approaches, but the report should show which questions each method answered.

How do you turn a concern into a test case?

Consider a fictional document assistant used by two workspaces. The concern is that text retrieved for one workspace could influence an operation involving another. The test case names the caller, synthetic input, requested object and expected decision. It also names a legitimate operation that must continue to work. The scope defines where a read must be denied and which telemetry can establish whether restricted text entered the model context.

Before execution, agree the environment, identities, data classes, permitted effects, attempt budget, request limits and stop conditions. A document instruction cannot authorize a new target or destructive action. Keep real credentials and production documents out of public inquiry forms and example reports.

What deliverables support an engineering decision?

A compact LLM assessment evidence package

Deliverable	What it establishes
Scope and configuration	Which versions, roles, tools and environments were actually assessed.
Case ledger	Expected behavior, permitted action and observed outcome for each approved case.
Finding	The affected boundary, sanitized evidence, demonstrated impact and known limitations.
Remediation and retest	The control owner, reviewed change, tested deployment and result of repeating the relevant case.

Use clear outcome labels such as observed violation, blocked for the tested condition, inconclusive and outside scope. Explain missing visibility or unavailable access. A test that stops at the user interface may not establish what a downstream tool or processor received. Preserve the original observation even when the engineering ticket is later closed.

Which exclusions need an explicit decision?

Training pipelines, model weights, extraction testing, third-party services, production writes and load testing can require different methods or permissions. Discuss them explicitly rather than assuming that an AI application assessment includes them. Framework mapping can organize the test plan; it does not create regulatory certification or guarantee auditor acceptance.

The OWASP Top 10 for LLM Applications is a primary reference for risk categories. The worksheet on this site is FailSafe's planning aid, not an OWASP-mandated scope. The owner should select cases based on the system's actual data and action boundaries.

How do research results inform the scope?

FailSafe's AttackBench research with NEAR examines model-framework combinations under a defined adversarial task set. It provides a reason to record the runtime and its controls alongside the model. It is not a measurement of the fictional document assistant described here. Use benchmark observations to form testable hypotheses, then collect application-specific evidence.

After a proposed fix, repeat the original negative case, the legitimate control and approved alternate paths on a recorded deployment. State which results remain unknown. A new connector or changed approval rule can invalidate assumptions even when the model version is unchanged. See the sample finding and retest record for how to keep that chain understandable.

Review the full AI/LLM assessment sequence or scope an AI security engagement. Confirm specialist requirements before buying the Startup offer; the standard black-box run does not automatically include every AI system or test method.