Prompt Injection Prevention: A Control-to-Regression Standard

Prompt-injection prevention becomes an operating problem once different teams own prompts, retrieval, tools, policies, and releases. This guide defines one prevention-to-regression standard: every protected capability is paired with a control, a test, an owner, and evidence that can block or approve a change. It complements the deeper implementation and testing guides rather than compressing them.

Define one prevention-to-regression standard

Start with a capability register, not a payload list. Each row names the untrusted input channel, protected tool or data class, caller identity, allowed destinations, deterministic prevention point, expected denial, and harmless target used for verification. The MCP protocol architecture is useful when a capability crosses an MCP client and server, but the row must still name the deployment's real identity and effect.

Assign a control owner and a test owner. They can be the same person in a small team, but both responsibilities must be visible: one maintains the boundary and the other confirms that a hostile input cannot cross it. A release owner decides what happens when evidence is missing.

Use an integrated control and test matrix

Read each row as a paired obligation: the left cell states what must stop the attack, and the right cell states what evidence must remain after the test. A row is incomplete when the prevention rule and regression proof describe different tools, identities, destinations, or effects.

Set ownership and release thresholds

Define a minimum release record for every changed capability: configuration version, affected matrix rows, allowed baseline, denied attack case, policy decision, final target state, and unresolved exception. Do not turn all failures into one percentage. A single test that gains a high-impact capability can block a release even when hundreds of text-only cases pass.

Exceptions need an owner, reason, compensating control, expiry, and a case that will be rerun when the exception closes. If the team cannot identify the changed boundary, pause the release and reduce the failure to the smallest reproducible input, tool call, and state change.

Handle failures as control defects

Classify the failed matrix row before changing the prompt. An authority failure means untrusted data changed policy. A scope failure means the agent saw an unnecessary tool. An argument failure means the right tool reached the wrong tenant or destination. An execution failure means a denial did not stop the side effect. Fix the owning boundary, then keep the minimized case as a regression.

Use the OWASP Prompt Injection guidance to expand attack channels and the NIST AI RMF Playbook to assign ownership and response work. Neither source supplies the pass/fail evidence for your application.

Use product evidence as one row in the operating standard

Mark the admission and execution cells as separate evidence obligations before assigning either one to a product result.

Use AgentGuard documentation to decide which matrix cell the integration can actually populate. Deep Scan fits the component-admission cell for the exact version under test; a selected Runtime Guard result fits the execution-observation cell only on a supported host.

The same row still needs application-owned authority, argument validation, target-state proof, and recovery evidence before it can support a release decision.

Version the standard with every release

Store the matrix beside the release evidence and update it when a model, prompt, retriever, tool, connector, identity, or policy changes. The standard succeeds when a reviewer can see which capability changed, which rows were rerun, what failed, who accepted any residual risk, and whether rollback restored the previous protection.