Time-to-exploit went negative. Mandiant maps where AI helps the vulnerability queue, and where it fails silently.

You wire your CI to fail on known CVEs. Reasonable. Then Mandiant tells you the mean vulnerability is exploited seven days before a patch exists to fix it. Sit with that for a moment.

Google Cloud's threat-intelligence blog published a piece on 2026-07-16 by Mandiant's Jules Czarniak, titled "Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management." The blueprint is more interesting than the title. It anchors the pitch on the M-Trends 2026 finding of a negative-seven-day mean time-to-exploit, then maps where a language model earns a seat in the vulnerability pipeline, and where it will fail with a straight face.

The verdict up front: this is one of the cleaner descriptions of where LLMs actually belong on a security team, written by people who spend their working hours writing the response after the breach. It is also, in places, a careful list of the ways this can go wrong. Both halves matter.

The number that reframes the pipeline

The M-Trends 2026 figure cited is a mean time-to-exploit of -7 days. In plain terms: on average, an exploit is running before the patch is written. Scan-and-patch as a defensive posture is a week behind the attacker on average, and averages have long tails.

Which is the operational premise for the rest of the post. If a patch cannot outrun an exploit, the lever you have left is triage. Which finding drops everything. Which one waits. Which one you never look at because it is theoretically reachable but never actually exposed. Pipelines already do this work implicitly, badly, on gut feel and a spreadsheet nobody updates.

Where a model earns its seat

Mandiant splits the work into two tracks that map onto stages you already recognize.

Track one is enterprise vulnerability management. Normalize findings from every discovery source (SAST, DAST, EASM, CSPM, CTEM, EDR, SOAR), dedup them, score each one on asset sensitivity, active-exploitation signal, and CVSS. The blueprint sketches a rubric: an internet-facing asset holding customer data scores 100, an internal box with nothing sensitive scores 25; an actively exploited CVE gets a threat score of 100, a theoretical exploit gets 25. It is a shape more than a formula, and one an LLM can populate at scale.

Track two is product security. Contextual triage of SAST warnings, memory-safety scans on C, C++ and assembly, IDE-integrated fixes, CI-runner-driven patch generation for specific bug classes. Google's not-yet-public CodeMender project is cited here as the direction of travel for LLM-assisted remediation on a pipeline runner. Nothing you can adopt today. A shape.

Both tracks share one design decision: the model sits on the queue, not on the codepath. It reads alerts, ranks them, drafts a patch on a runner, hands the artifact to a human. Nothing reaches production without a human review gate. This is deliberate, and it is the reason the blueprint reads as sober rather than embarrassing.

The failure list is the interesting part

Now the honest section. If you skip everything else in the source, read this one.

Attention degrades over long contexts. Taint a variable on line 10, sanitize it on line 500, and the model may lose the sanitization. Chunk a codebase to fit the context window and cross-function data flows fragment. Ask the model about an authorization bypass and you get contextual narrowing: hyper-fixated on a local syntax issue, blind to the architectural one three services over.

Mandiant frames this as an oracle problem. Bugs with a binary, observable oracle (crash on this input, not-crash on that one) are where the model shines. Bugs with an architectural oracle (this request should not be allowed because of a business rule nobody wrote down) are where the model produces well-formed silence. That is the class of vulnerability attackers care about most, and the class an LLM helps least. Awkward.

Then the plumbing risks. Indirect prompt injection through source comments and third-party dependency files. A malformed tool call that crashes an unrelated process, followed by a fluent hallucinated success message. MCP plugins turning a benign integration into a silent supply-chain injection on the next update. Model drift on managed services quietly eroding the calibration of every downstream score.

Signed. Verified. Still exploitable.

What to actually wire into a pipeline

Three moves fall out for a CI/CD owner.

First, treat AI-assisted vulnerability management as a triage layer, never a gate. Ship the scoring, the enrichment, the dedup, the summary-to-issue conversion. Keep the deploy decision on a human.

Second, wire evaluation harnesses. If a model scores findings, you need a labelled ground-truth set from your own history, replayed on every model version and prompt change, with a red/green step on the pipeline. Otherwise "model drift" becomes a euphemism for "our triage got worse and nobody noticed".

Third, name the trust boundary. Least-privilege runner: read-only access to source, no credentials, no outbound network beyond the model provider and the ticketing system. Prompt-injection payloads buried in a third-party dependency stop mattering the moment your agent has nothing worth stealing.

The framework name-check, if you like anchors

For readers who like their security architectures with a name attached, Mandiant lines up the usual anchors: the NIST AI Risk Management Framework, the OWASP Top 10 for LLMs, Google's Secure AI Framework, PASTA for threat modelling, SLSA for supply-chain provenance. On orchestration, LangChain and AutoGen are the cited references. Model Armor gets a mention as an example of a guard model, and Wiz appears as the external-attack-surface piece of the sample architecture. If you have been building your own harness, treat the list as a checklist to be sure you are not reinventing a wheel with a CVE already filed against it.

Read it, then argue with it

Most vendor security posts arrive with a product and a chart. This one arrives with an oracle-class taxonomy and a sentence that says, roughly, if an exploit relies on a novel technique the agent will scan right past it in silence. Pin that sentence in every meeting where someone proposes replacing the triage on-call with an autonomous agent.

Time-to-exploit is negative now. Aim the model at the queue, not at production.