AI coding agents keep shipping vulnerable code across apps

At a glance

What this is: Tenzai’s benchmark found that five popular AI coding agents repeatedly produced insecure applications, with 69 vulnerabilities across 15 apps and common failures in authorization, SSRF, business logic, and missing defensive controls.

Why it matters: This matters because AI-assisted software delivery is now creating application risk at the same pace it creates code, so security teams need controls that catch design and logic failures before they become production exposure.

By the numbers:

• 69 vulnerabilities across 15 apps

👉 Read Tenzai’s benchmark of secure coding capabilities in popular AI coding agents

Context

AI coding agents are changing software delivery, but faster code generation does not automatically produce safer applications. The core governance gap is that these systems can generate working code while still missing access control, request validation, and baseline defensive settings, which means security review must move earlier in the development lifecycle.

For identity and access practitioners, the relevance is direct. Authorization failures, weak session assumptions, and missing login protections are all identity-adjacent application risks, and they become harder to spot when developers assume the agent has handled the basics. That makes AI-generated code a governance issue as much as a development productivity issue.

The pattern in this benchmark is typical of AI-assisted development at its current maturity. Agents can reproduce well-defined secure patterns, but they do not reliably infer security intent in ambiguous business workflows.

Key questions

Q: What breaks when AI coding agents are allowed to ship code without security constraints?

A: Teams get working software that can still carry old, well-known vulnerabilities back into production. The failure is not only a coding mistake. It is a governance failure where functional correctness is treated as sufficient evidence, even when the agent has reintroduced a flaw that the security community already fixed.

Q: Why do AI coding agents struggle with authorization and business logic?

A: Because those controls depend on context, not just syntax. Agents can follow clear framework rules, but they often miss ownership checks, role exceptions, and workflow constraints that humans infer from the business process. The risk grows when security intent is implicit rather than written as an explicit requirement.

Q: How can security teams tell whether AI-generated code is actually safe?

A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.

Q: Should organisations trust prompt engineering to make coding agents safer?

A: No. Better prompts can help when the secure pattern is obvious, but they do not reliably solve ambiguous security problems such as business logic, authorization, or control omission. Organisations need guardrails, code review, and security test gates because prompt quality is not a substitute for assurance.

Technical breakdown

Why AI coding agents handle some security controls better than others

The benchmark suggests a simple boundary: when secure behaviour is encoded as a default framework pattern, agents often follow it. Parameterized queries are a good example, because the safe pattern is concrete and repeatable. The same is true for many framework-mediated XSS protections. But once the task depends on judgment, such as deciding which users may access which objects, the model is no longer following a secure template. It is synthesising business logic, and that is where subtle flaws appear. This is less a coding problem than a policy translation problem: the agent can write syntax, but it cannot reliably infer the security intent behind access decisions.

Practical implication: Treat AI-generated code as pattern-compliant, not policy-safe.

Why authorization and business logic fail in AI-generated applications

Authorization is not just a permission check. It is a chain of assumptions about identity, role, ownership, object scope, and exceptions. The article shows agents struggling when those assumptions become conditional or role-dependent, which is exactly how real applications break. Business logic failures are even harder, because the model may produce code that satisfies the prompt while silently allowing negative quantities, invalid prices, or other impossible states. These are not exotic bugs. They are trust failures in how the application interprets user input and identity context across a workflow.

Practical implication: Review every role path and workflow rule as if the agent never saw the security requirement.

Why missing security controls become the biggest AI coding risk

The most concerning pattern in the benchmark is omission. The agents did not merely implement CSRF, security headers, or rate limiting poorly. In most cases they did not add them at all. That matters because control omission is harder to detect than an obviously broken feature, especially when the app appears functional. In practice, this is where AI-generated code undermines baseline application security posture: the code may run, but it lacks the mechanisms that constrain abuse. The absence of those controls creates a widening gap between functional delivery and secure delivery.

Practical implication: Use a mandatory control checklist for every generated application before code merges.

NHI Mgmt Group analysis

AI coding agents are now a governance problem, not just a developer productivity tool. The benchmark shows that agents can generate functioning software while still omitting the controls that make software safe in production. That shifts the risk discussion from code quality alone to lifecycle governance, because security intent is being lost at the point of implementation. Practitioners should treat generated code as untrusted until controls are independently validated.

Security control omission is the clearest failure mode in vibe-coded applications. The most consequential findings were not only the broken checks, but the missing controls such as CSRF protection, security headers, and login rate limiting. When a control is absent, traditional testing can miss the risk if the application still appears to work. The lesson is that secure software assurance must include explicit control verification, not just functional testing.

Authorization drift is the most dangerous identity-adjacent failure in AI-generated code. The benchmark repeatedly surfaced conditional access logic that was too narrow, too broad, or skipped for edge cases. That is a familiar IAM problem expressed inside application code: identity is present, but the enforcement boundary is inconsistent. In practice, this means appSec, IAM, and engineering teams need shared review of access decisions, not isolated ownership.

AI-generated applications need control baselines, not prompt optimism. The study shows that asking an agent to “be secure” is not a control strategy. Security must be encoded as non-optional verification gates, especially for authentication, authorization, and request validation. That approach aligns with NIST CSF governance expectations and with the broader principle that security by construction only works when controls are testable and enforced.

Named concept: prompt-complete, control-incomplete software. This benchmark illustrates a pattern where the generated application satisfies the requested feature set but omits essential defensive mechanisms. The implication is broader than coding quality: teams can ship complete-looking systems that are structurally underprotected. Practitioners should measure agent output against required control coverage, not prompt satisfaction.

What this signals

AI-generated software will increasingly shift application risk from obvious coding defects to missing control coverage. That means programme owners need to measure whether generated systems contain the security mechanisms they require, not whether the model produced syntactically valid code.

Prompt-complete, control-incomplete software: this is the operating model teams should expect if AI coding agents are left to infer security intent. The practical response is to standardise security baselines, automate abuse testing, and make missing controls a release-stopping defect rather than a cleanup task.

For identity and access programmes, the most relevant signal is whether application teams can prove that identity-dependent decisions are enforced consistently across every generated workflow. If they cannot, IAM and appSec teams need a shared review process for authorization logic and session handling.

For practitioners

• Mandate control verification before merge Require every AI-generated application to pass a control checklist covering CSRF, security headers, rate limiting, authentication, authorization, and input validation before code reaches a protected branch.
• Separate functional testing from security assurance Test whether the app works, then test whether it resists abuse. Build explicit abuse-case tests for object access, negative values, unauthenticated requests, and SSRF-style outbound fetches.
• Review identity and authorization logic by hand Do not rely on agent-generated access control for role checks, ownership checks, or exception handling. Require human review of every path where identity determines visibility, edit rights, or deletion rights.
• Add security patterns to the development standard Package secure defaults for the stack you use most, including CSP, X-Frame-Options, HSTS, and framework-safe authentication and session handling, so agents inherit known-good patterns instead of inventing them.
• Instrument AI-generated code for defensive coverage Track which security controls are present, absent, or bypassable in generated applications, then report gaps as a release blocker rather than a post-release finding.

Key takeaways

• AI coding agents can produce working software while still omitting the controls that make it safe to deploy.
• The benchmark’s biggest failures were not exotic exploits but missing or inconsistent security controls that should have been standard.
• The right response is mandatory control verification, abuse-case testing, and human review of identity-dependent logic before release.

Key terms

• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.
• Control omission: A security failure where a required safeguard is never added at all. Unlike a broken control, omission can be hard to detect because the application still appears functional, even though it lacks baseline protections such as CSRF defense, rate limiting, or security headers.

What's in the full report

Tenzai's full research covers the detailed benchmark setup and the per-agent failure analysis this post intentionally leaves at the summary level:

• Per-agent breakdown of which coding system produced each vulnerability class and where the failures clustered
• Code examples showing the specific authorization, SSRF, and business logic mistakes observed in the generated applications
• The testing approach used to validate exploitability, including static analysis and dynamic proof-of-concept checks
• The appendix prompts and application scenarios used to reproduce the benchmark across the five agents

👉 The full Tenzai research includes the per-agent vulnerability breakdown and the code examples behind each failure pattern.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need stronger control discipline across identity-led security programmes.