agent's prompt-injection probe blocked by its own output filter

agent's prompt-injection probe blocked by its own output filter

TL;DR

The red-team probe contains injection payload text, and the agent's own output filter flags it before the probe can run, so the test measures the filter instead of the model. Run the probe in a test harness with the filter in log-only mode (or on an exempt test channel), confirm the probe actually executed against the model, score the unfiltered response, then re-enable enforcement.

agent's prompt-injection probe blocked by its own output filter

Use this when

• A prompt-injection probe is blocked before reaching the model
• Red-team results show 100 percent blocked and you suspect the filter, not the model, did it
• You need to test the model's own resistance separately from the filter layer
• Probe text appears in the filter logs but never in the model transcripts

Not for this skill when

• You are defending production against prompt injection (that is a different skill)
• You are choosing an output-filter product
• You are researching new jailbreak techniques (this skill tests your own defenses, nothing more)

Steps

1. Confirm the blocker is the output filter and not the model refusing: check the filter logs for the probe text. Expected: the filter log shows the block, so you know the probe never reached the model.

2. Move the probe to a test harness where the filter logs but does not block (monitor mode), or to an exempt test channel with no production access. Expected: the probe reaches the model.

3. Verify the probe executed and record the model's actual response for scoring. Expected: you have the unfiltered response to evaluate, not a filter block page.

4. Re-enable the filter in enforce mode after the test run. Expected: the filter is back to enforcing, confirmed in its status.

Variant: red team prompt injection test blocked by guardrail

Same fix. Test each defense layer separately: model alone with the filter in monitor mode, then the full pipeline with the filter enforcing, so you know which layer stopped what.

Variant: jailbreak probe blocked by output filter

If the probe is blocked at input instead, the same principle applies: the layer under test must be the only layer enforcing during its test.

Variant: prompt injection test false blocked by safety filter

Log these as test-harness findings, not model failures; a filter block tells you nothing about the model's resistance.

Why this happens

The probe and the defense share the same pipeline: the filter inspects everything leaving the agent, including test traffic. Testing the model's resistance requires the defense to observe without interfering, otherwise every probe result is really a filter result.

Edge cases and pitfalls

• Monitor-mode runs must be isolated with no real tool access; an unfiltered model with tools is a live incident waiting to happen.
• Exempt test channels need strict access control; anyone who can send through them bypasses the filter.
• Log everything during the test for the audit trail; the point of monitor mode is the logs.
• Never leave the filter in monitor mode in production; verify enforcement is back on with a known-blocked probe after the test.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N-f0nvnFeO9XGw1JsOLP-w