403 PERMISSION_DENIED on generateContent with file_data.file_uri since 2026-08-14 ~11:40 UTC (uploads and text-only OK)

Gemini API
,
1

Since 2026-08-14 ~11:40 UTC, every generateContent request that references a Files API file fails with 403 PERMISSION_DENIED — "The caller does not have permission". No code or config change on our side (zero occurrences of this error in the previous 90 days, then an abrupt start).

What works vs. fails, with the same API key:

  • files.upload / files.get / files.list → OK, file reaches ACTIVE, ~48h from expiry
  • generateContent text-only → OK (gemini-3.1-pro-preview and gemini-3.6-flash both answer)
  • generateContent with a file reference → 403 on both models, with both payload shapes (the python-genai typed File object and a raw file_data dict)

Minimal repro (python-genai):

client = genai.Client(api_key=API_KEY)
f = client.files.upload(file="doc.pdf")        # OK, state=ACTIVE
client.files.get(name=f.name)                  # OK
client.models.generate_content(                # 403 PERMISSION_DENIED
    model="gemini-3.6-flash",
    contents=[f, "Reply with the single word OK."],
)

Ruled out on our side:

  • Reproduces identically with 3 different API keys across 2 unrelated GCP projects — one paid-tier project with API-restricted keys, plus the unrestricted free-tier AI Studio default key of a separate project. So: not key restrictions, not project config, not billing tier.
  • Cloud audit logs show zero admin activity in either project around the onset (checked 10:00–12:30 UTC and the full last 7 days).
  • No VPC Service Controls perimeter, billing account active and paid, quotas nowhere near limits.
  • Files are freshly uploaded and ACTIVE — not expired or failed.

This looks like a server-side regression in the internal file-permission check that generateContent performs when resolving file_data.file_uri — everything a client can call directly works; only the server-to-server file fetch inside generation is denied.

Is anyone else seeing this since ~11:40 UTC today? Any acknowledgement from the Gemini API team would be appreciated — this breaks all document/media workloads that rely on the Files API (inline base64 still works as a fallback).

2

Hello @Massi ,

We recently rolled out a fix that should have resolved this issue. Request you to retry and let us know if you still face the issue.