TL;DR: In a survey of 117 security professionals, LEGIT Security found that 82% are already using or experimenting with AI assistants in software development, while 73% worry about new vulnerabilities and 56% cite lack of visibility or control as top concerns. The governance gap is not code generation speed, but the inability of traditional AppSec to inspect, classify, and bound AI-assisted output fast enough.
At a glance
What this is: LEGIT Security's survey shows AI-assisted development is now mainstream while AppSec teams still lack enough visibility and control over the code it produces.
Why it matters: This matters because security teams need governance over where AI is used, what it generates, and how quickly insecure patterns can enter production code paths.
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 say securing AI-generated code is their top priority in the next 12 to 24 months.
Context
AI-generated code creates a governance problem before it becomes a code-quality problem. When software is produced faster than security teams can inspect, classify, and approve it, traditional application security controls begin to lag behind the development workflow they are meant to protect.
The identity angle is indirect but real: AI coding tools increasingly act as non-human contributors inside the software factory, and security teams need visibility into who or what generated code, which credentials or repositories were touched, and where automated suggestions entered the delivery chain. The article's starting position is now typical for mature engineering environments, not an edge case.
Key questions
Q: How should security teams govern AI-generated code in production pipelines?
A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.
Q: Why does AI-assisted development increase application identity risk?
A: Because many applications implement identity controls in code, and AI tools can reproduce insecure login, token, and access patterns at scale. That means the risk is not limited to software defects. It extends to the trust boundaries that govern users, service accounts, and any downstream system that accepts those credentials as valid.
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: What should organisations do when AI coding assistants touch private repositories?
A: Restrict assistant access until logging, policy enforcement, and approval workflows are in place for sensitive codebases. Private repositories deserve stricter governance because assistant prompts, suggestions, and generated snippets can expose code or secrets if the toolchain is not bounded. The decision should be based on visibility and control, not developer convenience.
Technical breakdown
AI-generated code changes the AppSec control point
AI-assisted development shifts the security question from whether code meets a scan rule after commit to whether insecure logic, secrets handling, or unsafe dependencies were introduced before the code was ever reviewed. Application security tools were built around human-authored workflows, so they often inspect artifacts after risk has already propagated into the branch, build, or pull request. The control problem is not only vulnerability detection, but provenance and oversight of code origin. Practical implication: move security checks earlier in the pipeline and require traceability for AI-generated contributions.
Practical implication: move security checks earlier in the pipeline and require traceability for AI-generated contributions.
Visibility into AI use is now part of software governance
Security teams cannot govern what they cannot see. If developers use AI assistants in IDEs, chat workflows, or code-generation plugins without inventory, policy, and telemetry, the organisation loses the ability to distinguish human-written code from machine-assisted output. That breaks meaningful review, exception handling, and risk acceptance because the review target is no longer clear. This is especially relevant where generated code can touch secrets, authentication flows, or data handling paths. Practical implication: inventory AI coding tools, define approved use cases, and log where generated code enters production branches.
Practical implication: inventory AI coding tools, define approved use cases, and log where generated code enters production branches.
Novel vulnerabilities require AI-aware inspection, not just classic SAST
AI-generated code can be functionally correct while still introducing weak input handling, insecure defaults, unsafe prompts, or brittle dependency choices. Traditional AppSec testing remains necessary, but it is not sufficient when the source of risk includes model behaviour, prompt manipulation, and generated snippets that bypass secure coding patterns. The article also points to emerging attacks against coding assistants themselves, which means the toolchain can become part of the attack surface. Practical implication: pair code analysis with AI-specific controls for prompt safety, tool governance, and assistant-integrity testing.
Practical implication: pair code analysis with AI-specific controls for prompt safety, tool governance, and assistant-integrity testing.
Threat narrative
Attacker objective: The attacker aims to exploit the trust placed in AI-assisted development to extract code, secrets, or insecure changes that widen downstream compromise opportunities.
- Entry occurs when developers adopt AI coding assistants inside everyday software delivery workflows, often before governance and telemetry are in place.
- Credential or source exposure can follow when the assistant or surrounding workflow touches private repositories, secrets, or internal code suggestions without tight access boundaries.
- Impact is insecure or manipulated code entering the software supply chain, with the possibility of secrets leakage, unsafe suggestions, or hidden vulnerabilities reaching production.
Breaches seen in the wild
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
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 faster than most AppSec programmes can absorb. The core issue is not simply that code is being produced faster, but that the trust boundary around authorship has changed. Security teams now have to govern machine-assisted output as a distinct intake stream, which means review, approval, and exception handling need to understand provenance, not just syntax. Practitioners should treat AI-assisted delivery as a separate control domain, not a minor variation of normal development.
Visibility is the missing control plane. If teams cannot see where AI is used, they cannot reliably assess what needs inspection, what needs policy, or what should be blocked. This is where the identity bridge matters: AI coding tools operate as non-human actors inside the delivery chain, and their presence creates a governance problem similar to any other machine identity with access to code and repositories. Practitioners should inventory these tools and make their activity auditable.
Traditional AppSec still matters, but it is no longer the full answer. SAST, DAST, dependency scanning, and code review all remain necessary, yet they do not fully address model-driven risk such as prompt manipulation, insecure suggestions, or compromised coding assistants. The article signals a shift toward AI-aware application security where tool integrity and output provenance become first-class concerns. Practitioners should plan for controls that evaluate both the generated artifact and the generation path.
AI-assisted software delivery: this is the control gap the article exposes, where AI-generated contributions enter pipelines faster than governance can classify them. The security problem is not just bad code, but the collapse of assumptions about who authored it, how it was reviewed, and whether a human ever had meaningful oversight. Practitioners should design AppSec around machine-assisted provenance, not only human review.
What this signals
AI-generated code security is now a programme-design issue, not a tooling add-on. Security leaders need to decide where machine-authored changes are allowed, how they are labelled, and which repositories remain off limits until visibility improves. That is a governance question about development trust boundaries, not only a code-quality question.
Machine-assisted development creates a new review gap. Traditional AppSec assumes there is a stable human author behind each change set, but AI-driven workflows blur that assumption. The practical response is to push provenance, policy, and telemetry into the development path itself so the organisation can see where generated code originates and how it is used.
For practitioners
- Map every AI coding entry point Catalogue IDE copilots, chat-based coding helpers, repository bots, and agentic developer tools so you know where machine-generated code can enter the delivery chain.
- Require provenance for generated code Tag AI-assisted commits, preserve prompt and suggestion context where feasible, and make review workflows distinguish machine-authored changes from human-authored ones.
- Add AI-specific checks to AppSec Extend code review with prompt-safety, assistant-integrity, and secret-exposure controls so scanning is not limited to static source findings.
- Restrict AI tools from sensitive repos Limit access to private repositories, secrets-heavy projects, and production release paths until the organisation can prove logging, approval, and monitoring coverage.
- Separate policy for human and machine authorship Write rules that define approved AI use, required review thresholds, and escalation paths when generated code touches authentication, secrets, or data handling.
Key takeaways
- AI-generated code widens the gap between development speed and AppSec oversight, especially when teams cannot reliably see where machine-assisted code is entering the pipeline.
- The survey evidence points to mainstream AI adoption in software development, with security leaders most concerned about new vulnerabilities and limited visibility.
- The strongest control response is to govern provenance, visibility, and review boundaries for AI-assisted code before those changes reach release.
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, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI coding assistants act as non-human contributors whose access and authorship need governance. |
| ASI09 — Human-Agent Trust Exploitation | The article shows how developers may trust AI-generated output beyond its security assurances. | |
| Recommendation — Govern machine-assisted coding so assistant identity, privilege, and output boundaries are auditable. Validate AI-assisted changes independently rather than assuming generated code is safe by default. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | AI assistants and developer tooling can expose repositories and code when misconfigured or overexposed. |
| Recommendation — Harden tool configurations and permissions so coding assistants cannot reach sensitive assets unnecessarily. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article describes assistant compromise leading to source and secret exposure. |
| Recommendation — Map assistant abuse to credential access and exfiltration techniques in detection and response planning. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The topic is fundamentally about governing AI use in software delivery workflows. |
| Recommendation — Establish governance, accountability, and inventory for AI coding tools before approving broad use. | ||
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.
- 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.
- Application Security: Application security is the practice of protecting software across development, deployment, and runtime. It covers code, dependencies, secrets, infrastructure, and execution behaviour, because any one of those layers can expose data or access if it is not governed as part of the same lifecycle.
- Machine-assisted Development: Machine-assisted development is a software delivery model in which AI tools contribute code, suggestions, or remediation steps inside the engineering workflow. It changes the security baseline because generated output can move faster than traditional review processes and may require provenance and policy controls.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need a structured way to connect identity controls to emerging machine-authored workflows.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org