AI
Why Vibe Coding Leaves Security Behind
In March 2025, a developer vibe-coded an app in a few days, shared it publicly, got attacked within a week, and had to shut it down. A year later the same problem persists. The workflow is: see something, prompt, click accept all, run. As Gupta put it:
“the focus these days is mostly around is my code working rather than is my code secure” — Srajan Gupta
The developer-to-security ratio sits at 100:1. With code generation at this speed, security teams catch only 40% of flaws. The missing 60% comes from AI replicating insecure patterns from public repos and generating code that looks correct but isn’t. CI/CD scanners don’t catch design flaws, and manual threat modeling every new endpoint cannot match the pace.
Security Context Pack: What AI Agents Are Missing
A security context pack is the information an AI agent needs before writing a single line: the Jira ticket, the data classification policy, relevant compliance requirements, internal standards. Without it, the agent pulls patterns from public repositories and generates code that looks correct but carries the assumptions of whatever training data shaped it. A PCI application must not log card IDs in error messages. The AI doesn’t know that unless you tell it.
Gupta’s term for this collection is the security context pack — task scope, feature-specific constraints, internal policies, all assembled before the generation prompt runs. The code the agent produces is then constrained by that pack rather than by its defaults.
MCP as the Delivery Mechanism
MCP fits here because it is already inside the IDE where code generation happens. It connects to Jira, Confluence, internal policy docs, and security scanners through a single composable layer, so the agent pulls only the guidelines relevant to the task instead of loading a monolithic prompt every time. An organization with a thousand repos does not need to copy context into each one. The MCP server is the centralized source, and changes propagate everywhere at once. Gupta also noted that MCP calls are auditable by default, and for teams that need stricter enforcement, agent hooks can make the tool calls deterministic rather than best-effort.
Three-Step Secure Coding Workflow Demo
The demo task: build a webhook receiver in OTel that accepts payloads from GitHub or Slack. Run without tools, the agent produced code with two issues — header forwarding leaked sensitive data and authorization tokens moved loosely through the workflow. Without tools: two security issues found post-generation Both caught after the code was written. With tools: pre-coding analysis flags high-risk, pulls guidelines — the task classified as high-risk, header filtering and least-privilege baked into the generation prompt before a line was written. Step 3 inline verification: all checklist items pass returned no critical, high, or medium issues. The PR hit CI/CD clean.
“the feedback is immediate when the context and the requirement the developer requirement is still fresh still in the chat window and it is not somewhere in the CI uh pipeline” — Srajan Gupta
Customization, Limits, and What This Does Not Replace
The built-in guidelines cover OWASP cheat sheets, but the tool accepts your own content too. Drop in internal threat models, golden paths, approved library lists, or data classification policies, and pull from Confluence or Google Docs directly. Each guideline needs three category tags so the agent filters by relevance rather than loading everything at once. Without that filtering, context bloat kills the benefit.
“The security guidelines that work for humans does not work very well with our AI.” — Srajan Gupta
MCP tool descriptions govern whether the agent calls the security review at all. Good descriptions make invocation likely; hooks make it deterministic. Hooks only run on Claude and Cursor today, not every IDE. And the tool has a hard ceiling: it catches repetitive patterns and business logic issues early, but it does not replace human threat modeling for new systems or major architectural changes.
Q&A
Do you think this will eventually just be adapted as a skill — a sub-agent that automatically runs when you make a feature request? A skill could work for a single repo, but at organizational scale (thousands of repos) you need a centralized MCP server so context updates propagate everywhere instead of requiring per-repo edits. ▶ 19:41
When does the security review trigger — when code is committed to the repository or before that, during the IDE? The review triggers inside the IDE at generation time, not at commit or CI. ▶ 20:41
How do you make sure this actually happens? Do you have telemetry, and how do you encourage local IDEs to call the MCP server? MCP tool invocation depends on how the tool description is written, and Gupta acknowledged it is not 100% reliable through prompting alone — Claude and Cursor hooks can make it deterministic. ▶ 21:06
Have you measured how well it’s working — what residual security bugs are found after using this process? No specific metrics were shared, but Gupta said it catches business logic issues that scanners miss and reduces developer round-trips by pulling requirements automatically from Jira tickets. ▶ 22:09
Notable Quotes
the focus these days is mostly around uh is my code working rather than is my code secure Srajan Gupta · ▶ 2:07
vibe coding fails when the context is missing. We will always have some some flaw uh if we do not provide the correct context Srajan Gupta · ▶ 18:22
the security guidelines that work for humans does not work very well with uh with our AI Srajan Gupta · ▶ 15:46
the feedback is immediate when the context and the requirement the developer requirement is still fresh still in the chat window and it is not somewhere in the CI uh pipeline Srajan Gupta · ▶ 14:03
Key Takeaways
- Inject security requirements into the AI generation prompt before code is written, not after it ships to CI/CD.
- Use MCP to deliver centralized security context across thousands of repos without per-repo duplication.
- Run inline verification immediately after generation while developer intent is still in the chat window.