Prompt Injection Assessment

---
name: prompt-injection-assessment
description: "Assesses whether direct, indirect, multi-turn, retrieved, or tool-mediated instructions can override an AI system's intended policy or scope. Use when conducting an authorized prompt-injection test with benign canaries and evidence-bound outcomes."
metadata:
  portability: universal
  discipline: penetration-testing
  domain: ai-systems
  tags: [prompt-injection, indirect-injection, guardrails, agents, evidence]
---

# Prompt injection assessment

Measure instruction integrity across every authorized input channel without
turning a response into a stronger claim than the evidence supports. Use inert
canaries and bounded effects instead of secrets, destructive actions, or
reusable bypass payloads.

## When to Use

- Testing direct, indirect, multi-turn, retrieved, or tool-mediated instruction
  handling in an authorized environment.
- Evaluating whether guardrails, canonicalization, role separation, and approval
  controls preserve stated security invariants.
- Reproducing a suspected prompt-injection path with a harmless observable.

## When NOT to Use

- Do not use this skill as permission to jailbreak a public or third-party
  system.
- Do not request secrets, destructive actions, persistence, or uncontrolled
  external effects as proof.
- Do not publish transferable bypass strings when a bounded test description
  and redacted evidence are sufficient.

## Preconditions

Require the named system, environment, identity, allowed channels, prohibited
effects, benign canary set, attempt and duration budgets, reset method,
monitoring owner, stop condition, and cleanup duty. Return a blocked plan when
these are absent.

## Evidence states

Keep these states separate:

1. `delivered` — test content reached the authorized input boundary.
2. `context-present` — runtime evidence shows it entered model context.
3. `instruction-influenced` — output or decision changed consistently with it.
4. `policy-bypassed` — a stated invariant failed under the test condition.
5. `action-influenced` — a tool or downstream action was selected or altered.
6. `effect-verified` — target-origin evidence confirms the bounded effect.

## Chain map

Map every case as `INPUT -> CONTEXT -> ACTION -> OUTPUT`. Record each node as
`supported`, `contradicted`, `missing`, or `not-applicable`, and bind every
supported node to its own receipt.

1. **INPUT** — where the test content entered, who or what supplied it, the
   tested identity and channel, and evidence that it reached the authorized
   input boundary.
2. **CONTEXT** — whether the content entered model context, what trust label and
   role it carried, and whether it influenced instructions, decisions, or a
   stated policy invariant. Context presence and influence do not by themselves
   prove policy bypass.
3. **ACTION** — what the model or agent selected or requested, whether approval
   occurred, whether the runtime dispatched it, and whether the target observed
   it. Keep selection, request, approval, dispatch, and target observation as
   separate claims.
4. **OUTPUT** — where resulting bytes or state were delivered: UI text, rendered
   content, a file, callback, API response, downstream agent, or target state.
   Record the receiving identity and target-origin effect evidence where
   available. Output existence is not automatically security impact.

Stop the chain at the first blocked, contradicted, or unsupported edge. Name
that boundary explicitly and keep every downstream action, output, or impact
claim unproven. A complete chain map reports both the foothold and the point
where the system prevented or failed to prevent consequence.

## Workflow

1. Record the policy or scope invariant in testable language before creating a
   test case.
2. Establish a clean baseline with the same identity, route, tools, retrieval
   state, memory state, model configuration, and ordinary task.
3. Assign one unique inert canary and run identifier to each case.
4. Build a channel matrix covering only authorized paths: direct user input,
   prior-turn context, retrieved content, tool results, files or messages, and
   agent-to-agent handoffs where present.
5. Build the `INPUT -> CONTEXT -> ACTION -> OUTPUT` map for the intended test,
   including the evidence required at each node and the first boundary that
   would stop the chain.
6. Vary one instruction-control factor at a time: placement, trust label,
   multi-turn accumulation, canonicalization, role framing, boundary splitting,
   or conflict with higher-priority policy. Describe the family; do not emit a
   public payload catalog.
7. Capture input, context receipt where available, model output, policy decision,
   tool request, approval event, runtime dispatch, target receipt, telemetry,
   final state, and reset receipt.
8. Compare against the baseline. Treat nondeterminism, route changes, cache,
   memory, retrieval, and policy-version drift as alternative explanations.
9. Grade each case `resisted`, `influenced-no-bypass`, `policy-bypassed`,
   `inconclusive`, `blocked`, or `not-tested`.
10. Stop on unexpected privilege, sensitive disclosure, cross-tenant effect,
   monitor loss, cleanup failure, or exhausted budget.
11. Reset context and state between cases; record any residual influence.

## Boundary with adjacent skills

- Use `agent-runtime-validation` for broader runtime controls, hooks, memory,
  approval binding, and tool behavior.
- Use `agent-trust-boundary-audit` to map authority and identity propagation.
- Use `agent-action-proof` to grade downstream action and impact receipts.

## Deliverable

Return the tested invariants, channel matrix, `INPUT -> CONTEXT -> ACTION ->
OUTPUT` map, exact chain-stop boundary, baselines, per-case evidence state,
control grade, alternative explanations, stop events, residual influence,
cleanup status, and focused remediation. Keep exact sensitive test content in
a restricted evidence reference.

## Rationalizations to reject

- **“The model repeated the canary, so the guardrail was bypassed.”** Repetition
  proves influence, not failure of a stated invariant.
- **“A refusal means the whole system resisted.”** Tools, hooks, or downstream
  consumers may still have acted.
- **“The agent requested the tool, so the action happened.”** Selection and
  request do not prove approval, runtime dispatch, target observation, or
  effect.
- **“Encoding makes it a different vulnerability.”** Classify the failed
  boundary and canonicalization behavior, not the novelty of the string.
- **“More variations will eventually prove it.”** Stop at the approved budget;
  repetition without a new hypothesis adds noise.
- **“A stronger payload would be more realistic.”** Proof should minimize harm,
  not maximize consequence.
- **“One successful response proves deterministic exposure.”** Preserve model
  variability and reproduce only within the bounded plan.