API Key in a Frontend AI App: How to Move the Model Call Off the Page
A practical case story about securing client-side AI calls
The feature was doing its job: a user entered a prompt, the app sent it to a model, and a useful reply appeared on screen. People were using it. The founder had built it using modern AI builders like Lovable and Bolt, improving it continuously as the business grew.
This is a composite situation, not a documented Smicolon customer case.
Then the founder asked a question that a working screen cannot answer: where does the model API key live in the live app?
When using tools like Lovable, Bolt, Replit, or Cursor, calling a model provider directly from the browser can be a rapid way to validate whether a concept works. The page sends a prompt, receives a response, and displays it. That speed is why these tools are so effective for getting an idea off the ground.
However, a live production page is different from a private preview. It is delivered to every visitor's browser. When you leave an api key in frontend ai app code or browser network requests, any visitor using developer tools can inspect it. The founder was not looking to discard a working feature. They simply needed to resolve an exposed model key Lovable Bolt setup by shifting the client side API key AI builder pattern to a protected backend architecture.
The key was visible in the live request
The founder asked a technical person to inspect the live app, rather than the editor or a local preview. They opened the browser developer tools, used the model-powered feature, and checked the network tab.
The browser was contacting the model provider directly, sending the secret key in the request headers. The person checking also reviewed the compiled JavaScript files to see whether the key was bundled there.
That is the practical risk of an api key in frontend ai app architecture. Any code, asset, or network request delivered to a visitor's browser can be inspected. A secret is not secure simply because it does not appear on the screen, or because it is bundled into a minified script. As teams scale their applications, addressing AI code quality as an appsec problem becomes essential to protecting infrastructure.
Testing this does not require pasting credentials into third-party scanners. A direct inspection in the browser console provides the answer: “Does the browser client receive or transmit our model key?”
This established exposure, not theft. Nothing in this composite situation indicated that anyone had copied or misused the key.
Replacing the key would repeat the same problem
The founder's initial instinct was to generate a new key in their model provider dashboard.
Yet if the app continues to dispatch requests directly from the client side, the replacement credential must also be sent to the browser. The exact same vulnerability reappears immediately. This scenario illustrates the verification gap, where building a feature quickly outpaces checking how securely that code actually runs in production.
Anyone with access to a functioning model key can make independent requests billed directly to the account. That is a clear reason to act promptly. OpenAI's API key safety guidance explicitly advises against deploying API keys in client-side environments such as web browsers, recommending that requests route through an application backend instead.
For a founder, the operational principle is straightforward: a secret used to call an external model should never be delivered to the client browser.
The founder kept the screen and moved one call
The resolution did not require a complete rebuild. Smicolon starts from what the founder has already built rather than pitching a rewrite.
The founder kept the exact user interface where users entered prompts and read outputs. They changed only the network path that the request took:
- Before: The browser called the model provider directly with a client side API key AI builder configuration.
- After: The browser sent the user prompt to an internal endpoint. To move AI call to server route environments, a lightweight backend handler received the prompt, added the private server-side key, called the model provider, and returned the reply.
A server route is a small backend endpoint running on a server or edge function that executes the model request without exposing the secret key to the visitor.
The credential was saved as a server environment variable rather than bundled in frontend assets. From the end-user perspective, the product performed identically: submit a prompt, wait for processing, view the output.
The server implementation required proper error handling so failures would return clear status messages instead of leaving the interface hanging. Aligning these technical details with standard practices is covered in our guide on aligning AI-generated code with engineering standards.
Moving the key also introduced a secondary requirement: keeping the key off the page does not make an open route safe by default. The server route requires authentication checks and rate limits so unauthorized parties cannot abuse the endpoint as a free proxy.
The old key was retired only after the new path worked
The migration followed a disciplined sequence:
- A replacement key was generated and stored strictly in server-side environment variables.
- The server route was deployed to handle incoming requests and communicate with the model provider.
- The frontend interface was updated to call the new internal server route instead of the provider API.
- The live application was verified in production to ensure authentications, requests, and streaming responses functioned as expected.
- Browser developer tools were re-inspected to confirm that the replacement key appeared nowhere in network headers or downloaded JavaScript.
- The initial, exposed API key was revoked in the provider dashboard.
Revoking the old key prevents future unauthorized calls. Inspecting the live browser confirms that the new key remains isolated on the server.
What this case teaches
A working UI preview confirms that a feature can return an answer. It does not verify whether secrets remain confidential in production.
The interface looks identical whether the browser contacts the provider directly or delegates the task to a backend endpoint. The crucial architectural distinction is whether credentials must be downloaded by the visitor.
Fixing an exposed model key Lovable Bolt implementation does not mean throwing away working software. By taking the step to move AI call to server route infrastructure, founders protect their budgets and user data while preserving everything they have created.
Our approach to existing apps starts with what you have built and fixes the specific technical bottlenecks holding you back.
To verify your current setup, ask your engineer or technical partner two questions:
- Does the live client browser receive or transmit our model key during runtime?
- Can we inspect shipped browser requests and source files to verify that our model credentials remain exclusively on the server?
Keep building with a senior engineer beside you
You remain the builder. Tools like Lovable, Bolt, Cursor, Replit, Claude Code, and Codex give founders incredible momentum. The challenge is navigating technical architecture, secret management, and production stability alongside feature delivery.
Smicolon's Solo Founder Plan provides 40 hours of senior engineering support for €1,000 per month, with a 3-month minimum (€25 per hour). You receive a weekly 1-hour 1:1 session with a senior engineer, code reviews on what the AI wrote, and hands-on guidance while you remain the builder.
For companies and growing teams, Smicolon also provides standard hour plans: Start (€2,000 for 80 hours), Grow (€3,680 for 160 hours), and Scale (€4,800 for 240 hours). All hour plans end at the end date or when the hours are used up, whichever comes first.
AI builds fast, we make it last!
Book a discovery call to discuss your application architecture with Smicolon.