The Authorization Gap, Quantified: What Wiz's State of AI in the Cloud 2026 Tells Every CISO

Executive Summary

Wiz Research just published State of AI in the Cloud 2026, drawing on telemetry from hundreds of thousands of cloud environments. The headline numbers are striking on their own: at least 81% of organizations now use managed AI services, at least 90% run self-hosted AI software, 57% have deployed self-hosted AI agent technologies, and Model Context Protocol (MCP) servers appear in at least 80% of cloud environments — with 5% of those exposed directly to the internet.

But the strategic takeaway for security leaders is not the adoption curve. It is what sits underneath it. Wiz's data describes an attack surface that has expanded faster than the controls designed to govern it. Every figure in their report points to the same structural problem: enterprises have inherited a sprawling, fragmented, often invisible AI footprint — and the runtime authorization layer needed to govern that footprint does not yet exist in most environments.

EnforceAuth has called this the Authorization Gap since the company's founding. Wiz's report quantifies it. This brief translates the research into the boardroom-ready framing every CISO needs: what changed, what it means for risk, and what enforcement actually looks like — including a concrete look at the policy code that closes the gap in production.

AI security is not a future discipline. It is an extension of cloud security that must account for autonomy, automation, and the rapid spread of AI-driven systems. — Wiz Research, State of AI in the Cloud 2026

1. The Numbers That Should Reset Every Board Conversation

AI is no longer a pilot or a proof of concept. According to Wiz, it now functions as operational infrastructure across nearly every dimension of the cloud stack. The most important figures for security governance are not the high-level adoption rates — they are the ones that describe how AI capabilities enter the environment in the first place.

Figure 1. Two years of telemetry tell one story: AI is no longer adopted, it is accumulated. Source: Wiz Research.

Adoption is widespread. Visibility is not.

• 81% of cloud environments use managed AI services.
• 90% run self-hosted AI software.
• 63% self-host AI models.
• 68% of those self-hosters acquire models transitively — bundled inside third-party software they did not realize was AI-enabled.
• 18% run AI exclusively through these transitive components, meaning many security teams are operating self-hosted AI without knowing it.

The transitive figure is the one that should land hardest with a board. Nearly two-thirds of self-hosted AI is arriving inside the supply chain. CISOs are being asked to govern systems their procurement teams did not flag, their architecture review boards never saw, and their identity governance programs never enrolled. This is not a hypothetical risk. It is already inside the perimeter.

Development workflows have already shifted.

Wiz observes that at least 80% of organizations have developers running AI IDE extensions and at least 71% have at least one AI coding assistant present in their environment. GitHub's own data, cited in the report, shows 80% of new developers adopting AI coding assistants within their first week on the platform. External research suggests AI agents now participate in up to 10% of public pull requests.

The implication is that AI is no longer just consumed by an enterprise — it is producing code inside the enterprise. And when generation patterns are fragmented across dozens of assistants and largely unguided, the same insecure defaults replicate across projects. Wiz reports that roughly one in five organizations using AI-powered vibe-coding platforms had applications affected by systemic security weaknesses. Not isolated bugs — repeatable, structural ones.

When AI-generated code, configurations, and access patterns are repeated across projects, small mistakes become systemic weaknesses rather than isolated defects.

Agents and MCP servers are the new control plane.

57% of organizations have deployed self-hosted agent technologies. MCP servers — the connective tissue that lets agents reach tools, data, and APIs — appear in 80% of cloud environments, with 5% directly internet-facing. These are not pilot deployments. They are production orchestration layers, and they have spread faster than any meaningful governance pattern has emerged to control them.

What Wiz cannot tell you, because their tooling is not designed to enforce it, is what those agents are actually allowed to do. That is the gap.

From the CEO · Mark Rogge

I spent the better part of a decade — at GitLab, Weights & Biases, and as CRO at Styra before Apple acqui-hired the team — watching enterprises wire authorization into applications one at a time, by hand, in code. The pattern was always the same: every team built their own permission checks, every check drifted from policy over time, and every audit became an archaeology project.

When the agentic AI wave hit, that pattern did not just continue. It accelerated by an order of magnitude. The number of identities that needed authorization decisions exploded. The number of teams provisioning those identities exploded. The window for a human to review any of it disappeared.

The Wiz report is the first piece of third-party research that quantifies what we have been arguing since EnforceAuth's first whiteboard session: the AI era did not invent a new security problem. It exposed the inadequacy of a control we have been deferring for twenty years.

2. Why Wiz Sees the Surface but Cannot Close the Gap

Wiz's report is the most comprehensive picture of cloud AI exposure available today. The data is sound, the framing is sober, and the recommendations are right. But the report itself is honest about what it describes: the size and shape of the attack surface, not the runtime controls that determine whether that surface is exploitable.

This is the structural distinction CISOs need to internalize, because it is also the reason a CNAPP dashboard alone — Wiz, Orca, Palo Alto Prisma Cloud, or any of their peers — does not solve the problem the report describes. CNAPP is the visibility layer. EnforceAuth is the enforcement layer. They are complementary, not competitive, and a mature AI security program needs both.

Figure 2. CNAPP tells you the inventory. Runtime authorization governs the actions. They are not substitutes.

Visibility tells you the inventory. Enforcement governs the actions.

A cloud security platform can tell you that an MCP server exists, that an agent is running, that a service account has broad IAM privileges, and that a model is deployed behind an unauthenticated endpoint. That is the visibility layer, and it is essential. But none of those findings, by themselves, prevent an agent from calling a tool it should not call, accessing a record it should not access, or executing an action a human user would never have been authorized to take.

The runtime decision — should this identity, in this context, be allowed to take this specific action right now — is an authorization decision. It happens millions of times a day in a modern enterprise, across human users, service accounts, API tokens, and now AI agents. That decision layer is what Wiz's report keeps pointing to without naming. Every recommendation in their final section turns out to be an authorization problem in different clothing.

Figure 3. Each Wiz recommendation, translated into the runtime authorization control it requires.

These are the four pillars of a unified runtime authorization fabric. Wiz describes the symptoms accurately. The treatment lives one layer down.

The Authorization Gap, defined.

EnforceAuth defines the Authorization Gap as the structural distance between AI safety controls — content filters, alignment, behavioral guardrails — and AI security controls — runtime authorization, action-level enforcement, audit-grade logging. Most enterprises have invested heavily in the first category. Almost none have built the second. The result is a polite AI agent with broad credentials, no policy, and no audit trail. Polite AI is not secure AI.

Figure 4. The Authorization Gap: the space between heavily-funded AI safety and almost-universally-absent AI security.

Authentication answers who. Authorization answers what they are allowed to do. The AI era did not invent this distinction — it just made the consequences impossible to ignore.

3. The Five Risks the Wiz Data Forces Into the Open

Reading the report through an authorization lens, five distinct enterprise risks emerge. Each one maps to a specific finding in the data and to a specific category of control most organizations have not yet built.

Figure 5. Five risks, each anchored to a specific Wiz data point. None of them is solved by visibility alone.

Risk 1: Transitive AI you do not know you own.

When 18% of organizations rely exclusively on transitively acquired self-hosted AI models, a meaningful share of the enterprise AI footprint never went through procurement, never got a security review, and is not enrolled in identity governance. These models execute. They consume data. They call APIs. And they are operating under whichever permissions the enclosing application happened to inherit. The board-level question is direct: does your asset inventory include AI components introduced by third-party software, and do they sit behind the same authorization plane as everything else?

Risk 2: Internet-facing orchestration.

5% of cloud environments have at least one MCP server reachable from the public internet. MCP servers are not data stores in the traditional sense — they are tool brokers. An exposed MCP server is, functionally, a directory of capabilities an attacker can ask an AI to invoke. The risk is not just data exfiltration; it is action invocation. Authorization at the MCP layer — who can call which tool, against which resource, on whose behalf — is not optional once these systems are in production.

Risk 3: Agent privilege sprawl.

Wiz dedicates a full subsection to overprivileged agents and the so-called lethal trifecta — broad data access, untrusted external input, and outbound internet reach. This is the configuration most enterprises have already built, often unintentionally, in the rush to ship. The ratio of non-human identities to humans in modern enterprise environments now sits in the high tens to one, and most of those identities were provisioned with the privileges they needed on day one — and never re-evaluated. AI agents inherit that pattern and accelerate it. Continuous, runtime authorization, scoped to the specific action being requested, is the only durable answer.

Risk 4: AI tooling abused after initial access.

The s1ngularity supply chain attack referenced in Wiz's report is instructive. Attackers did not deploy new malware. They reused AI command-line tools — Claude, Gemini, Amazon Q — that were already installed and trusted in developer environments to perform reconnaissance and credential harvesting. This is living-off-the-LLM, and it changes how lateral movement works. If an authenticated developer endpoint can ask a local AI assistant to scan filesystems, summarize secrets, or query internal APIs, then every developer endpoint with AI tooling is also a privileged automation endpoint. Authorization needs to apply to AI tools the same way it applies to any other privileged binary.

Risk 5: Compressed attacker timelines.

The most consequential framing in the Wiz report is economic. AI does not invent new attack classes. It compresses timelines, lowers the skill floor, and scales familiar techniques. Benchmarks like Cyber Model Arena show measurable improvements in exploit-task performance generation over generation. The result, in plain language, is that the window between vulnerability disclosure and active exploitation is shrinking, and the volume of exploitation attempts is rising. Quarterly access reviews and human-paced approval workflows were already inadequate. Against an AI-accelerated adversary, they are obsolete. Authorization decisions need to be made at machine speed, with policy authored as code, evaluated continuously, and logged in full.

Even incremental attacker improvements lower the skill barrier, reduce the cost of discovery, and increase the speed of exploit development. — Wiz Research

What this looks like in production: a Fortune 10 retailer.

Consider a Fortune 10 retailer evaluating EnforceAuth in late 2025. The platform team had stood up an internal MCP server to give a fleet of operations-support agents access to inventory data, order systems, and a handful of internal HR tools — the latter included so the agents could answer employee benefit questions. The MCP server was not internet-facing, but the agents were authenticated as a single shared service account with read access spanning all three domains.

A CNAPP scan flagged the over-broad service account. It did not — could not — block the actual problem: any agent in the fleet, regardless of which user prompted it, could query the HR system on behalf of any employee. Visibility surfaced the misconfiguration. It did not prevent the action.

Inserting EnforceAuth at the MCP layer changed the geometry. Each agent runs under a distinct, attestable identity. Every tool call carries the requesting human's context. A policy — authored in Rego, versioned in git, deployed alongside the application — denies any HR-system call unless the requesting human is the subject of the query or holds an HR-admin role. The policy is short enough to print on the page:

# EnforceAuth — Fortune 10 retailer agent fleet policy

# Domain: AI Workloads · Mode: enforce · p99 target: <5ms

# Decision: allow MCP tool calls only when the requesting human is

# authorized for the resource the agent is acting upon.

package enforceauth.mcp.agent_fleet

import rego.v1

# Default-deny. Every decision is explicit.

default decision := {"allow": false, "reason": "default_deny"}

# Allow inventory and order tools for any authenticated employee.

decision := {"allow": true, "reason": "ops_tool_allowed"} if {

input.tool.namespace in {"inventory", "orders"}

input.identity.agent.attestation == "verified"

input.identity.human.authenticated == true

}

# HR tools require the requesting human to be the subject of the query

# OR hold an HR-admin role. The shared service account no longer suffices.

decision := {"allow": true, "reason": "hr_self_lookup"} if {

input.tool.namespace == "hr"

input.identity.human.id == input.tool.args.subject_employee_id

input.identity.agent.attestation == "verified"

}

decision := {"allow": true, "reason": "hr_admin_role"} if {

input.tool.namespace == "hr"

"hr_admin" in input.identity.human.roles

input.identity.agent.attestation == "verified"

}

# Explicit denial for HR cross-employee access without admin role —

# the exact case a CNAPP scan flagged but could not block at runtime.

decision := {"allow": false, "reason": "hr_cross_employee_blocked"} if {

input.tool.namespace == "hr"

input.identity.human.id != input.tool.args.subject_employee_id

not "hr_admin" in input.identity.human.roles

}

Listing 1. The actual policy that closed the gap. Versioned in git, evaluated at runtime, logged on every decision.

Read what the policy actually does. The default is deny. Inventory and order tools are allowed for any authenticated employee whose agent identity has been verified. HR tools require either that the requesting human is asking about their own employee record, or that they hold an hr_admin role. The fourth rule — the explicit denial — is the one that matters most. It blocks the exact scenario the CNAPP scan flagged but could not prevent: an arbitrary employee using an agent to query another employee's HR record. Every decision returns a structured reason that flows into the audit log. The policy lives in version control next to the application code. When HR adds a new tool, the policy gets a pull request, not a ticket.

This is what "closing the Authorization Gap" looks like in practice. Not a dashboard. Not a finding. A specific runtime decision, made in under five milliseconds, denying a specific action a specific identity should not have been allowed to take. Multiplied across the millions of agent-tool interactions a Fortune 10 enterprise generates every day.

Visibility produces findings. Enforcement produces decisions. Only one of them stops the breach.

4. The Six Questions Every CISO Needs to Answer This Quarter

The Wiz report closes with six questions security leaders should be able to answer about their AI footprint. EnforceAuth would suggest that each one becomes a board agenda item — not a security team exercise — and that each is fundamentally a question about authorization, not visibility:

• 1. Where is AI operating across our environments — including embedded and transitive components?

If your asset inventory was built for VMs and containers, it is missing models, agents, MCP servers, and the tooling that orchestrates them. Asset inventory is a precondition for authorization. Without it, policy has nothing to bind to.

• 2. Which AI-related systems are internet-reachable or connected to sensitive data?

Reachability without enforcement is exposure. A reachable MCP server with no authorization layer in front of it is a control plane handed to whoever discovers it first.

• 3. What permissions do agents, model servers, and AI services operate under — and are those privileges justified?

This is the classic least-privilege problem on a dramatically larger surface. The honest answer in most environments is that the privileges were granted at provisioning time and have never been re-evaluated against actual usage.

• 4. How is AI ownership distributed across development, platform, and product teams?

Distributed ownership is not a problem to be solved — it is a reality to be governed. The governance answer is unified policy enforcement that does not depend on which team deployed the workload.

• 5. Can we rapidly detect and respond to threats across AI applications?

Detection without enforcement is forensics. The goal is to deny the unauthorized action in the first place, then have the audit trail to explain the denial — not to discover the breach in next quarter's review.

• 6. Can we prioritize AI-related findings based on real business impact?

Context — identity, resource sensitivity, action class, environment — is what separates a theoretical misconfiguration from a material exposure. That context lives in the policy layer.

5. What an Enforcement Layer Actually Looks Like

EnforceAuth was built specifically for the environment Wiz describes. The platform is the AI Security Fabric — a unified runtime authorization layer that enforces policy across four domains where authorization decisions need to happen at machine speed: applications, infrastructure, data, and AI workloads. Three architectural choices matter most for the risks the report surfaces.

Figure 6. EnforceAuth sits between every identity and every resource — including AI agents, MCP servers, and the tools they invoke.

Continuous identity, not session identity.

Traditional identity systems authenticate at the door and trust from there. EnforceAuth treats every action — every API call, every tool invocation, every data read — as a fresh authorization decision. Human users, service accounts, API tokens, and AI agents are all first-class identities. The platform binds policy to the identity, the action, and the context, not to the session.

Policy as code, evaluated at runtime.

Authorization rules are versioned in git, tested in CI, reviewed in pull requests, and deployed like any other infrastructure — exactly the model demonstrated in Listing 1. This is the only model that scales to the pace and fragmentation Wiz documents. When AI assistants, agents, MCP servers, and embedded models are entering the environment from a dozen directions at once, the policy layer has to evolve as fast as the workloads — without waiting on a security ticket queue.

Action-level enforcement for agents and MCP.

EnforceAuth treats AI agents and MCP tool calls as authorization events. A policy can enforce that a given agent identity, operating on behalf of a given human, acting on a specific resource class, in a specific environment, may invoke a specific tool — and not others. Every decision is logged, every denial is explainable, every policy change is auditable. This is the layer that turns Wiz's 5%-internet-facing-MCP statistic from an existential risk into a managed one.

6. Where to Start

Most CISOs reading the Wiz report will not be shocked by the trends — they have been watching them develop for two years. The shock is the speed and the scale, and the recognition that visibility tools alone will not close the gap. EnforceAuth recommends a three-step starting motion that any security leader can run inside a quarter, with or without a vendor:

• Inventory the AI surface, including transitively acquired components. Treat embedded models and bundled AI as first-class assets. If you do not know where they are, you cannot enforce on them.
• Bind every AI workload to an identity. Agents and MCP servers should not run with shared service-account credentials. Every agent should be a distinct, attestable identity, scoped to the minimum privileges required for its job.
• Move authorization decisions out of code and into policy. If your enforcement logic lives in scattered if-statements across applications, you will not be able to govern it at the pace AI demands. Policy as code, runtime enforcement, full audit trail. There is no shortcut.

Closing: The Honest Reading of the Wiz Report

The State of AI in the Cloud 2026 is the clearest third-party validation yet of a thesis EnforceAuth has been arguing since inception: the AI era did not introduce a new category of security problem. It exposed the inadequacy of the authorization layer enterprises have been deferring for two decades. Cloud made it expensive. AI made it unavoidable.

The CISOs who treat AI security as a runtime authorization problem — and who build the enforcement layer their cloud environments have been missing all along — will be the ones who can answer Wiz's six questions when their boards ask. The rest will be answering them after the incident.

Polite AI is not secure AI. The Authorization Gap is the defining enterprise security challenge of the AI era — and it is now measurable.

The Authorization Gap Assessment.

A specific deliverable for security leaders who want to answer Wiz's six questions before their next board meeting. EnforceAuth runs a 60-minute working session with your platform and security teams, then produces:

• A mapped inventory of your AI footprint — including managed services, self-hosted models, agents, MCP servers, and transitively acquired components your CNAPP may have already flagged but not contextualized.
• A scored answer to each of the six Wiz questions with risk-weighted findings and the specific authorization controls that close each gap.
• Sample Rego policies for your three highest-risk authorization scenarios — written against your actual identity model and tool inventory, not generic templates.
• A 90-day enforcement roadmap showing where runtime authorization integrates with your existing identity, cloud security, and policy stack — sequenced by risk and effort.
• All deliverables in writing within five business days of the working session. No long sales cycle. No procurement gauntlet. A real artifact your team can act on.

To request an Authorization Gap Assessment, contact the EnforceAuth team or visit enforceauth.com/assessment.

EnforceAuth · The AI Security Fabric · San Diego, CA

Source: Wiz Research, State of AI in the Cloud 2026.