Stop Asking Your AI to “Write Secure Code”

If you use Claude Code, Cursor, or Windsurf, i bet you already know the “4-Minute Problem.”

You ask your AI assistant to build a user profile page with a profile picture upload feature, for example. Four minutes later, you have fully working code. It compiles beautifully, the UI looks amazing, and the files successfully upload to your S3 bucket.

You also have:

1. An SVG XSS vulnerability because the code trusts the client-provided MIME type.
2. A path traversal risk because it uses the original filename for the storage key.
3. A world-readable S3 bucket because the infrastructure-as-code relied on overy-permissive defaults.

These AI models optimize for working code, not secure code. And simply dropping “always write secure code and check the OWASP Top 10” into your .cursorrule file doesn't fix it. Generic system prompts fail because security isn't a generic state; it is 100% a phase-gated process.

So, to solve this in our own workflows, we built a set of 8 specialized AI agents that hook directly into MCP-compatible tools to enforce a Secure Software Development Lifecycle (SDLC). We open-sourced the whole thing.

Moving from “Vibe Coding” to Artifacts

The problem with typical AI coding is that it skips the design phase. We wanted to force the LLM to pause and put on a specific security hat at specific phases of development.

Instead of one massive prompt, we broke the SDLC down into 8 distinct agents:

1. Product Manager: Maps user stories to OWASP ASVS requirements.
2. AppSec Engineer: Runs STRIDE threat models and triages SAST/DAST findings.
3. Cloud/Platform Engineer: Reviews Terraform/Kubernetes for CSPM gaps and hardcoded secrets.
4. GRC Analyst: Maps controls to SOC 2, ISO 27001, and GDPR, maintaining the risk register.

(Plus, a Dev Lead, Release Manager, Security Champion, and an AI Security Engineer).

These are not autonomous agents running wild in your repository, they are exposed via the Model Context Protocol (MCP). When you invoke a tool like sdlc_threat_model in Cursor, it loads a highly specific STRIDE checklist and forces the LLM to output a concrete Markdown artifact (e.g., docs/threat-model.md).

How It Works in Practice: The File Upload Example

Let’s go back to the file upload feature.

If you use the Secure SDLC agents, the workflow looks completely different.

Before writing code, you invoke the product-manager agent. It generates security-requirements.md mapped to ASVS Level 2, explicitly requiring magic byte validation (not just MIME checks) and server-side re-encoding.

Next, you invoke the appsec-engineer to threat-model the architecture. It flags that SVG files must be explicitly blocked because they are XML and can contain script tags, making them impossible to safely sanitize.

When the AI eventually writes the code and the PR is opened, you invoke the dev-lead agent. Armed with the context of the threat model and the ASVS requirements, it catches the exact flaw that "vibe coding" misses:

Simultaneously, the cloud-platform-engineer agent reviews your Terraform and throws a CRITICAL block because the S3 bucket's Block Public Access setting was disabled, risking a data leak.

The CI/CD Reality Check

A common question we get is:

“Do these LLM agents run in my GitHub Actions pipeline?”

Absolutely not.

LLMs are non-deterministic and have no place making autonomous pass/fail security decisions in an automated pipeline.

Instead, the GitHub Actions workflow we provide (secure-sdlc-gate.yml) acts as a deterministic gatekeeper. It runs traditional tools (Gitleaks, Checkov, CodeQL, npm audit).

Crucially, it also verifies that the AI-generated Markdown artifacts (like the risk register and the release sign-off) actually exist in the repository and are fully filled out before allowing a merge to the main branch.

The AI does the heavy lifting of context-gathering and threat modeling locally in your IDE, and CI/CD simply ensures you didn’t skip the process.

Security is Engineering, Not Theatre

We built this because the current approach to AI coding generates massive amounts of technical and security debt.

These agents won’t replace a skilled AppSec engineer or a thorough penetration test and they should not be used to do so. What they will do is force you to ask the right questions earlier, produce consistent audit artifacts, and catch the low-hanging architectural flaws that traditional SAST tools miss.

You can install the CLI globally via npm (npm install -g @kaademos/secure-sdlc) or via Claude marketplace to scaffold the git hooks, templates, and MCP server into your project.

Check out the repo, read the worked examples, and let us know where the prompts can be improved.

Repository: https://github.com/Kaademos/secure-sdlc-agents

(Author note: If you are an AppSec practitioner navigating the new world of AI coders, I’d love to hear your feedback on the ASVS prompt mappings in the repo comments.)