New Report: Nearly Half of AI-Generated Code Fails Security Tests
Serge Bulaev
A new report suggests that nearly half of AI-generated code may fail basic security tests, with failure rates reported between 45 and 70 percent. Enterprises using AI coding assistants might face new security and compliance challenges. Experts recommend controls like approved tool lists, usage monitoring, and mandatory reviews of AI-generated code to reduce risks. About 20 percent of AI code suggestions may reference non-existent packages, which could expose teams to extra threats. Vendors and contracts should include rules for security, data ownership, and exit options to help keep systems safe and compliant.

As enterprises adopt AI coding assistants, they encounter significant security and compliance risks. A new report highlights a critical issue: nearly half of AI-generated code fails security tests, with failure rates between 45% and 70%. This playbook provides actionable controls for security, engineering, and procurement teams to mitigate these emerging threats.
To manage these risks, a robust governance baseline is essential. A recent study outlines five pillars for enterprise adoption: an Approved Tool Registry, Data Classification, Usage Monitoring, Training Requirements, and Incident Response (Baeseokjae framework). The goal is to integrate AI assistants into existing SDLC, IAM, and vendor risk management programs, not manage them in isolation.
Governance Controls to Stop Shadow AI
To mitigate risks from AI coding assistants, enterprises should establish strong governance. This includes creating an approved tool registry, enforcing role-based access control with SSO, and mapping controls to a tiered risk model. Centralized logging and clear policies are essential for preventing shadow AI adoption and ensuring compliance.
Begin by registering all assistants in an approved-tool catalog and mandating single sign-on (SSO) with role-based access control (RBAC). A comprehensive deployment strategy includes seven critical controls: SSO, SIEM-integrated audit logs, secret scanning, policy-as-code gates, license governance, sandbox isolation, and incident response runbooks (Northflank blog). These controls should be mapped to a tiered risk model:
- Green tier - documentation, prototypes, and test generation with standard logging.
- Conditional tier - internal code with data-retention limits and periodic review.
- Restricted tier - production-critical or regulated work that demands explicit security approval and compensating measures.
Ensure all tiers log to a single, centralized destination, enabling auditors to correlate user prompts, AI outputs, and repository commits.
Technical Gates in the SDLC
Always treat AI-generated code as untrusted input. Implement strict pre-merge gates that block commits based on high-severity findings from mandatory security scans. Key controls include:
- Secrets detection
- Static Application Security Testing (SAST)
- Software Composition Analysis (SCA)
- Package allowlisting
The CSA research note warns that around 20% of AI suggestions may reference non-existent packages, exposing teams to dependency confusion or 'slopsquatting' attacks. To improve traceability, tag all commits modified by AI assistants. Furthermore, isolate AI agent execution from production networks using ephemeral, least-privilege tokens. Any automated tasks or tests initiated by an agent must run in a containerized sandbox without write access to protected branches.
Essential AI Coding Policy Checklist
Establish a concise, enforceable policy documented in both the developer handbook and the procurement portal. The policy should mandate the following:
- Developers may use only tools on the Approved Tool Registry, with company-managed accounts.
- Prompts and context must exclude secrets, credentials, regulated data, and core IP unless the endpoint is explicitly approved for that class.
- All AI-generated code requires mandatory human review and must pass all SAST, SCA, and secret scanning gates before being merged.
- Any suggestion that adds a new dependency triggers automated license and supply-chain checks.
- Suspected policy violations or unsafe outputs must be reported within one business day through the incident response channel.
These rules mirror familiar guardrails from open-source software intake processes, simplifying adoption for development teams.
Vendor and Contract Safeguards
Your vendor contracts must align with your technical security posture. When negotiating with AI tool providers, prioritize clauses that:
- Prohibit the vendor from training on customer code without an explicit opt-in.
- Grant the customer ownership of generated outputs, subject to third-party rights.
- Provide AI-specific IP indemnification.
- Require advance notice of major model changes with the right to pin or roll back versions.
Security riders should also mandate SOC 2 Type II compliance, specific breach notification timelines, and audit rights for model versioning and log access.
Finally, secure your long-term continuity with robust exit provisions. Contracts should include rights to data export in open formats, transition assistance, and an escrow or source-available option for mission-critical deployments. This ensures operational stability if the vendor changes its terms or ceases operations.
Why is AI-generated code failing security tests so frequently?
Research from 2026 indicates that 45% to 70% of AI-generated code samples fail security tests depending on the method used, with authorization flaws, missing access controls, and hardcoded credentials dominating the failure patterns. Additionally, approximately 20% of AI-generated code references non-existent packages, creating direct supply-chain risks through "slopsquatting" attacks. The core issue is that AI models are trained on vast code repositories that include both secure and insecure patterns - they reproduce what they see without understanding security context.
What governance structures should enterprises establish for AI coding tools?
Enterprises should implement a tiered risk model with three clear levels:
- Low-risk/Green-tier use: documentation, boilerplate, tests, internal tooling, and prototypes with standard monitoring
- Medium-risk/Conditional use: internal code assistance with data-retention controls, centralized audit logging, and periodic review
- High-risk/Restricted use: production credentials, PII, regulated data, infrastructure changes, or security-sensitive code requiring explicit security approval
Central to effective governance is maintaining an approved AI coding tool registry with formal vendor review processes. This prevents shadow AI and ensures procurement, legal, and security teams evaluate tools before broad deployment. Organizations should also establish organization-managed accounts rather than allowing personal free-tier accounts, enabling proper auditability and access control.
What technical controls are most effective for mitigating AI code risks?
The most practical enterprise control set for 2025-2026 centers on mandatory, automated controls embedded throughout the SDLC:
Pre-commit and merge gates:
- Secrets detection scanning across all repositories, with signatures for AI-service credentials
- SAST (Static Application Security Testing) as a blocking gate for AI-generated contributions
- SCA (Software Composition Analysis) and dependency verification against your SBOM
Runtime and operational controls:
- Sandbox isolation for agent execution, especially when agents can run commands or modify repositories
- Code provenance tracking to tag AI-assisted files and commits for future re-review
- Package allowlisting/firewalling to block known-malicious or suspicious packages
Escalated review requirements should apply specifically to code touching authentication, authorization, IAM, database access controls, cryptography, or infrastructure - areas where AI-generated code shows recurring weakness.
What contractual protections should enterprises negotiate with AI coding vendors?
Enterprise SLAs must move beyond generic SaaS terms to address AI-specific risks. The highest-priority clauses include:
| Priority | Clause | Enterprise Ask |
|---|---|---|
| 1 | Training-data restriction | No training on customer code or prompts without explicit opt-in |
| 2 | Output ownership/IP rights | Customer owns outputs with clear third-party rights carve-outs |
| 3 | AI-specific indemnity | Coverage for generated code infringement and training-data claims |
| 4 | Versioning/change control | Advance notice of material model changes; version pinning rights |
| 5 | Audit rights/transparency | Access to logs, model/version info, and compliance documentation |
| 6 | Exit/portability | Data export in open formats, transition assistance, escrow where critical |
Vendors should provide SOC 2 Type II assurance, clear data retention and deletion policies, and subprocessor transparency. For regulated environments, contract language should map to specific compliance obligations rather than generic promises.
What developer training and operational practices reduce AI coding risks?
Even with strong technical controls, human review remains essential. Organizations should require:
- Disclosure and traceability: PR templates or internal records identifying AI-generated contributions
- Mandatory security review: AI-generated code must pass the same gates as human-written code, with heightened scrutiny for high-risk changes
- Prompt hygiene training: Developers need education on what data must never enter AI prompts (secrets, credentials, customer data, proprietary source code)
- Incident reporting: Defined processes for accidental disclosure, suspicious assistant behavior, or policy violations
A critical operational practice is disabling auto-apply of AI suggestions. Human code review should be mandatory before any AI-generated code enters production, treating such code as third-party code with equivalent scrutiny.