Building Security Guardrails for AI Code Generation

The Thoughtworks team coined the term VibeSec to describe a growing problem: AI coding assistants generate insecure code with alarming consistency, and developers building at high velocity often accept those suggestions without proper scrutiny. The phenomenon extends beyond simple oversight. When you ask an AI to scaffold a web server, it might default to CORS policies set to *, disable HTTPS verification for convenience, or generate authentication flows that store passwords in plaintext.

The challenge is architectural. AI models trained on public codebases learn from a corpus where quick prototypes, Stack Overflow answers, and tutorial code outnumber production-hardened implementations. The model has seen thousands of examples where someone disabled SSL verification to fix a certificate error, so it confidently suggests the same approach when you encounter a similar error message. This is not a training problem that newer models will solve. Even frontier models in 2026 reproduce these patterns because they optimize for code that runs, not code that runs securely.

Context Files as Security Policy

The first mitigation layer involves encoding security requirements directly into the AI’s context window. Tools like Claude Code, Cursor, and Windsurf read project-level instruction files (typically CLAUDE.md, .cursorrules, or similar) that guide code generation. The Thoughtworks team found that explicit security directives in these files reduced insecure suggestions significantly.

A minimal security context file might include:

# Security Requirements

## Authentication
- Use bcrypt with cost factor 12 or higher for password hashing
- Never store credentials in environment variables committed to version control
- Implement rate limiting on all authentication endpoints (max 5 attempts per 15 minutes)

## API Security
- All API endpoints must validate input against a schema
- CORS policies must explicitly list allowed origins, never use wildcard
- Require authentication tokens in headers, not query parameters

## Data Handling
- Use parameterized queries exclusively, never string concatenation for SQL
- Sanitize all user input before rendering in HTML contexts
- Log security events (failed auth, permission denials) to a separate audit stream

The file serves as a persistent reminder that the model references on every generation. When you ask it to create a database query, it sees the parameterized query requirement and structures the code accordingly. This approach works because modern AI coding assistants retrieve and incorporate project documentation into their working context before generating code.

However, context files have limits. They add tokens to every request, which can push older conversation history out of the context window. They also require maintenance; outdated guidance (referencing deprecated libraries or superseded best practices) can be worse than no guidance. The context file should be treated as security documentation that happens to also instruct the AI, not as a replacement for code review.

Permission Boundaries and Tool Access

AI coding assistants increasingly operate as agents with file system access, shell execution, and network capabilities. Claude Code can run arbitrary bash commands, read and write files, and invoke language servers. Cursor can execute code directly in your development environment. This execution model introduces a new attack surface: the AI itself becomes a vector for security issues.

The permission model matters significantly here. Some tools implement a prompt-per-action model where the AI must request permission for each file write or command execution. Others batch operations or allow blanket permissions for certain directories. The Thoughtworks team recommends treating AI permission requests with the same scrutiny you would apply to a junior developer with shell access.

Specific permission boundaries to enforce:

1. File system isolation: Restrict write access to source directories, prevent modifications to configuration files like .env, .aws/credentials, or SSH keys.
2. Command restrictions: Disallow commands that modify system state (package installation, service management, firewall changes) without explicit review.
3. Network boundaries: Block outbound requests to internal network ranges, require approval for any external API calls.
4. Secrets access: Never allow the AI to read files containing credentials or API keys, even to help debug authentication issues.

Implementing these boundaries requires tooling support. Claude Code allows fine-grained permissions through its settings file. You can specify allowed commands, file path patterns, and require approval for specific operations. A secure configuration might include:

{
  "allowedCommands": [
    {"command": "git status"},
    {"command": "npm test"},
    {"command": "npm run build"}
  ],
  "blockedPaths": [
    "**/.env*",
    "**/credentials.json",
    "**/.ssh/**"
  ],
  "requireApprovalFor": [
    {"pattern": "npm install*"},
    {"pattern": "curl*"},
    {"pattern": "wget*"}
  ]
}

Security Intelligence Feeds

The Thoughtworks team implemented a daily security intelligence feed that surfaces new CVEs, dependency vulnerabilities, and security advisories relevant to their stack. This feed gets incorporated into the AI’s context, making it aware of recent disclosures.

The feed aggregates multiple sources:

• GitHub security advisories for dependencies in package.json, requirements.txt, or equivalent
• NIST NVD updates filtered by technology keywords (Node.js, PostgreSQL, Redis, etc.)
• Language-specific security mailing lists (npm security advisories, Python security announcements)
• Internal security bulletins from your security team

The aggregated feed gets formatted as a markdown document and placed in the project root. The AI coding assistant reads it as part of the project context. When it suggests adding a new dependency or upgrading an existing one, it checks the feed for known vulnerabilities.

This approach caught several issues in the Thoughtworks deployment. The AI suggested using an older version of a library to maintain compatibility with existing code, but the security feed noted a critical RCE vulnerability in that version. The model adjusted its recommendation to use the patched version and suggested refactoring the compatibility layer instead.

Secure-by-Default Templates

The fourth pillar involves providing template projects and scaffolding tools that embed security from the start. Rather than asking the AI to generate a new Express server from scratch (where it might choose insecure defaults), you point it to a hardened template that includes:

• Helmet.js configured with strict CSP, HSTS, and other security headers
• Rate limiting middleware pre-configured
• Input validation using a schema library (Zod, Joi, or similar)
• Authentication middleware with secure session handling
• Logging configured to capture security events
• Dependency scanning integrated into the CI pipeline

The template becomes the starting point for all new services. When you ask the AI to add a new endpoint, it works within the existing security infrastructure rather than reinventing it. This reduces the surface area where insecure defaults can appear.

Template maintenance is critical. A template that falls behind current best practices or includes outdated dependencies becomes a liability. The Thoughtworks team treats their template repository as production infrastructure, with regular security reviews and automated updates for dependencies.

Measurement and Iteration

These mitigations only work if you measure their effectiveness. Key metrics include:

• Security findings in AI-generated code during review: Track how many security issues appear in pull requests where AI tools contributed significant portions of the code.
• False positive rate on AI permission denials: If developers frequently override permission restrictions, the boundaries might be too strict or poorly calibrated.
• Context file reference rate: Monitor whether the AI actually retrieves and uses the security context file, or if it gets pushed out by other context.
• Template adoption: Measure how often new projects use the secure templates versus starting from scratch.

The Thoughtworks team found that security findings in AI-generated code dropped by roughly 60% after implementing these four practices together. Importantly, this did not significantly slow development velocity. Developers still prototyped quickly, but the prototypes started from a more secure baseline.

The approach requires ongoing investment. Context files need updates as new vulnerabilities emerge and security practices evolve. Permission boundaries need refinement as developers encounter legitimate use cases that the initial restrictions blocked. Security feeds require maintenance to filter noise and surface relevant threats. Templates need regular refreshes to stay current with the ecosystem.

But the alternative is accumulating security debt at AI-accelerated speed. The same tools that let you ship features faster also let you ship vulnerabilities faster. Building guardrails into the AI-assisted development workflow means you can maintain velocity without sacrificing security posture.