Injecting Security Context During Vibe Coding

Injecting Security Context During Vibe Coding

Speaker: Srajan Gupta, Senior Security Engineer, Dave

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 4, 2026, San Francisco

Watch: YouTube

Reading time: ~8 minutes

TL;DR

Vibe coding fails not because the AI is bad at writing code, but because it's writing code without security context. Srajan Gupta built an MCP-based tool that injects security requirements before code generation, verifies the output immediately after, and patches inline — keeping security inside the developer's workflow rather than catching problems after the fact in CI.

Introduction

In March 2025, a developer went viral on Twitter for all the wrong reasons. He had vibe-coded an app over a few days, shared it publicly, and a week later was under attack from threats he didn't know how to handle. He eventually had to shut the app down.

A year later at [un]prompted 2026, Srajan Gupta stood on stage and pointed to that story as the canonical illustration of why the security community still doesn't have a good answer to AI-assisted development. Gupta is a Senior Security Engineer at Dave, a fintech company, where his focus areas are threat modeling and secure-by-design principles. His concern is grounded in numbers: 75% of developers are using AI for code writing, 41% of code on GitHub is AI-generated, and according to research cited in his talk, 65% of code generated by LLMs has been deemed insecure.

"One of my biggest fears," Gupta told the audience, "is that one day my grandma will call me and say, 'I've built this new dog walking app. Can you please use it?' And I'm actually not ready for that."

That fear reflects a real structural problem. The developer-to-security ratio is roughly 100:1. Code velocity is increasing 30-40% per year. And as Gupta noted, AppSec teams operating at that scale can expect to fail to detect roughly 40% of security flaws.

▶ Watch: The Problem with Vibe Coding (00:00)

Why Traditional AppSec Can't Keep Up

The "accept-all" culture at the heart of vibe coding generates a specific class of problems that traditional security tooling handles poorly. When a developer sees code that looks functional and plausible, they accept it. The AI model generating that code doesn't know the company's data classification policies, doesn't know that card IDs shouldn't appear in error log messages for PCI applications, and doesn't know which internal libraries are approved versus which ones have known issues.

Gupta articulated four failure modes specific to AI-assisted development:

1. Code is generated without a deep understanding of security requirements
2. The "accept-all" culture embeds hidden bugs and structural problems from day one
3. AI models replicate insecure patterns from public repositories
4. Hallucinated code can look entirely plausible while being fundamentally insecure

Traditional AppSec gates compound the problem by showing up too late. By the time findings arrive from CI scans, the code is already "done" in the developer's mind. Feedback arrives through a slow cycle: PR review, then CI, then a ticket, then context-switching back to something the developer finished days ago. Features harden quickly, fixes cost more, and teams bypass gates under deadline pressure. AppSec becomes the "no" team by accident.

"The design flaws," Gupta noted, "are basically not going to be caught in the traditional CI/CD scans."

▶ Watch: Why AppSec Gates Show Up Too Late (02:00)

The Core Insight: Put Security in the Generation Loop

Gupta's key realization is that the problem isn't that developers are careless — it's that security context is simply absent when code is being generated. His proposed solution follows from that diagnosis: inject security requirements into the generation loop itself, before the first line of code is written.

The approach has three steps:

1. Pre-coding analysis — Before code generation, identify what security context is needed and inject it into the prompt
2. Generate with context — The AI writes code constrained by the security context pack
3. Verify and patch inline — Immediately after generation, verify the output against the requirements identified in step one; fix any gaps before the developer moves on

The result Gupta targets: fewer findings, faster fixes, less rework for both developers and AppSec — all without pulling developers out of their workflow.

▶ Watch: The Approach Explained (04:00)

What Goes into the Security Context Pack

The concept of a "security context pack" is central to Gupta's design. It's a structured bundle of information scoped to the specific feature being built, assembled from several sources:

• Jira tickets / PRDs — Scope, acceptance criteria, what data the feature will touch
• Confluence / internal docs — PRD, architecture, trust boundaries
• OWASP cheat sheets — Proven safe patterns for the relevant technologies
• Internal standards — Authn/authz rules, logging policies, secrets handling, PII requirements
• Repo signals — Existing patterns, approved libraries, team helpers

A PCI application that handles card IDs requires different context than a general API endpoint. If the company policy says card IDs must never appear in error log messages, that policy needs to be in the context pack — the AI model has no way to know it otherwise.

"What I mean by security context is like the data classification policies," Gupta explained. "For example, if a developer is working on a PCI application where it has to deal with card ID, your compliance policy says we don't log that card ID in the error messages. AI possibly doesn't know all of this, so that data classification policy that is written in the internal docs will come in handy at the security context pack."

The context pack feeds into the code generation prompt, constraining what the AI produces. The key design principle is "context on demand" — fetching only the guidelines relevant to the task, rather than maintaining monolithic prompts that become unwieldy across different contexts.

▶ Watch: The Security Context Pack (06:00)

MCP as the Implementation Layer

To implement this workflow, Gupta chose the Model Context Protocol (MCP) as the mechanism for connecting the AI agent to security tooling. His reasons were specific:

• It's a standard protocol that IDEs already support
• It's composable — Jira, Confluence, internal policies, and security scanners can all be plugged in
• It keeps the workflow inside the IDE, meaning inside the developer's environment
• It supports "context on demand" rather than forcing monolithic prompt construction
• It produces audit logs as a side effect

The MCP tools Gupta wired up for his implementation include: jira.getIssue, jira.getAcceptanceCriteria, confluence.getPage, confluence.search, security.lookupCheatSheet (for OWASP and internal standards), policy.getGuidelines, and scan.run plus patch.apply for the verification and remediation step.

He also noted that Claude and Cursor support hooks — deterministic triggers that fire MCP tool calls at defined points — as an alternative to tool descriptions for ensuring the workflow actually runs. The tool description approach relies on the model choosing to invoke the tool; hooks can make it mandatory.

▶ Watch: Why MCP (08:00)

Demo: Webhook Receiver Security Review

To demonstrate the workflow, Gupta used an open-source MCP observability tool called OBAT as his base and built a webhook receiver endpoint — a realistic scenario where a developer asks the coding agent to accept incoming webhooks from GitHub or Slack and trigger downstream agentic workflow executions.

He ran the scenario twice: once without his security tools enabled, and once with them.

Without the tool: Two issues surfaced only after code generation — header forwarding leaking sensitive data, and authorization tokens being passed improperly through the workflow.

With the tool enabled: Before any code was written, the pre-coding analysis identified the task as high-risk and flagged three key security categories: API security, data validation, and web security. The agent pulled in relevant guidelines and determined that the code should, from line one, validate all inputs, filter sensitive headers, enforce body size limits, and follow least privilege principles.

The generated code included a header blocklist baked in from the start — including filtering for Authorization, X-Forwarded-For, and X-Real-IP headers. The post-generation security verification checked the code against the requirements identified in step one and confirmed: no critical or high severity issues, no hardcoded passwords, no raw SQL queries. The implementation aligned with the security review guidance.

"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 pipeline," Gupta noted.

▶ Watch: Demo Walkthrough (10:01)

Making It Your Own

Gupta designed the tool to be extensible for organizations' specific needs. Beyond the OWASP cheat sheets bundled by default, teams can inject:

• Their own threat models from internal documentation
• Internal secure coding guidelines and golden paths
• Approved library lists (particularly useful given SCA concerns with vibe coding)
• A custom "definition of done" from a security perspective

Guidelines use category labels so the AI agent can filter intelligently — if a task involves JWT authentication, only JWT-related guidelines are injected, preventing context bloat. Three specific tags are required for custom guidelines to be recognized by the system correctly.

One important limitation Gupta acknowledged: the tool handles repetitive work and known insecure patterns well. For large system changes or entirely new architectures, human threat modeling is still necessary. "For big systems or big changes, you absolutely do a human review as well."

▶ Watch: Customization and Limitations (16:01)

Q&A: The Scalability Question

During the Q&A, an audience member raised a pointed question: won't this eventually just become a skill that every IDE has built in automatically? Gupta's response illustrated why centralization matters. Embedding security knowledge as a skill in individual repositories doesn't scale to organizations with hundreds or thousands of repos — you'd have to update each one when policies change. A centralized MCP server solves this: one update to the server propagates to every developer context.

Another attendee asked how you ensure developers actually use the tool. Gupta's answer: tool descriptions matter a lot. The MCP tool description needs to be specific enough that the AI agent reliably invokes it when the conditions are right. Hooks, where supported, remove the ambiguity entirely.

▶ Watch: Q&A and Adoption (20:01)

Notable Quotes

"One of my biggest fears is that one day my grandma will call me and say, 'I've built this new dog walking app. Can you please use it.' And I'm actually not ready for that."

— 02:00

"Vibe coding fails when the context is missing. We will always have some flaw if we do not provide the correct context."

— 18:01

"The focus these days is mostly around, is my code working rather than is my code secure."

— 02:00

"AppSec becomes the 'no' team by accident."

— Slides

Key Takeaways

• Security context is absent, not ignored. AI models generating code have no access to internal policies, compliance requirements, or data classification rules. The problem is architectural, not attitudinal.
• Inject before generation, not after. Pre-coding security analysis produces dramatically different results than post-generation scanning — the same issues that would be caught as findings are instead never written in the first place.
• MCP enables composable, IDE-native security. Using MCP as the delivery mechanism keeps security context within the developer's workflow, pulls only relevant guidelines for the specific task, and scales across organizational changes without per-repo updates.
• Centralization beats per-repo skills. Organizations with many repositories need a centralized policy server; per-repo skill definitions don't scale when guidelines change.
• The tool augments but doesn't replace threat modeling. For new systems or large architectural changes, human review and formal threat modeling remain essential.

Slides Reference

Slides available: 2026-04-04-D2-S2-10-51-Injecting-Security-Context-During-Vibe.pdf

Key slides cover: statistics on AI code generation (75% of devs using AI, 41% of GitHub code AI-generated, 65% of LLM code deemed insecure); the dark side of vibe coding; the three-step approach (context → generate → scan → patch); the security context pack composition; the high-level MCP architecture diagram; and the full tool list with the public GitHub repo at github.com/Srajangpt1/ai_security_crew.