AI coding assistants can still generate vulnerable code at scale

At a glance

What this is: VirtueAI’s audit compares four AI coding assistants and finds that each can produce insecure code, with recurring weaknesses in encryption, access control, input handling, and unsafe execution.

Why it matters: For IAM and security teams, the issue is that AI-assisted development can introduce exploitable logic and access flaws into production faster than review processes can reliably catch them.

👉 Read VirtueAI's audit of AI coding assistant security across four tools

Context

AI coding assistants reduce manual effort, but they also move security decisions earlier in the development flow and often outside traditional review checkpoints. In practice, that means insecure patterns can be generated at the point of code creation, where developers may trust the suggestion because it looks syntactically correct and operationally convenient.

This matters to identity and access teams because code-generation tools can introduce access control failures, sensitive data exposure, and unsafe execution paths into applications that later rely on IAM, PAM, secrets management, and runtime policy to contain the blast radius. NHIMG’s broader view is that AI-assisted coding changes not only development velocity, but also the governance burden around code provenance, review, and policy enforcement.

For teams already struggling with secrets sprawl and over-permissioned service accounts, insecure code suggestions compound an existing control gap rather than creating a brand-new one. That makes this a familiar but accelerated risk pattern, not an edge case.

Key questions

Q: How should security teams govern AI coding assistants that can execute commands?

A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.

Q: Why do AI coding assistants create access control risk in applications?

A: Because they often generate code that assumes the caller is trusted or that sensitive fields are safe to expose. That can produce direct object access, weak filtering, or missing authorisation checks, which later become real breaches when application logic is reused in production. The risk is strongest around data-rich and admin-facing flows.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

Q: How can organisations reduce data exposure in AI tools?

A: Start with data classification, then map where sensitive information can flow into prompts, connectors, and logs. Limit AI systems to the minimum data they need, require owner approval for higher-risk datasets, and monitor for unsanctioned sharing. Data controls work best when paired with identity controls and usage visibility.

Technical breakdown

Why AI coding assistants produce insecure code

These systems optimise for plausible next-token completion, not security intent. In tab completion mode, they infer the most likely code pattern from context, which means insecure idioms can appear when the prompt, surrounding code, or training data normalise them. If a completion looks functionally correct, a developer may accept it before considering threat model, input trust, or privilege boundaries. The core issue is that code generation is probabilistic assistance, not policy enforcement.

Practical implication: treat AI-generated code as untrusted input until it passes review, test, and security validation.

Why access control and sensitive data exposure are common failure modes

Access control failures occur when generated code assumes the caller is trusted, the data is safe to expose, or the runtime context is already constrained. Sensitive data exposure happens when templates, logging, serialization, or helper functions include fields that were never meant to leave memory or backend storage. These are governance failures as much as coding defects because they reflect missing policy boundaries around what the assistant may suggest and what the application may reveal.

Practical implication: apply explicit data-minimisation and authorisation rules to any AI-assisted code path that handles secrets or personal data.

Why secure-looking code can still hide unsafe execution paths

AI assistants can produce code that appears defensive while still relying on dangerous primitives, weak parsing, or incomplete validation. A function may look carefully structured yet still evaluate untrusted input, bypass type constraints, or expose execution channels through helper logic. This is especially risky in automation, receipt generation, script parsing, and admin tooling, where developers often optimise for convenience and flexibility. Security must therefore inspect both the visible logic and the hidden trust assumptions.

Practical implication: add static analysis, targeted tests, and human review for any generated code that evaluates input or invokes dynamic behaviour.

Threat narrative

Attacker objective: The attacker aims to turn AI-assisted coding mistakes into code execution, data exposure, or broader application compromise.

1. Entry occurs when a developer accepts AI-generated code completion that already contains an insecure pattern or unsafe assumption.
2. Escalation follows when the flawed code reaches a path handling inputs, credentials, or sensitive fields without proper validation or filtering.
3. Impact occurs when attackers exploit the weakness to execute arbitrary code, expose confidential data, or weaken application access controls.

NHI Mgmt Group analysis

AI code generation is becoming a governance problem, not just a developer productivity problem. Once assistants can emit insecure code at scale, the control question shifts from whether developers can write faster to whether organisations can govern what the model is allowed to suggest. That is a policy, review, and assurance issue, not a syntax issue. Practitioners should treat AI-generated code as a governed supply stream.

Access control logic is where AI-generated defects become enterprise risk fastest. The article’s examples map directly to access control, data exposure, and unsafe execution paths, which are the same categories that create downstream IAM and secrets-management failures. If code can print credentials, evaluate untrusted content, or overexpose objects, the organisation inherits a control failure that later identity tooling must try to contain. Practitioners should prioritise security review on code paths that touch trust boundaries.

Named concept: AI-assisted code trust gap. This is the difference between code that looks safe to a developer and code that has actually been validated against security policy. The trust gap widens when teams rely on autocomplete as a quality signal instead of a prompt for verification. Practitioners should close it with review gates, policy checks, and secure coding standards for AI use.

Identity and secrets governance must move left into the development workflow. When assistants can expose sensitive fields or encourage insecure handling of credentials, the downstream problem is not only code quality but identity sprawl in application logic. IAM and PAM teams should collaborate with engineering to define what generated code may touch, store, log, or transmit. Practitioners should align AI coding controls with identity and secrets policies, not just application security review.

Security benchmarks for AI assistants need to measure harmful precision, not just general correctness. A tool that writes valid code but repeatedly misses security boundaries is operationally unsafe even if it performs well on ordinary developer tasks. The relevant question is whether the assistant respects authorisation, secrecy, and input-validation boundaries under realistic prompts. Practitioners should demand evaluation criteria that reflect security outcomes, not only functional completion.

What this signals

AI-assisted development expands the attack surface of identity and secrets governance. When code generators can surface credentials, expose customer data, or normalise unsafe execution, development teams need controls that span prompts, pull requests, and runtime review. The practical shift is toward policy-backed secure coding, not just code scanning after the fact.

A useful operating model is to treat generated code as part of the trust chain. That means IAM, PAM, and application security teams should define what data can be referenced in assistant prompts, what code patterns are disallowed, and which workflows require mandatory verification before merge. For identity-heavy systems, the control question is whether the assistant is allowed to touch secrets, sessions, and access logic at all.

For practitioners

• Require human review for security-sensitive completions Gate AI-generated code that touches authentication, access control, secrets, logging, serialization, or input parsing behind mandatory review by an engineer who can assess trust boundaries and data exposure.
• Add static analysis to every AI-assisted pull request Scan generated code for unsafe primitives such as eval-like execution, unvalidated string formatting, insecure cryptography, and direct access to sensitive object fields before merge.
• Define an AI coding policy for protected data Specify which fields may never appear in generated code, tests, logs, or templates, and tie that policy to redaction rules for credentials, payment data, and personal information.
• Build prompt and completion test cases for security failures Create regression tests that intentionally probe for injection, overexposure, and unsafe execution so model behaviour is measured against realistic failure modes, not only happy-path correctness.

Key takeaways

• AI coding assistants can accelerate insecure code creation as easily as they accelerate delivery, so security has to govern suggestions, not only finished code.
• Access control failures, unsafe execution, and sensitive data exposure are the recurring defect classes that matter most for identity and secrets governance.
• The right response is a combination of human review, static analysis, redaction, and policy enforcement for every AI-assisted code path that touches trust boundaries.

Key terms

• AI-Assisted Code Trust Gap: The gap between code that appears safe to a developer and code that has actually been checked against security policy. It grows when autocomplete is treated as a quality signal instead of a prompt for verification, especially around secrets, access control, and unsafe execution paths.
• Sensitive Data Exposure: Sensitive data exposure is the condition where high-value or regulated information is reachable by identities, applications, or services beyond its intended scope. In modern environments, exposure is often driven by sprawl, duplicated storage, and poor entitlement visibility rather than a single leaked file.
• Unsafe Execution Path: A code path that can execute untrusted input or otherwise bypass the intended trust boundary. In AI-assisted development, this can appear as direct evaluation, weak parsing, or helper logic that accepts attacker-controlled content without sufficient validation.

What's in the full report

VirtueAI's full research covers the implementation detail this post intentionally leaves for the source:

• Side-by-side code examples for Cursor, GitHub Copilot, Codeium, and Qodo Gen across CWE categories
• The SecCodePLT methodology used to test tab-completion behaviour against insecure prompts
• Concrete examples of how specific completions introduced eval-based execution and sensitive data exposure
• Best-practice examples for automated code review and runtime guardrails in AI-assisted development

👉 The full VirtueAI post includes code examples, CWE comparisons, and secure coding guidance for AI assistants.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building controlled access programmes. It helps security and identity teams connect development workflows to governance outcomes across the wider identity estate.