Google Published the Defensive Roadmap. Here's What It Looks Like at the Infrastructure Layer.

✓ Human-authored analysis; AI used for formatting and proofreading.

Google Cloud's COO Francis deSouza and Mandiant published a defensive roadmap for the AI-accelerated vulnerability landscape. The core argument: AI-enabled adversaries can identify, chain, and weaponize weaknesses faster than traditional vulnerability management was designed to respond. The traditional window between disclosure and exploitation is gone. The traditional concept of severity is shifting. AI can chain low-level vulnerabilities into critical breach paths.

The roadmap has seven advanced modernization priorities and seven foundational steps. It's comprehensive. It's also almost entirely focused on patching, scanning, and runtime detection. The infrastructure configuration layer where blast radius is determined before any attack arrives gets one paragraph about "posture management" and a mention of Wiz.

That paragraph deserves an entire article, because the compound risk lives in the configuration layer.

Google's Roadmap Priorities vs. Infrastructure Reality

#	Google's Priority	What It Means	What Exists Today	What Stave Adds
1	Secure Your Code / CI/CD	CI/CD pipelines are attack targets — stolen credentials from build environments enable ransomware	Semgrep (code), TruffleHog (secrets), Wiz (cloud posture) — none detect long-lived CI/CD credentials composing with overprivileged roles	Detects long-lived AWS + AI-provider keys in CI/CD. Compound chains model the post-theft lifecycle: stolen key + admin role + no MFA = critical path
2	Automated Security Operations	SOC must operate at AI speed — manual triage can't keep up	Google SecOps, Splunk, CrowdStrike — runtime detection and response	Out of scope. Infrastructure verification is pre-attack, not runtime
3	Reduce Attack Surface	Segmentation + identity controls must limit blast radius when edge devices are compromised	Wiz (posture), Prowler (checks) — evaluate settings individually, not compositions	Compound chains prove whether dangerous states are reachable. Public IP + IMDSv1 + admin role = one critical chain, not three separate findings
4	Continuous Posture Management	Unidentified assets are a blindspot — static spreadsheets don't scale	Wiz, Prisma Cloud, AWS Config — continuous scanning but no input completeness reporting	stave readiness reports what % of infrastructure is observed. stave gaps names missing properties and what each unlocks, in priority order
5	Expand Scanning Coverage	Every OS, endpoint, and server must be scanned for vulnerabilities	Qualys, Tenable, Rapid7 — OS and network vulnerability scanning	Out of scope. Infrastructure configuration, not OS/firmware vulnerabilities
6	Secure AI Agents / SAIF	AI agents with elevated permissions create a new attack surface — fine-grained IAM is critical	Wiz (cloud posture for AI), Model Armor (prompt filtering) — no compound detection across agent + role + guardrail + logging	49 AI agent controls. Compound chain: broad execution role + no guardrail + no logging = one critical finding. Ghost detection for deleted Lambda functions agents still reference
7	Formalize Remediation SLAs	SLAs must be severity-based with emergency processes for active exploitation	Jira SLA tracking, Wiz ticket routing — no temporal context on findings	Time-aware evaluation: how long has this been misconfigured? Drift detection: what changed between snapshots? Observation freshness: is this data current enough to trust?

The gap: Google's roadmap acknowledges AI can chain low-level vulnerabilities into critical paths. No tool in the roadmap detects that chaining at the infrastructure configuration layer. Stave fills this gap with 711 compound chains across 129 AWS service domains.

Compound risk

Buried in the closing paragraph:

"The practical impact difference between a remote code execution flaw and a seemingly benign local-only exploit is rapidly disappearing."

This is Google acknowledging the compound risk problem. A local-only exploit means nothing in isolation. Combined with a misconfigured instance profile, a missing guardrail, and disabled logging, it means full breach. The severity of the individual vulnerability is misleading. The severity of the composition matters.

The roadmap's recommendation: use "AI-enabled scanning tools to detect groups of weaknesses that may appear minor on their own but could be chained together for exploitation."

That's compound chain detection. It exists. It ships in open source. Here's what it looks like at the infrastructure layer.

Priority 1: Secure your code — CI/CD as an attack surface

The roadmap says: "Security controls should cover build runners, CI/CD pipelines, and other automated execution mechanisms, which are increasingly attractive targets for threat actors."

Google's own GTIG report from last month proved why. TeamPCP compromised LiteLLM, an AI gateway library used in CI/CD pipelines, and extracted AWS access keys and GitHub tokens from build environments using the SANDCLOCK credential stealer. The stolen credentials were sold to ransomware groups.

The attack technique was a supply chain compromise. The blast radius was determined by a configuration property: were those CI/CD credentials long-lived access keys, or short-lived OIDC federation tokens?

If the pipeline used OIDC federation, the stolen credential expires in minutes. The attacker gets nothing useful. If the pipeline stored a long-lived AWS access key as a repository secret, the attacker has persistent access until someone manually revokes it which may never happen if nobody notices the theft.

One configuration property. One check. The difference between "contained incident" and "ransomware deployment."

Infrastructure verification detects this before the supply chain compromise. A control that fires when a CI/CD pipeline uses long-lived AWS access keys instead of OIDC federation catches the vulnerability while it's still a configuration choice, not a breach.

Extend this to AI-provider API keys. The same pipeline that stores AWS keys as long-lived secrets often stores Anthropic, OpenAI, or Gemini API keys the same way. The GTIG report described threat actors pooling stolen API keys through relay services. A control that detects long-lived AI-provider keys in CI/CD secrets catches the same pattern for a different credential type.

Now compose the two. A long-lived credential in CI/CD (the initial access vector) plus an admin-equivalent IAM role (the blast radius multiplier) plus no MFA on the role (the persistence mechanism). Three individually-rated findings maybe two highs and a medium. The compound: a single compromised dependency gives the attacker permanent admin access to the AWS account with no second factor and no rotation backstop. That's a critical compound chain, not three separate findings.

Priority 3: Reduce attack surface — blast radius containment

The roadmap says: "Network segmentation and identity-based access controls should be in place so that if an edge device is compromised through a zero-day exploit, the blast radius is limited and easier to contain."

This is the infrastructure verification thesis stated by Google. The zero-day itself is unknowable before disclosure. The infrastructure conditions that determine blast radius are knowable right now, on a static configuration snapshot.

An EC2 instance with a public IP, IMDSv1 enabled, and an admin-equivalent instance role is a compound chain. Any SSRF vulnerability in any application on that instance gives the attacker full AWS account access via the metadata endpoint. The individual settings might each pass their check: the public IP is intentional (it's a web server), the instance role has the permissions the application needs (it grew over time), and IMDSv1 was never disabled (it was the default when the instance launched).

Each setting passes. The composition is catastrophic. A compound chain that composes public reachability + SSRF-exploitable metadata + admin-equivalent credentials names the exact attack path and fires before any vulnerability is discovered.

The roadmap calls this "reducing attack surface." Infrastructure verification calls it "proving that dangerous states are unreachable." The distinction matters: reducing attack surface is aspirational (you try to minimize exposure). Proving unreachability is deterministic (the state is reachable or it isn't, and the proof is reproducible).

Priority 6: Secure AI agents

The roadmap says: "Locking down connections that AI systems can establish, with fine-grained IAM roles, is critical to prevent insecure plugin use threats."

This maps directly to the SAIF taxonomy's two risk categories:

Insecure Integrated Component (IIC): A compromised dependency or malicious skill gains access through the agent's elevated permissions. The GTIG report documented weaponized OpenClaw skills executing unauthorized code. The infrastructure question: what can the agent's execution role do?

Three configuration properties determine the blast radius of a compromised agent: execution role scope, guardrail presence, and invocation logging. When all three fail simultaneously — broad Lambda invoke permissions, no content-filtering guardrail, no audit trail — the compound effect is worse than any individual misconfiguration. The agent can invoke any function, access any data the role permits, and operate without triggering any alert.

A scanner checking each property independently reports three separate findings, maybe three highs. A compound chain that composes all three fires one critical finding that names the exact failure pattern: "This agent has broad reach, no content filter, and no audit trail. A compromised skill or prompt injection operates with full access and zero detection."

Rogue Actions (RA): An AI agent with elevated permissions executes unauthorized commands. The infrastructure check: does the execution role follow least privilege? Does the agent have permissions it doesn't need?

An agent execution role that can invoke any Lambda function in the account, read from any S3 bucket, and access secrets. That's overprivileged by definition. The agent only needs to invoke 2 specific functions and read from 1 bucket. The other 200 functions and 50 buckets are collateral damage if the agent is compromised. Permission scope controls detect this overprivilege on the static configuration, before any rogue action occurs.

Priority 4: Continuous posture management

The roadmap says: "Unidentified assets are a major blindspot for organizations. Static spreadsheets and manual asset tracking are no longer viable."

This is the input quality problem. Every verification tool's output quality depends on its input quality. If the collector didn't capture an asset, no control can evaluate it. If the observation is missing a critical property, the control that reads it silently doesn't fire. The silence looks like safety when it means "unchecked."

A readiness assessment turns silence into signal. Before running evaluation, the tool reports: "47 assets observed across 8 services. 66 services not in the snapshot. 88% of compound chains cannot fire with current input. The single highest-value action: add data_classification tags to 19 S3 buckets — unlocks 98 compound chains including PHI exposure detection."

A field-level gap analysis goes deeper: for each observed asset, which properties are absent, what controls and chains does each property unlock, and what's the priority order for adding them? "19 of 22 buckets lack data_classification. 35 of 35 IAM roles lack role-type tags. Fix these two gaps to unlock 143 compound chains (24% of detection capability). Estimated time: 30 minutes."

The roadmap says maintain a continuously updated inventory. Infrastructure verification says: know exactly what your inventory is missing, what it costs in detection capability, and what to fix first.

Priority 7: Remediation SLAs — time as a dimension

The roadmap says: "Define remediation SLAs based on severity, exposure, and asset criticality."

Most tools report findings without temporal context. "This bucket is public. Severity: High." Is it a new finding? Has it been public for 6 hours or 6 months? Did someone change it yesterday, or has it been this way since the account was created?

Time-aware evaluation tracks how long each misconfiguration has persisted. The same public bucket at 6 hours and 6 months tells different stories — different SLA urgency, different compliance exposure, different remediation priority. Drift detection compares snapshots and flags configuration changes: "This security group was restrictive yesterday and is open today." Observation freshness detects when the data itself is too old to trust: "These findings are based on a snapshot from 90 days ago."

The roadmap says formalize SLAs. Infrastructure verification says provide the temporal data that makes SLAs enforceable: when the misconfiguration started, how long it has persisted, whether it's getting worse, and whether your snapshot is current enough to trust.

Two tables, two questions

Google's GTIG report compares vulnerability discovery tools such as SAST, DAST, manual expert review, and frontier LLMs across flaw categories from memory corruptions to semantic logic flaws. That table answers: "Who finds the vulnerability?"

A second table answers a different question: "What determines the damage when it's exploited?"

Blast Radius Factor	SAST	DAST	Expert Review	Frontier LLM	Stave
Is the exploited service's role least-privilege?	❌	❌	⚠️ Sometimes	❌	✅
Does the credential rotate within its declared TTL?	❌	❌	❌	❌	✅
Is lateral movement blocked by segmentation?	❌	⚠️ Can test	⚠️ If scoped	❌	✅
Do multiple low findings compose into a critical path?	❌	❌	✅ Best at this	⚠️ Emerging	✅
Is the AI agent guardrailed if a skill is compromised?	❌	❌	⚠️ If scoped	❌	✅
Are deleted resource references cleaned up?	❌	❌	❌	❌	✅
Is the proof mathematical (SAT/UNSAT)?	❌	❌	❌	❌	✅

A frontier LLM discovers a hardcoded trust assumption in application code. The severity depends on the infrastructure underneath. An auth bypass on a service with a least-privilege role, rotating credentials, and audit logging is a contained incident. The same bypass on a service with an admin-equivalent role, stale credentials, and no logging is a full breach. The code vulnerability is identical. The blast radius is determined by the infrastructure layer.

The compound risk gap in the roadmap

The roadmap's seven advanced priorities are sound. They cover code security, automated SOC, attack surface reduction, posture management, scanning coverage, device patching, and AI agent security. Each priority is addressed by tools in Google's ecosystem. Wiz for posture, SecOps for SOC, Model Armor for AI agents.

What's missing is the layer between individual findings and compound risk. Every tool in the roadmap evaluates settings independently. The roadmap itself acknowledges that "AI can chain together multiple low-level vulnerabilities". But none of the recommended tools detect that chaining at the infrastructure configuration layer.

This is the gap compound chain detection fills. Not replacing any tool in the roadmap — complementing them. The scanner finds the individual settings. The compound chain detector finds the compositions that make those settings dangerous together. The scanner says "three highs." The compound chain says "one critical path from unauthenticated access to patient data through three individually-correct configurations."

The roadmap says the problem exists. The tools it recommends don't solve it at the infrastructure layer. The solution exists in open source.

What's out of scope

Infrastructure verification doesn't address four of the roadmap's priorities:

Automated Security Operations — runtime detection and response. Different product category. A Stave finding says "this configuration is unsafe." A SOC alert says "this attack is happening." Both are needed. Neither replaces the other.

Vulnerability scanning — code and OS-level scanning. Semgrep, OSS-Fuzz, Qualys territory. Infrastructure verification checks configurations, not code.

Network device patching — firmware updates for routers, switches, firewalls. Operational IT discipline, not configuration verification.

Model Armor / prompt injection defense — model-level safety. The model vendor's responsibility. Infrastructure verification checks whether a guardrail IS configured, not whether it IS EFFECTIVE against a specific jailbreak.

The honest scope: infrastructure verification addresses three of seven advanced priorities directly (CI/CD security, blast radius reduction, AI agent security) and provides temporal data for a fourth (remediation SLAs). The other three are different product categories.

The five-minute test

If you're reading the Google roadmap and wondering how your infrastructure stacks up on the compound risk dimension:

git clone https://github.com/sufield/stave.git
cd stave
bash examples/demo-ai-security/run.sh

The demo shows five AI agent findings composing into three CRITICAL compound chains. The exact failure pattern the roadmap's "Secure AI Agents" priority describes. Broad execution role + no guardrail + no logging = one critical compound, not three separate findings.

Then run the readiness assessment against your own data:

stave readiness --observations ./your-snapshots/
stave gaps --observations ./your-snapshots/

The readiness report tells you what percentage of your infrastructure Stave can evaluate. The gaps report tells you which missing properties to add first and what they unlock. Both run on static snapshots. No cloud credentials leave your machine.

Google published the defensive roadmap. The infrastructure configuration layer where blast radius is determined, where compound risk lives, where the proof that dangerous states are unreachable either exists or doesn't is the part of that roadmap you can verify today.

---

Stave is an open-source intent verification engine for cloud infrastructure. 2,650+ controls across 74 AWS service domains, 585 compound chains, 49 AI agent controls, 40 per-asset-type JSON Schemas, 9 independent reasoning engines. All analysis runs on air-gapped snapshots. Try it: bash examples/demo-ai-security/run.sh