Preserve the document that changed agent behaviour

Establish what happened outside the conversation

Find the execution records for the reported action. Determine whether the assistant merely described an operation, proposed a tool call or caused a side effect. Check the downstream system where possible. A chat transcript alone is not authoritative evidence of execution.

Capture the request identifier, tool arguments, policy decision and operation result. Keep the model and prompt configuration identifiers too. Restrict access to the incident record because tool arguments and retrieved material may contain sensitive business data.

If the action is still running or can repeat, use the supported capability switch, job cancellation or credential restriction to contain it. Choose the narrowest control that reliably prevents further effects, and verify that alternate tools cannot perform the same operation.

Preserve the actual input

Retain the source document version or a controlled copy, its extraction output and the passages supplied to the model. The visible PDF or web page may differ from what the parser extracted. Hidden text, attachment fields or a tool response may explain the unexpected instruction.

Do not overwrite the source in an attempt to clean it up before preserving evidence. If removal is needed for containment, keep the authorised incident copy separately with an appropriate retention rule.

Trace any saved summaries or memory records created from the input. A hostile instruction can continue influencing later turns through derived content even after the original source is excluded.

Find the missing authority check

Reconstruct the route from external content to proposed action. Identify which application rule should have denied it and whether that rule ran. Common questions include whether the target belonged to the caller, the destination was approved and the operation required a separate confirmation.

If the executor behaved correctly and denied the request, the incident may be a contained attempt. Still investigate repeated attempts, misleading user messages and unnecessary data exposure. A denied write does not prove that all preceding reads were appropriate.

Avoid treating a new detection phrase as the complete repair. The next input can express the same request differently. Fix the concrete capability or access gap and use prompt changes as an additional measure where useful.

Reproduce before restoring the capability

Build an isolated regression case from the incident using synthetic records. Confirm the prohibited effect is blocked and that the legitimate task still works. Test equivalent routes through other tools and resumed jobs.

Restore access gradually according to the incident's consequence and available monitoring. Record affected data or actions, recovery work and the control that now prevents recurrence. Keep the reproduction owned by the team responsible for the capability, so future tool changes exercise it automatically.