Keep distinctSuspicious content observed is not successful prompt injection.
Testing methodology
Prompt Injection Security Testing
A practitioner foundation for authorized testing of real LLM, RAG and AI agent applications. It connects controlled execution to evidence, local pass criteria, remediation and residual risk without turning model behavior into an impact claim.
What security testing must establish
Prompt injection security testing is not equivalent to asking whether a model followed injected text. A rigorous test reconstructs the full application chain and identifies exactly where evidence ends.
Keep distinctModel influence is not security impact, and a plan change is not an authorization bypass.
Keep distinctAn action proposed is not submitted; submitted is not executed; executed does not establish downstream effect without evidence.
Keep distinctA detector alert is not confirmed impact. A control block proves a control decision, not malicious intent.
Keep distinctUnobserved does not mean failed and does not mean safe.
Keep distinctA valid tool, schema or protocol exchange is not permission. Registration and discovery are not authorization.
Keep distinctSeverity follows demonstrated or credibly possible impact and scope, not prompt cleverness.
Labs, Testing and Adversarial Testing
These activities support each other, but they have different objects and evidence claims.
| Activity | Purpose | Environment | Primary output |
|---|---|---|---|
| Labs | Controlled learning and practice | Client-side fictional simulations | Understanding and decision practice |
| Testing | Evaluate actual application boundaries | An explicitly authorized real system or faithful test environment | Evidence, local outcomes, findings and residual risk |
| Adversarial Testing | Assurance control and program concept | Governed test program | Coverage, repeatability and control assurance |
Authorized testing lifecycle
Scope, ownership and stop conditions come before any execution. Each run should be controlled, attributable and reversible.
- 01Scope and authorization
Name the owner, assets, versions, permitted actions, limits, stop conditions and escalation path.
- 02Threat model and trust boundaries
Map variable content, authoritative state, principals, resources, tools, destinations and possible effects.
- 03Instrumentation and evidence plan
Define the application and provider records needed before running the test.
- 04Select representative attack paths
Choose relevant entry, context, action and control paths rather than maximizing prompt variation.
- 05Execute a controlled test
Use safe synthetic stimuli, isolated data, rate limits, cleanup and monitoring.
- 06Classify observations
Record content, influence, proposal, control, submission and execution as separate states.
- 07Validate downstream effect and impact
Confirm effects through provider-side or application-owned evidence, not model narration.
- 08Remediate
Correct the boundary or control that failed and preserve the minimum evidence needed for review.
- 09Regression retest
Repeat versioned cases after the change and after material model, tool, corpus or policy updates.
- 10Report residual risk
State what was demonstrated, what remains possible and what was not observed.
Evidence model
Variable model-visible content can be test input or an observation. It must not define identity, policy, permission, execution or impact by itself.
Evidence stateSource and provenance record
Application-owned ingestion record, content hash, origin, version and transformation lineage.
Evidence stateContext observation
Application instrumentation showing what representation entered model-visible context.
Evidence stateModel or plan influence
Versioned output or plan diff showing a change, without claiming execution or impact.
Evidence statePolicy or control decision
Authoritative authorization, approval, information-flow, egress or validation record.
Evidence stateSubmission and execution telemetry
Application and tool records distinguishing proposal, request, acceptance and execution.
Evidence stateDownstream effect
Provider audit or authoritative state proving the resource, destination and resulting change.
Evidence stateSecurity-impact classification
Analysis tied to affected principal, data, resource, action, persistence and scope.
Evidence stateEvidence gap or unobserved
An explicit state where required telemetry is absent, incomplete or not retained.
Outcome and local pass criteria
There is no universal binary result. The test objective defines which observable states pass, fail or remain inconclusive. A deterministic block can satisfy one control objective even when the model was influenced.
| Observed state | What it establishes | Possible local treatment |
|---|---|---|
| No observable influence | No measured change in the selected runs | Pass only for a narrowly defined influence objective |
| Model influence only | Output or plan changed | Fail for an influence objective; not proof of impact |
| Unsafe proposal generated | Model proposed an out-of-scope action | Usually fail for proposal safety; authorization still untested |
| Deterministic control blocked | A named control denied the concrete operation | Pass for that enforcement objective |
| Action submitted | A request crossed the application boundary | Fail where submission must be prevented |
| Action executed | A tool or provider accepted and ran the action | Fail for execution prevention; effect still separate |
| Downstream effect confirmed | Authoritative state proves the resulting change | Fail and scope the affected resource |
| Credential or data exposure confirmed | Evidence proves disclosure or unauthorized use | Fail with impact classification |
| Persistence or cross-run effect confirmed | State survived or influenced another run | Fail with persistence scope |
| Unobserved or insufficient evidence | Required evidence is unavailable | Inconclusive, never silently converted to pass |
Testing domains
This taxonomy guides future coverage. It does not create child pages or claim that every system needs every domain.
Entry and context
- Testing domainDirect input and instruction competition
User-controlled language competing with application instructions.
- Testing domainIndirect web, email, document and search channels
External content entering context through application processing.
- Testing domainRAG, retrieval and poisoned knowledge
Retrieval permission, provenance, relevance and corpus integrity.
- Testing domainPersistent and multimodal context
Stored state, images, audio and derived representations across runs.
Agents and actions
- Testing domainTool outputs
Post-call variable content and each resulting proposal.
- Testing domainAI agents and action boundaries
The transition from model or plan influence to proposed and executed actions.
- Testing domainMCP metadata and discovery
Pre-invocation metadata, catalogue changes and the registration boundary.
- Testing domainMulti-agent handoffs
Delegated authority, lineage and reauthorization at every handoff.
Controls and data flow
- Testing domainAuthorization and least privilege
Exact decisions over principal, resource, action, parameters and capability reach.
- Testing domainInformation flow and egress
Permitted movement of classified data and permitted network paths.
- Testing domainHuman approval
Informed approval bound to the exact action and current state.
Operations and assurance
- Testing domainDetection, plan drift and tool-chain telemetry
Correlated signals that support testing without becoming authorization.
- Testing domainIncident evidence and regression
Reconstructable evidence, sanitized regression cases and change-triggered retesting.
Test case library
Open the case libraryReviewed test cases
Safe, synthetic test cases: at least one case per testing domain plus selective additions for distinct boundaries, each with evidence-chain mapping and pass, fail and inconclusive conditions.
Practitioner kit
Open the templatesPractitioner templates
Six templates for test plan, test case, run record, evidence record, finding report and regression retest - from authorized plan to versioned retest.
Coverage
Open the coverage matrixCoverage matrix
Which test objectives the reviewed cases cover, partially cover or leave open - no scores, with required evidence and prioritized gaps.
Tooling
Open the Assessment BuilderAssessment Builder
Select reviewed cases and export an assessment plan as Markdown or JSON - in the browser only, nothing stored.
Representative test-case record
Future cases should be reviewable records rather than prompt snippets. Each record must define its oracle and evidence before execution.
Required fieldTest ID
Required fieldObjective
Required fieldSystem boundary
Required fieldPreconditions
Required fieldSource and trust assumptions
Required fieldSafe synthetic stimulus
Required fieldExpected model behavior, if relevant
Required fieldExpected deterministic control
Required fieldRequired telemetry and evidence
Required fieldPass condition
Required fieldFail condition
Required fieldInconclusive or unobserved condition
Required fieldCleanup and reset
Required fieldRegression tag
Reporting model
Report evidence and scope without upgrading possibility into fact. Findings should remain useful for remediation and retesting.
Report fieldScope and system version
Report fieldTested boundary
Report fieldObserved evidence
Report fieldAffected principal, resource, action and destination
Report fieldActual impact versus potential impact
Report fieldControl that held or failed
Report fieldReproducibility and run count
Report fieldRemediation owner and change
Report fieldRetest status
Report fieldResidual risk and evidence gaps
Entry points for practice and evidence
Use the architecture map to frame the chain, the control articles to define deterministic oracles, and the evidence libraries to calibrate claims.
Operational controls
Operational controls
Define exact oracles with Prompt Injection Detection, Agent Authorization, Information Flow Control and Incident Response. None is a complete testing solution alone.