All posts

Mandiant: vulnerabilities now exploited 7 days before patches

Manaal KhanJuly 18, 2026 at 2:32 PM7 min read
Mandiant: vulnerabilities now exploited 7 days before patches

Key Takeaways

AI Now Exploits You 7 Days Before the Patch Exists

  • Mean time-to-exploit has gone negative: attackers exploit vulnerabilities a week before patches exist
  • AI agents for vulnerability scanning require strict isolation, zero data retention, and deterministic guardrails
  • Codebases themselves must be treated as untrusted input since attackers can embed prompt injections in source code comments

Mandiant's M-Trends 2026 report contains a number that should unsettle every security team: the mean time-to-exploit has dropped to negative seven days. Attackers are exploiting vulnerabilities a full week before vendors ship patches. The defensive playbook that worked when you had a 32-day window no longer applies.

The response from many organizations has been predictable: integrate LLM agents into CI/CD pipelines for automated vulnerability discovery. Google's Mandiant Consulting, in a new technical guide authored by Jules Czarniak, argues this approach can work. But only if teams treat the AI agents themselves as potential attack surfaces.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image1.max-1400x1400.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image1.max-1400x1400.png
-7 days
Mean time-to-exploit in 2026, meaning vulnerabilities are exploited a week before patches exist
Advertisements

Why AI agents create new attack vectors

The core problem is privilege. An AI agent scanning your codebase for vulnerabilities needs access to that codebase. An agent that can generate pull requests and commit fixes needs write access to your repository. Give it those privileges without proper controls, and you have created a new entry point for attackers.

Mandiant identifies a particularly insidious risk: indirect prompt injection via source code. Threat actors can embed malicious instructions inside code comments or third-party dependencies. These hidden prompts might tell the agent to ignore vulnerabilities, exfiltrate environment variables, or suppress findings from scan reports.

This means security teams must treat the codebase itself as untrusted input, even for internal scanning. The same logic that validates user input in web applications now applies to the prompts your AI agents receive from your own repositories.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image5.max-1300x1300.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image5.max-1300x1300.png

The four guardrails Mandiant recommends

The Mandiant guidance centers on four operational controls. These are not suggestions. They are prerequisites for deploying AI agents in production security workflows.

  1. Pre-agent data security: Agents must never access PII, PHI, or other sensitive data. Enforce this before prompts reach the model. Use synthetic data in non-production environments and deploy a hybrid defense-in-depth model with deterministic policy engines (Layer 1) and reasoning-based guard models like Model Armor (Layer 2).
  2. Zero data retention agreements: Establish strict ZDR contracts with LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models. Also negotiate authorized testing agreements since many cloud providers throttle automated offensive probing by default.
  3. Workload isolation: Execute agent workloads in unprivileged containers with dynamically limited privileges. Strong sandboxing contains the blast radius if an agent hallucinates a destructive command or gets hijacked.
  4. Least-privileged machine identities: Agents need commit access, but that access should be strictly scoped and tied to human controllers for accountability.
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image8.max-1200x1200.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image8.max-1200x1200.png

Red team the AI before you deploy it

Mandiant makes an argument that should be obvious but often gets skipped: before deploying autonomous vulnerability scanners that can spin up sandboxes and execute code, subject the AI agents themselves to human-led red teaming.

The testing should validate resilience against jailbreaks, recursive logic loops, and complex prompt injections. The goal is ensuring your security tooling does not become the attack vector. If an attacker can manipulate your AI scanner into approving vulnerable code or hiding findings, you have automated your own compromise.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image4.max-1100x1100.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image4.max-1100x1100.png
Advertisements

How the hybrid model works in practice

The Mandiant approach combines AI capabilities with deterministic controls and human judgment. AI accelerates the scan-and-triage cycle. Deterministic policy engines act as chokepoints that cannot be reasoned around. Humans make final decisions on remediation and handle edge cases.

This hybrid model acknowledges a truth about current LLMs: they hallucinate. They can be manipulated. They lack the ability to reliably distinguish between a clever optimization and a security vulnerability in all cases. The deterministic layers catch failures the probabilistic layers miss.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image3.max-2100x2100.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Demystifying_AI_image3.max-2100x2100.png

Mandiant references Google's Secure AI Framework (SAIF) and Google's approach to secure AI agents as practical implementation guides. These frameworks extend existing security controls directly into the AI execution environment rather than treating AI as a separate, ungoverned system.

https://storage.googleapis.com/gweb-cloudblog-publish/images/image_20.max-1800x1800.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/image_20.max-1800x1800.png

The broader context: patch windows are dead

The shift to negative time-to-exploit represents a fundamental change in the vulnerability landscape. In 2021-2022, Mandiant reported a mean TTE of 32 days. By 2023, that had dropped to 5 days. Now it has gone negative.

Zero-day exploits have become the majority attack vector for initial access. Google's Threat Analysis Group tracked 97 zero-day vulnerabilities exploited in the wild in 2023 alone. The traditional model where vendors discover, patch, and organizations deploy no longer matches reality.

This is why organizations are turning to AI-assisted vulnerability discovery. They need to find and fix issues before the CVE is published, before the patch exists. But rushing to deploy AI agents without the guardrails Mandiant describes just trades one set of risks for another.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Screenshot_2026-07-15_at_10.24.22PM.max-1600x1600.png
https://storage.googleapis.com/gweb-cloudblog-publish/images/Screenshot_2026-07-15_at_10.24.22PM.max-1600x1600.png
ℹ️

Logicity's Take

Mandiant's guidance is solid but incomplete. It assumes organizations already have mature CI/CD security practices, container orchestration, and the engineering capacity to build custom integrations. For teams that lack in-house security engineering depth, commercial vulnerability management platforms like Snyk, Veracode, or Semgrep are building these guardrails into their AI features. The build-vs-buy calculus has shifted: building your own AI vulnerability scanning pipeline means taking on all the risks Mandiant describes. Most organizations should wait for vetted commercial implementations or engage Mandiant directly for integration support.

Frequently Asked Questions

What is negative time-to-exploit?

A negative TTE means vulnerabilities are being actively exploited before a patch or CVE is publicly available. Mandiant's M-Trends 2026 report puts the mean at -7 days, indicating attackers exploit flaws roughly a week before organizations can deploy official fixes.

How can AI agents introduce security vulnerabilities?

AI agents with code access can be manipulated through indirect prompt injection (malicious instructions hidden in code comments or dependencies), can hallucinate destructive commands, or can be hijacked to exfiltrate secrets. Without isolation and deterministic controls, they become new attack surfaces.

What is a zero data retention agreement for LLMs?

A ZDR agreement with an LLM provider contractually guarantees that proprietary code, prompts, and discovered vulnerabilities are not stored or used to train the provider's models. This protects intellectual property and prevents vulnerability details from leaking into training data.

Should AI security agents have commit access to repositories?

Yes, but with strict scoping. Mandiant recommends least-privileged machine identities that tie back to human controllers for accountability. The agent should only have the minimum access needed for its specific task, not broad write permissions across repositories.

ℹ️

Need Help Implementing This?

If your security team is evaluating AI-assisted vulnerability management, Mandiant Consulting offers integration services. Contact Mandiant directly through Google Cloud's security services portal to discuss authorized testing agreements and implementation guidance for your environment.

Source: Cloud Blog

M

Manaal Khan

Tech & Innovation Writer

Produced with AI assistance and reviewed by the Logicity editorial team. Learn more in our Editorial Policy.