Decide Before You Let AI Write. Forrester's 3 Implementation Principles for 'Secure Vibe Coding' — The Trilogy's Answer Key

Let’s Check the Answers to the Trilogy

In Vibe Coding’s 170 Back Doors: A Former Failed Engineer Seriously Investigates the 10.3% Security Flaw Rate in Lovable Apps, I wrote about how 170 security flaws were found in 1,645 apps built with Lovable. An incident where the “code” AI generated had holes.

In The Day the Cursor CEO Admitted ‘Our Tool Builds on a Fragile Foundation’: The Next Question Vibe Coding Faces from the Zero-Click CurXecute Vulnerability, I wrote about how a zero-click remote code execution vulnerability called “CurXecute” was discovered in Cursor itself. An incident where the AI coding “tool itself” became the attack vector.

The code is dangerous. The tools are dangerous. So should we quit vibe coding?

The answer is no. Don’t quit — change how you do it. This time I’m writing about that specific method.

There’s a concept proposed by Forrester analyst Janet Worthington on the official blog. “Secure Vibe Coding.” Safe vibe coding is not a paradox but a paradigm (a new standard).

These words are the conclusion of the trilogy. Design change over hunting for culprits. Build safety into the generation process itself, rather than bolting on security reviews afterward.

The Numbers Show the Reality of “It Works But It’s Not Safe”

First, let’s get the current situation straight. With data, not gut feelings.

Veracode’s 2025 report puts out shocking numbers. After evaluating over 100 LLMs (large language models), only 55% produced safe code. The remaining 45% contained known security flaws.

Almost half are full of holes. And the Spring 2026 update shows the trend hasn’t changed. Even in the GPT-5 and Claude 4.6 generation, the “security ceiling” hasn’t been broken. The expectation that smarter models would be safer has been betrayed.

One more. The results from Stanford University’s SVIBES benchmark are even sharper. Using SWE-Agent combined with Claude 4 Sonnet, 61% passed functional tests. Of those, only 10.5% were also secure.

Even of the code that passed functional tests, only 1 in 6 is safe. The “if it works, it’s OK” credo I’ve held was completely wrong when it comes to security. I’ll admit it honestly.

And Forrester’s 2025 predictions forecast that by 2026, 75% of technology decision-makers will perceive technical debt as medium to high severity. As a result of mass-generating code with AI, security debt is piling up. With 75% feeling “this is bad,” after-the-fact reviews can’t keep up.

What Is the “Secure Vibe Coding” Forrester Proposes?

Worthington, having tried vibe coding herself using Cursor, wrote this in her blog post.

The generated code lacked input sanitization (safe processing of user input). It had no rate limiting (control of consecutive access). API keys were embedded in plain text.

I’ve experienced this with Claude Code too. Something that works gets built quickly. But the security settings are missing. Same structure as the Lovable incident in Part 1.

Worthington’s conclusion is this: even in the era of AI-assisted development, the basics of DevSecOps (integration of development, security, and operations) are not exempted. But the developer’s role changes. From “programmer” to “agent orchestrator (conductor of AI agents).”

From the person who writes code to the person who designs what to have AI write. This shift is the heart of “Secure Vibe Coding.”

Forrester’s 2026 predictions report predicts that vibe coding will evolve into “vibe engineering.” An era where engineering as a whole — beyond coding to include design, testing, and operations — is done in collaboration with AI. Without security as its foundation, it can’t stand.

A 3-Layer Framework: Spec / Agent / Gate

So how do you actually implement this? After organizing the research and recommendations from various institutions, it became clear that thinking in three layers makes things easier to understand.

Spec Layer: Decide Constraints Before Having AI Write

The top layer. This is the most important.

A technique called Constitutional Spec-Driven Development was proposed in January 2026. Embed a “security constitution” based on CWE (Common Weakness Enumeration) and MITRE frameworks into the spec. Code generated by AI must follow this constitution.

The result: a 73% reduction in security flaws was reported in case studies.

In the Checkmarx framework I introduced in Part 2, including security requirements in the prompt at generation time was placed as the first layer. It also aligns with the VibeContract concept introduced in Part 1.

At a practical level, it looks like this. Before telling Claude Code to “build a Slack Bot,” write upfront as the spec: “implement authentication with OAuth 2.0,” “read API keys from environment variables,” “sanitize all input values.” Instead of letting AI write freely and checking afterward, set constraints from the start.

Agent Layer: Restrict Permissions While Writing

The middle layer. This is the direct answer to the challenge posed by the CurXecute incident in Part 2.

The UK NCSC (National Cyber Security Centre) AI System Development Guidelines present four principles.

• Least privilege: Give AI agents only the minimum permissions required
• Safe defaults: Make “off” the default for new features
• Opt-in for dangerous operations: Make file writes and external communications explicitly permission-based
• Action restriction: Predefine the range of actions AI can execute

CurXecute exploited the unconditional execution of instructions from MCP servers in Auto-Run mode. If the NCSC principles had been followed, Auto-Run would be “off” by default. Connection to external MCP servers would be “opt-in.” In other words, the very conditions that made the attack possible disappear.

In another NCSC report, they warn that understanding prompt injection (injection of malicious instructions to AI) through the metaphor of SQL (database) injection is dangerous. Inside an LLM, there is no robust boundary between instructions and data. That’s exactly why restricting permissions at points of external connection becomes important.

Gate Layer: Stop It at the Gate Before Shipping

The bottom layer. The last line of defense.

The features GitHub announced in succession in March 2026 strengthen this layer.

March 17, 2026: Via MCP Server, secret scanning is possible before commit and before PR. Just by telling an AI coding agent “scan the current diff,” you can detect API key and token leaks in advance.

March 23, 2026: AI-powered detections added. Detection coverage was expanded to Shell, Dockerfile, Terraform, PHP, and more. In internal testing, over 170,000 findings were detected in 30 days, with 80% or more receiving positive feedback.

March 31, 2026: Further added tokens from Langchain, Salesforce, Figma, and more to the detection list. Secret management in the agent era has entered a “weekly update” phase.

In addition, a research paper called VibeGuard published on April 1, 2026, is interesting. It proposes a gate targeting “artifact hygiene,” which is hard to cover with traditional static analysis. Source map leaks, packaging configuration drift (unintended changes). A mechanism that catches the kinds of oversights specific to vibe coding.

3 Practical Steps You Can Take Today

In Part 1 I introduced a 3-item checklist, and in Part 2 a 5-item one. This time, as the overall summary of the trilogy, I’m organizing practical steps based on the 3-layer framework.

Step 1: Write Security Specs in Your Prompt (Spec Layer)

Before asking AI to generate code, include the following items in your prompt.

# Security spec template (paste at the top of the prompt)
# 1. Authentication: OAuth 2.0 / JWT / API Key (read from environment variables)
# 2. Input validation: sanitize all user input
# 3. Permissions: principle of least privilege. DB access is READ only, etc.
# 4. Logging: record authentication events and errors
# 5. Secrets: no hardcoding. Manage via .env or secrets manager

If you save the template at the project root as .ai-security-spec.md, you save the trouble of copy-pasting every time. With Claude Code, writing it into CLAUDE.md is also effective.

Step 2: Verify the Agent’s Permissions (Agent Layer)

This overlaps with the 5-item checklist from Part 2, but again:

• Is Auto-Run mode limited to only trusted MCP servers?
• Are there any unfamiliar servers registered in .cursor/mcp.json?
• Are features that perform external communication explicitly opt-in?

Step 3: Add Gates to CI/CD (Gate Layer)

# Secret scanning via GitHub MCP
# Example instruction to AI agent
# "Run a secret scan on this PR's diff"

# VibeGuard-style pre-ship checks (concept)
# 1. Are source maps not included in build artifacts?
# 2. Are .env files not committed?
# 3. Are package versions as intended?

By using the GitHub MCP Server, you can automatically run these checks via an AI agent. You don’t need to memorize commands. Just ask “scan it.”

In Summary: Vibe Coding Is Not About “Quitting” but “Changing How”

Let me organize what I wanted to convey through the trilogy at the end.

• Part 1 (Lovable): The code AI generated has holes. 170 security flaws across 1,645 apps. The target is the “code”
• Part 2 (CurXecute): The AI coding tool itself becomes the attack vector. A zero-click vulnerability with CVSS 8.6. The target is the “tool”
• Part 3 (this article): Forrester proposes “Secure Vibe Coding.” Build in safety across the 3 layers of Spec / Agent / Gate. The answer is “design change”

45% of AI-generated code has security flaws. Even passing functional tests, only 10.5% is safe. 75% of technology decision-makers feel the debt. The numbers are harsh.

On the other hand, the answer is starting to emerge. Forrester defined the paradigm. NCSC released guidelines. GitHub keeps strengthening gate features almost weekly. There’s even research showing that just by adding constraints to the spec, security flaws drop by 73%. The tools are coming together.

I once thought I couldn’t compete with professional engineers. In deep security design, I may still not be able to. But I can write security specs into prompts. I can verify the agent’s permissions. And as for adding gates to CI/CD, GitHub has prepared the steps for us.

The speed of vibe coding is a weapon. You don’t need to let go of that weapon. But change how you grip it. Secure Vibe Coding is not a choice between “safety or speed,” but a transition to a new standard where “you’re fast because you’re safe.” With everyone who read the trilogy, I’d like to keep moving forward through this transition together.