TL;DR: AI-led software development now requires discovery of AI use, AI-specific security testing, threat modelling for new AI components, and control of toxic combinations such as GenAI use alongside missing branch protection, according to LEGIT Security. The core issue is not AI itself but unmanaged change in the software supply chain and the governance gap it creates.
Editorial analysis by NHI Mgmt Group, based on content published by LEGIT Security: “4 New AppSec Requirements in the Age of AI”.
By the numbers:
- On average, 17% of repos per organization have developers using GenAI tools plus lack of branch protection or code review.
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.
Q: Why do AI-generated code pipelines become risky when branch protection is missing?
A: Branch protection and code review act as the brake on rapid change.
Q: What are the signs that AppSec governance is lagging behind AI development?
A: The clearest signs are unclear code ownership, delayed vulnerability routing, inconsistent framework approval, and release decisions that rely on manual review after the change is already too large to inspect well.
Practitioner guidance
- Discover AI use across repositories and pipelines Inventory AI-generated code, AI services, MCP-connected tools, and developer copilots so you can map where AI influences software change.
- Add AI-specific security tests to AppSec gates Extend testing beyond traditional scanning to look for model poisoning, excessive agency, and untrusted or low-reputation models in the delivery chain.
- Treat branch protection as a control paired with AI use Flag any pipeline where GenAI is used but branch protection or code review is missing, because that combination creates an outsized governance gap.
Bottom line: AI-led development is turning AppSec into a governance discipline that must discover AI use, not just inspect code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
AI discovery is now an AppSec control, not an optional inventory exercise. If teams cannot identify where generated code, AI services, and developer copilots are used, they cannot govern the risk introduced by those tools. The discipline shifts from code inspection after the fact to policy enforcement at the point AI enters the delivery chain. That is the new baseline for AppSec programme design.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations treat AI-specific testing separately from standard AppSec testing?
A: Yes. Standard scanners still matter, but they do not reliably detect model poisoning, excessive agency, or malicious model behaviour. AI-specific testing should sit alongside existing AppSec checks so teams assess both the code and the AI behaviour embedded in the application and pipeline.
👉 Read our full editorial: AI-led code development is exposing new AppSec governance gaps