Antigravity Gemini 3.8 Flash: PROHIBITED_CONTENT despite safetySettings=OFF, with inconsistent outcomes

Google Antigravity
, , ,
1

Antigravity Gemini 3.8 Flash: PROHIBITED_CONTENT despite safetySettings=OFF, with inconsistent outcomes

Hi,

I’m investigating inconsistent safety behavior on the Antigravity / Cloud Code Assist serving path for gemini-3.8-flash-tiered.

I verified in the final HTTP payload, immediately before dispatch, that the request contains explicit safetySettings with the supported harm categories set to OFF, including:

{
  "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
  "threshold": "OFF"
}

The requests are accepted with HTTP 200.

However, on the Antigravity path, the same model has produced three distinct outcomes for adult consensual fictional content:

  1. Textual refusal

    • finishReason: STOP
    • normal HTTP 200
    • no safetyRatings
    • no promptFeedback
    • no blockReason

  2. Normal completion

    • finishReason: STOP
    • several thousand output tokens can complete normally

  3. Generation begins normally and is later terminated

    • native finishReason: PROHIBITED_CONTENT
    • HTTP 200
    • the stream may already contain substantial generated text before termination
    • no visible reasoning
    • no safetyRatings, promptFeedback, or blockReason observed in the captures

Some observed examples from gemini-3.8-flash-tiered:

Outcome Chunks Visible chars Approx. duration
PROHIBITED_CONTENT 34 3,117 ~30.5 s
PROHIBITED_CONTENT 163 15,424 ~25.8 s
PROHIBITED_CONTENT 26 2,350 ~7.5 s
PROHIBITED_CONTENT 19 1,590 ~7.3 s
STOP 151 14,167 ~21.9 s
STOP 167 15,821 ~24.6 s
STOP 33 2,809 ~9.6 s

The same provider account has produced both STOP and PROHIBITED_CONTENT.

This means the behavior does not appear to be explained by a simple threshold based on:

  • output length;
  • number of chunks;
  • generation duration;
  • provider/account selection.

I also tested omission of Antigravity body metadata:

  • requestType: "agent"
  • body userAgent: "antigravity"

Removing either or both did not change the observable model routing (gemini-3.8-flash-tiered) or the textual-refusal behavior in the controlled test.

The HTTP User-Agent remained unchanged during those tests.

What I am trying to understand

I am specifically trying to understand the API contract of safetySettings on the Antigravity / Cloud Code Assist path.

Questions

  1. Does safetySettings: OFF apply to PROHIBITED_CONTENT, or only to the configurable harm-category filters that normally expose safetyRatings / SAFETY?

  2. Is PROHIBITED_CONTENT generated by a separate, non-configurable serving-side policy?

  3. Does Antigravity / Cloud Code Assist apply additional product-level safety policy beyond the supplied Gemini safetySettings?

  4. Is a model-generated textual refusal with finishReason: STOP expected even when the relevant harm category is explicitly set to OFF?

  5. Is it expected that regenerated/equivalent requests may alternate between normal completion and PROHIBITED_CONTENT?

  6. Is there any additional response metadata that clients should inspect to determine which safety layer caused PROHIBITED_CONTENT?

  7. Is the behavior of safetySettings intentionally different between:

    • Antigravity / Cloud Code Assist
    • Vertex AI
    • Gemini API / AI Studio

  8. When a request returns HTTP 200 and later terminates with PROHIBITED_CONTENT, should clients treat that as:

    • configurable safety filtering,
    • non-configurable policy enforcement,
    • or a separate serving-layer termination condition?

Related observation

I am aware of previous reports where the Antigravity builder omitted safetySettings, causing Google Cloud Code to apply its own defaults and return PROHIBITED_CONTENT.

That specific issue does not appear to explain this case, because here the final request payload has been captured and safetySettings is present on the wire with the relevant categories set to OFF.

So the main question is whether PROHIBITED_CONTENT belongs to a different enforcement layer than the configurable Gemini safety filters.

I’m not asking how to bypass safety policy.

I’m trying to understand which configuration fields are actually authoritative on this serving path, and which response metadata clients should use to distinguish configurable safety filtering from other server-side enforcement.

I can provide sanitized final request payloads, raw SSE traces, timestamps, and exact finishReason captures if useful.

2

Hi @Rick2030,

Welcome to the Forum,

The safetySettings configuration in your request (where you set thresholds to OFF) only applies to the four standard configurable harm categories (Harassment, Hate Speech, Sexually Explicit, and Dangerous Content). Setting these to OFF does not disable the PROHIBITED_CONTENT filter.

PROHIBITED_CONTENT belongs to a separate, mandatory, global enforcement layer that cannot be disabled by clients. It triggers when system heuristics detect potential violations of the core API Terms of Service.

Advanced models like Gemini 3.8 Flash utilize dynamic reasoning paths. When generating long-form creative content or operating within an agent loop, the model takes a slightly different internal “chain of thought” on every execution.

While you are generating consensual fictional content (which is permitted when the Sexually Explicit filter is OFF), the model’s dynamic generation might occasionally produce text—or internal reasoning—that closely resembles topics covered by the mandatory PROHIBITED_CONTENT heuristics. When it crosses this strict threshold, the serving layer terminates the stream immediately with PROHIBITED_CONTENT.

On the next run, the model might take a different narrative path and complete normally with a STOP reason. Alternatively, if the model’s own internal alignment training decides a prompt is unsafe, it will natively generate a textual refusal and also end with a STOP reason—this happens independently of your API safety settings.

To handle this, when a request terminates with PROHIBITED_CONTENT, clients should treat this as a non-configurable policy enforcement termination.

To mitigate this in creative writing or fictional generation workflows:

  • Audit your instructions: Look for ambiguous relational dynamics or scenarios in your prompts.
  • Constrain the reasoning: Add explicit boundaries to your system prompt instructing the agent to strictly maintain clear guardrails that do not resemble non-consensual or prohibited themes.

The behavior of safetySettings and the overarching PROHIBITED_CONTENT layer is consistent by design across the Gemini API, AI Studio and Antigravity.

3

Thanks, this clarifies the distinction substantially.

One remaining implementation question:

Is there any response metadata, subreason, diagnostic field, or header that allows a client to determine which mandatory-policy heuristic caused PROHIBITED_CONTENT?

I ask because there are also recent reports of apparently benign workloads, such as OCR of Czech-language PDFs, receiving the same PROHIBITED_CONTENT finish reason and a generic prohibited-use message.

From the client side, that means the same terminal reason may represent very different underlying situations, including potential false positives.

If no additional diagnostic metadata is exposed, should clients treat PROHIBITED_CONTENT as an opaque mandatory-policy termination?

Also, given that you mentioned a subsequent run may take a different generation path and complete normally, is automatic retry/regeneration considered appropriate client behavior for PROHIBITED_CONTENT, or should it always be surfaced as a terminal result to the user?