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.
At a glance
What this is: This is an analysis of Wiz Research's AI-in-cloud telemetry showing that AI adoption has outrun the controls needed to govern runtime actions.
Why it matters: It matters because IAM and cloud teams now need to enforce what AI workloads can do at decision time, not just inventory where AI exists.
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.
- 5% of MCP servers are exposed directly to the internet, according to Wiz Research cited by EnforceAuth.
Context
AI security now depends on whether an identity can be authorised to take a specific action at runtime, not just whether the environment can be discovered and inventoried. That is the core governance gap in the article: AI systems, agents, and MCP-connected tooling can already reach tools, data, and APIs faster than conventional control models were designed to review.
Wiz Research's telemetry shows the problem is not theoretical. Managed AI services, self-hosted AI software, self-hosted agents, and MCP servers are already embedded across cloud estates, while the authorization layer needed to govern their actions is still immature in most environments.
For IAM, PAM, and NHI teams, this shifts the question from visibility to enforcement. If the identity model cannot express who or what may invoke a tool, touch a record, or trigger an action in context, then AI governance remains descriptive rather than preventive.
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. Without that baseline, policy, monitoring, and incident response all become incomplete. The result is blind spots where agents can act, connect, and expand their effective scope without clear governance.
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. If the permissions are broad, the workload can invoke tools or access data in ways no human reviewer intended. The problem is not the identity alone, but the action surface attached to it.
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. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.
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.
Technical breakdown
Why runtime authorization is the missing control layer
Runtime authorization is the decision point that determines whether an identity may perform a specific action in a specific context at the moment it is requested. For AI workloads, that matters because the same agent, service account, or MCP server can be legitimate in one context and unsafe in another. Discovery tools can inventory the workload, but they cannot answer the policy question: should this tool call, data read, or outbound action be allowed now? That is why visibility alone leaves a governance gap. In AI environments, the control plane must bind identity, action, and context together.
Practical implication: move enforcement to the action layer, not just the asset inventory layer.
How MCP changes the authorization problem
Model Context Protocol connects AI agents to tools and data sources, so the security issue is not merely that an MCP server exists. The real issue is that MCP becomes an action broker, translating requests into real-world operations across APIs, files, and systems of record. If access decisions are made only at provisioning time, the environment assumes static trust where dynamic tool invocation is actually happening. That mismatch creates a wider blast radius, especially when servers are shared, internet-exposed, or wired to high-value systems without per-action policy checks.
Practical implication: treat MCP as an enforcement boundary and define policy per tool, resource, and actor context.
Why self-hosted AI agents amplify privilege sprawl
Self-hosted AI agents inherit the permissions, reach, and trust of the environment they run in, but they often operate with broader access than human users would ever receive. Because these systems can execute repeatedly and at machine speed, privilege reviews that depend on periodic human review arrive too late. The governance problem is not just overpermissioning, but the assumption that a stable access grant can safely cover an unpredictable runtime sequence. In practice, that means AI agents can turn inherited access into persistent operational reach unless policy is evaluated continuously.
Practical implication: scope agent privileges to the exact action and context, then re-evaluate them continuously.
Threat narrative
Attacker objective: The attacker aims to use AI-connected runtime paths to expand action reach, access data, and execute operations that should never have been authorised.
- Entry occurs when AI services, self-hosted software, or MCP servers are introduced into cloud environments and connected to data or tools without action-level enforcement.
- Credential or privilege access then comes from inherited permissions, shared service accounts, or overly broad runtime entitlements that the AI workload can use repeatedly.
- Escalation happens when the same identity can invoke tools, query internal systems, or execute tasks beyond the human request that triggered the action.
- Impact is the ability to perform unauthorized reads, tool calls, or operational actions at cloud scale, making governance failures directly exploitable.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Authorization Gap: This article correctly names the structural distance between AI safety controls and AI security controls. That gap exists because most enterprises have focused on content filters and guardrails while leaving runtime enforcement, audit-grade decision logging, and per-action policy immature. The implication is not to add more monitoring, but to stop treating safety controls as a substitute for access control.
AI agents turn inherited privileges into machine-speed operational reach. Self-hosted agents and MCP-connected systems do not merely inherit cloud permissions, they reuse them at a pace that makes human-paced governance ineffective. When policy is applied only at provisioning time, the programme assumes access will remain stable long enough for review. The practitioner conclusion is that AI governance must assume continuous decision pressure, not static entitlements.
MCP exposure creates an authorization boundary, not just an exposure problem. An MCP server is not only another workload to inventory. It is a tool broker that can convert a single request into real system actions, which means governance must distinguish between a discoverable service and an enforceable decision point. The implication is that teams should treat tool invocation as the unit of control, not the server itself.
AI security is now cloud security with a stricter identity model. The report shows that AI did not invent a new category of risk so much as accelerate the failure of old assumptions about provisioning, review, and trust. That makes NHI governance, workload identity, and runtime authorisation part of the same control conversation. The practitioner conclusion is to align AI governance with identity enforcement, not separate it from the rest of the security programme.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Runtime authorization is becoming the practical boundary for AI governance. As AI systems move from pilot projects into production workflows, the control question shifts from discovery to decision time. Teams that rely on inventory, scanning, or post-hoc review will keep finding AI after the fact, but they will still be unable to constrain what it can do when it matters.
Policy has to follow the action, not the asset. The article's core lesson is that AI workloads can be present, authenticated, and still unsafe if enforcement is absent at invocation time. That means identity programmes should treat tool calls, data reads, and external actions as first-class governance events, especially where agents and MCP are involved.
For practitioners
- 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.
- Replace periodic review with continuous enforcement Move away from quarterly access review assumptions for AI workloads and enforce policy at the moment of invocation, with full decision logging.
Key takeaways
- 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.
- The telemetry shows AI and MCP are already embedded across cloud estates, which means governance gaps are now operational, not hypothetical.
- Teams need to shift from discovery-led security to action-led enforcement if they want AI control models to work in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AI workloads and MCP-connected systems rely on identity checks before action is allowed. |
| NHI-05 — Overprivileged NHI | The article centres on AI agents inheriting broader permissions than they need. | |
| Recommendation — Bind AI workloads to verified identities and evaluate each tool call against policy at runtime. Reduce agent entitlements to the minimum action scope and re-check them continuously. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The risk is agent identities using inherited privileges to perform unsafe actions. |
| Recommendation — Model agent privilege boundaries explicitly and block actions that exceed the requesting context. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article references AI tooling abuse for reconnaissance and credential harvesting after access. |
| Recommendation — Map AI-tool abuse to credential access and lateral movement detection in your monitoring pipeline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime authorization maps directly to permissions and entitlement governance in CSF 2.0. |
| Recommendation — Apply entitlement controls to AI workloads and enforce action-level authorization decisions. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Authorization Gap: The distance between what an authenticated identity can do and what it is actually permitted and proven to do in real time. For AI agents, the gap widens when decisions are made per action, at machine speed, and through workflows that expand faster than human review cycles.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Transitive AI: Transitive AI is AI capability that enters an environment through third-party software, bundled components, or dependencies rather than direct adoption. It matters because the organisation may inherit models, assistants, or agents without deliberate review, ownership, or governance enrollment.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org