TL;DR: Wiz Research’s State of AI in the Cloud 2026 finds 81% of cloud environments use managed AI services, 90% run self-hosted AI software, and MCP servers appear in 80% of environments, with 5% internet-exposed, showing the AI footprint is outrunning governance. The control problem is no longer discovery; it is whether runtime authorization exists at all.
NHIMG editorial — based on content published by EnforceAuth covering Wiz Research's State of AI in the Cloud 2026: State of AI in the Cloud 2026 and the authorization gap
By the numbers:
- 81% of cloud environments use managed AI services.
- 90% run self-hosted AI software.
- MCP servers appear in at least 80% of cloud environments, with 5% of those exposed directly to the internet.
Questions worth separating out
Q: How should security teams govern AI workloads that can call tools and APIs?
A: Treat the workload as a non-human identity with explicit permissions, not as a generic application.
Q: Why do MCP servers create a new authorization problem for IAM teams?
A: MCP servers broker access to tools, data, and APIs, so they sit at the point where capability becomes action.
Q: What breaks when AI security stops at inventory and posture management?
A: What breaks is enforcement.
Practitioner guidance
- Inventory AI as an identity surface Map managed AI services, self-hosted models, agents, and MCP servers alongside service accounts, tokens, and API keys.
- Scope MCP tool permissions explicitly Define which tools an MCP server may expose, which resources each tool can reach, and which human or machine context is required for approval.
- Move AI access decisions into runtime policy Replace scattered application checks with policy evaluated at execution time so every agent action, tool call, and API request is approved or denied in context.
What's in the full report
EnforceAuth's full article covers the operational detail this post intentionally leaves for the source:
- The concrete policy code used to close the authorization gap in production AI workloads.
- The board-level framing for translating AI inventory findings into runtime enforcement decisions.
- The step-by-step control model for binding agents, MCP servers, and service accounts to explicit permissions.
- The retailer example showing how shared credentials and broad access are constrained by policy.
👉 Read EnforceAuth's analysis of Wiz Research's State of AI in the Cloud 2026 →
Runtime authorization for AI workloads: are your controls keeping up?
Explore further
Authorization gap, not visibility gap, is the defining failure mode here. The report shows that enterprises can now see the AI surface, but they still cannot consistently enforce what those systems may do at runtime. That is a governance failure, not a tooling shortage. The practical conclusion is that identity programmes must stop treating AI exposure as an inventory problem and start treating it as an action-control problem.
A few things that frame the scale:
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do teams decide whether AI access should be reviewed like other non-human identities?
A: If the AI system consumes credentials, reaches internal data, or triggers business actions, it should be reviewed like any other non-human identity. The question is not whether it is sophisticated enough to count as special. The question is whether it can exercise privilege that changes risk, auditability, or accountability.
👉 Read our full editorial: AI security now depends on runtime authorization, not visibility