Topic starter
18/08/2026 2:42 pm
TL;DR: An audit of Cursor, GitHub Copilot, Codeium, and Qodo Gen found that all four AI coding tools could generate insecure code across multiple CWE categories, including weak encryption, access control issues, and unsafe execution patterns, according to VirtueAI. The finding is a governance problem, not just a coding quality problem: developers need policy, review, and runtime guardrails around AI-assisted code generation.
Editorial analysis by NHI Mgmt Group, based on content published by VirtueAI: “How Safe is Your AI Coding Assistant? A Virtue AI Security Audit”.
Key questions
Q: How should teams govern insecure code suggestions from AI coding assistants?
A: Use policy, review and automated checks together.
Q: Why do AI coding tools still create security risk even when developers use security-aware prompts?
A: AI coding tools can still produce insecure output because prompt discipline does not guarantee secure implementation.
Q: What breaks when AI-generated code handles access control or sensitive data poorly?
A: The application can silently ship insecure logic that exposes data, weakens authorisation, or enables arbitrary execution.
Practitioner guidance
- Define prohibited code patterns for AI assistants Block generation of dangerous constructs such as direct eval, unsafe deserialisation, broad wildcard access, and unredacted sensitive-field templates in approved coding workflows.
- Add secure-code review gates for AI output Route AI-generated code through the same review and testing path used for high-risk third-party code, with explicit checks for CWE-79, CWE-95, CWE-200, CWE-327 and access-control issues.
- Require policy enforcement beyond prompts Treat prompt text as guidance only and enforce security requirements with automated linters, test cases, and build-time blockers that can reject unsafe completions.
Bottom line: AI coding assistants can improve productivity and still create serious security exposure when they autocomplete unsafe patterns into live code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:26 pm
AI coding assistants are now part of the software trust boundary. When an assistant can generate insecure code at autocomplete speed, the risk is no longer limited to developer error. It becomes a governance problem across prompt policy, code review, secure SDLC controls, and post-generation validation. Practitioners should treat generated code as an untrusted intermediate artifact until it passes the same security checks as third-party code.
A few things that frame the scale:
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
Q: What should organisations do when AI coding assistants touch private repositories?
A: Restrict assistant access until logging, policy enforcement, and approval workflows are in place for sensitive codebases. Private repositories deserve stricter governance because assistant prompts, suggestions, and generated snippets can expose code or secrets if the toolchain is not bounded. The decision should be based on visibility and control, not developer convenience.
👉 Read our full editorial: AI coding assistants can still generate vulnerable code at scale