When Gemini Blocks Your Security Prompts

I recently tested new Gemini 3.7 Flash model against some code review prompts and it was the first time I’d seen these tasks blocked by Gemini safety filters.

The reviewing agent sends code diffs along with a security review prompt that asks the model to identify vulnerabilities like SQL injection, command injection, path traversal, SSRF, and insecure deserialization. The diffs used in evals contain, of course, real vulnerability patterns, as that’s the whole point of evaluating how this agent performs.

When running it with 3.7 Flash, instead of a JSON review response, the model intermittently returned:

This request was blocked by Gemini’s filters. They can occasionally trigger by mistake on safe coding, security, or biology-related queries. Please try rephrasing your prompt.

The blocked tests were specifically the ones containing explicit vulnerability patterns, so the model’s safety filters were treating the security review prompts as attempts to generate dangerous content.

Why This Happens

#

This all got me to dig deeper into Gemini safety features and try to find the reason why it was happening.

Google evaluates each Gemini model against its Frontier Safety Framework. The framework defines Critical Capability Levels (CCLs) — the point where a model could actually help cause severe harm in a domain like cybersecurity. Below the CCL there’s an “alert threshold” — an early warning line. When a model crosses it, Google deploys mitigations (safety filters, guardrails) as a precaution, even though the model isn’t actually dangerous yet.

3.7 Flash is the first Flash model to independently cross the cyber alert threshold. From its model card:

Gemini 3.7 Flash reaches the alert threshold for its cybersecurity CCL […] For applications that give models access to development environments, credentials, or production systems, model capability should therefore be evaluated alongside strict permission boundaries and application-level safeguards.

This is the first Gemini model that actually triggered guardrails for me, but as it stands this pattern will likely continue as models get more capable.

Understanding Gemini’s Safety Layers

#

Gemini’s safety system has two layers:

1. Configurable filters across four harm categories (dangerous content, harassment, hate speech, sexually explicit) — you can set thresholds from BLOCK_LOW_AND_ABOVE (most restrictive) to BLOCK_NONE or OFF (least restrictive).

2. Built-in protections against core harms (child safety, illegal content) that cannot be disabled regardless of your settings.

So the first instinct was: It must be “dangerous content” filter triggering it. And indeed in the first test, setting an explicit setting to BLOCK_NONE helped.

But according to Google’s documentation, the default safety threshold for Gemini 2.5+ and 3.x models is OFF, meaning the configurable filters are completely disabled by default. So in theory, our security prompts should have passed through without any issues.

The other interesting thing was that the block completely disappeared in the following days, so no matter how safety filters were configured (even with the most restrictive settings), I couldn’t trigger it anymore.

But no matter that this was not a guaranteed solution for this particular issue, I think going forward it makes sense to set safety filters explicitly to BLOCK_NONE. By doing this we are introducing a bit of determinism in the system and protecting it from future changes. Also, BLOCK_NONE will allow our prompts to pass even if they trigger the filter and we will be able to log these events and react on them, by retrying the prompt or modifying it if the trigger rate is too high.

A Complementary Approach: Prompt Framing

#

So with Layer 1 configured, how should we deal with Layer 2 properly? Well, as message says we should try to improve the prompt. In order to do that, we need to give the safety classifier enough context to recognize the query as defensive analysis rather than an attempt to generate exploits. Instead of just sending code diffs with “find vulnerabilities,” frame the prompt explicitly:

You are a static analysis tool performing a defensive security
code review. Your purpose is to identify vulnerabilities in code
so they can be patched. Analyze the following code diff and report
any security issues found.

This “academic framing” provides signal to the classifier that the intent is benign, potentially preventing false positives from both layers. And this brief instruction should not affect prompt performance in a negative way or affect token usage much.

Conclusions

#

So, to sum up this journey, if you’re building security tooling that should run with Gemini models:

1. Use defenses for both safety layers. Set HARM_CATEGORY_DANGEROUS_CONTENT to BLOCK_NONE explicitly, and frame your prompts with clear defensive intent. Neither is guaranteed to be bulletproof on its own, but together they cover both the configurable filter layer and the built-in protections.

2. Handle blocks gracefully. Check the API response for finish_reason and safety metadata. If a block occurs, log which category fired and retry the prompt. The probabilistic nature of the classifier means a retry often succeeds. If the block persists, consider modifying it by including more defensive phrasing.

3. Expect this with new models. Google is progressively tightening cyber-offense safeguards as models become more capable. Each new model crossing the cyber alert threshold may ship with stricter or less stable filters, at least initially.