AI coding agents keep shipping vulnerable code across apps

At a glance

What this is: Tenzai’s benchmark found that five popular coding agents collectively introduced 69 vulnerabilities across 15 generated applications, including broken authorization, SSRF, missing CSRF protection, and absent security headers.

Why it matters: For IAM, PAM, and application security teams, the finding matters because AI-generated code can accelerate delivery while silently weakening access control, session protection, and secure defaults.

By the numbers:

• Five popular coding agents were benchmarked across 15 generated applications, producing 69 vulnerabilities in total.

Context

AI coding agents can write large amounts of application code quickly, but speed does not equal secure design. The governance gap is that these tools often follow the prompt literally and miss controls that security teams would normally expect to be built in by default, especially around authentication, authorization, and request validation. In practice, that shifts risk from coding velocity to control completeness.

This article sits at the intersection of application security and identity governance because many of the failures were access-related: broken authorization, unauthenticated deletion paths, and weak enforcement around user roles. Where software creation is increasingly delegated to agents, the security question becomes whether the development process can still enforce least privilege, session integrity, and explicit control intent.

The benchmark behaviour is atypical only in its scale of testing, not in the failure modes themselves. These are the same classes of problems teams see when guardrails are missing, but AI accelerates how quickly they can enter production code.

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: What are the signs that AI-generated application code has weak access control?

A: Look for tables exposed without effective policies, permissive access conditions, authentication that blocks legitimate users, and unexplained access to sensitive actions such as bulk email or account deletion. Those symptoms usually mean the code was generated without a secure governance layer around identity and data access.

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 coding agents handle some bugs better than others

Coding agents tend to do better when a vulnerability class has a crisp, widely understood rule set. SQL injection and many XSS cases are easier for them because frameworks already steer them toward parameterized queries and output escaping. The harder cases are the ones where security depends on application context, workflow nuance, or business intent. In those situations, the model can generate plausible code that satisfies the prompt while missing the security boundary that a human reviewer would instinctively enforce.

Practical implication: treat framework-provided protections as necessary but not sufficient, and review every agent-generated path where context determines safety.

Authorization and business logic failures in AI-generated code

Authorization is not just a gate at the start of a request. It is a set of decisions about who can access which object, under what role, and with what constraints. AI coding agents often collapse those distinctions, especially when logic branches by role, ownership, or workflow state. Business logic failures follow the same pattern: if the prompt does not spell out a rule such as positive quantities, non-negative prices, or ownership checks, the agent may create code that is syntactically correct but operationally unsafe.

Practical implication: specify object ownership, role boundaries, and state validation explicitly in design reviews before letting agents write the implementation.

Why CSRF, security headers, and rate limits are often omitted

Some controls are not naturally inferred from the functional request because they protect the application’s operating envelope rather than the user-visible feature. CSRF protection, security headers, and login throttling live in that category. AI agents often implement the requested endpoint or page and stop there, leaving out defensive layers that are easy to forget because they are not part of the main user story. That omission creates exposure even when the visible feature appears to work correctly.

Practical implication: make cross-cutting controls part of your acceptance criteria, not an afterthought delegated to code review or platform defaults.

Threat narrative

Attacker objective: The attacker’s objective is to exploit AI-generated implementation gaps to gain unauthorized access, manipulate application behaviour, or trigger server-side actions that should have been blocked.

1. Entry occurs through AI-generated application code that implements a requested feature but omits or weakens access control, request validation, or browser-side protections.
2. Credential or authorization abuse follows when broken checks let unauthenticated users, wrong-role users, or unprotected requests reach sensitive functions.
3. Impact appears as order tampering, arbitrary URL fetches, account abuse, or other exploitable behaviour embedded in otherwise functional code.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI coding agents create a security debt problem, not just a code-quality problem. The central issue is that they optimize for task completion and feature delivery, while security controls often depend on explicit governance intent. When the prompt does not encode the control, the control is frequently absent. For practitioners, the operational conclusion is that secure software delivery must assume AI will accelerate both code volume and control omission.

Access control is the most exposed governance boundary in agent-generated software. The benchmark repeatedly found failures in authorization logic, role handling, and ownership checks, which are exactly the areas where application identity and permission models matter most. That intersects directly with IAM thinking, because application code becomes an enforcement point for who may do what. If application authorization is weak, identity assurance upstream cannot compensate for it downstream.

Security controls need to be treated as first-class requirements, not inferred by the model. CSRF protection, security headers, and rate limiting were largely absent because they are not always part of the natural language feature request. This is a named gap we would call control omission by default: the system builds the feature but not the defensive context around it. Teams should treat that as a design and governance issue, not a model accuracy issue.

Ambiguous security decisions are where coding agents fail most consistently. Clear patterns such as parameterized queries are easier for models to reproduce, but business rules, authorization exceptions, and context-sensitive trust decisions are not. That matters because the hardest failures are also the ones that evade routine syntax testing. Practitioners should assume that AI-assisted development lowers the cost of producing insecure edge cases unless the review process is deliberately security-led.

The likely future is not better prompts alone but paired generation and verification. The article suggests that asking the agent to think harder about security is not enough to eliminate the problem at scale. The more durable pattern is to use AI for secure code generation and AI-assisted testing together, while preserving human ownership of the control model. For identity-heavy applications, that means verifying permissions and session behaviour as explicitly as you verify functionality.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Control omission by default: AI coding agents do not merely generate buggy code, they systematically underproduce the defensive context around that code. That means security leaders should measure not only defect rates, but whether generated software includes the control layers that human teams would normally insert without being asked.

For identity and application teams, the practical shift is to move security checks left into the specification itself. If authorization logic, session protection, and anti-abuse controls are absent from the request, they are often absent from the output as well, which makes review quality and test design part of the governance model.

The Tenzai benchmark also reinforces a broader pattern seen in AI-assisted development: clear rules are easier for models to follow than context-sensitive judgement. That means ambiguous controls such as business logic validation and privilege boundaries need explicit ownership before code generation starts.

For practitioners

• Define security acceptance criteria before generation Write authorization, CSRF, header, and rate-limit requirements into the feature brief so the agent has explicit non-functional constraints to satisfy.
• Review every role-based code path manually Check object ownership, role branches, and fallback logic in generated APIs, especially where a missing check could expose another user’s data or actions.
• Test ambiguous workflows with abuse cases Use negative tests for quantities, prices, SSRF targets, and unauthenticated requests because these are the cases agents are most likely to mishandle.
• Make defensive controls part of release gating Block release when generated code omits CSRF protection, security headers, or login throttling, even if the feature itself behaves correctly.
• Use AI-assisted verification alongside AI generation Apply automated review and test generation to the code that agents produce, then keep a human accountable for the final security decision.

Key takeaways

• AI coding agents can accelerate development while still leaving critical security controls out of the code path.
• The benchmark’s 69 vulnerabilities were not random defects but a repeatable pattern across authorization, SSRF, CSRF, and missing headers.
• Teams that want to use coding agents safely need explicit requirements, negative testing, and human control over the final security decision.

Key terms

• Coding Agent: A coding agent is a software system that can plan, generate, and modify code with limited human prompting. In governance terms, it is not just a tool but an actor whose permissions, tool access, and rollback path must be managed as part of the delivery process.
• Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
• Cross-Site Request Forgery: Cross-site request forgery is a technique that tricks a logged-in browser into sending authenticated requests the user did not intend. It matters in NHI-heavy systems because cookie-backed token refresh or session renewal can be abused without ever learning the underlying secret.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners who need stronger control over machine and human identity risk. It is useful for security teams that want a practical governance baseline as AI-accelerated delivery increases pressure on access controls and review processes.