TL;DR: LLMs should be treated as a probabilistic new kind of pentest, while traditional SAST remains the deterministic layer needed for coverage, prioritisation, and defect prevention, according to Semgrep. The practical shift is not replacing static analysis with AI, but using both to harden AppSec workflows as code generation accelerates.
NHIMG editorial — based on content published by Semgrep: AI-assisted AppSec, Mythos, and defense in depth
Questions worth separating out
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.
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.
Q: What breaks when organisations rely on AI findings alone for AppSec?
A: The main failure is loss of deterministic assurance.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Semgrep's analysis of AI-assisted AppSec, Mythos, and defense in depth →
AI-assisted code review and AppSec automation: are your controls keeping up?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: AI-assisted AppSec raises the stakes for SAST and defense in depth