Keep an injection regression corpus with the tool owner

Store the expected effect with the fixture

An injection fixture needs more than a provocative paragraph. Keep the legitimate user task, untrusted input, targeted capability and prohibited outcome together. Include any required source records and a controlled destination for observing side effects.

Use synthetic data where practical. The corpus should be safe to run during normal development without copying customer documents or creating real external actions. A test that requires production credentials is difficult to maintain and easy to misuse.

Record why the case exists. A short explanation such as "supplier text attempts to change the export destination" gives future maintainers a mechanism to preserve when prompts and tools evolve.

Give ownership to a capability team

Prompt specialists can help improve behaviour, but the executor owner controls the final authority boundary. That team should review regression results when changing schemas, permissions, destinations or retry handling.

Name a coordinator for failures that cross teams. A case may begin in document extraction, persist through conversation memory and end in a tool call. Without coordination, each team can report its component working while the combined route remains unsafe.

Keep a map from capabilities to relevant fixtures. When a new tool replaces an old one, its tests should follow the power being transferred rather than being deleted with the old function name.

Make results reproducible

Save application policy, model configuration and fixture versions with each run. Record the proposed action and observed effect, not only the final assistant message. Preserve enough trace information to identify the failed boundary while respecting data access rules.

Explain how to distinguish an inconclusive run from a blocked attack. A payload that never reached the model, a harness timeout and a policy denial are different outcomes. The receiving team should be able to interpret the report without asking its original author.

Maintain benign fixtures alongside adversarial ones. They show whether a protective change has broken useful work, such as summarising a document that quotes instructions for discussion.

Rehearse a capability change

During handover, add a harmless test capability or alter an existing destination rule. Have the receiving team select the relevant tests, run them and explain the result. This reveals whether the corpus is organised around real authority boundaries.

Agree when the suite runs and who can accept unresolved failures. Consequential execution failures should have a clear escalation route and a capability-level disable mechanism. A maintained corpus becomes part of ordinary release work, rather than a security exercise that is forgotten after the first launch.