I am requesting a technical assessment of the behavior of a legacy Google AI Studio deployment on Cloud Run.
This is not a billing-support request. Google Cloud Billing Support instructed me to obtain a technical assessment from the Google AI Studio / Gemini API team because Billing Support could not investigate the product behavior described below.
Summary
I used Google AI Studio to generate a simple live-audio transcription application and deployed it through the AI Studio Cloud Run deployment flow.
The application did not implement image generation and did not use several of the Gemini models later observed in the logs. The API key was stored as a server-side environment variable.
In June 2026, Cloud Run request logs recorded repeated POST requests from external IP addresses directly to the following public endpoint:
/api-proxy/v1beta/models/[caller-selected-model]:generateContent
The external callers did not need to know or submit the API key. The AI Studio-generated proxy added the server-side key when forwarding each request to the Gemini API.
The retained logs contain more than 10,000 requests. Depending on the day, approximately 100 to 2,000 requests were recorded.
Examples include requests to models that were not used by the audio transcription application:
gemini-3-pro-image:generateContent
gemini-3.1-flash-image-preview:generateContent
gemini-3.1-pro-preview:generateContent
gemini-2.5-flash:generateContent
gemini-2.5-flash-lite:generateContent
Many requests returned HTTP status 200. The logs also show automated clients such as:
Go-http-client/2.0
The requests originated from multiple external IP addresses and reached the Cloud Run service created for the live-audio application.
Expected behavior
A public user of an AI Studio-generated application should not be able to use its backend proxy as a general-purpose Gemini API endpoint.
The proxy should enforce at least one or more of the following:
- authentication at the public entry point;
- an allowlist of models and API routes actually used by the application;
- validation of the requested model and operation;
- rate limiting and abuse controls.
Actual behavior
The legacy /api-proxy/ endpoint appears to have accepted a Gemini API path supplied by the external caller.
The caller could select models and operations unrelated to the application. The proxy then forwarded the request using the server-side API key.
This means the external caller did not need to extract, expose, or directly use the API key.
Why API key restrictions did not prevent this behavior
I received notices from the Gemini API Team on June 12 and June 19, 2026, stating that the project contained at least one unrestricted API key.
The notices instructed me to restrict the key to the Gemini API (generativelanguage.googleapis.com) or replace it with a key generated by Google AI Studio. They also stated that unrestricted keys would no longer be accepted after June 19.
However, successful /api-proxy/ requests continued after June 19. For example, retained logs from June 28 show external requests returning HTTP status 200.
This appears to be a different security path from direct use of an unrestricted or leaked API key:
- Restricting the key to the Gemini API does not prevent the abuse because the proxy is being used specifically to call the Gemini API.
- The external caller does not present the API key.
- An IP restriction would see the Cloud Run proxy as the Gemini API caller, rather than the external client that sent the original request.
- The June notices did not state that existing AI Studio Cloud Run deployments contained a caller-controlled public
/api-proxy/. - The notices did not instruct owners to disable, authenticate, patch, or redeploy existing AI Studio applications.
I have attached an illustrative diagram showing why API key restrictions alone do not distinguish legitimate application use from requests sent through an unauthenticated public proxy.
The diagram is based on the retained Cloud Run request logs and is intended only to explain the request flow.
Related prior disclosure
A public security disclosure appears to describe the same or a closely related legacy AI Studio Cloud Run proxy behavior:
https://github.com/qudent/qudent.github.io/blob/master/_posts/2026-01-16-aistudio-proxy.md
My retained Cloud Run logs show that similar behavior was actively used against an existing deployment after the issue had reportedly been raised with Google.
Questions for the Google AI Studio / Gemini API engineering team
-
Was it intended behavior for a legacy AI Studio Cloud Run deployment to accept a caller-controlled Gemini model and API path through
/api-proxy/? -
Was the external caller expected to be able to invoke models and operations that were not used by the application?
-
Was the deployment-flow change reportedly made around March 2026 applied only to newly deployed applications?
-
Were existing deployments automatically updated, disabled, or migrated?
-
Were owners of affected legacy deployments notified that they needed to stop or redeploy their applications?
-
Was the June 19 unrestricted-key enforcement expected to protect legacy
/api-proxy/deployments? -
Why did successful proxy requests continue after June 19?
-
What mitigation, other than disabling or redeploying the application, would have prevented external callers from using the public proxy?
-
Does Google classify this behavior as expected use, abuse of an intended feature, or a product security/design issue?
I can privately provide Google staff with:
- complete Cloud Run request logs in JSON format;
- timestamps and request statistics;
- deployment and revision metadata;
- application source code;
- screenshots of the relevant log entries;
- the Gemini API Team notices dated June 12 and June 19.
I have intentionally omitted the live hostname, project ID, API key, billing-account information, and complete source IP addresses from this public post.