From CNAPP to AI-APP: How the Wiz Platform Changed

What CNAPP covered, and where it stopped

Gartner named the CNAPP category in 2021 for platforms that bundled posture management, workload protection, entitlement analysis, and infrastructure-as-code scanning (CSPM vs CNAPP covers the pieces). The defining idea was context: a graph of resources, identities, network paths, vulnerabilities and data, so that "public, vulnerable, over-privileged and holding customer data" shows up as one problem instead of four tickets.

That graph described the estate as it stood. It had three blind spots, and they are the three things the newer platforms join to it:

• Where a resource came from. A misconfigured bucket was found in the cloud, but a Terraform file in someone's repository created it. The finding landed on a security team that could not fix it, and the fix had to be made in code by someone who never saw the finding.
• What was happening to it. Posture is a snapshot of risk. Whether anyone was exploiting that risk lived in a different tool, usually a SIEM run by a different team, which saw log lines without the graph's context.
• Where the credentials started. Cloud intrusions often begin on a developer's machine, as in the CircleCI and LastPass incidents. The laptop belonged to the endpoint team and sat outside the cloud graph entirely.

CNAPP vs XDR describes the categories converging in general. This page looks at one platform's version of it in detail.

The two meanings of "AI" in AI-APP

Wiz announced AI-APP in March 2026 and, in its launch post, calls it "the natural evolution" of CNAPP. The "AI" in the name carries two meanings, and it helps to keep them apart:

• AI as something to protect. The platform inventories AI applications built on the managed AI services of AWS, Azure, and Google Cloud, on SaaS platforms such as OpenAI and Microsoft Copilot Studio, and in custom code. It classifies what each agent's tools can do (read data, run code, call APIs, change infrastructure), and it watches model inputs and outputs, agent tool use, and the identities agents act as, for threats such as prompt injection. The AI/ML security and MCP security pages cover this territory.
• AI as something that does the work. The Red, Green, and Blue agents described below use language models to test, fix, and investigate, working from the platform's graph.

For cloud security teams in general, most of what is new sits in the joins and in the second meaning, so that is where this page spends its time.

Join one: source code and pipelines

The platform connects to version control the way it connects to a cloud account. Wiz documents GitHub, GitLab, and Azure DevOps repositories (July 2024), and the code product, Wiz Code, was introduced in September 2024. Once a version control system is connected, four things become possible that a cloud-only tool cannot do.

Scanning before production

Repositories are scanned for vulnerable open-source dependencies, infrastructure-as-code misconfigurations, exposed secrets, sensitive data, and malware, with results shown in pull requests and the IDE. Static analysis of first-party code arrived in public preview in December 2025 (announcement). Since April 2026 the platform also reads GitHub Actions workflow files for excessive permissions and dangerous triggers such as pull_request_target, the misconfiguration behind recent supply-chain attacks (announcement; see GitHub Actions security).

Tracing code to cloud

The platform links a repository to the image it builds and the workload that image runs as, so a vulnerability in a running container traces back to the Dockerfile, repository, and commit that introduced it, and a code finding can be ranked by whether that code actually runs somewhere exposed. Wiz says it builds this lineage from repository, registry, and image analysis, "with no tagging, no CI/CD changes, and no dependence on developer hygiene" (October 2025).

Finding the owner

Every finding needs a person. For a leaked secret, for example, the platform links the finding to the commit author, falls back to CODEOWNERS files and the mapping of GitHub users, and hands off to the repository's maintainers when the author has left (August 2025). Ownership is what turns a cloud finding into a ticket or a pull request for a named developer, rather than an item in a security team's queue.

Fixes as pull requests

Because the platform knows which file produced a resource, it can propose the fix where the fix belongs: a suggested change in the pull request, or a generated pull request against the repository. Remediation moves from "security files a ticket from the cloud console" to "the owner reviews a diff", which is how developers already work.

Join two: logs, runtime, and the SOC

The detection product, Wiz Defend, analyzes cloud and SaaS logs alongside runtime signals from an eBPF-based sensor that runs on VMs, containers, and serverless containers (product page), and it ingests the audit logs of supported version control platforms, with built-in detections for attacks on repositories and pipelines (August 2026). Detections are correlated against the same graph that holds posture and code. Since August 2026, findings are also enriched with Google Threat Intelligence, which draws on Mandiant and VirusTotal data (announcement).

The correlation is the point. A log-only detection says an access key listed buckets from an unfamiliar address. The same detection on the graph also knows which identity the key belongs to and what it can reach, which of those buckets hold sensitive data, whether the workload involved is internet-facing, which repository deployed it, and who owns that repository. The analyst starts with the answers a senior responder would otherwise spend the first hour assembling.

When the sensor fires on a workload, it can also collect a forensics package at that moment: the triggering script or binary, the process tree, shell histories, SSH configuration, the container's drift layer, and system logs (May 2026). Evidence gathered at detection time survives a container that is gone by the time anyone looks.

The sensor is not limited to the public cloud. In August 2025 Wiz announced, in public preview, sensor-based scanning for VMs in private clouds such as VMware and OpenStack, self-hosted Kubernetes, and bare-metal and edge hosts (announcement), so on-premises servers can sit in the same graph as cloud workloads.

None of this makes the platform a SIEM replacement by default. Detections also flow out to existing SIEM and SOAR tools (Google SecOps, for example, documents a Wiz integration), and log retention, non-cloud sources, and compliance storage are questions to settle for your own environment. The cloud SOC covers how those pieces usually fit.

Join three: developer workstations

In August 2026 Wiz announced a sensor for developer workstations, in private preview for Windows and macOS and deployed through existing device management (announcement). It inventories the packages, secrets, IDE extensions, AI coding agents, and MCP servers on each machine. It detects known-malicious packages and suspicious behavior, such as a postinstall script spawning an unexpected process or a secrets scanner reading credential files, and it can kill the process, collect forensic artifacts, and rotate or revoke exposed credentials.

The reason to put a laptop in a cloud graph is reach. A developer's machine holds cloud credentials, package-publishing tokens, and access to source code, and AI coding agents now act with those same credentials. Once the machine is a node in the graph, "this laptop ran a malicious package" becomes "these credentials, which can reach these production resources, were exposed", which is the question responders need answered. The Shai-Hulud npm worm is the case study: its install script ran TruffleHog against the developer's own machine and used what it found to spread.

Private preview means this is a direction, not something to plan around yet. It also raises questions an agentless cloud scanner never did; see what to be skeptical of.

The agents: Red, Green, and Blue

Wiz announced three agents in March 2026, each working from the graph above, plus Workflows, a builder that decides when an agent acts on its own and when a human approves. The status column reflects Wiz's own posts as of the date at the top of this page.

The five verdicts

Blue Agent closes an investigation with one of five verdicts, Malicious, Security Test, Planned Action, Not Malicious, or Inconclusive, each with a confidence level (Wiz). Two of those matter most to a SOC. Cloud alerts often turn out to be an authorized test or an engineer making a change, and "Security Test" and "Planned Action" give that work names of its own instead of forcing it into "false positive". Planned actions are also where the code join pays off: the code-analysis sub-agent correlates runtime behavior with source code and recent pull requests, to tell an application doing what it was written to do apart from an attacker (announcement).

A verdict is bounded by the evidence behind it. In Wiz's own example, the same detection reads "Low Confidence, Inconclusive" without a forensics package and "High Confidence Malicious" with one (May 2026). Where the sensor is not deployed, the agent reasons over less, and its confidence should drop to match.

Wiz describes routing by confidence: high-confidence containment can run automatically, while lower-confidence decisions go to a person through Slack, Jira, ServiceNow, or similar tools. Where to draw that line is the customer's decision, and it is the most consequential setting on this page.

A worked example

This is an illustration of how the joins are meant to compose, not a recorded incident, and its first step depends on the workstation sensor, which is in private preview. It follows the shape of the Shai-Hulud worm.

1. Workstation. A developer installs a package whose postinstall script runs a secrets scanner over the home directory. The workstation sensor flags the behavior, kills the process, and records which credentials were on the machine: a GitHub token and an AWS access key.
2. Graph. The graph already knows what those credentials reach. The token can push to forty repositories; the access key can assume a role that reads a bucket of customer data.
3. Version control. The VCS audit log shows the token adding a new GitHub Actions workflow to one of those repositories a few minutes later.
4. Cloud. CloudTrail shows the access key listing buckets from an address the account has never seen.
5. Blue Agent. Instead of three alerts in three tools, the investigation opens with all four signals tied to one developer, one token, one key, and the resources at risk. It returns Malicious with high confidence and shows its reasoning.
6. Workflows. The playbook revokes the token and deactivates the key. Whether that happens automatically or waits for a person is the setting described above.
7. Green Agent. It picks up the related posture issues, such as other workflows whose declared permissions are broader than they need, works out each owner, and proposes pull requests to narrow them.

Each step exists in some separate tool today. The difference is that the endpoint team, the cloud security team, the SOC, and the repository owners would each have seen one piece, and connecting them would have depended on someone noticing.

Not only Wiz

The same convergence is happening across the market, which is a better reason to understand it than any one product. Three examples, from the vendors' own announcements:

• Palo Alto Networks introduced Cortex Cloud in February 2025 as the next version of Prisma Cloud, merging its CNAPP with cloud detection and response on the Cortex platform beside its Cortex XSIAM SOC platform. Palo Alto describes this as a third wave of CNAPP, spanning "code to cloud to SOC".
• CrowdStrike correlates application code analysis with cloud entitlements in Falcon Cloud Security (July 2026), and in September 2026 announced multi-agent investigations across endpoint, identity, SaaS, cloud, and network that return a verdict with staged response actions, at an autonomy level each customer sets per workflow.
• Microsoft made the integration between Defender for Cloud and GitHub Code Security generally available in June 2026, enriching code findings with production context such as internet exposure and data sensitivity and generating fixes through GitHub Copilot, and announced discovery of local AI agents and MCP servers on developer machines (Build 2026).

The starting points differ, and a starting point shapes what is deep and what is thin. Palo Alto starts from a SOC platform, CrowdStrike from an endpoint agent, Microsoft from owning a cloud, an identity provider, and GitHub, and Wiz from an agentless cloud graph. Whichever side a platform grew from, test hardest on the side it grew into. The vendor landscape lists many more companies working on parts of the same problem.

What to be skeptical of

None of these are reasons to avoid the approach. They are the costs a launch post leaves out, and most apply to any platform built this way.

The platform becomes a crown jewel

To do what this page describes, one system needs read access to every cloud account, every repository, the audit logs, and, with the workstation sensor, every developer laptop. To open pull requests or run containment it also needs write access. That makes the platform one of the most valuable targets in the estate. Ask which permissions each connector needs, whether write access can be granted separately and limited to specific repositories or actions, where source code is processed and stored and for how long, whether customer code or data trains any model, and how tenants are isolated. Then review those grants as you would any non-human identity with that much reach.

A verdict is a probability

An agent that sorts detections into five verdicts will sometimes be wrong, and the errors do not cost the same. A false Malicious costs an analyst some time; a confident Not Malicious that closes on its own can cost a breach. Until you have measured how often the agent agrees with your analysts on your own data, keep closure and containment behind human approval, sample closed verdicts every week, and read the reasoning rather than the label. Coverage gaps become confidence gaps, as Wiz's own forensics example shows.

Ownership is only as good as your metadata

Routing a fix to its owner depends on commit history and CODEOWNERS files that reflect reality. Stale entries send fixes to teams that no longer own the code or to people who have left, and a fallback to the repository maintainer lands everything on whoever that is. Owner mapping rewards repository hygiene; it does not replace it.

Workstation monitoring is employee monitoring

A sensor that inventories every package, extension, AI tool, and secret on a developer's machine is collecting data about a person's work. Tell developers what it collects and why before it ships, check works-council and privacy obligations where they apply, decide how long the data is kept, and work out how it coexists with the EDR agent already on that machine.

Autonomous testing needs scope and permission

An agent that probes internet-facing applications for exploitable flaws is doing penetration testing. Confirm that it targets only assets you own, that your contracts and your cloud providers' testing policies allow it, and that the SOC knows it is running. The Security Test verdict exists so that authorized testing is not mistaken for an attack, which only works if the two are wired together. Cloud pentesting covers the ground rules.

Consolidation trades seams for concentration

One platform removes hand-offs between tools and teams, which is where many investigations used to stall. It also means one vendor's blind spot becomes yours, one outage affects posture, detection, and response at once, and leaving gets harder with every workflow you build. Some teams keep an independent detection source, such as the cloud provider's own threat detection or a separate SIEM rule set, for exactly that reason.

Ownership of the vendor matters too. Google completed its acquisition of Wiz in March 2026 and said that Wiz products "will continue to work and be available across major clouds" (Google's announcement). If you run mainly on AWS or Azure, that commitment is worth tracking over time, as it would be for any security product a cloud provider owns, Microsoft's Defender for Cloud included.

The name belongs to a vendor

CNAPP came from an analyst firm. AI-APP came from Wiz, and Palo Alto, CrowdStrike, and Microsoft describe overlapping scope in their own terms. Expect the labels to keep moving, and, as CNAPP vs XDR puts it, buy for outcomes rather than acronyms.

Questions to ask any vendor

These apply to Wiz and to every platform that claims to join code, cloud, and the SOC. Ask for the answers in a trial on your own environment, not on a slide.

1. Which version control, CI, and cloud platforms are supported today, and which features are generally available rather than in preview?
2. What permissions does each connector need? Can write access (pull requests, containment) be granted separately and narrowly?
3. Where is source code processed and stored, for how long, and does it train any model?
4. For each agent verdict, can I see the evidence and the reasoning, and export both for an audit or a post-incident review?
5. What can an agent do without a human approving it, and who in my organization sets that?
6. How do you measure agent accuracy, and how can I measure it on my own data during the trial?
7. Which logs do you ingest, how long are they kept, how are they queried, and what do you forward to my SIEM?
8. How are owners resolved, and what happens when an owner has left or a CODEOWNERS entry names a group?
9. For endpoint sensors: what is collected, what is not, and what can the sensor do on the machine?
10. If we leave, what can we export, including workflows and investigation history?

Author's note