AI-assisted AppSec raises the stakes for SAST and defense in depth

At a glance

What this is: This is Semgrep’s analysis of how AI-assisted code review, agentic workflows, and traditional SAST should coexist in AppSec, with the key finding that probabilistic model output does not replace deterministic coverage.

Why it matters: It matters because AppSec teams now have to govern AI-generated code, model-assisted remediation, and defence in depth without assuming one scanning layer can cover all risk.

👉 Read Semgrep's analysis of AI-assisted AppSec, Mythos, and defense in depth

Context

AI-assisted application security is moving from experimentation into operational use, but the core governance problem has not changed: teams still need deterministic control over what enters the codebase. Large language models can accelerate review and remediation, yet they also introduce inconsistent findings, false positives, and variable coverage. In practice, that creates an AppSec control gap between what the model can suggest and what the programme can prove.

For IAM and security teams, the identity angle sits in the tooling layer rather than the code itself: AI coding assistants, model-driven workflows, and automated remediation systems all need access boundaries, approval controls, and traceable execution. That makes this a governance question about how much trust to place in agentic tooling inside the software delivery chain, not just a tooling choice about scanning speed.

Key questions

Q: How should AppSec teams use LLMs without replacing SAST?

A: Use LLMs to expand discovery and speed triage, but keep SAST as the deterministic control that enforces repeatable policy and coverage. Model output is useful for finding candidates and helping developers respond faster, yet it should not be the sole release gate. The safest pattern is layered validation, with AI augmenting review rather than replacing the proving layer.

Q: Why do AI coding tools create a security risk even when code looks correct?

A: They optimise for syntax and pattern completion, not contextual security reasoning. Code can compile, satisfy tests, and still mishandle input, logging, or trust boundaries in ways that create exploitable flaws. That is why functional correctness and security correctness must be measured separately in governed pipelines.

Q: What breaks when organisations rely on AI findings alone for AppSec?

A: The main failure is loss of deterministic assurance. AI can miss defects, vary by model and prompt, and create false confidence when teams mistake plausible analysis for repeatable control. Without static checks and policy enforcement, vulnerable code can move through the pipeline simply because the model did not flag it clearly enough.

Q: How should security teams govern agentic workflows that are built from real user activity?

A: Security teams should govern them as delegated identities with explicit ownership, approval, scope, and revocation. The captured workflow is not just a script. It is an identity-derived execution path that can reach real systems, so the approval process, runtime boundary, and audit record all need to be controlled together.

Technical breakdown

Why LLM-based AppSec behaves like probabilistic testing

LLMs used for security review do not operate like traditional static analysis. They infer likely defects from patterns in code, so results vary by prompt, model, and context window, which means they are probabilistic rather than fully deterministic. That makes them useful for surfacing candidate issues, especially in large or noisy repositories, but not sufficient as the only line of defence. Traditional SAST still matters because it can enforce repeatable rules, produce consistent findings, and give teams coverage guarantees that model output cannot.

Practical implication: use AI review to widen discovery, but keep deterministic SAST as the control that gates release decisions.

Why defence in depth matters more when AI writes code

When code is generated or modified by AI assistants, the security problem shifts from finding isolated bugs to controlling how insecure patterns enter the pipeline. A model can create plausible but flawed code, miss surrounding context, or ignore earlier findings. That means security controls need to operate at multiple layers, including pre-commit checks, CI validation, dependency controls, and hardening around the development workflow itself. In AppSec, defence in depth is no longer just about runtime containment; it is about preventing a single unsafe generation step from becoming a release path.

Practical implication: enforce layered checks on AI-generated code, including generation-time guardrails and CI blockers for high-confidence findings.

What agentic workflows change in security engineering

Agentic workflows move AppSec from point-in-time scanning toward delegated action, where tools can triage, remediate, or harden code with less manual intervention. That is operationally useful, but it also changes the trust model because the system is now acting, not just reporting. Once a workflow can modify code or infrastructure, the organisation needs permissions, logging, and rollback discipline comparable to other privileged automation. The governance challenge is not whether automation exists, but whether its scope, approvals, and failure modes are explicit.

Practical implication: treat AI security automation like privileged automation and constrain it with least privilege, auditability, and rollback controls.

Threat narrative

Attacker objective: The objective is to exploit the weakness created when AI-assisted development reduces review quality or hides exploitable defects inside an overloaded AppSec process.

1. Entry occurs when AI coding tools or model-assisted workflows introduce insecure code patterns into the development pipeline.
2. Escalation happens when those patterns are accepted because model output is treated as sufficient evidence instead of being validated by deterministic controls.
3. Impact follows when flawed code reaches production or when vulnerability noise overwhelms teams and delays remediation of exploitable issues.

NHI Mgmt Group analysis

AI-assisted AppSec is becoming a governance problem, not just a tooling problem. Once models participate in code review or remediation, teams are managing decision quality, not only defect detection. That shifts attention to trust boundaries, approval logic, and evidence quality across the development pipeline. Practitioners should design controls for model-assisted work the same way they would for privileged automation.

Probabilistic security findings cannot substitute for deterministic coverage. A model can help prioritise likely defects, but it cannot guarantee repeatable enforcement across the same codebase. That means organisations need a stable control layer beneath any AI-assisted review, especially where release approval depends on evidence. Practitioners should keep SAST, policy checks, and CI controls as the proving layer.

Defense in depth now includes the AI generation path. The real risk is not only that insecure code exists, but that AI tooling accelerates its introduction faster than the programme can detect and contain it. This is where AppSec and identity governance intersect: tools that can act on code need least privilege, traceability, and clear ownership. Practitioners should govern AI coding systems as high-trust automation.

Rotating model use is useful, but it does not solve the control problem on its own. Changing models may improve coverage at the margins, yet the architectural issue remains the same: security teams still need a repeatable way to distinguish signal from noise. That is why multi-layered AppSec programmes are becoming more important, not less. Practitioners should invest in control depth rather than chasing model novelty.

Code security is moving toward delegated remediation, and that raises the bar for operational discipline. If tools can not only find issues but also fix them, the quality of change control, logging, and rollback becomes central to AppSec assurance. The question is no longer whether AI can help, but whether the organisation can prove what it changed and why. Practitioners should align AI security workflows with formal change management.

What this signals

AI-assisted development will force AppSec teams to measure control quality, not tool count. Adding more scanners will not help if release decisions still depend on noisy or inconsistent signals. The programme question is whether deterministic checks, approval logic, and rollback discipline are strong enough to contain AI-generated defects before they become production incidents.

Model-assisted remediation will increasingly resemble privileged change management. Once tools can fix code or adjust security settings, the boundary between developer convenience and operational authority narrows. That creates a direct identity and governance intersection for access scoping, auditability, and session-level accountability across the delivery pipeline.

AppSec leaders should expect vendor-neutral pressure to prove which layer actually enforces policy and which layer only accelerates discovery. The organisations that separate signal generation from release control will be better placed to absorb AI-driven code volume without turning vulnerability management into backlog inflation.

For practitioners

• Keep deterministic SAST in the release path Use static analysis as the control that blocks merges on high-confidence findings, even when LLM-assisted review is also running. AI can widen discovery, but only repeatable policy checks should decide whether code ships.
• Add generation-time checks for AI-written code Run security validation at the point where models or copilots produce code, so insecure patterns are caught before they are copied into the branch. This is especially useful for Claude, Cursor, and Codex-style workflows.
• Treat AI remediation as privileged automation Constrain agentic workflows with least privilege, audit logs, and rollback capability whenever they can modify code or security settings. The access model should reflect that the system is acting, not just advising.
• Reduce vulnerability noise before adding more signals Prioritise the triage logic that separates exploitable issues from background findings so new model output does not overwhelm engineers. Without better prioritisation, AI-assisted discovery can increase backlog pressure rather than reduce risk.

Key takeaways

• AI-assisted AppSec should be treated as a governance challenge because model output is probabilistic, while release controls still need deterministic assurance.
• Security teams cannot rely on AI findings alone, especially when noisy pipelines and fast code generation make prioritisation and enforcement harder.
• The practical response is layered control: keep SAST, add generation-time checks, and govern AI remediation as privileged automation.

Key terms

• Probabilistic Security: A security approach that relies on likelihood, scoring, or inference rather than fixed rules. It is useful for prioritisation and detection, but it cannot guarantee enforcement because the system is estimating risk rather than making a hard authorisation decision.
• Defense in depth: Defense in depth is the practice of stacking independent controls so one failed check does not expose the whole system. In App Router authentication, that means verifying identity in middleware, route handlers, and data access logic, because each layer protects a different part of the request path.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

What's in the full article

Semgrep's full post covers the operational detail this post intentionally leaves for the source:

• How Semgrep positions Mythos, Multimodal, and Workflows in the AppSec stack for teams already using LLM-assisted development
• The beta-to-GA operational context behind Semgrep Multimodal, including the kinds of issues it surfaced in customer environments
• The specific workflow changes Semgrep recommends for teams using Claude, Cursor, and Codex style coding assistants
• The TeamPCP incident example and the control adjustment Semgrep made after Claude ignored a finding

👉 Semgrep's full post covers the model strategy, workflow changes, and incident example in more detail.

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, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect access, automation, and governance across modern security programmes.