AI-generated code is outpacing AppSec visibility and control

At a glance

What this is: This survey shows AI assistants are now embedded in most software development workflows, while security teams struggle to see and control the vulnerabilities they introduce.

Why it matters: It matters because IAM, AppSec, and governance teams now need visibility into AI use, code provenance, and delegated development activity before AI-generated output becomes an unmanaged risk surface.

By the numbers:

• 82% of respondents are experimenting with or using AI assistants in software development.
• 73% of respondents cite introduction of new vulnerabilities as a top concern related to AI use in software development.
• 56% cite lack of visibility or control over AI-generated code as a top concern.
• 24% of respondents cite securing AI-generated code as their top priority in the next 12 to 24 months.

👉 Read LEGIT Security's survey on securing AI-generated code

Context

AI-generated code is now a governance problem as much as a development problem. When assistants produce code faster than teams can review it, the security boundary shifts from the developer keyboard to the tooling, review pipeline, and policy controls around code creation. For identity and access teams, that shift also raises questions about who or what is allowed to generate, approve, and commit code in the first place.

The article’s central claim is that AppSec tooling was built for human-paced development and is struggling to keep up with AI-assisted workflows. That creates a new visibility gap across code provenance, prompt-driven behavior, and the security posture of the tools themselves. In practice, this is typical of early-stage AI adoption: capability arrives first, then governance catches up later.

Key questions

Q: What breaks when AI-generated code enters delivery pipelines without strong visibility?

A: Security teams lose the ability to distinguish human-written from AI-assisted code, which makes review depth inconsistent and weakens risk triage. The result is not just faster output, but faster propagation of defects, unsafe patterns, and hidden dependencies that ordinary static controls may not flag in time.

Q: Why do AI coding agents create different governance risks from normal developer tools?

A: AI coding agents combine code execution, context persistence, external tool access, and memory across sessions. That makes them governed identity actors with a wider blast radius than a standard editor or plugin. The risk is not just what they generate, but what they can read, retain, and trigger on behalf of the developer.

Q: How can organisations tell whether AI-assisted development is actually working?

A: Use downstream indicators such as escaped defects, rework after merge, security findings, and time spent validating generated code. If the assistant increases review load, secret exposure, or release friction, the apparent speed gain is likely being paid back later in the delivery lifecycle.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

AI-generated code changes the AppSec inspection model

Traditional AppSec assumes code is written, reviewed, and scanned in a predictable lifecycle. AI-generated code breaks that assumption because output can be produced in bulk, copied across repositories, and modified by prompts that never appear in source control. Security review now has to account for provenance, intent, and tool-mediated transformations, not just static code content. That is why visibility into where AI is used has become part of the control plane, not an optional reporting layer.

Practical implication: create a policy-backed inventory of AI-assisted development paths and require code provenance signals in the review workflow.

Prompt injection and model manipulation create code-path risk

The article points to prompt injection, poisoned training data, and malicious model updates as emerging threats. In software development, these attacks matter because the assistant can be influenced to suggest unsafe code, reveal confidential information, or alter the content shown to users. That makes the AI tool itself part of the attack surface. Security teams need to think in terms of trust boundaries between the developer, the model, the plugin ecosystem, and downstream repositories.

Practical implication: isolate AI coding tools from sensitive repositories and test them for prompt injection and data leakage paths.

AI visibility is now a governance control, not just an observability issue

The article’s strongest operational message is that teams cannot secure what they cannot see. Visibility means knowing which developers are using AI, which tools are connected, what data they can access, and whether generated code is being reviewed with the right risk thresholds. That intersects with IAM because access to models, plugins, and code repositories should be controlled as a governed privilege, not treated as a free productivity layer.

Practical implication: treat AI coding access as a governed entitlement with approval, logging, and periodic review.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI development tooling into a channel for code theft, secret exposure, or the insertion of malicious logic.

1. Entry occurs when attackers influence AI-assisted development through prompt injection, malicious updates, or poisoned data inputs.
2. Escalation follows when the coding assistant generates unsafe code, leaks source material, or exposes secrets and hidden vulnerabilities.
3. Impact is achieved when confidential code, credentials, or exploitable logic reaches production or private repositories without adequate review.

NHI Mgmt Group analysis

AI-generated code creates an assurance gap that AppSec teams are not yet staffed or instrumented to close. Security programmes were built to inspect code after it was written, but AI-assisted development compresses the creation-to-commit window. That leaves less time for human review and more dependence on provenance signals, repository policy, and runtime controls. The practical conclusion is that code assurance now has to start before the pull request, not after it.

Visibility into AI use is becoming a first-class governance control. Organisations cannot govern what they cannot enumerate, and AI assistants are often adopted faster than policy teams can classify them. That means inventorying tools, developer entitlements, and repository connections is now part of the security baseline. In identity terms, access to AI coding systems should be treated as a governed entitlement with lifecycle oversight, not informal developer convenience.

Prompt injection is the named concept teams should use to describe a new class of software supply risk. It is not just a model issue and not just an application issue. It is the point where untrusted input changes the behavior of a tool that users already trust to generate or modify code. The practitioner takeaway is to test AI coding workflows as if they were externally exposed input channels, because in effect they are.

Agentic development tooling will force a rethink of who is authorized to act on behalf of the developer. As AI agents and assistants begin to extend AppSec workflows, the question is no longer only whether the code is secure, but whether the actor producing or modifying it is properly controlled. That is where IAM and NHI governance intersect with AppSec: delegated actions need identity, scope, and revocation discipline.

What this signals

AI-assisted development is moving faster than most organisations can classify, inventory, and govern. For security leaders, the near-term signal is that review controls alone will not be enough unless they are paired with repository policy, tool inventory, and identity-based access governance across the development stack.

Code provenance control: the practical challenge is not just identifying AI-generated code, but proving which tool, user, and context produced it. Teams that can trace that chain will be able to set higher-risk review thresholds for credentials, authentication flows, and externally facing logic. Those that cannot will be forced into blanket review, which does not scale.

The identity angle is real, even in AppSec. If AI assistants can modify code, access repositories, or act on behalf of developers, then entitlement review and lifecycle management need to expand to machine-mediated development activity, not just human users.

For practitioners

• Inventory AI-assisted development paths Map every IDE plugin, assistant, model endpoint, and repository integration used in the software delivery chain. Require named ownership for each connection and log which teams can generate or alter code through AI tools.
• Classify AI coding access as a governed entitlement Assign access to coding assistants, model gateways, and code repositories to roles with approval, logging, and periodic review. Remove informal access paths that bypass central policy and make exception handling explicit.
• Test AI tools for prompt injection and secret leakage Run red-team scenarios that try to coerce assistants into revealing private code, suggestions, or embedded credentials. Measure whether the tool can be influenced through malicious prompts or poisoned context.
• Add provenance checks to code review workflows Require signals that identify AI-generated or AI-modified code before merge approval. Use those signals to trigger deeper review when the change touches authentication, secrets handling, or external integrations.

Key takeaways

• AI-generated code creates a visibility problem first and a vulnerability problem second.
• Security teams already see budget and operational priority shifting toward AI-assisted development controls.
• Identity governance now needs to extend to the tools, entitlements, and workflows that generate code on behalf of developers.

Key terms

• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

What's in the full report

LEGIT Security's full report covers the operational detail this post intentionally leaves for the source:

• Full survey breakdown across 117 security professionals, including where respondents are prioritising AI-generated code controls.
• Detailed findings on how teams are using AI assistants for security tasks and AppSec augmentation.
• Examples of the prompt injection and secret exfiltration vulnerabilities identified in AI coding tools.
• The report's own analysis of how purpose-built AI security tools are expected to change AppSec operations.

👉 The full LEGIT Security report includes survey detail, vulnerability examples, and AppSec planning signals.

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 in operational terms. It helps identity and security practitioners apply governance discipline to emerging delegated workflows and access patterns.