test_team_with_disable_flag_bypasses_global_guardrail created a default-on
content filter and asserted that a key on a team with disable_global_guardrails
got a successful response. It never checked the guardrail was enforcing, so any
reason it was inert (keyword never matching, default_on not applied, a partial
create) made the call succeed for the wrong reason and the test pass. A
completely broken disable_global_guardrails stayed green.
Prove enforcement on a key outside the opted-out team first, then assert the
bypass, and check the response is the model's own answer rather than the
content-blocked message by requiring the model was actually invoked. That
mirrors what the block_code_execution suite already does, and it holds up on a
thinking model where a low max_tokens budget can leave the text empty.
Verified against a live proxy on real gemini-2.5-flash: both tests pass, and
with the guardrail registered under a keyword absent from the prompt the old
shape still passed while the new one fails on the enforcement check.
171660ab96