Summary
The output-guardrail PR (#544) scans the visible assistant text (output[].content[].text) on /v1/responses. It does not scan tool-call material in output[] — function_call / custom_tool_call items carry model-generated text in their name + arguments fields.
On /v1/chat/completions, ChatResponse::guardrail_output_text serializes tool_calls (name + arguments) into the scanned text — this was the #448 fix, closing exactly this hole. So a blocked literal emitted inside a Responses function_call.arguments bypasses the output guardrail on /v1/responses even though the chat equivalent is caught.
Scope
Severity
LOW — the visible-text echo concern #719 demonstrates is covered; this is the tool-call channel, asymmetric with chat. Surfaced by the independent audit of #544. Refs #719, #544, and the chat-side #448.
Summary
The output-guardrail PR (#544) scans the visible assistant text (
output[].content[].text) on/v1/responses. It does not scan tool-call material inoutput[]—function_call/custom_tool_callitems carry model-generated text in theirname+argumentsfields.On
/v1/chat/completions,ChatResponse::guardrail_output_textserializestool_calls(name + arguments) into the scanned text — this was the #448 fix, closing exactly this hole. So a blocked literal emitted inside a Responsesfunction_call.argumentsbypasses the output guardrail on/v1/responseseven though the chat equivalent is caught.Scope
responses_output_text(and the streamingresponses_sse_output_text) should also collectfunction_call/custom_tool_callname+argumentsfromoutput[], so tool-call output is scanned like chat's security: enforce guardrails through a unified request policy pipeline #448.Severity
LOW — the visible-text echo concern #719 demonstrates is covered; this is the tool-call channel, asymmetric with chat. Surfaced by the independent audit of #544. Refs #719, #544, and the chat-side #448.