LLMs Are Becoming Security Engineers: The SAST Shift Happening Now

Two signals dropped today that, taken together, mark a quiet inflection point: LLMs are being architected as the primary reasoning engine in security tooling, not as a bolt-on assistant. CodeCrucible published a blueprint for LLM-driven static application security testing, and separately, Claude Mythos Preview identified a real cryptographic vulnerability in a weakened form of AES. These are not demos. They are architecture signals.

The pattern

Traditional SAST tools are rule engines. They match code patterns against known vulnerability signatures. They are fast, auditable, and brittle: they miss novel vulnerabilities and flood teams with false positives because they have no semantic understanding of what code is trying to do.

The LLM-driven SAST pattern flips this. Instead of matching patterns, the model reasons about intent, data flow, and trust boundaries. CodeCrucible frames this as a blueprint, meaning a composable architecture other teams can adopt, not a closed product. The core idea: treat the LLM as a structured reasoning layer that receives code chunks, produces vulnerability hypotheses with confidence scores, and hands off to a verification step.

The Claude Mythos cryptographic finding reinforces this from a different angle. Cryptographic vulnerability discovery has historically required deep specialist knowledge. A model finding a flaw in a weakened AES implementation suggests the reasoning capability is now sufficient to operate in domains that were previously human-expert-only.

Also worth noting alongside these: Enprompta launched production tooling for prompt management, LLM evaluation, and observability, which is exactly the infrastructure layer these security agents need to be trustworthy in production.

Why now

Three things converged. First, context windows are large enough to ingest entire modules or services in a single pass, not just isolated functions. Second, models have improved enough at structured output that you can reliably get back machine-readable vulnerability reports, not prose summaries. Third, the agent tooling ecosystem, including eval frameworks like those Enprompta is building, has matured enough that teams can actually monitor and iterate on these pipelines.

Back in 2024, LLM code review was mostly "ask GPT to review this PR." What is shipping now is fundamentally different in architecture.

How it works in practice

1. Chunking strategy matters more than model choice. Security reasoning requires preserving call graphs and data flow context. Naive line-by-line chunking breaks the semantic thread. Chunk at function or module boundaries, and include import graphs as structured context.
2. Use structured output schemas from the start. Define a vulnerability schema: type, severity, location, reasoning chain, confidence. Models that are prompted to fill a schema produce more consistent, auditable results than models asked to write prose findings.
3. Chain-of-thought is not optional here. Security findings without reasoning are useless. Prompt the model to explain why a pattern is dangerous before it returns the finding. This also makes false positives easier to filter.
4. Build a verification step. LLM-identified candidates should feed into a lightweight symbolic check or a targeted fuzzer. The model generates hypotheses; deterministic tools confirm them. This is how you get to a defensible false-positive rate.
5. Instrument everything. If you are shipping this to a team that will act on findings, you need eval pipelines and observability from day one. Prompt drift and model updates will silently change recall rates.

The trade-off

The honest caveat: LLM-driven SAST is slower and more expensive than rule-based tools on large codebases. A traditional SAST scan that runs in two minutes may take ten to thirty minutes and real money when the reasoning layer is a frontier model. For teams running scans on every commit, this is a real constraint.

The current practical pattern is hybrid: run fast rule-based tools first, then route flagged files or novel code paths to the LLM layer for deeper reasoning. This keeps costs bounded while capturing the semantic advantage where it matters most.

There is also the question of prompt injection in the code itself. Malicious strings in source files could theoretically manipulate a model's analysis. This is not theoretical anymore, and any production security agent needs sanitization and sandboxing at the ingestion layer.

Where it goes next

The fact-checking agent that also surfaced today is worth watching as a parallel architecture. It uses the same pattern: retrieve evidence, reason over it, return a structured verdict. Security auditing and information verification are converging on identical agent skeletons. Teams that build this pattern well in one domain will port it to the other quickly.

Expect to see LLM-driven SAST move from "blueprint" to "default" in security-conscious engineering teams within the next two to three quarters, especially as prompt observability tooling matures and brings the operational costs of running these pipelines down. The teams that invest in prompt engineering discipline for security agents now will have a significant head start.

The shift is not that AI can write code. It is that AI can audit it, reason about it, and find what rule engines miss.