Topic starter
10/06/2026 11:13 pm
TL;DR: Managed AI services appear in 81% of cloud environments, self-hosted AI software in 90%, self-hosted AI agent technologies in 57%, and MCP servers in 80%, with 5% internet-exposed, according to EnforceAuth research from Wiz Research's State of AI in the Cloud 2026. The real security gap is no longer visibility but runtime authorization over what AI systems can do in production.
Editorial analysis by NHI Mgmt Group, based on content published by EnforceAuth: “The Authorization Gap, Quantified: What Wiz's State of AI in the Cloud 2026 Tells Every CISO”.
By the numbers:
- 81% of cloud environments use managed AI services, according to Wiz Research cited by EnforceAuth.
- 90% run self-hosted AI software, according to Wiz Research cited by EnforceAuth.
- MCP servers appear in 80% of cloud environments, according to Wiz Research cited by EnforceAuth.
Key questions
Q: What breaks when organizations do not inventory AI agents and MCP connections?
A: Security teams lose the ability to answer what exists, what it can reach, and who owns it.
Q: Why do AI workloads create risk when they inherit broad cloud permissions?
A: They create risk because AI systems can execute many actions at machine speed, so inherited privileges become operational reach rather than passive access.
Q: How do teams know whether AI governance is actually working?
A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement.
Practitioner guidance
- Inventory AI workloads as enforceable identities Classify managed AI services, self-hosted AI software, agents, and MCP servers as identities with explicit authorization scope, not just as assets in a catalogue.
- Bind each agent to per-action policy Separate shared service-account access from the requesting human's context so every tool call is evaluated against a specific identity, resource, and action.
- Place MCP behind a policy decision point Define allow and deny rules for tool invocation, resource class, and environment so the MCP layer cannot execute requests by inherited trust alone.
Bottom line: The article's central problem is not AI adoption itself, but the lack of a runtime control that can govern what AI identities are allowed to do.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 5:03 am
Runtime authorization is now the control that separates AI visibility from AI governance. Discovery tells you where AI lives, but it does not determine what an agent, model, or MCP server may do in context. The article's data shows the footprint has already spread beyond what periodic review models can manage. The practitioner conclusion is that authorization must move to the action layer if governance is to mean anything in production.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between AI visibility and runtime authorization?
A: AI visibility tells you what is present in the environment, while runtime authorization determines what that identity may do when a request is made. Visibility helps inventory and risk discovery, but it does not block unsafe actions. Authorization is the decision layer that prevents an allowed identity from doing the wrong thing in the wrong context.
👉 Read our full editorial: AI security now depends on runtime authorization, not visibility
This post was modified 1 day ago by NHI Mgmt Group