TL;DR: AI-assisted code generation is accelerating software output faster than security review can keep up, while static analysis that explains risk in developer context may finally narrow the gap, according to Semgrep. The deeper shift is upstream: organisations are moving from catching bad code in production to preventing it in the IDE and pull request.
At a glance
What this is: Semgrep argues that AI-assisted code security is shifting left because code is now being produced faster than review can keep up, making upstream prevention more important than downstream detection.
Why it matters: For IAM, NHI, and broader security teams, the article matters because it frames secure development as a governance and control problem, not just a tooling problem, with prevention moving closer to the point of code creation.
Context
The core problem is not new: insecure software still comes from code written without enough context, enough guardrails, or enough feedback at the point of creation. AI-assisted development increases that pressure by accelerating output, which makes downstream review and remediation less effective as the primary control.
For identity and security programmes, the relevance is indirect but real. If developers can produce more code faster, then authentication flows, access checks, secrets handling, and service-to-service trust patterns are introduced at greater speed, which raises the burden on secure-by-design governance rather than only production monitoring.
Key questions
Q: How should teams stop AI-generated code from introducing insecure patterns before merge?
A: Security teams should enforce checks in the pull request and IDE workflow, because that is where insecure code can still be stopped cheaply. Late scanning still has value, but it is a detection control, not a prevention control. The goal is to make security feedback available while the developer is still editing the code.
Q: Why does AI-assisted development create more security risk even when scanners improve?
A: Because scanners only help if the team can act on their output. AI-assisted development increases both the number of findings and the speed at which they arrive, while remediation remains bounded by human capacity. If the organisation does not change prioritisation and automation, better detection simply produces a larger queue.
Q: What are the signs that shift-left security is being applied too late?
A: Shift-left security is being applied too late when vulnerabilities are discovered after code has already moved far through the pipeline, forcing teams back into rework. Other signs include repeated manual remediation, delayed engineer feedback, and security checks that only happen near release. In that state, testing becomes a bottleneck instead of an early quality control.
A: Pull request detection prevents the vulnerable pattern from shipping, while production detection only reduces exposure after the code is already live. The difference is not just timing. It changes remediation cost, blast radius, and how much security learning the engineering team can still absorb.
Technical breakdown
Why AI-assisted coding changes the security control point
AI-assisted code generation changes the control point from after-the-fact review to in-flow prevention. When code volume rises, manual review and late-stage scanning become backlog controls rather than preventive controls. The security issue is not that AI writes code, but that it can scale the same classes of mistakes faster, including weak input handling, insecure defaults, and brittle authentication logic. That means the practical unit of defence moves closer to the IDE and pull request, where feedback can influence the code before it becomes a release artifact.
Practical implication: move security checks earlier in the developer workflow so defects are blocked before merge, not triaged after deployment.
Why context-aware static analysis matters more than alerts
Static analysis only changes behaviour when it explains risk in the language of the developer's task. A bare finding is easy to ignore; a finding tied to call path, data flow, and likely impact is far more actionable. The article's key technical point is that LLM-assisted analysis can bridge the comprehension gap between security tooling and engineering decisions. That does not eliminate the need for deterministic rules or expert review, but it can reduce the translation failure that has historically made security findings hard to act on.
Practical implication: tune developer-facing findings for explainability and workflow fit, not just detection volume.
How shift-left security intersects with identity and access control
The identity angle appears when insecure code creates or weakens authentication, authorisation, or secret-handling logic. Faster development can multiply mistakes around session handling, access tokens, service credentials, and API permissions, especially when teams rely on shared libraries or copied patterns. In practice, the code layer is where identity controls are either preserved or diluted. If those controls are not encoded into engineering guardrails, the security programme inherits technical debt at the same pace that AI increases delivery speed.
Practical implication: treat authentication and secret-handling patterns as enforceable engineering controls, not optional review comments.
Threat narrative
Attacker objective: The attacker objective is to exploit insecure code paths that were introduced faster than the organisation could review and correct them.
- Entry occurs when AI-assisted development produces insecure application logic faster than review processes can inspect it.
- Credential or control abuse follows when weak authentication, secrets handling, or access checks are embedded into shipped code and later exploited.
- Impact arrives as preventable vulnerabilities reach production, increasing exposure, remediation cost, and the number of places attackers can use the same flaw.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
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
Shift-left code security is really a governance problem about where control is enforced. The important change is not that AI writes code, but that code production now outruns the organisations' ability to review it late in the lifecycle. That makes prevention at the point of creation a structural issue, not just a tooling preference. Practitioners should treat this as a control-placement decision, not a developer productivity debate.
Developer-context security feedback is the missing translation layer. Security findings fail when they arrive as detached alerts instead of guidance tied to the code path the developer is touching. LLM-assisted explanation can narrow that gap if it improves relevance without replacing precise static analysis. The practical conclusion is that security teams need to optimise for actionability, not just detection fidelity.
AI-assisted delivery increases the risk of repeating old mistakes at new speed. The industry is not facing a new class of vulnerability so much as a faster reproduction cycle for familiar defects. That means organisations need to measure whether review and prevention controls scale with code generation, not whether they merely exist. The failure mode is throughput without governance.
Identity controls now depend on engineering defaults as much as policy. Authentication, authorisation, and secret handling are often only as strong as the patterns developers are given and the checks their tools enforce. That makes secure coding a governance concern for identity programmes, especially where human and non-human access patterns intersect. The result is a tighter link between code quality and identity assurance than many programmes currently recognise.
What this signals
Shift-left only works when the control point moves with the developer. If security feedback arrives after code is merged, the organisation has already accepted the risk and is merely managing fallout. The better measure is whether prevention happens in the IDE and pull request, where the change still has a chance to be rejected or rewritten.
AI-assisted code creation makes identity assurance more dependent on engineering discipline. Authentication, authorisation, and secret-handling defects are now more likely to be repeated at scale unless approved patterns are enforced in the software delivery path. That makes secure coding standards a living governance control, not a documentation exercise.
For practitioners
- Embed security checks into pull requests Require authentication, authorisation, and secret-handling checks before merge so insecure patterns are blocked before release, not found after deployment.
- Tune developer-facing findings for context Use findings that explain the code path, likely exploitability, and developer-relevant remediation so teams can act without translating security jargon.
- Measure prevention at the point of creation Track whether issues are prevented in the IDE or pull request rather than only counting production findings, because late-stage detection is a backlog signal, not a control outcome.
- Govern identity-sensitive code patterns as standards Standardise approved patterns for authentication, access checks, and secrets handling so developers do not reintroduce known identity failures at scale.
Key takeaways
- AI-assisted code generation is increasing the speed of software delivery faster than many security review processes can adapt.
- The article argues that the real leverage point is earlier in the lifecycle, where security feedback can shape code before it ships.
- For practitioners, the key challenge is turning developer workflows into preventive controls for identity, secrets, and access logic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | AI-assisted code can introduce or weaken authentication logic in applications. |
| V8 — Authorization | The article's code-risk argument includes access checks and privilege logic in application code. | |
| V15 — Secure Coding and Architecture | The article is fundamentally about preventing insecure code before it reaches production. | |
| Recommendation — Use V6 to enforce authentication requirements in code review and verification workflows. Apply V8 to verify that application authorization logic is explicit, testable, and consistently enforced. Use V15 to embed secure coding controls into the developer workflow and release path. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Shift-left prevention depends on secure engineering controls being built into the production of code. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article touches identity-sensitive code paths where access decisions are implemented in software. | |
| Recommendation — Integrate security requirements into development and deployment configuration baselines. Validate that application code enforces access permissions consistently before release. | ||
Key terms
- Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
- Context-Aware Static Analysis: Context-aware static analysis is code scanning that explains a finding in relation to the surrounding code path, data flow, and likely impact. The value is not only detection, but also making the result understandable enough for engineers to act on it quickly and correctly.
- Developer-Integrated Security Feedback: Developer-integrated security feedback is vulnerability guidance that appears inside the tools and workflows developers already use. It reduces friction by presenting risk at the moment of editing or review, when a change is still cheap to fix and the developer can immediately adjust the code.
- Preventive Control Point: A preventive control point is the stage in a delivery process where a risk can still be stopped before it becomes an operational exposure. In software security, the strongest control points are usually pre-merge and pre-deploy, not only post-release monitoring.
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. It helps security and identity practitioners connect lifecycle control to the wider governance problems that code quality can create.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org