How The Wiz Green Agent Investigates & Fixes Cloud Risk

A critical Issue was just discovered in an environment: an internet-facing container running an image with a known initial-access vulnerability, with a role attached that can reach sensitive data. 

With AI speed reducing the time from discovery to exploitation, the pressure to fix it fast is intense. Yet remediation is never just about speed. Teams are forced to balance security urgency with business continuity, racing against the clock to answer three critical questions: what’s impacted, what the fix is, and who to send that fix to.

The Wiz Security Graph helps security teams answer the first question. It lays out the exact exposure path including the exposed endpoints, the deployment behind them, the image where the CVE sits, and the lateral movement path that carries an attacker from code execution to buckets holding PII.

Finding the fix and the owner, however, requires deeper investigation that security teams can’t spend hours on. They must rapidly contact the developer to deploy a fix, if it even exists, and apply mitigations in the meanwhile without disrupting production uptime.

That’s what we built Green Agent for. In this post, we’re excited to pull back the curtain and share how Green Agent investigates this exact Issue in minutes and determines the remediation strategies it recommends.

The Investigation

1. Understanding the Issue

Green Agent started by ingesting the Security Graph context to map the full attack path. This Issue represented a toxic combination centered on a single Kubernetes deployment in an AWS EKS cluster.

The Security Graph correlated five distinct risk types converging on this single workload:

1. External Exposure: A direct network path from the internet to the container.

2. Vulnerability: A known initial-access CVE-2026-111497 on the container image.

3. Insecure Kubernetes Cluster: A pod mounting a service account token to bridge into the cloud.

4. Unprotected Principal: An IAM role granting the workload access to cloud storage.

5. Unprotected data: Sensitive customer records residing in those accessible buckets.

Five risk types meant five distinct places where the attack chain could be broken – whether by removing the public exposure, patching the container image, unmounting the service account token, scoping down the IAM role, or purging the sensitive data.

Before it could recommend how to break the chain without disrupting production uptime, Green Agent needed to validate the ground truth behind each risk factor. It began investigating the attack path step-by-step, starting at the perimeter.

2. Validating Exposure: Is the Front Door Really Open?

Before recommending a fix, Green Agent needed to determine whether network containment was even an option. Many cloud workloads appear public in configuration tables but are actually shielded behind internal subnets, VPNs, or closed security groups.

Green Agent traced the full inbound route from 0.0.0.0/0:

• The Ingress Route: Traffic flowed from the public internet through an AWS Internet Gateway, routed across an AWS Network Load Balancer, passed through the Traefik Ingress controller, and directly into the application’s main container.

• Unauthenticated Access: Both HTTP (port 80) and HTTPS (port 443) served public endpoints returning unauthenticated 2XX status codes.

• No Perimeter Defense: Green Agent inspected the hops and confirmed no Web Application Firewall (WAF) or firewall rules were in place.

This established a critical operational boundary for remediation. Because this frontend was an intentionally public production service, simply pulling the network plug – like tearing down ingress or blocking the load balancer – would cause a total production outage. Any network-level remediation plan from Green Agent would need to preserve uptime, such as introducing authentication middleware rather than severing traffic entirely.

3. Assessing Exploitability: Is the Vulnerability Running in Memory?

With the front door confirmed open, Green Agent moved to the next link in the attack chain: the vulnerability risk factor, to evaluate whether the attack path could be severed at the application layer.

It investigated the container image flaw: CVE-2026-111497 (“Broccoli2Shell”), a critical RCE in the Brotli decoder bundled with Node.js and cataloged in CISA’s Known Exploited Vulnerabilities (KEV).

It confirmed from the Wiz Sensor that the vulnerable Brotli libraries were actively loaded in memory by the running Node.js process, verifying that code execution was a live, viable threat.

Green Agent also checked upstream advisories and verified that vendor patches (including Node.js 22.23.4 and libbrotli 1.2.1) were already available, confirming a permanent code fix was viable.

However, organizational release processes mean that rolling out a new container image through testing and CI/CD pipelines takes time. Because the attack path can be broken at any of the five risk types, Green Agent turned to the remaining links – the Kubernetes configuration, IAM role, and sensitive data – to see if the toxic combination could be severed immediately in the cloud.

4. Evaluating Cloud Identity & Data: Can the Cloud Path be Severed?

Investigating the workload’s connection to cloud storage, Green Agent evaluated the three remaining risk types:

• The Cluster Remediation Lever (IRSA): Green Agent examined the Kubernetes service account and confirmed it projected cloud credentials via IRSA into the container. This revealed an immediate mitigation lever: disabling token automount on the pod spec to cut off cloud access.

• The IAM Remediation Lever: Inspecting the assumed IAM role, Green Agent found overprivileged s3:GetObject and wildcard s3:* permissions across three S3 buckets. This surfaced a second lever: scoping the IAM policy down to least privilege.

• The Data Remediation Lever: Querying the S3 buckets revealed over 5,000 unmasked records (credit cards and PII) in files, identifying a third remediation lever: purging or masking unprotected data at rest.

Investigating these layers proved that Green Agent didn’t have to wait on a code deployment to neutralize the risk. Multiple zero-downtime levers were available in the cloud right now.

5. Code-to-Cloud Lineage: Finding the Source and Owners

Cloud mitigations can sever the attack path immediately and buy critical time, but permanent remediation requires fixing at the source. If changes aren’t committed to code, the next CI/CD build or Terraform apply will simply overwrite your cloud tweaks and recreate the issue. Green Agent called its Code Subagent to bridge the runtime assets back to version control, tracing the container image to its source Dockerfile, the overprivileged IAM role to its Terraform definitions, and the workload to its GitOps deployment manifests.

By inspecting commit history and metadata, Green Agent connected each fix directly to the engineers who actually maintain the code: the application developer, service owner, and infrastructure lead so security teams didn’t have to go on a search for the right owner.

6. Determining a Verdict and Creating Remediation Plans

Within minutes, Green Agent analyzed organizational context to reach a verdict that this Issue needed to be remediated and is of Critical severity. Green Agent factored in real business impact: the workload belonged to High Business Impact (HBI) production projects, formed an active breach path to 5,000+ sensitive records, and aligned with historical remediation evidence showing 100% of similar sampled issues in the subscription were successfully remediated with a 0% rejection rate.

To break the toxic combination, Green Agent determined that Mitigate and Fix plans were most appropriate to break the risk types identified, balancing immediate protection against permanent resolution:

• Mitigate Plans: Immediate actions security teams can deploy right now to reduce the risk, like disabling service account token automount to instantly sever cloud access while developers work on the code fix.

• Fix Plans: Permanent root-cause resolutions, like updating the base image in the Dockerfile or scoping down Terraform IAM policies.

Just as importantly, Green Agent evaluated operational trade-offs to skip unviable strategies: it explicitly rejected deleting the ingress because severing an intentionally public frontend would cause a total production outage, and skipped long-term hardening where environment prerequisites weren’t in place.

Finally, Green Agent turned planning into execution by assigning each plan directly to its verified owner, ready to resolve via a one-click pull request or by handing instructions straight to a coding agent.

Why this Matters

Green Agent brought two things to this remediation that are notoriously difficult to balance in security: addressing security urgency, and maintaining the context needed to protect business continuity.

First, speed. With risks and threats moving faster than ever, security urgency demands an immediate response. A human team investigating this toxic combination would spend hours or days context-switching: security analysts verifying the public endpoint, platform engineers checking if the Brotli library is actually in memory, cloud admins auditing IAM policies, and developers tracking down which Git repository built the image. Green Agent conducted this investigation in minutes, eliminating the friction and guesswork that typically stalls remediation.

Secondly, operational intelligence. Remediation isn’t only a security team problem, it’s an organizational decision that requires understanding real-world trade-offs. Green Agent knew better than to propose deleting the ingress and taking down a public service that would impact the business. Instead, it distinguished between immediate, zero-downtime cloud mitigations and permanent code fixes, found the exact files in version control, and assigned the work directly to the engineers who own them.

That balance is how organizations can move towards autonomous remediation. Trust has to be earned before teams hand over the keys to auto-execution. That trust is built on context: when engineers see that an agent genuinely understands business trade-offs and won’t break production, they can safely evolve from reviewing every action (human-in-the-loop) to supervisory oversight (human-on-the-loop).

That progression is what finally enables teams to get on a path to self-healing, while giving engineers their time back to keep building.