Safety Filters Must Cover Tool Side Effects

Harm travels through tools

A classic failure: the model refuses to write instructions for something dangerous in chat, then cheerfully calls a browser, mailer, or code tool that does it anyway. APRF Safety & Responsible AI calls out filters that only watch output text while tool-mediated side effects go unchecked.

An ops agent once blocked toxic completions in the response path but left `send_email` and `create_ticket` open. Injected ticket text steered a bulk outbound message. The refusal classifier never saw the payload—the tool did.

Mediate the action path

1. Map harm categories to tools: which actions are disallowed entirely, which need HITL, which need argument scanners.

2. Inspect arguments and destinations before execution (URLs, recipients, file paths, payment amounts)—not only the model's prose summary.

3. Fail closed when the safety classifier or policy service errors on high-severity classes.

4. Block tools by default for categories your product will not assist with—even if the chat tone stays polite.

5. Log policy ID, tool name, and decision next to the request ID (minimize sensitive content).

Chat refusals, Tool Safety allowlists, and Human Approval are complementary. Safety policy names what must not happen; Tool Safety enforces whether the tool exists; HITL holds irreversible calls.

Test what the tool would have done

Safety evals must include tool-call proposals and argument payloads for your harm taxonomy—not only string completions. If your suite never asserts `send_email` was denied, you have not tested production.