TL;DR: AI is changing both how software is built and what software contains, with Legit Security reporting that 81% of developers use AI coding assistants, 96% of security and development professionals see GenAI in application delivery, and Gartner expects 40% of new enterprise production software to use vibe coding by 2028. The security challenge is no longer just code review; it is governing AI-assisted development, AI-in-the-stack applications, and the new trust boundaries they create.
At a glance
What this is: AI is changing application security because it now affects both code production and the software architecture itself, with AI tools, agents and models increasingly embedded in delivery pipelines and production systems.
Why it matters: IAM, AppSec and platform teams need to govern AI-assisted development as a trust and access problem, because the same controls that protected human-led software delivery do not fully cover AI-generated code or AI-consuming applications.
By the numbers:
- 81% of developers surveyed reported using AI-powered coding assistants.
- 96% of security and software development professionals report that their companies use GenAI-based solutions for building or delivering applications.
- 88% of developers surveyed report using AI coding assistants.
- 40% of new enterprise production software will be created with vibe coding techniques and tools by 2028.
Context
AI-generated code changes application security because it changes both the speed of delivery and the composition of the application itself. Traditional AppSec models assume people write most code, reviews happen before release, and software remains clearly separable from the tooling used to create it. That assumption is breaking down as assistants, agents and prompt-driven development become part of the build path.
The governance problem is no longer limited to code quality or secure coding alone. Once AI models, agents and tool integrations become part of the software stack, teams must treat AI as both a development force and a runtime actor with access to data, tools and downstream workflows. That creates an identity and authorization boundary that AppSec, IAM and platform teams now have to govern together.
Key questions
Q: How should security teams implement AI code generation controls in the SDLC?
A: Start at the point of generation, not at the point of release. Put SAST, dependency checks, and secrets detection directly into the developer workflow, then back them with CI/CD enforcement and runtime testing. That combination lets teams catch insecure suggestions early without trying to audit every generated line after the fact.
Q: Why does vibe coding increase application security risk?
A: Because it increases the volume and speed of code changes faster than traditional review and scanning can absorb. That compresses decision time, expands dependency usage, and makes exposure harder to track. The risk comes from scale and timing, not from AI alone.
Q: What breaks when AI agents can generate code but cannot validate, test, or correct it end to end?
A: When agents can only generate code, teams often get incomplete output that still needs manual cleanup, integration work, and debugging. The result is a productivity gap where the easy part is automated but the risky part remains human dependent. That creates slower releases, more configuration errors, and a higher chance that insecure or noncompliant changes slip through.
Q: How do AppSec and IAM work together for AI-in-the-stack software?
A: AppSec defines what the software should and should not do, while IAM governs which non-human actors can create, modify or exercise those capabilities during development and runtime. When AI becomes part of the stack, the two disciplines need a shared view of tool access, data access and release authority.
Technical breakdown
AI coding assistants change the software supply chain
AI coding assistants do more than autocomplete lines of code. They can generate functions, suggest dependencies, produce tests and accelerate changes into production, which means the control point moves from manual authoring to governance of assisted output. The risk is not simply that code is faster, but that more code is accepted with less human scrutiny and less visibility into provenance. In security terms, this creates a supply chain problem inside the development workflow itself, where trust has to extend to prompts, model output, review thresholds and automated handoff into CI/CD.
Practical implication: Treat assisted code generation as a governed supply chain step, not just a developer productivity feature.
Vibe coding pushes security decisions upstream
Vibe coding uses natural language prompts to produce code and even execute development tasks such as testing. That changes the security model because the developer may no longer inspect every implementation detail before it is created. Instead, security has to focus on prompt quality, environment permissions, guardrails around generated output and validation of what the model produced. The key control question becomes whether the organisation can reliably prove what was generated, what was accepted and what was deployed.
Practical implication: Move review and approval controls earlier, to the prompt and generation stage, before code reaches production.
AI agents turn software into a multi-actor system
When AI agents plan, write, test and document code together, the application development environment becomes a system of interacting software actors. That matters because each agent may call tools, access repositories, query data or trigger downstream automation. In practice, the security challenge resembles privilege governance for non-human identities: each agent needs narrow, explicit boundaries, and every interaction must be attributable. The application is no longer just code plus data. It is code plus models plus agent-mediated access paths.
Practical implication: Define explicit identity, authorization and logging boundaries for every agent that can act in the software lifecycle.
Threat narrative
Attacker objective: The objective is to insert weak, opaque or overprivileged software paths into the delivery chain and production environment before normal review catches them.
- Entry occurs when developers use AI assistants, vibe coding tools or coding agents to create features, tests and supporting code with less direct human inspection.
- Credential access and privilege exposure emerge when those tools are allowed to interact with repositories, pipelines, data or cloud services through broad permissions.
- Escalation follows when generated code, copied snippets or agent actions propagate into production systems without sufficient validation or provenance checks.
- Impact is software that is harder to trust, harder to audit and more likely to embed insecure patterns, hidden dependencies or overbroad access paths.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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-generated code creates governance debt, not just code volume. The central issue is that security teams inherit more software, more quickly, while also inheriting uncertainty about how much of it was machine-generated and how much human review it received. That weakens traditional assurance models that depend on authorship, manual inspection and stable change windows. Practitioners should treat AI-generated code as a governance problem that spans AppSec, SDLC control and identity-aware access to development systems.
AI in the stack introduces a new identity boundary inside software. Once models, LLMs and agents can query data or call tools, they stop being only build aids and become actors in the application environment. That means access scope, attribution and lifecycle control matter as much for AI components as they do for human users or service accounts. The practitioner conclusion is clear: if the AI system can act, it needs identity governance.
AI-assisted development is a trust boundary problem before it is a code quality problem. The most important question is not whether the generated code compiles, but whether the organisation can trust the path from prompt to production. That path now includes models, agents, repositories, CI/CD and runtime integrations, each with its own failure mode. Security teams should focus on governing the whole path, because isolated code review no longer captures the real risk.
Prompt-driven development will expose weak change control faster than legacy review processes can absorb it. As more teams adopt assistants and agents, the gap will widen between the speed at which software is produced and the speed at which human review can validate it. That gap is where insecure dependencies, hidden permissions and untested logic will accumulate. Practitioners should respond by strengthening pre-production assurance, not by assuming more manual review can keep up.
AppSec and IAM are converging around software authorship and software action. The first governs what code is allowed to do, while the second governs what non-human actors are allowed to do during creation and operation. AI-generated code collapses that separation because the same agentic workflow can both write and exercise privileged paths. Teams should align AppSec controls with identity governance so that code generation, execution and access are treated as one control plane.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: AI Coding Agents Security Guide
What this signals
AI-generated code is becoming a governance issue for the whole delivery chain. As assistants and agents move into day-to-day development, organisations need controls that prove who or what introduced a change, what was validated, and what was allowed to deploy. The operational question is no longer just whether the code is secure, but whether the path that created it is governable.
Software teams should expect identity controls to extend into build systems and coding workflows. Once AI tools can query repositories, run tests or interact with data, they behave like non-human actors that need explicit access boundaries. That creates a direct governance link between AppSec, IAM and non-human identity management, and programmes that ignore that link will struggle to maintain auditability.
For practitioners
- Establish prompt-to-production governance Define controls for AI-assisted coding that cover prompt approval, generated output review, dependency validation and release authorization.
- Constrain agent permissions in delivery pipelines Limit what coding agents can read, write, test and deploy, and log every tool action they take across repositories and CI/CD.
- Require provenance for AI-generated changes Track which changes were produced by assistants or agents, then attach that provenance to code review and release records.
- Update AppSec threat models for AI-in-the-stack applications Account for models, chat-based interfaces and agent-to-agent interactions as part of the application attack surface, not as peripheral features.
Key takeaways
- AI-generated code changes application security by altering both how software is produced and what software now contains.
- The core risk is governance debt: faster delivery can outpace review, provenance tracking and access control.
- Security teams need to align AppSec and IAM around prompts, agents and release boundaries rather than relying on human code review alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents in coding workflows create privilege and attribution risks inside software delivery. |
| ASI02 — Tool Misuse | AI coding tools can overreach when they are allowed to invoke build, test or deployment tools. | |
| Recommendation — Constrain agent privileges and log every tool action that affects code, data or deployment. Restrict agent tool access to the minimum functions required for each development task. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing AI use in software creation and delivery. |
| Recommendation — Define accountability, approval and oversight for AI-assisted development in your AI governance programme. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI tools that can change code or access data need explicit authorization boundaries. |
| Recommendation — Apply least-privilege authorization to AI assistants, agents and the systems they can reach. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | AI-assisted workflows can amplify credential and access abuse if permissions are too broad. |
| Recommendation — Map agent-enabled development abuse to credential access and lateral movement detections. | ||
Key terms
- AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
- Vibe Coding: A software development approach where natural-language prompts drive much of the implementation and AI produces the code. In practice, the term covers a wide range of control levels, from no-review prototyping to structured engineering with tests, review, and architecture held by humans.
- AI-in-the-Stack: An application design in which models, agents or LLM-enabled features are part of the runtime architecture, not just the development process. This expands the attack surface because AI components may fetch data, call tools or interact with other systems as active participants in the application.
- Software Trust: Software trust is the ability to prove that code was produced, approved, deployed, and maintained under controlled conditions. It goes beyond finding defects to include provenance, verification, remediation, and evidence that the running software matches the trusted state.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and machine identity security. It helps practitioners connect identity controls to the wider security programmes that now depend on them.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org