Genace
Sign inGet started

IMAGE_PROHIBITED_CONTENT — Gemini API image blocked (Nano Banana finishReason)

finishReason Do not retry as-is

The exact error 

The model output could not be generated. This output contains sensitive words that violate Google's Responsible AI practices. If you think this was an error, send feedback.

What it means

IMAGE_PROHIBITED_CONTENT is a finish reason on Gemini image generation. It means Google’s content policy blocked the image before it was produced. Google’s API errors page lists image_prohibited_content under “Generation blocked codes” and describes it as prohibited content guidelines blocking image generation. That is a different entry from image_safety, which the same page ties to safety violations.

The clearest public example is litellm issue #20357. The reporter was using Nano Banana models (Gemini 2.5 Flash Image and Gemini 3 Pro Preview Image). The raw response they posted, from gemini-3-pro-image-preview, has three notable features:

  • finishReason is IMAGE_PROHIBITED_CONTENT.
  • The candidate’s content holds only "role": "model", with no parts, so there is no image and no text.
  • A finishMessage gives the human-readable reason and ends with a support code.

The usageMetadata block in that response still reports prompt tokens and thinking tokens, so the model did work before the output was blocked.

How to confirm it’s this

  1. Read candidates[0].finishReason. It is IMAGE_PROHIBITED_CONTENT.
  2. Read candidates[0].finishMessage. In the litellm report it said the output contained sensitive words that violate Google’s Responsible AI practices, invited feedback, and included a support code.
  3. Check that content has no parts. An empty candidate with this finish reason is the expected shape, not a transport error.

If you call Gemini through a proxy or SDK and just get an empty completion, look at the raw upstream response. In litellm issue #20357, the reporter noted that LiteLLM did not map this finish reason. As a result, callers received an empty response with finish reason stop, which looks like a normal but blank answer. The fix was merged in LiteLLM PR #20524, titled as mapping IMAGE_PROHIBITED_CONTENT to content_filter. If your gateway reports stop with no content on an image call, suspect this, and check how your gateway version maps Gemini finish reasons.

If you use the Interactions API, Google’s errors page says errors come back as an error object with a snake_case code. There, look for image_prohibited_content.

Fix

This is a policy decision on the content, not a malformed request, and no documented parameter turns it off:

  1. Branch on the finish reason before reading image data. Treat IMAGE_PROHIBITED_CONTENT as a terminal, blocked result. Do not treat it as success with a missing file.
  2. Keep the finishMessage and support code. Log them with the model name and the responseId. If you think the block is wrong, the message itself tells you to send feedback. Keep the support code with your report.
  3. Tell the end user plainly. An agent should say that Google blocked the image under its content policy. It should not silently return nothing or rewrite the user’s request on its own.
  4. Map it correctly in your own layer. If you normalize finish reasons across providers, map this one to your “content filtered” state, as LiteLLM did in PR #20524, not to a normal stop.
  5. Do not expect safety thresholds to change it. Google’s safety settings page lists four adjustable harm categories and says built-in protections against core harms cannot be adjusted. It does not list prohibited-content blocks among the settings you can change.

Retry or not

Do not retry the same request automatically. Google’s errors page says that for generation-blocked codes you should modify your input and then retry. The change has to come from whoever owns the request. Resending the identical input from an agent loop has no documented chance of a different result. Going by the usageMetadata in the litellm report, it can also consume tokens before the block.

A retry only makes sense after a person has deliberately revised the request, or after Google has responded to feedback on a suspected false positive.

When it’s not this

  • IMAGE_SAFETY: a sibling finish reason for safety violations, not prohibited content guidelines. You handle it the same way, but log it separately.
  • PROHIBITED_CONTENT without the IMAGE_ prefix: Google’s errors page lists this for blocked requests in general, not specifically image generation.
  • promptFeedback.blockReason is set: Google’s safety settings page says this means the prompt itself was blocked.
  • An HTTP 429 or 503 error: that is quota or capacity, reported as an HTTP error rather than as a finish reason. Check the status code first.

Error text last verified against the sources below on .

Where these facts come from