how to protect API keys in an AI app

To protect API keys in an AI app, keep provider credentials on your server, store them in a managed secrets service, and route requests through authenticated backend endpoints. Use separate keys for each environment, restrict permissions, enforce usage limits, redact logs, and rotate exposed credentials immediately. Never ship secret keys to browsers or mobile clients.

Key takeaways

• Anything delivered to a browser or installed client can be inspected, including bundled environment variables.
• Your backend must authorize requests and control spending, not merely hide an OpenAI or Anthropic key.
• Use managed secret storage in production and separate development, staging, and production credentials.
• Keep API keys out of prompts, retrieval documents, analytics, error reports, and application logs.
• Combine secret scanning, usage monitoring, and a tested rotation process. No single tool covers every failure mode.

Where should you store API keys in an AI app?

The safest practical pattern is simple: your browser calls your backend, and your backend calls the AI provider. The provider key exists only in trusted server infrastructure. This applies whether you use Next.js, FastAPI, Express, or serverless functions.

Separate public configuration from secrets

A public API base URL is configuration. A credential that authorizes billable AI requests is a secret. Naming a variable “private” does not protect it if your framework includes it in browser JavaScript.

1. Create separate provider projects or credentials for development, staging, and production where supported.
2. Put local credentials in an untracked environment file, such as .env.local, and verify your framework loads it only where intended.
3. Use your hosting platform’s protected environment settings or a dedicated secrets manager for deployed workloads.
4. Limit access to the people and service identities that actually need those credentials.

For Next.js, never put a provider secret in a variable prefixed with NEXT_PUBLIC_. Vite’s VITE_ variables are also exposed to client code by default. Build-time substitution can embed values permanently in static assets.

Local environment files cost nothing, and hosting platforms often include environment-variable storage. Dedicated secret stores add service charges but provide stronger access controls and auditing. Avoid storing keys in Docker images, shared notes, or database fields readable by normal application users.

How do you keep API keys out of frontend and mobile code?

Do not call a provider’s billable API directly from React, a browser extension, or a mobile app using your long-lived secret. Obfuscation, encrypted strings with embedded decryption keys, and hidden configuration files only make extraction less convenient.

Build a narrow backend endpoint

1. Create an endpoint such as POST /api/chat using Next.js route handlers, Express, or FastAPI.
2. Validate the user’s session with a service such as Clerk, Auth0, or Supabase Auth.
3. Check that the user belongs to the requested workspace and has permission to use the feature.
4. Validate the request and set the model, token ceiling, and enabled tools on the server.
5. Call the provider using the server-held credential, then return only the required response data.

Never let the client submit an arbitrary upstream URL or authorization header. That turns a protective proxy into a credential-leak or abuse endpoint. Likewise, CORS controls browser behavior; it does not stop attackers from calling your backend directly.

For a small prototype, budget roughly $0–$30 per month for backend hosting within modest usage limits, excluding AI calls and authentication overages. Free tiers can help with testing, but check execution timeouts and streaming support before choosing one.

Some realtime AI APIs support short-lived client credentials. When supported, mint those on an authenticated backend with provider-supported expiration and session restrictions. Never substitute a permanent account key because it is easier to integrate.

Which secrets manager should you use, and what does it cost?

Choose the option that matches your hosting stack and operational needs. Moving secrets into another service helps only if access to that service is also controlled. Prefer workload identities over another long-lived credential used solely to fetch secrets.

Start by granting the application read access to its specific secret, not the entire vault. Keep secret administration separate from runtime access. Enable access auditing and document how deployments receive updated versions.

For a small US startup, engineering time usually matters more than saving cents on secret storage. Do not introduce a complex self-hosted system without someone responsible for patching, backups, and recovery. Verify current vendor pricing before setting a budget.

How do you prevent unauthorized users from running up your AI bill?

A hidden key does not make an unrestricted endpoint safe. Attackers can spend through your application without ever seeing the credential. Treat authentication, authorization, and spending controls as separate requirements.

Enforce limits before expensive work starts

• Per-user limits: Cap requests, simultaneous jobs, and daily usage using a shared store such as Redis or Upstash Redis.
• Workspace budgets: Track aggregate usage so multiple accounts cannot bypass a customer’s allowance.
• Request constraints: Allow approved models only, cap output tokens, and limit upload size and retrieved context.
• Job controls: Set agent step limits, tool-call ceilings, retry limits, and execution deadlines.
• Emergency controls: Add a server-side switch that disables costly features without waiting for a deployment.

Reserve usage allowance atomically before starting concurrent requests, then reconcile against actual consumption. Otherwise, parallel jobs can all pass the same budget check. Input length, images, audio, and tool activity can matter as much as output tokens.

Redis-based controls may fit within a free tier at prototype scale; allow a few dollars to tens of dollars monthly as traffic grows. AI provider charges remain separate and model-dependent.

Configure provider alerts and available project limits, but verify whether each setting is a hard stop or only a notification. Cloudflare rate limiting can add an outer layer, yet IP-only rules are weak for shared office networks and distributed attackers. Cookie-authenticated endpoints also need appropriate CSRF protection.

How do you stop keys leaking through logs, Git, and AI agents?

Credential leaks often happen outside the main request path: a developer logs an SDK configuration object, a support ticket includes a header, or an agent reads an environment file. Prevention needs coverage across development and production.

Check every place data leaves the application

1. Add environment files and local credential exports to .gitignore. Remember that this does not remove files already tracked.
2. Run Gitleaks in local checks and CI, and enable GitHub secret scanning and push protection where available.
3. Redact authorization headers, cookies, and known secret fields before logs reach Sentry, Datadog, or another monitoring service.
4. Review analytics events, exception payloads, CI output, and support exports for accidental credential collection.
5. Keep secrets out of model prompts, vector databases, and documents accessible to retrieval tools.

Gitleaks can run without a software license fee, although CI compute and maintenance still cost time. GitHub security feature availability and pricing depend on repository visibility and plan. Monitoring services may charge for ingested events, so filtering sensitive data at the source helps both privacy and cost.

For AI agents, inject credentials into trusted tool-execution code, not into the conversation. Give each tool narrowly defined actions. An agent with unrestricted shell access may read process environment variables even if no prompt contains them.

Prompt injection can also trick an agent into sending sensitive output elsewhere. Restrict filesystem access and outbound network destinations, and validate tool arguments outside the model. Do not assume a system prompt saying “never reveal secrets” is a security boundary.

What should you do if an API key is exposed?

Treat a key committed to a public repository, pasted into an external chat, or shipped in client code as compromised. Removing the visible text does not revoke copies already downloaded, indexed, or logged.

Use a short incident runbook

1. Contain: Revoke the exposed credential immediately. If necessary, temporarily disable the affected feature.
2. Replace: Create a new, narrowly scoped key and update the secret store. Restart or redeploy workloads that cache credentials.
3. Verify: Confirm the old key fails and the replacement works across web servers, workers, and scheduled jobs.
4. Investigate: Review provider usage, application logs, repository history, and deployment artifacts.
5. Remediate: Remove the leak source, clean relevant artifacts, and add a regression check.

For planned rotation, overlapping credentials can prevent downtime where supported. For an actively exposed key, preserving availability should not delay revocation. Rewriting Git history reduces future exposure but never makes the original credential safe again.

Creating replacement keys generally has no separate fee; incident response time and unauthorized usage are the larger costs. Contact the provider promptly about suspicious charges, but do not assume reimbursement. If customer data may have been accessed, consult qualified counsel about applicable US state notification and contractual obligations.

Frequently asked questions

Is a .env file enough to protect API keys?

It is useful for local development when excluded from version control and protected by filesystem permissions. It does not prevent frontend bundling, unsafe logging, or access by a compromised server process.

Can I encrypt an API key in frontend JavaScript?

Not securely if the browser also receives everything required to decrypt and use it. Keep the permanent key on your backend, or use provider-supported short-lived client credentials for specific use cases.

How often should I rotate AI provider API keys?

Rotate immediately after suspected exposure, relevant access changes, or a provider security notice. Set a routine schedule based on risk and compliance requirements, and test the process so rotation does not become an outage.

How should I store API keys supplied by customers?

Encrypt customer credentials using a managed key service such as AWS KMS, and enforce tenant isolation before every use. Do not display full keys after saving them; provide replacement and deletion controls, and exclude decrypted values from logs and prompts.

Does a backend proxy completely protect my API key?

No: it removes the key from client code, but backend compromise and excessive internal access remain risks. You still need narrow permissions, patched dependencies, controlled outbound requests, usage limits, and monitoring.

Muhammad Tariq at Tariq Services builds AI products, agents, and automations with server-side credential handling and practical usage controls. Explore our AI development services if you need help securing an AI app before launch or improving an existing integration.