I built a resume scanner with "vibe coding." It worked great. Then I discovered my API key was sitting in the code like a welcome mat for anyone who cared to look.

The resume scanner was my first real vibe-coded tool. I’d used Gemini, ChatGPT, and a handful of other AI tools before, but this was the first time I built something from scratch with AI doing most of the heavy lifting. I’ve written about that experience in my blog here Blogs the short version is that it worked, it shipped, and real people started using it.

Then things got weird.

One day I tried using the tool myself, I was building an interview simulator as an extension to my previous Resume scanner tool and it kept throwing a 429 error. Every single time, it meant I was exceeding requests per minute (RPM), tokens per minute (TPM), or daily limits. It was understandable at first; I figured it was just popular. But after this continued for 3–4 days, I dug into it. No bugs. No code changes. The interface was fine. The Google Cloud console looked normal. The API keys were still there.

For days, I couldn’t figure it out. The tool had been working perfectly. Nothing had changed.

Red Team, Blue Team

Around that time, I’d gone deep on Claude. Moving from the free tier all the way to the $100/month plan because I was running experiments constantly. I was watching YouTube videos about AI tool workflows, and one of them mentioned something that stopped me mid-scroll: you can give Claude a codebase and ask it to break it down. Not just review it but ctually try to find faults and vulnerabilities.

I’d done QA on my tools before. Basic stuff: Find the errors, this doesn't look right, the padding is off, this feature isn't working, etc. But I’d never asked an AI to think like an attacker.

So I tried it. I gave Claude the link to my resume scanner, enabled web access, and wrote: “Do a deep research analysis. Try to break this tool. Tell me every fault and issue you can find.”

In hindsight, I could have written a much sharper prompt. But because it was Opus 4.6, the output was thorough anyway. Claude scanned the tool in detail and without me even asking generated a full, structured report.

And there it was, right in the Critical Risk section: my API keys were visible in the code.

The Thing I Didn’t Know I Didn’t Know

I’m not a developer. I am an experience designer, product designer, researcher, and an Architect; hell, I even know how consultancy and IT services orgs operate. I know how a project flows through a funnel, from the first meeting with a client until it's delivered. I know the stages and which teams touch it. I have experienced it all.

But I’ve never sat in the developer's or security expert's chair. I’ve never been the person whose job it is to check whether API keys are exposed in frontend code. I didn’t even know such a risk existed until a few months ago.

So when Claude explained what exposed API keys actually mean, my stomach dropped. Anyone could open the browser console, grab the key, and use my tokens for whatever they wanted. Even on a free tier, that meant either someone else was burning through my daily quota or the tool was just being used that heavily. That’s why the tool kept giving me errors.

In this economy of AI tools and tokens, your API key is currency. Token consumption costs real money. Protecting it isn’t optional, it’s the equivalent of not leaving your wallet on a park bench. This makes the case for the future of "Group Vibe Coding": an expert from every role coming together to develop a produtc.

Taking the red pill

I wasn’t satisfied with just one tool’s opinion. So I went wide. I ran the same analysis through Gemini 2.5 Pro, Perplexity, and ChatGPT. I asked each one to audit the code and produce a security report. I took the report from one tool and fed it to another, repeating the process. Then I took all of those reports, plus the one Claude had already generated and fed them back into Claude Opus 4.6 with a new instruction: “Be extremely critical. Break down all of this and tell me the reality.”

Claude’s response surprised me. It said the "Master Prompt" the big, consolidated security prompt that the earlier analysis had produced was essentially a joke. Not because the individual rules were wrong, but because cramming that many instructions into one giant paragraph means the AI model is likely to skip portions of it.

What Claude actually said (paraphrasing) was: A massive block of security instructions creates a false sense of protection. LLMs deprioritize rules as prompt length increases. Later instructions get less attention. If you want the AI to actually follow security rules, keep them concise, structured, and organized by priority not dumped into a single wall of text.

That sent me further down the rabbit hole. I watched YouTube videos covering cybersecurity for vibe coding, ran NotebookLM deep research sessions, and manually compiled a list of vulnerabilities. I found issues in my manual list that none of the individual AI reports had caught. That’s when I decided to build this guide. Not a theoretical framework, but a practical reference built from actually breaking my own stuff.

The Uncomfortable Truth About Security Prompts

Let me be very clear: security prompts are a reminder system, not a firewall.

Every prompt in this post can be ignored, misinterpreted, or forgotten by the AI. Research from Columbia University found that coding agents will remove validation checks, disable authentication, and relax database policies just to make error messages go away. The AI optimizes for “it runs” not “it’s safe.”

So why bother? Because prompts meaningfully improve default behavior. They won’t make your app bulletproof, but they’ll stop it from shipping with the doors unlocked. Think of them as a co-driver who reminds you to check your mirrors helpful, but not infallible.

Two Architecture Rules Before Anything Else

No prompt will save you if the architecture is wrong. These two rules are the foundation:

1. Never put API keys on the client side

This is the mistake I made. This is the mistake that drained my quota. If you ask an AI to “connect my app to OpenAI,” there’s a good chance it’ll put the API call directly in your frontend JavaScript.

CRITICAL ARCHITECTURE RULE: Never place external API keys or make paid API calls from frontend/client-side code. Build a server-side intermediary (Vercel Edge Function, Cloudflare Worker, Express server, or equivalent). The frontend talks only to your server; your server talks to the paid API. All API keys live in server-side environment variables, never in client-accessible code.

2. Never trust the frontend

Your HTML form has maxlength="50" and a dropdown with three safe options. It does not matter. Attackers use Postman. They send whatever they want directly to your backend.

ZERO TRUST BACKEND RULE: The HTML UI is just a suggestion. Assume a hacker has bypassed the frontend entirely. Duplicate every validation rule on the backend. Reject non-conforming payloads. Do not "fix" bad data drop the request and return a generic error.

The 8 Security Prompts That Actually Matter

The Red Team Trick (The One That Found My API Key)

1. Step 1: Build the feature normally.
2. Step 2 (Same session): “Review the code you just wrote as a security engineer. List every vulnerability. Don’t fix anything yet.”
3. Step 3 (Fresh session): Paste code into a new session and use:
   Red Team Audit Prompt Copy

   Red Team Audit: You are a hostile, highly skilled cybersecurity researcher. I'm giving you the source code to a public-facing web tool. Your goal is to find ways to: (1) drain API credits or access paid features for free, (2) extract hidden data, secrets, or user information, (3) inject malicious scripts or achieve code execution, (4) bypass rate limits or authentication, (5) access other users' data. Write a step-by-step Exploit Report. Do NOT fix anything just show me how you'd break it.
4. Step 4: Take the Exploit Report into a new session and fix everything.
5. Step 5: Run an actual scanner. AI review supplements tools it doesn’t replace them.

Why the “Master Prompt” Doesn’t Work

Its verdict: Security theater.

When you give an LLM a massive block of instructions, it doesn’t treat each sentence equally. Rules at the end get deprioritized. Subtle conflicts create ambiguity the model resolves by picking one rule and ignoring the other. Keep prompts short, structured, and scoped.

Pre-Deploy Checklist

• No API keys in client-side code.
• Server-side intermediary for API calls.
• Content Security Policy (CSP) header configured.
• Parameterized queries for database operations.
• Auth uses established libraries with proper hashing.
• Authorization checks verify ownership on every endpoint.
• CSRF protection on all state-changing endpoints.
• File uploads validated (type, size, sanitized filenames).
• HTTPS enforced everywhere.
• Rate limiting on all public/auth endpoints.
• Dependencies pinned and scanned (npm audit / Snyk).
• CAPTCHA on all public-facing forms.
• Error messages reveal nothing about internals.
• Cookies set with Secure, HttpOnly, SameSite.

What I Actually Took Away From All This

When I started building the resume scanner, I thought the hard part was making AI tools understand what I wanted to build. But the more difficult part is knowing what you don’t know.

I come from design. I can spot a bad experience from across the room. But I couldn’t spot an exposed API key. That’s not a failure of vibe coding; it’s the reality of building in domains where you’re not the expert.

The fix isn’t to stop vibe coding. It’s to build the thirty-minute habit: run the red team prompt, walk the checklist, fire up the free scanners. Treat security the way you’d treat any other design constraint.

I am compiling everything all 15+ prompts, detailed caveats, the full tooling breakdown into a downloadable guide. i will add the detailed guide with my next post, so keep tuned.