Secure AI Development Lifecycle: A Practical Checklist

98.9% of public Claude Code configs scanned across 18,470 repositories had no deny rules configured. That is not a configuration quirk. It is a precise description of where most AI-assisted development sits today: agents generating production code with no explicit guardrails on what they could touch. Security in an AI-assisted pipeline does not live in the model. It lives in your process: the gates, the constraints, and the automated checks you build around the model.

The 5-stage AI development pipeline

Is AI-generated code actually less secure?

Yes. The current evidence is not ambiguous. AI-generated code passes security review at roughly 50% the rate of human-written code for equivalent functionality, against a human baseline of approximately 95% functional correctness (Veracode 2025). The model is optimising for correctness and coherence - not for the absence of exploitable conditions.

Two data points sharpen the picture. AI coding agents select insecure implementation paths 45% of the time when a secure and an insecure option are both plausible given the context. And a 19.7% hallucinated package rate - packages named but never published - creates a direct supply chain attack vector. A malicious actor registers the hallucinated name, publishes a payload, and the agent installs it. This was documented as "slopsquatting" at USENIX Security 2025.

Stage 1: Spec - security starts before the first token

The agent writes what you describe. If the description is silent on security, so is the output. Three things to do at the Spec stage:

• Name the auth model explicitly. "Authenticated users can only read their own records" is not obvious to a model. Write it. Put it in the spec and in the system prompt the agent runs under.
• Write abuse cases alongside use cases. For every user story, add a corresponding adversarial case: "A user who knows another user's record ID cannot retrieve it." This gives the agent something to check against and gives your reviewer something to test.
• Put OWASP ASVS requirements in AGENTS.md or CLAUDE.md. The agent reads its context file before generating. A short block stating which OWASP Application Security Verification Standard requirements apply to this codebase will shift the output distribution measurably.

Stage 2: Generate - constrain the agent before it runs

The generation phase is where most AI security advice currently lives, and most of it is still not implemented. Three controls:

• Write deny rules before you open the agent. In .cursorrules, CLAUDE.md, or the equivalent for your tool, explicitly list what the agent cannot touch: production credentials, payment processing logic, auth middleware. No deny rules means no constraints. The 98.9% stat is the baseline state of teams without this.
• Box the agent in a worktree or sandbox with scoped credentials. The agent should not have access to production databases, third-party API keys with write permissions, or deployment tooling during generation. A worktree with read-only credentials limits the blast radius of a compromised or confused agent.
• Tag every AI-written diff with [ai-generated]. This sounds trivial. It is not. It creates a searchable, auditable record. It tells your reviewer to apply a different lens. It feeds your Merge Gate tooling - you can run different or stricter rulesets on tagged diffs.

Stage 3: Merge Gate - where to start if you are starting today

The Merge Gate is the highest-leverage intervention point in the pipeline. Code has been generated but not yet deployed. Four controls to implement, in order:

Stage 4: Deploy - least privilege before it goes live

What reaches the deploy stage has cleared the code-level gates. The deploy stage is about constraining what the running service can do, and how it was authorized to do it:

• IAM Access Analyzer. Run it before every deploy. It catches over-permissioned roles before they reach production - AI-generated infrastructure code almost always over-provisions because the model defaults to permissive patterns.
• Kubernetes RBAC least-privilege. Every pod gets the minimum permissions it needs for the documented use case, and no more. No wildcard verbs, no cluster-admin in production.
• Egress allowlist. The service should only be able to call the destinations it is supposed to call. An allowlist prevents a compromised or prompt-injected service from exfiltrating data to an attacker-controlled host.
• IMDSv2 enforced. If you are on AWS, enforce IMDSv2 on all instances. IMDSv1 SSRF is a well-documented attack path. AI-generated code introduces SSRF at elevated rates - this closes the infrastructure-level blast radius.
• OIDC for CI - no long-lived keys. CI/CD pipelines should authenticate to cloud providers via OIDC, not long-lived access keys. Long-lived keys in environment variables are a single-secret-leak away from full deployment access.

Stage 5: Runtime - continuous red team, not annual pentest

The first four stages are pre-production controls. Runtime is where you find what they missed.

• ZAP or Nuclei running continuously. Not on a quarterly schedule. Continuously, against your production environment, integrated into your deployment pipeline so new surfaces are tested as they ship.
• Agentic attack runs on new features. Every new feature that touches auth, data access, or external integrations gets an automated adversarial run before it stabilises. The agent that built it is a useful model for what attack paths exist - run it in adversarial mode.
• AI feature monitoring for prompt injection and tool misuse. If your product includes AI-powered features, those features are an attack surface. Monitor for prompt injection attempts, unexpected tool calls, and data exfiltration via the model's outputs.
• Canary tokens from canarytokens.org. Plant canary tokens in database records, configuration files, and internal APIs. If an attacker accesses them, you get an alert immediately - before the data is used, before the breach is escalated.

IDOR is where static tooling consistently underperforms. A SAST rule can flag an obvious missing authorization check, but it cannot reason about whether a chain of individually correct-looking calls adds up to an authorization bypass. The attacker does not need a single broken line - they need a sequence that the tool never evaluates as a unit. Runtime testing with an adversarial agent evaluates the sequence. That is the gap the first four stages leave open, and why Runtime is not optional.

Where should I start?

Start at Stage 3: the Merge Gate. It requires no change to how your team writes code, no change to your deploy process, and no runtime access. It sits between generation and production and catches the majority of AI-generated vulnerabilities before they matter. Add Semgrep, gitleaks, and Socket this week. Add the authorization test this sprint. Then build outward from there.

Below is the full checklist, stage by stage. Use it as an internal audit.