If an AI-generated website contains a secret API key in its HTML or browser JavaScript, uploading it makes that key available to visitors who inspect the page. A hidden input, a minified script, or an environment-variable name in frontend source does not by itself make a credential private.
Before publishing, ask what authority each value grants. Some services intentionally provide public browser identifiers. Others issue secret credentials that can spend money, read private data, or act on an account. Follow the issuing provider's current documentation instead of deciding from the value's appearance.
Understand what the browser receives
The browser needs the website's HTML, JavaScript, and other assets to display and run the frontend. A credential placed in those delivered files can be read by the browser's user. A build tool may substitute frontend environment variables directly into the generated scripts.
Moving a credential into a source project's environment file is therefore only part of the review. Check whether the build exposes that particular variable to the client. Inspect the output you plan to upload, not just the source folder's file names.
Never put a server's secret configuration file inside the website upload. The published output should contain public assets only. If a ZIP includes an environment file, private certificate, credential export, or unrelated client document, remove it before creating the upload package.
Distinguish public identifiers from secret credentials
A public project identifier can tell a service which application is calling. It should not, by itself, authorize privileged operations. A secret credential grants authority the visitor should not receive. The service's documented permission model determines the distinction.
Check access controls, allowed operations, and any origin restrictions the provider recommends. An origin restriction can be a useful additional control; do not treat it as a universal replacement for keeping a private key private.
Write down the purpose of each credential and its owner. This small inventory helps the next maintainer understand why a value is present and which service to contact if it appears in an unexpected place. Use a label or reference, not the complete secret, in handoff notes.
Put privileged calls behind a server
For a static frontend calling a paid or privileged API, a common architecture is browser → your server endpoint → provider. The server stores the secret and enforces the operations a visitor may request. Cloudflare's Workers secrets documentation illustrates a supported server-side secret store; other providers have their own mechanisms.
The endpoint still needs validation and abuse controls. Simply hiding the key while allowing any visitor to make arbitrary expensive requests leaves the account exposed to unwanted use. Limit the permitted operation, validate request size and fields, and use appropriate authentication or rate controls for the feature.
If the generated project requires a server runtime, publish that component with a platform that supports it. A folder of static files does not execute arbitrary server code. Be explicit about which part GeminiLaunch publishes and which service receives the privileged request.
If a secret has already been published
Treat a delivered secret as exposed. Use the provider's supported process to revoke or rotate it, review the account's usage, and update the server-side integration. Removing the string from the latest page is useful but does not invalidate copies someone could already have saved.
Check repository history, old deployment artifacts, downloads, and screenshots where practical. Do not paste the credential into a public issue or an AI prompt while asking for help. Describe its type and location instead.
Test the replacement integration with synthetic data. Verify the old credential no longer works through the provider's controls and that the intended feature still behaves correctly. Record the event and the resolution without retaining the secret in a shared document.
Make credential review a launch habit
Review the published output, the connected form or API destination, and the account owner before announcing the site. Keep the check in the client website handoff. A clean static upload is a useful starting point; its connected services deserve the same deliberate review.
Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.