Most “AI code security” content either repeats vague warnings about hallucinated code or pitches a scanning tool. This piece does neither: it’s a walkthrough of what OWASP itself has actually published on securing AI-generated and AI-assisted code — specifically the OWASP Top 10 for LLM Applications and, more directly, the OWASP AI Security Verification Standard’s (AISVS) dedicated appendix on AI-assisted secure coding. If you want the broader technical-debt angle or a tool-by-tool comparison, see our pieces on AI-generated code’s hidden technical debt, static analysis tools (SonarQube, Semgrep, CodeQL), and our agentic-security checklist — this one stays specifically inside OWASP’s own published framework.
At a Glance
| OWASP Source | What It Covers | Relevant to AI-Generated Code? |
|---|---|---|
| OWASP Top 10 for LLM Applications (2025) | Ten risk categories for applications built on or with LLMs (prompt injection, output handling, supply chain, etc.) | Indirectly — these are the risk mechanisms that also show up when an LLM writes code |
| OWASP AISVS (AI Security Verification Standard) v1.0, Appendix C | A dedicated appendix titled “AI-Assisted Secure Coding,” with 14 control families and three verification levels | Directly — this is OWASP’s explicit guidance for teams using AI to generate, refactor, or review code |
Short Verdict
OWASP’s most direct, named guidance on AI-generated code lives in AISVS Appendix C, “AI-Assisted Secure Coding” — not in the better-known Top 10 for LLM Applications, which is about risks in LLM-powered applications generally. Appendix C’s core message is procedural, not technical: AI coding tools must be forced into your existing secure development lifecycle (SSDLC) rather than allowed to bypass it, humans (never the AI itself) must remain the accountable reviewer, and every AI-generated artifact — code, infrastructure files, pipeline configs — needs the same or stricter scanning and sign-off as human-written equivalents.
What OWASP’s Guidance Actually Says
The Top 10 for LLM Applications (2025) catalogs ten risk categories relevant to any system built around a large language model: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, and LLM10 Unbounded Consumption. Several of these map directly onto AI coding tools: a prompt-injected code comment or PR description (LLM01), an agent given more repository permissions than it needs (LLM06), or a coding assistant quietly leaking a secret it was shown in context (LLM02).
AISVS Appendix C takes those general risks and translates them into specific, testable requirements for code-generation workflows. Its core premise: AI coding tools must fit into the existing SSDLC without weakening its security gates, and organizations should document which adversarial-AI threats each guardrail addresses before adopting a tool. OWASP names concrete risk scenarios the appendix is designed to address, including prompt injection delivered through PR descriptions, issues, commit messages, or MCP tool outputs; sensitive data leaking into prompts; AI-generated dependencies that are typosquatted or unresolvable; autonomous agents approving their own work; and bulk, AI-driven fork-and-PR campaigns from low-reputation accounts.
The 14 Control Families in AISVS Appendix C
| Control Family | Key Requirement |
|---|---|
| AC.1 Workflow | Document when AI may generate/refactor/review code; keep mandatory security gates regardless of AI involvement |
| AC.2 Tool Qualification | Threat-model every AI tool and run adversarial robustness (prompt-injection/jailbreak) tests before onboarding |
| AC.3 Prompt and Context Management | Prohibit secrets in prompts; treat external context as untrusted; enforce an instruction hierarchy |
| AC.4 Validating AI Code | Require review by a human who is not the requester; never count the AI as the reviewer; run SAST/DAST/SCA on AI PRs |
| AC.5 Traceability | Log prompt-response pairs with correlation IDs; store AI event logs in tamper-evident storage |
| AC.6 Feedback and Red-Teaming | Let developers flag insecure suggestions; run scheduled red-team exercises against the AI tooling itself |
| AC.7 Infrastructure and Pipeline Artifacts | Label AI-generated IaC/CI/CD files; require human approval before they run outside a sandbox |
| AC.8 Agent Change Control | Agents must not approve, merge, sign, or deploy their own output — enforced in tooling, not just policy |
| AC.9–AC.10 Origin Validation | Attach signed provenance (SLSA/in-toto attestations, AI BOM entries) to AI-generated artifacts |
| AC.11 AI Review Bot Hardening | Treat PR content as untrusted; sign/hash-pin bot system prompts; run bots in isolated, least-privilege sandboxes |
| AC.12 Pipeline Hardening for AI | Never run untrusted fork code in privileged workflow contexts; use ephemeral runners and two-stage workflows |
| AC.13 Inbound Adversarial Detection | Flag bulk PR creation from new accounts and coordinated fork waves; map detections to MITRE ATT&CK/ATLAS |
| AC.14 Containment and Remediation | Maintain an incident playbook for AI-in-pipeline compromise; test time-to-revoke AI agent credentials |
OWASP assigns each requirement a verification level — Level 1 (baseline), Level 2, or Level 3 (advanced) — modeled on the existing OWASP ASVS (Application Security Verification Standard). Level 1 covers essentials like an AI usage policy, prompt redaction, untrusted-input screening, and separation of duties between the AI and its human reviewer. Level 3 covers more mature practices like measuring AI-produced code against a human-only baseline, tamper-evident logging, and continuous regression testing of the AI tooling itself.
Practical Mitigations: Adapting Code Review and Security Practice
- Keep humans as the accountable reviewer. AISVS AC.4 is explicit that the reviewer must not be the AI agent itself, and should not be the person who requested the generation — this closes the “autonomous agent approves its own work” gap named under AC.8.
- Run the same scanners on AI output as on human code — or stricter ones. AC.4 calls for SAST, DAST, IAST, secret scanning, IaC scanning, and SCA on AI-generated PRs, with merges blocked on critical findings absent a written human exception, and stricter review reserved for security-critical files (auth, crypto, IAM, CI/CD).
- Treat anything an AI tool reads from a repository as untrusted input. AC.3 and AC.11 both call for screening external context — PR descriptions, issues, comments, web content, MCP tool outputs — for injection attempts before it reaches a model or an AI review bot.
- Harden the pipeline itself, not just the code. AC.12 specifically warns against running untrusted fork code in privileged GitHub Actions contexts like
pull_request_targetorworkflow_run, and calls for ephemeral runners and two-stage workflows that pass only validated artifacts forward. - Attach provenance to AI-generated artifacts. AC.9–AC.10 call for signed attestations (SLSA, in-toto) and AI bill-of-materials entries recording model identity, tool identity, and prompt hash — so a compromised or hallucinated artifact can be traced back to its origin.
Where OWASP’s Guidance Is Still Maturing
OWASP is explicit that some of this ground is still shifting. AC.13 notes that “where automated detection of LLM-generated code is immature, use compensating controls such as mandatory human review and sandboxed execution” — in other words, OWASP itself does not claim there’s a reliable automated way to detect whether code came from an AI versus a human, and recommends process controls instead of a detection tool. AISVS is versioned at 1.0, positioned as the latest stable release and modeled on the long-established OWASP ASVS, but it is a newer, community-driven standard rather than a decades-proven one — teams should expect it to evolve and should check for newer versions before treating any specific control as final.
Who This Guidance Is For
This is directly useful for security and platform engineering teams standing up policy around AI coding assistants, AI PR-review bots, and autonomous coding agents — especially teams that need a structured, levelled checklist (Level 1/2/3) to decide how far to go rather than starting from a blank page.
This is less directly useful for teams looking for a specific tool recommendation (OWASP’s guidance is tool-agnostic and procedural) or for a ranked list of today’s most severe AI-code vulnerabilities (that’s closer to what the Top 10 for LLM Applications covers at the application level, not the coding-workflow level Appendix C addresses).
Bottom Line
OWASP’s position, stated plainly across AISVS Appendix C, is that AI-generated code is not inherently more or less dangerous than human-written code — it’s dangerous when it’s allowed to skip the controls human-written code already goes through. The fix isn’t a new scanning product; it’s making sure your existing SSDLC gates (review, SAST/DAST/SCA, least-privilege CI, signed provenance) apply with equal or greater force to anything an AI tool touches, and that no AI agent is ever its own approver. Teams adopting AI coding agents in 2026 should treat AISVS Appendix C as a checklist to audit against, not a one-time read.
FAQ
Does OWASP have guidance specifically about AI-generated code, or only about LLM applications in general?
Both exist, but they’re different documents. The OWASP Top 10 for LLM Applications (2025) covers risks in applications built on LLMs generally. OWASP’s AI Security Verification Standard (AISVS) v1.0 includes a dedicated appendix, “Appendix C: AI-Assisted Secure Coding,” that speaks directly to AI-generated/AI-assisted code in software development workflows.
Can an AI code review bot count as the required human reviewer under OWASP’s guidance?
No. AISVS AC.4 explicitly requires review by a qualified human who is not the original requester, and states the AI agent must never be counted as that reviewer.
What does OWASP say about letting AI agents merge or deploy their own code?
AISVS AC.8 (“Agent Change Control”) states that agents must not approve, merge, sign, or deploy their own output, and that this must be enforced in source control, CI, and the artifact registry — not just written as policy.
Is AISVS a finished, stable standard?
Version 1.0 is described by OWASP as the latest stable release, modeled on the established OWASP ASVS. It is newer and less battle-tested than ASVS itself, and OWASP structures it with three verification levels so organizations can adopt baseline controls first and add more advanced ones over time.
Sources
- OWASP AISVS — Appendix C: AI-Assisted Secure Coding (official document)
- OWASP — AI Security Verification Standard (AISVS) Project Page
- OWASP — Top 10 for LLM Applications (2025)
- OWASP GenAI Security Project — Top 10 for LLM Applications 2025 Resource Page
- OWASP AISVS — GitHub Repository
Discover more from Software Online Review
Subscribe to get the latest posts sent to your email.
