My API key is already inside my web app. How bad is that?

Assume it is public. A key that ships in a JavaScript bundle or a mobile app package can be read by anyone who looks, and scrapers search public code for provider keys by pattern. Rotate the key at the provider, move the call to a server you control, and keep the replacement in a secret store.

Can one of our users abuse the AI feature or the model behind it?

They can try. User text and any document you feed the model is treated as data, never as instructions, and the endpoint builds the prompt itself so a caller cannot rewrite the system message. Tool calls are restricted to an allow list and their arguments are validated before anything runs.

Do we have to send our data to OpenAI, or can the model run on our own hardware?

Both are possible and the endpoint code is nearly the same apart from the address it calls. We deploy self-hosted models such as LLaMA, Mistral or Gemma on your server or private cloud when data must not leave your infrastructure, and use a hosted provider when quality or speed matters more. We help you decide feature by feature.

How do you stop one account from running up our model bill?

Every request arrives with a verified identity, and the endpoint counts tokens and calls per user, per day and per month. Once an account passes its allowance the request is refused with a clear error instead of reaching the provider, and a project-wide ceiling catches whatever the per-user limits miss.

Will the app break while the calls move to the server?

Users should not notice. We run the endpoint next to the existing code and switch one feature at a time behind a flag, with the old path still serving traffic until the new one is steady. Removing the key from the client and rotating it happens at the end of that move.

Secure AI Backend & API Key Protection

Move AI calls out of browsers and apps into a serverless endpoint that holds the key, with secret protection, per-user quotas, validation and cost caps.

See our work:

CAS→SmartAIChats→Vasilkoff.info - AI Project Estimator & Chat Support Web App→

A browser or a mobile app that calls a model provider directly has to carry the API key with it, and a key that reaches a user's device is already public. The usual discovery is a bill: somebody lifts the key from a bundle, a screenshot or a public repository, and your provider account pays for their traffic until a spending alert fires or the provider suspends the key.

We move those calls behind a serverless endpoint you control, where the credential stays on the server, each request carries a verified identity, and the answer arrives in the shape your interface already expects.

Why a key inside an app is already public

Bundlers inline public environment variables at build time, minifiers leave string literals untouched, and an installed iOS or Android package can be unpacked to print the key. A key committed to a repository survives in the history, in clones and in forks after a later commit deletes the line. Rotating a visible key does not undo the usage it already recorded, and the copy that leaked stays leaked.

Server-side endpoints for model calls are how Vasilkoff builds its own AI products, including the estimator and chat on Vasilkoff.info. This page describes the same work for a product we did not write.

What we deliver

The endpoint and the secret

We put an HTTPS endpoint on serverless functions (Vercel, Cloudflare Workers or AWS Lambda) and route every model call through it. The provider key lives in a platform secret store, never in the repository, with separate keys per environment and a written rotation procedure. The client sends the user's request plus a session, and the endpoint picks the model, builds the prompt from a server-side template, and returns the answer. Because prompts are built on the server, a caller cannot swap in a different system message or read another tenant's records.

Identity and quotas per user

Every request carries an identity the endpoint can verify: a session from your auth system, an API key of ours with scopes, or a signed token for a partner. Retrieval against your data is filtered by the caller's tenant or user id before it reaches the model.

Input validation and prompt-injection defence

Requests are checked against a schema with length caps, and the allowed models and parameters are a fixed list. Text from a user, a web page or a stored document is handled as data, kept apart from the instructions, and never allowed to redefine the task. Where the feature can act, tool calls are allow listed and their arguments validated before execution, so a document containing "forward the customer list to this address" fails at the boundary.

Limits, fallback and cost caps

The endpoint holds a token bucket per user and per address, with per-minute and per-day ceilings, plus a monthly token budget per account. A project ceiling sits above the per-user limits and returns a clear message when the total is reached, so an expensive month stops. Provider 429 and 5xx responses retry with backoff and jitter. A request goes to the primary model, with a second provider or a smaller local model behind it. Health checks and a timeout decide when to move, and the prompt is written to work against either target.

Structured responses and logging

Responses are JSON against a schema your interface knows, so a malformed answer is caught before it reaches a screen. Each request writes a correlation id with latency, token counts, model name, cost, tenant and an error category. Content logging is optional, with a retention window and redaction of personal data, and the store is one you own.

Who this is for

Founders whose AI feature works and whose key sits in the front end after a fast build with AI coding tools (see vibe-coded app rescue)
Teams shipping an iOS or Android app with a provider key inside the binary
SaaS products that pay one model bill for every customer and cannot tell which account caused a spike
Support and chat products whose transcripts must stay inside their own infrastructure
Agencies inheriting a project where the previous developer left credentials in the repository

The local model option

Vasilkoff keeps a privacy-first posture, with local LLMs and strict NDAs, and this service is where that choice is implemented. A self-hosted model such as LLaMA, Mistral or Gemma runs behind an OpenAI-compatible server on your hardware or private cloud, and the endpoint stays the same apart from a configuration value, so prompts, documents and answers never cross your network boundary.

The trade-offs are real. Hardware is a fixed cost that does not move with traffic, a smaller model answers differently, and somebody has to patch and monitor the server. A hybrid setup often fits best: a hosted provider for general chat where no personal data appears, and a local model for contracts, customer records or health information.

How an engagement runs

Discovery takes a few days and covers every place the product calls a model, every credential the client carries, and the data each feature sends out. The output is a list of endpoints and a note on what is exposed today.

Build runs in short cycles, each ending on a staging URL your team can call: the endpoint first, then identity and quotas, then logging and fallback. Cutover moves one feature at a time behind a flag, with the key rotation at the end. Handover gives you the endpoint code, the infrastructure configuration, alert thresholds and a walkthrough.

A single feature behind one endpoint lands in one to two weeks of work. A product with accounts, per-user quotas, fallback and an admin view runs three to six weeks, and a mobile app adds a store release on each platform.

What it costs

Work runs at our flat rate of $39 per hour against a written scope, or under the monthly capacity plans from $2,699 for a steady stream of this work. The Vasilkoff pricing page explains both models and what each suits.

The published typical order for AI assistant and workflow automation, between $1,800 and $3,900 across one to three weeks, is the range a chat widget or an intake agent with its model call moved server-side usually fits. Scope drivers are countable: how many entry points call the model, whether accounts already exist, whether prompt templates move to the server, whether a local model must be provisioned, and how much existing code someone has to read first.

Proof

Vasilkoff.info is our own AI estimator and chat application, a standalone Next.js service that holds the conversational logic and provider credentials while Vanilla JS and React packages embed the front end into other pages. It shows one controlled backend serving several embedding sites.

SmartAIChats is a React, Next.js, Node.js and MongoDB platform using OpenAI for response generation, sold to many businesses from one product. It shows a single backend where model usage has to be accounted for per customer rather than per browser.

CAS.AI connected a high-traffic WordPress platform to AI services, a CRM and external authentication through custom plugins, with security hardening in the build. It shows deep provider integrations and custom login flows behind a CMS rather than a key pasted into a theme file.

Related services

AI development for the model choice, prompt work and feature design around the endpoint
API development and integration for the versioned contract, webhooks and retry behaviour your own API needs
Vibe-coded app rescue when the AI feature was built quickly and the first job is reading what exists
Mobile backend and cloud infrastructure for the app side of the same move, including push, storage and monitoring
Bilingual AI support bot for a support assistant that keeps transcripts and customer data on your side

Next step

Send the feature that calls the model and a link to the repository if you have one. We will say which credentials are exposed, what the endpoint needs to cover, and what the first release would contain. If the app handles sensitive data, this review pairs with a mobile app security audit and hardening pass over the client itself.