AI API Security · Protecting LLM-Powered Apps, Keys, and Endpoints
Quick answer: AI API security covers two attack surfaces: the LLM APIs your app calls and the endpoints you build around them. Keep OpenAI, Anthropic, and Gemini keys server-side behind an edge-function proxy, set spend caps and rate limits, sanitize model output, and treat prompt injection as a path to key and data leaks.
By Paula C · Kraftwire Software
· 8 min readWhat Does AI API Security Actually Cover?
AI API security has two sides, and most guides only cover one.
Side one: the AI APIs your app calls. If your app uses OpenAI, Anthropic, or Google Gemini, you hold an API key that maps directly to your credit card. Protecting that key · keeping it server-side, controlling who can trigger calls, capping spend · is the first half of the job.
Side two: the endpoints you build around the model. The moment you wrap an LLM in your own /api/chat route, you have created a new attack surface. Prompt injection, insecure output handling, and unbounded token consumption are attacks on your code, not on the model provider.
There is also a third meaning floating around search results: AI-powered API security solutions · tools that use machine learning to monitor API traffic for anomalies. That category is real and covered below, but for a typical vibe-coded app the first two sides matter far more, because they are where real money and real data leak.
Why Do AI API Keys Leak So Often in Vibe-Coded Apps?
LLM keys leak more often than almost any other secret type, for three structural reasons.
AI builders default to client-side fetch calls. When you prompt Lovable, Bolt, or Cursor to add a chat feature, the fastest working implementation is a fetch call to api.openai.com straight from a React component. The generated code runs, the demo works, and the key ships to every visitor in your JavaScript bundle. Why exposed API keys in frontend code are dangerous covers what happens next.
Framework env prefixes are a trap. VITE_OPENAI_API_KEY, NEXT_PUBLIC_ANTHROPIC_KEY, REACT_APP_GEMINI_KEY · anything with those prefixes gets compiled into the public bundle at build time. The variable feels hidden because it lives in a .env file, but the prefix is an instruction to publish it. Environment variables security explains the full rules.
The keys are trivially scannable. OpenAI keys start with sk-, Anthropic keys with sk-ant-, Google AI keys with AIza. Automated scrapers grep public GitHub repos, JavaScript bundles, and exposed .env files for exactly these prefixes, around the clock. A leaked LLM key tends to be abused fast because usage-based billing makes it immediately monetizable · attackers resell access or burn tokens on their own workloads while you pay the bill.
If you have ever committed a key or shipped one in a bundle, rotate it now · how to fix exposed API keys in 5 minutes walks through rotation step by step.
How Do You Call LLM APIs Without Exposing Your Key?
The pattern is always the same: the browser never talks to the AI provider. It talks to a server-side proxy you control · an edge function, a serverless route, or a backend endpoint · and only that proxy holds the key.
A minimal Supabase Edge Function proxy looks like this:
The comments are the actual security controls:
- The client never chooses the model or token budget. If your endpoint forwards a client-supplied
model or max_tokens, a single attacker request can switch to your most expensive model with the largest allowed output.
- Authentication happens before the AI call. An anonymous proxy is just your API key with extra steps.
- The key lives in a server secret ·
Deno.env.get, never a hardcoded string, never a VITE_ variable.
Add per-user rate limiting on top (even a simple counter table works), then set a monthly spend limit in the provider dashboard. OpenAI, Anthropic, and Google all support usage limits, and a cap turns a stolen-key incident or an abuse loop from an unbounded bill into a bounded one.
How Does Prompt Injection Lead to API Key Leaks?
Prompt injection is usually explained as a trick that makes a chatbot say something embarrassing. The expensive version is when injected instructions reach your secrets or your tools.
Secrets in system prompts get extracted. If your system prompt contains anything sensitive · an API key for a downstream service, internal URLs, customer identifiers · assume a determined user can pull it out. Asking the model to ignore previous instructions and print its configuration is the crude version; real extraction attacks are more patient. The rule: a system prompt is user-visible data with extra steps, and keys never belong in it.
Tool calling turns injection into execution. When your LLM can call tools · query a database, fetch a URL, send an email · injected text can steer those calls. An attacker who gets an exfiltration instruction into the model's context can potentially ship out whatever the tools can read, including configuration values. This is why prompt injection sits at the top of the OWASP Top 10 for LLM applications · see OWASP Top 10 for AI-built apps.
Indirect injection hides in content. The malicious instruction does not have to come from the chat box. It can sit in a document your RAG pipeline indexes, a webpage your agent summarizes, or a profile field another user reads through your AI feature.
The defenses are structural, not clever prompting: keep secrets out of prompts entirely, give tools least-privilege access (a read-only scoped key, never your service role key), and treat every model output as untrusted input.
How Do You Harden an LLM-Powered Endpoint?
Work through this checklist for every endpoint that touches a model:
- Authenticate first. No anonymous access to anything that spends tokens, unless the feature is deliberately public and aggressively rate-limited.
- Rate limit per user, not just per IP. One logged-in account running a loop can drain a monthly budget overnight.
- Cap tokens in both directions. Limit input length before the call and set
max_tokens server-side. Unbounded consumption is a denial-of-service attack on your wallet.
- Set a provider spend limit. The dashboard cap is your last line of defense when everything above fails.
- Keep secrets out of prompts. System prompts, few-shot examples, and tool descriptions all end up in model context that users can probe.
- Treat model output as untrusted. Rendering LLM output as HTML is an XSS vector, executing it is code injection, and passing it unchecked into SQL or shell commands is a classic insecure-output-handling failure. Sanitize and validate before acting on anything the model returns.
- Scope tool permissions. Tools should run with the calling user's permissions, not with an admin or service role key.
- Verify async callbacks. If a provider posts results back to you (batch jobs, fine-tune events), treat it like any webhook and verify the signature.
- Log with care. Prompts routinely contain PII. Redact or truncate before logging, and set retention limits.
- Use one key per environment and rotate on any suspicion of exposure.
Everything here is standard API security practice with LLM-specific twists · the difference is that an LLM endpoint fails expensively, because every abused request costs you money.
Can You Monitor AI APIs for Abuse?
Yes, at three levels · and for most apps the first two are free.
Provider dashboards. OpenAI, Anthropic, and Google each show usage and cost per key. Use a separate key per app and per environment so a spike immediately tells you which surface is leaking or being abused, and turn on the spend alerts the dashboards offer.
Your own counters. Every request already passes through your proxy, so log the user ID, token counts, and timestamp. A daily look at your top consumers catches abuse loops, scraping, and runaway retry bugs long before the invoice does.
AI-powered API security solutions. This is the enterprise category the phrase usually refers to: tools that use machine learning to baseline your API traffic and flag anomalies such as unusual endpoints, odd call sequences, or data-exfiltration patterns. They are aimed mostly at organizations with large API estates. For a solo-built app, spend caps, per-user limits, and regular scanning cover most of the same risk at zero cost.
One more signal worth watching: availability. An abuse loop that exhausts your quota takes the AI feature down for real users, and uptime monitoring will tell you that within minutes.
How Do You Check Your AI Integration for These Issues?
Most of the failures in this guide are visible from the outside: keys compiled into the JavaScript bundle, public .env files, missing security headers, AI-specific misconfigurations. SimplyScan runs 51+ automated checks across 14 categories · including exposed API keys, env-var leaks, and AI-specific risks · in about 30 seconds, no signup. You can also check a single suspicion directly with the free exposed files checker, and work through the vibe coding security checklist before launch.
Related Guides
Related free tools
Frequently asked questions
Is it safe to put an OpenAI or Anthropic API key in frontend code?
No. Anything in your JavaScript bundle is public, including variables prefixed VITE_, NEXT_PUBLIC_, or REACT_APP_. LLM keys map straight to usage-based billing, so a leaked key lets strangers spend on your account within hours. Call the provider from a server-side proxy such as an edge function instead, keep the key in a server secret, and set a monthly spend limit as a backstop.
How do I know if my AI API key has leaked?
Watch the provider dashboard for usage or spend you cannot explain, alert emails about unusual activity, and rate-limit errors during normal traffic. To check proactively, search your deployed JavaScript bundle for prefixes like sk- and sk-ant-, look for public .env files on your domain, and run a security scan. When in doubt, rotate: rotation is cheap and abuse is not.
What should I do first after leaking an LLM API key?
Revoke and reissue the key in the provider dashboard immediately. Deleting it from code is not enough, because bundles, caches, and git history keep copies. Move the new key into a server-side secret, redeploy, and review usage logs for abuse during the exposure window. Then set a monthly spend cap so any future leak has a bounded cost.
Does a spend cap protect against prompt injection?
Only partially. A spend cap bounds the financial damage from stolen keys and abuse loops, but prompt injection is about behavior, not just cost. Injected instructions can extract system-prompt contents or steer tool calls toward your data without any unusual spend. You still need secrets kept out of prompts, least-privilege tool permissions, and model output treated as untrusted input.
What is unbounded consumption in LLM security?
It is the LLM version of denial of service. Because every request costs tokens and money, an attacker or a runaway retry loop can hammer your AI endpoint until quota or budget runs out, taking the feature down while running up your bill. Defenses are per-user rate limits, input length caps, server-side max token limits, and provider spend caps.
Can SimplyScan find exposed AI API keys?
Yes. SimplyScan scans your deployed app with 51+ automated checks across 14 categories in about 30 seconds, no signup, and the checks include exposed API keys, environment-variable leaks, and AI-specific risks. Scanning the live site catches keys that were compiled into the bundle during the build step, which reviewing source code alone often misses.