Google Says Pre-July Agent Studio Web Apps Need Regeneration After SSRF Fix
Google Cloud has fixed a server-side request forgery vulnerability in the backend code that Agent Studio generated for web applications. The affected component is the auto-generated /api-proxy endpoint in apps created before July 1, 2026. Google’s July 20 security notice tells anyone who downloaded, generated, or deployed that code before the cutoff to regenerate the application in Agent Studio and deploy the new version.
This is not a console-only repair that automatically reaches code already exported into a customer project. The vulnerable artifact is generated application code. An existing deployment remains a remediation target until its owner replaces it and verifies that the old revision is no longer serving traffic.
Google’s notice does not assign a CVE, severity score, exploitation status, or detailed impact statement. It identifies the weakness class as SSRF and says the updated backend performs strict destination-domain allowlist validation. Defenders should preserve that boundary: the confirmed facts support urgent regeneration and exposure review, but not unsupported claims that credentials or internal services were accessed.
The proxy needed a destination policy
Agent Studio lets a builder turn a prompt into a shareable web application. Its generated backend mediates requests to the managed AI service through /api-proxy. A server-side proxy is a security boundary because the server—not the browser—makes the outbound connection and may have network reach or an execution identity unavailable to an external caller.
Google says the replacement code validates that destination hostnames end with approved Google Cloud domains, giving *-aiplatform.clients6.google.com as an example. That changes the proxy from a generic destination mechanism into one constrained to the service endpoints the application is intended to reach.
The release note does not publish the vulnerable implementation, bypass syntax, authentication preconditions, or the exact resources reachable from a deployed app. Teams should therefore test their own deployment rather than infer impact from the SSRF label alone. Relevant context includes whether the application was public, what authentication protected it, where the backend ran, which service account it used, and what private routes and metadata services were available from that runtime.
Regeneration is a source and deployment migration
Regenerating code addresses only the first half of the repair. Teams must compare the new output with their maintained application, reapply intentional customizations without restoring the old proxy logic, build the result, deploy it to every active environment, and retire previous revisions. A generated-code workflow can otherwise produce a false sense of safety: the template is fixed upstream while a copied or forked vulnerable backend continues running indefinitely.
The same inventory problem applies to code that was downloaded but not deployed at the time of the notice. Templates in internal repositories, starter projects, CI artifacts, tutorials, and developer branches can reintroduce the old endpoint later. Searching source control and deployment manifests for /api-proxy is more reliable than checking only currently visible Agent Studio applications.
Because Google gives creation time—not package version—as the affected boundary, provenance matters. If an organization cannot establish when its Agent Studio backend was generated, the safe course is to regenerate it now and record the resulting source revision and deployment identity.
Defensive response checklist
- Inventory generated applications. Find every Agent Studio web app, exported source tree, staging instance, sample, and production deployment created from code before July 1, 2026.
- Regenerate from Agent Studio. Follow Google’s instruction rather than attempting an improvised hostname check in the older backend. Review the resulting diff and preserve the new allowlist behavior.
- Redeploy every live environment. Confirm that traffic reaches the regenerated build, then remove or disable stale revisions, preview URLs, containers, and serverless deployments.
- Search for copied proxy code. Look across repositories and artifact stores for the route name and older generated templates. Prevent archived examples from becoming future production code.
- Review request and egress telemetry. Inspect application, load-balancer, platform, DNS, and network logs for unusual
/api-proxyrequests or outbound destinations. Keep conclusions proportional to the telemetry available. - Reduce runtime reach. Give the backend a dedicated least-privileged service account, restrict egress where the platform permits it, and avoid attaching the app to private networks it does not need.
- Test the control without weakening it. Verify that legitimate approved AI endpoints work and that unapproved external, private, loopback, link-local, redirecting, and alternate-encoding destinations are rejected.
- Record the migration. Capture generation time, source commit, build artifact, deployment revision, service account, environment, and retirement of the old version for later audit.
The broader engineering lesson is that generated AI application code is part of the software supply chain, not disposable scaffolding. When a platform fixes a generator, deployed copies do not inherit the repair. Owners need an inventory that connects generator version or creation date to source repositories, artifacts, and live revisions—and a repeatable way to replace all of them.
This also complements the containment controls discussed for agent-generated code in Cloud Run sandboxes. Network egress and service identity remain security controls even when an application is generated by a managed platform. A narrow destination allowlist reduces the proxy’s authority; least-privileged runtime placement limits the consequences if another parsing or validation defect appears.
Sources: