# Prompt-Injection Control Matrix

- Version: 1.0.0
- License: Apache-2.0
- Maintainer: Signal Studio
- Updated: 2026-08-25
- Purpose: Map prompt-injection paths to preventive, containment, detection, and recovery controls.
- Boundary: This is a design-review aid, not a penetration-test result or proof that an agent is secure.
- Canonical: https://signalstudio.cc/resources/
- Guide: https://signalstudio.cc/guides/can-system-prompts-stop-prompt-injection/
- Book: https://signalstudio.cc/books/securing-ai-agents/

## How to use it

Start with one concrete workflow and one effect that matters. For every row, name the untrusted input, the decision it may influence, the authority available at that point, and the evidence retained after execution. A prompt can reduce accidental misuse, but the enforcement column must name a control outside the model.

| Injection path | Security decision at risk | Prevent or reduce exposure | Contain authority | Detect | Recover | Review evidence |
|---|---|---|---|---|---|---|
| User message directly asks the agent to bypass policy | Whether a proposed action is allowed | Separate policy text from user data; constrain accepted task types | Authorize each tool call against subject, resource, action, parameters, and time | Record denied proposals and policy reason codes | End the run or request a narrower task | Input provenance, proposal, decision, policy version |
| Retrieved webpage contains hidden or visible instructions | Whether retrieved data becomes control | Label retrieved content as untrusted evidence; minimize retrieved fields | Read-only retrieval token; no ambient write tools in the same step | Flag instruction-like patterns and unexpected domain changes | Discard the retrieval result and rebuild context from approved sources | Source URL, content hash, retrieval query, trust label |
| Tool description or tool output carries hostile instructions | Which tool is selected next | Treat tool metadata and results as data; pin reviewed tool definitions | Broker tools through a reference monitor; split read and write capabilities | Compare requested action with the declared workflow state | Revoke the run capability and quarantine the tool integration | Tool version, arguments, result digest, downstream proposal |
| Memory contains poisoned guidance from an earlier run | Which facts or preferences persist | Store claims with provenance, expiry, and purpose; never persist raw instructions by default | Scope memory reads and writes by tenant, user, workflow, and sensitivity | Detect provenance gaps, unusual write volume, and policy-like memories | Tombstone the record, rebuild derived memory, and review affected runs | Memory record ID, writer, source, policy, expiry, readers |
| Document or image contains cross-modal instructions | Whether content is interpreted as evidence or command | Apply media-specific extraction and trust labeling before model use | Keep high-impact tools unavailable during untrusted-content analysis | Compare extracted instructions with the user's declared task | Re-run in a read-only analysis profile and invalidate prior proposals | Original media hash, extractor version, derived text, trust decision |
| Another agent sends an instruction through a handoff | Whether delegated output expands the parent run's authority | Use a typed handoff contract with allowed objectives and data classes | Child receives a narrower capability envelope than the parent | Record handoff lineage and attempts to request unavailable tools | Cancel the child, return a typed denial, and preserve parent state | Parent run, child run, handoff payload, capability envelope |

## Minimum review questions

1. Can any model output directly trigger an effect without an independent policy decision?
2. Is the execution credential narrower than the user's standing access?
3. Can the same request be retried without duplicating an effect?
4. Can operators reconstruct which untrusted bytes influenced the proposal?
5. Is there a tested path to revoke authority and reconcile partial effects?

The matrix intentionally does not assign a universal risk score. Impact, likelihood, legal obligations, and acceptable residual risk depend on the workflow and must be reviewed by the owning organization.
