Mandiant’s guidance explains how organizations can safely use LLM agents for vulnerability management by combining AI with deterministic controls, human oversight, and strong operational guardrails. It also outlines where AI works best across enterprise vulnerability management and product security, while emphasizing risks such as prompt injection, supply chain poisoning, and unsafe automated remediation. #Mandiant #SAIF #RBVM #SLSA #MCP #CodeMender #CISA #SOC2 #PCI-DSS #FedRAMP #CMMC #EUAIAct
Keypoints
- AI agents can accelerate vulnerability discovery and remediation, but they must be deployed with structural guardrails and human oversight.
- The article recommends using established frameworks such as NIST AI RMF, OWASP Top 10 for LLMs, and Google SAIF to operationalize safe AI use.
- Security teams should treat codebases and third-party dependencies as untrusted inputs because indirect prompt injection can be embedded in source code comments or dependencies.
- Operational controls should include sandboxing, least privilege, ZDR agreements, red teaming, and strong observability to reduce blast radius and data leakage.
- Human-led threat modeling remains essential because LLMs lack full business context and can miss architectural vulnerabilities or misread stale documentation.
- For enterprise vulnerability management, AI should feed risk-based vulnerability management, exposure management, and remediation prioritization rather than replace existing controls.
- For product security, AI is most effective when paired with deterministic test harnesses, reproducible validation, and carefully scoped IDE or CI/CD remediation workflows.
MITRE Techniques
- [T1204 ] User Execution – The article notes that malicious instructions can be embedded so a model or operator follows them during analysis or remediation (‘hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables’).
- [T1059 ] Command and Scripting Interpreter – AI agents may generate and execute scripts or commands in sandboxes for testing and proof-of-concept validation (‘generate a fully reproducible, deterministic test harness such as a compiled binary or a Python test script’).
- [T1057 ] Process Discovery – Runtime observability and sandbox validation depend on monitoring what processes and actions are occurring during agent execution (‘monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production’).
- [T1601 ] Modify System Image – The article discusses agents writing patches and code changes through pull requests, which can alter deployed software (‘generate pull requests and commit code’).
- [T1195 ] Supply Chain Compromise – Third-party skills, MCP servers, dependencies, and orchestration frameworks are treated as supply chain risks (‘MCP plugins introduce the risk of supply chain poisoning’).
- [T1199 ] Trusted Relationship – The article warns that agents tied to human controllers and scoped identities must not be able to pivot into adjacent codebases through trusted access paths (‘tie back to human controllers to ensure accountability’).
- [T1027 ] Obfuscated Files or Information – Hidden instructions in comments or dependencies and malformed payloads are described as concealed or deceptive content (‘hidden instructions telling the agent to ignore vulnerabilities’).
- [T1005 ] Data from Local System – The article emphasizes preventing agents from accessing local sensitive data such as PII, PHI, and code artifacts (‘Agents should not be able to access personally identifiable information… or other sensitive data’).
- [T1041 ] Exfiltration Over C2 Channel – The runtime monitoring goal is to stop agents from sending internal context to unvetted external endpoints (‘ensure agents do not exfiltrate sensitive internal context to unvetted external endpoints’).
- [T1078 ] Valid Accounts – The discussion of service accounts, machine identities, and JIT tokens highlights the need to restrict credential use (‘distinct, strictly scoped machine identities’).
- [T1611 ] Escape to Host – Workload isolation and sandboxing are explicitly intended to prevent privilege escalation out of containers (‘robust sandboxing to prevent privilege escalation’).
- [T1484 ] Domain Policy Modification – The article references policy engines and guardrails that enforce execution constraints before model actions are allowed (‘Layer 1 deterministic policy engines acting as chokepoints’).
Indicators of Compromise
- [Model / tool names ] AI safety and remediation framework references – Model Armor, CodeMender, LangChain, AutoGen, Wiz
- [Security standards / controls ] governance and compliance context – SAIF, ZDR, SLSA level 3, SOC 2, PCI-DSS, FedRAMP, CMMC, EU AI Act
- [Vulnerability and exposure data ] prioritization and scoring context – CVEs, CVSS Base Score, EPSS, PASTA, FAIR, CMDB
- [Identity / access artifacts ] access-control and workload isolation context – FIDO2 MFA, ZTNA, IAP, JIT tokens, machine identities
- [Cloud / infrastructure terms ] deployment and sandboxing context – CI/CD runners, ephemeral compute infrastructure, RDP, SSH, SASE
Read more: https://cloud.google.com/blog/topics/threat-intelligence/ai-assisted-vulnerability-management/