Review the controls with the detection prompt removed

Ask for a direct executor demonstration

In a test environment, bypass the model and submit an unauthorised proposed action directly to the executor. Use a real operation shape with a target the caller cannot access. The request should fail because of an application policy, not because a model recognises suspicious wording.

Repeat with an allowed target and an unapproved destination. Then use an approval record belonging to a different payload. These cases test separate authority checks and reveal whether the implementation has collapsed them into a broad "approved" flag.

There is no need to disable production controls to perform this review. A test harness can exercise the executor independently and preserve the result.

Inspect every route with equivalent power

List tools by capability rather than their display names. A generic HTTP client, file uploader or report attachment feature may provide the same export route that a restricted email tool blocks.

Check read capabilities too. If an assistant can retrieve unrelated confidential records, preventing an external send operation does not stop those records appearing in its answer. The user-facing response is itself a data-release path.

Review resumed jobs and retries. An operation queued while a user had access may execute after that access changes. The design needs an explicit rule for when authority is checked again.

Examine how detection changes behaviour

Ask what happens when the detector times out, returns an uncertain result or flags an ordinary document. A fail-open path may be acceptable for a non-security quality hint, but it should not silently bypass required authorisation. A fail-closed path can cause availability problems if applied too broadly.

Look at the evidence behind detector thresholds. Include benign procedural text and security examples, not only obvious attack phrases. The review should explain false positives and false negatives in terms of the actual workflow.

Detection results should help containment and investigation. They should not become the only reason a tool is considered safe to execute.

Finish with an observable attack case

Use a synthetic document to request an unauthorised action, then inspect the proposed call, policy decision and controlled destination. Verify the final response does not misrepresent what happened.

Record any boundary that depends entirely on model behaviour. For each one, decide whether the capability should be reduced, the executor strengthened or the use case restricted. A successful review produces evidence that the application retains authority even when the model interprets external text badly.