Google Cloud issues guardrails for AI vulnerability agents

Google Cloud has published guidance from Mandiant Consulting on using AI agents in vulnerability management.

The document outlines a framework for security teams that want to deploy large language model agents in code repositories, development environments and software delivery pipelines without giving them unchecked access to sensitive systems or data.

It argues that growing interest in automated vulnerability discovery and remediation reflects a wider problem: attackers are exploiting software flaws faster than many organisations can patch them. Google cited Mandiant research showing that mean time-to-exploit has fallen to minus seven days, indicating that some vulnerabilities are abused before a patch is available.

Guardrails first

The guidance urges companies to apply established risk frameworks to AI security work and extend existing deterministic controls to any environment where an AI agent operates. It also recommends treating source code as untrusted input, warning that prompt injection could be hidden in comments or third-party dependencies.

Key controls include using non-production environments with synthetic data for testing, strictly isolating agent workloads in unprivileged containers, issuing short-lived machine credentials tied to specific repositories and branches, and red-team testing agents before broad deployment.

Google also advises companies to seek zero data retention terms from model providers so proprietary code and discovered flaws are not used to train external models. The paper adds that runtime logging and monitoring are needed to detect whether an agent sends sensitive internal context to unapproved destinations.

Human oversight

A central argument is that AI systems remain weak at understanding business intent and architectural context, even when connected to internal documentation through retrieval tools. According to the paper, stale or contradictory documents can lead a model to produce confident but inaccurate conclusions about how systems work in production.

Mandiant therefore advises organisations to keep human-led threat modelling in place before and after systems are built. The goal is to identify deeper design flaws, such as overbroad permissions between services, that an automated scanner may miss while focusing on code-level defects.

The guidance divides AI-assisted vulnerability management into two broad areas: enterprise vulnerability management for commercial software and infrastructure, and product security for first-party code. In both cases, AI should complement traditional controls rather than replace them.

Managing volume

For enterprise vulnerability management, the paper notes that security teams already face more findings than they can process, and that new AI-driven discovery tools could add to that burden. It recommends normalising and deduplicating findings from external attack surface management, cloud posture tools and exposure management systems before feeding them into a risk engine.

That engine should combine three factors: the technical severity of a vulnerability, the importance and exposure of the affected asset, and the current threat context, including whether attackers are actively exploiting the issue. The result should guide remediation priorities and service levels, though compliance mandates may still override internal scoring.

The guidance also calls for stronger containment measures based on zero trust principles. These include identity-aware access controls, load balancer and gateway inspection for public-facing applications, stricter software supply chain checks, ephemeral build infrastructure and short-lived credentials instead of static secrets.

Code security limits

On product security, Google distinguishes between deterministic tools such as static and dynamic application security testing and probabilistic AI models. It says language models can be effective at spotting localised issues such as hardcoded secrets or outdated dependencies, but often struggle to track logic across large or fragmented codebases.

The paper says AI agents work best where there is a clear binary test for success, such as a crash in memory-unsafe software written in C or C++. It is more cautious about using the same approach for business logic flaws, authorisation errors and indirect request forgery, where confirmation often depends on architectural context rather than a simple pass-or-fail result.

To limit false positives, the guidance proposes a routing system in which an agent must generate a reproducible test harness and prove its finding in an isolated sandbox before a human reviews the issue. If the exploit attempt fails, the ticket should be discarded. If it succeeds, an engineer should assess reachability, impact and whether the flaw matters in the wider threat model.

That approach changes rather than removes the role of security staff. Teams still need experienced practitioners to validate AI-generated findings, review proposed fixes and guard against false negatives where the model fails to identify a real weakness.

Remediation controls

For automated remediation, Google describes two operating models: local assistance in the developer's coding environment and centralised review in the delivery pipeline. It says the former is better suited to narrow, syntax-level changes, while the latter should be limited to generating pull requests that then go through regression testing, proof-of-fix validation and human approval.

The paper adds that post-deployment controls remain necessary even after testing. It recommends automated rollback mechanisms, model version pinning to reduce the risk of drift, and immutable audit logs recording which model proposed a fix, what tests were run and who approved the change.

In its final assessment, Google says AI can help tackle technical debt and speed some forms of vulnerability discovery, but it does not remove the need for secure system design, deterministic controls and human judgement. It also argues that the recent rise in AI-assisted discovery of memory corruption flaws should push organisations towards memory-safe languages over time.

"LLMs augment discovery, but they do not guarantee exhaustive coverage."