On November 12, 2026, Wiz published part three of its ASPM-in-the-AI-era series, focusing on remediation speed. The post describes how Wiz Code maps cloud vulnerabilities back to repository owners, how the Green Agent drafts fixes with Security Graph context, and how Wiz Workflows tickets engineers in Jira, ServiceNow, Slack, or Teams.
The security-relevant addition for readers who run Claude Code, Codex, or similar harnesses is explicit: after the Green Agent produces a fix, Wiz can open a pull request or hand the same remediation context to your organization's coding agent so that agent opens the PR. That collapses triage and implementation into an automated path—which is exactly when local observability and hook policy still matter on developer machines.
Wiz's research team already showed how capable those harnesses can be offensively in Cyber Model Arena; this post is the defender-side mirror: using agents to close findings faster.
Parts one and two of the series (linked from the November 12 article) established centralizing AppSec signals and prioritizing attack paths with the Security Graph. Part three is deliberately operational: it assumes you already know which issues matter and asks how to close them in code before an AI-assisted exploit beats your patch queue.
TL;DR
| Question | Answer |
|---|---|
| What changed? | Wiz documents end-to-end ASPM remediation: ownership → Green Agent plan → PR or coding-agent handoff |
| Am I affected? | Organizations using Wiz Code plus allowed coding agents on repositories |
| Is there a patch? | Not applicable—this is product workflow design |
| Does data leave my machine? | Cloud ASPM data stays in Wiz; coding agents may read repo context you authorize for PR creation |
| What should I do? | Gate agent PRs behind review, log tool usage locally, and align cloud ownership mapping with actual teams |
How this differs from scanner auto-fix features
Standalone SAST products have shipped suggested patches for years. Wiz's pitch is cross-layer context: the same issue list is enriched with which cloud asset exposes the vulnerable code path, who committed the relevant change, and which scanner first saw the pattern. The Green Agent is not rewriting a single file in isolation—it is generating a plan that assumes defenders care about exploitability in production, not just CWE id on a line number.
That distinction matters when coding agents enter the loop. A harness told to "fix semgrep finding X" without cloud context might apply a superficial guard; Wiz claims the Green Agent's plan accounts for infrastructure linkage. The handoff still depends on the agent faithfully implementing that plan—something offensive benchmarks suggest is not guaranteed on hard tasks.
Remediation bottleneck Wiz describes
Wiz frames part one and two as visibility and attack-path prioritization. Part three argues the remaining gap is fixing at the speed AI enables both code generation and exploitation. The post cites industry patch-delay medians (47 days in Verizon DBIR, up from 32) and states that legacy timelines are inadequate when models compress discovery-to-exploit windows.
Three challenges Wiz lists:
- Knowing which developer owns a fix regardless of which scanner surfaced the issue.
- Delivering actionable context, not generic version-bump advice.
- Automating routing and follow-through where developers already work.
That third step is where coding agents enter the story.
Ownership mapping before any agent runs
Traditional scanners see repository names or container digests without org structure. Wiz claims agentless VCS integration traces a cloud asset to a specific repo and commit author, correlating tags, cloud logs, CMDB entries, service catalog mappings, and project ownership.
For the Green Agent, Wiz says ownership identification is the first automated step before generating a fix—routing issues to the person equipped to act under tiered ownership policies.
Accuracy here determines whether an agent later edits the right service—or churns on a forked dependency no one maintains.
Green Agent plans grounded in code-to-cloud context
Once ownership is assigned, Wiz argues standalone scanner fixes are too generic. The Green Agent produces multi-step remediation using Security Graph linkage between runtime posture and source, including imported findings from Snyk, Checkmarx, Semgrep, and similar tools.
Developers receive two options Wiz highlights:
- Create a Pull Request — Wiz generates the code change and opens a PR in the repository.
- Send to a Coding Agent — Wiz shares the Green Agent's remediation guidance with an organization coding agent such as Claude Code to create a PR for review.
Both paths assume humans still merge—but the agent may draft files, run tests, and iterate locally or in CI depending on how you wired the harness.
What Wiz still does not automate
The post focuses on happy-path remediation. It does not claim the Green Agent verifies that a merged PR actually removed cloud exposure, that IaC drift is gone, or that a container image rebuilt in CI matches what runs in production. Those gaps are where coding agents can still look productive—opening a version bump that does not redeploy the vulnerable service—while Wiz Workflows marks the Jira ticket resolved.
Security teams should define verification steps after agent or Green Agent PRs: rescan, runtime confirmation, and explicit ownership sign-off. That is parallel to how Beam treats hook denies: a blocked command is evidence, not proof that no other path exfiltrated data.
Comparative snapshot: manual vs Green Agent vs coding-agent handoff
| Stage | Traditional ASPM ticket | Green Agent PR | Coding-agent handoff |
|---|---|---|---|
| Ownership | Manual lookup or stale CMDB | Automated VCS correlation | Same plan, executed locally by harness |
| Fix quality | Generic scanner text | Security Graph–aware steps | Depends on harness tools and repo access |
| Review | Human engineer | Human merges Wiz PR | Human merges agent PR |
| Local audit trail | None on laptop | None on laptop unless you add one | Beam / logs on developer machine if fix ran locally |
Wiz Workflows and developer-native alerts
Wiz Workflows automates ticketing to Jira, ServiceNow, or other ITSM tools, plus Slack or Teams alerts. Tickets include third-party scanner context and the Green Agent plan so developers are not asked to log into a separate security portal for every task.
For agent security, the implication is volume: more auto-generated fixes and more agent-invoked edits increase the odds of subtle logic errors, dependency bumps with transitive risk, or credential snippets in commit messages. Pair cloud automation with the same MCP and dependency hygiene you expect from human developers.
What this means if you run AI coding agents
If Wiz (or any ASPM vendor) can push structured remediation into Claude Code or Codex:
- Treat the coding agent as a CI bot with repo write access. Require branch protection, mandatory review, and secret scanning on every agent-opened PR.
- Log locally what the harness did when it received Wiz context—tool calls, file paths, and network fetches are not automatically mirrored into Wiz's cloud narrative.
- Scope tokens so the agent cannot pivot from a Wiz-supplied fix into unrelated directories or production secrets.
- Compare cloud ownership mapping with
CODEOWNERSand team reality; misrouted agent PRs waste review time and can touch the wrong microservice. - Reconcile with kernel and host risk on machines where agents run tests—cloud ASPM does not patch Linux privesc chains on developer laptops.
Wiz is optimizing MTTR for cloud-backed AppSec. It does not replace deciding which tools a coding agent may call when a developer asks for an unrelated feature the same afternoon.
Policy questions to answer before flipping the switch
Document these before enabling coding-agent handoffs from Wiz:
- Which repositories may agents modify, and are forked libraries excluded?
- Which branches are in scope, and does the agent open feature branches or commit to default?
- Test execution: will the harness run
npm test,go test, or supply-chain scripts that need network? - Secret access: does the developer machine hold production
.envfiles in the same workspace the agent edits? - Rollback: who reverts a bad agent merge if Wiz already closed the cloud finding?
Answering them turns Wiz's automation from a black box into a governed pipeline—similar to enrolling laptops in agent monitoring before moving workspace policy from observe to enforce.
How Beam handles this
Beam is local-first observability and policy for coding agents on developer machines: hook-based PreToolUse deny for Claude Code and Codex when workspace policy is enforce, heuristic scans of skills and MCP configs, and on-device event retention with redaction. It does not open pull requests from Wiz tickets or map cloud assets to owners.
Where Beam fits: when Wiz hands remediation to Claude Code, Beam records what that session actually executed—file writes, shell commands, credential-shaped strings—on the laptop even if the PR looks clean in GitHub. That gives security teams an independent artifact for disputes ("did the agent run curl during the fix?").
Beam does not ingest Wiz Issues natively and does not block cloud-side workflow automation. Cached workspace policy can fail open if expired; enforce mode requires enrolled devices per agent monitoring docs.
Operators can also use Beam's offline skill and MCP scans on any remediation playbook the Green Agent exports to disk—if your process saves agent instructions as files before Claude Code runs—without waiting for cloud ticketing to close.
Related reading
- Wiz Cyber Model Arena offensive benchmarks — harness capability baselines
- OpenAI Codex security CLI — vendor-side agent security tooling
- AgentRun managed control plane — another pattern for centralized agent execution
- Recorded Future AI incidents and coding tools — incident trends across agent tooling
- CVE volume record and agent-assisted discovery — why faster fixes matter
Primary source: Wiz blog — ASPM in the AI Era Pt 3 (published November 12, 2026).
Frequently asked questions
Is the Green Agent the same as Cyber Model Arena?
No. Arena benchmarks offensive capability on isolated tasks. The Green Agent is a Wiz Code remediation workflow for real customer environments.
Which coding agents does Wiz name?
The November 12 post names Claude Code as an example organization coding agent for PR creation. It does not claim an exclusive integration list.
Do third-party scanner results flow into the agent handoff?
Yes. Wiz states automated tickets include context from connected scanners plus the Green Agent plan.
Can Wiz fix cloud misconfigurations without code changes?
The post emphasizes code fixes and PRs. Cloud-only issues may still route through ownership mapping, but the highlighted developer options are repository actions.
Does faster remediation reduce agent risk?
It reduces exposure window for known CVEs if patches land correctly. It can increase risk if agents merge unsafe fixes faster than reviewers catch them—governance must scale with automation.
Where does Beam store events?
On-device under the local collector data path; forwarding to a workspace is optional and best-effort per Beam docs.
Related reading: OpenAI Daybreak Defense Factory — another November 12 vendor path that automates patch agents with human merge gates.
Product capabilities described here follow Wiz's November 12, 2026 blog post; verify current Wiz Code documentation before changing production workflows.