AI security now depends on runtime authorization, not visibility

At a glance

What this is: This analysis says cloud AI adoption has become widespread while the authorization layer needed to govern agents, MCP servers, and self-hosted AI remains immature.

Why it matters: It matters because IAM teams now have to govern non-human identities, autonomous tool use, and human-context access decisions in the same control plane.

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.

👉 Read EnforceAuth's analysis of Wiz Research's State of AI in the Cloud 2026

Context

Cloud AI is no longer confined to a few experimental workloads. The primary governance issue is that managed services, self-hosted models, AI agents, and MCP servers are entering production faster than identity and access controls can keep pace.

For IAM and cloud security teams, the key gap is runtime authorization: deciding, at the moment of execution, what an AI workload, agent, or tool broker is allowed to do. Visibility alone can inventory the surface, but it does not enforce action-level policy.

The article’s core message is that enterprises are accumulating AI systems through procurement, software supply chains, and developer tooling, often without enrolling those systems into a coherent identity model.

Key questions

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. The key is to bind identity, action, and context together so every tool call is checked at runtime. Without that, the system can access more than the original approval intended, especially when assistants or agents operate across multiple services.

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. If permissions are broad or implicit, the server becomes a high-value trust boundary that can be abused by a legitimate agent or an attacker. IAM teams need scoped, contextual approvals rather than blanket access to the broker.

Q: What breaks when AI security stops at inventory and posture management?

A: What breaks is enforcement. Discovery can show that AI exists, but it cannot stop an agent from reading data, invoking a tool, or chaining actions in ways the business never intended. The control failure is assuming that visibility is equivalent to governance, when the real requirement is action-level authorization.

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.

Technical breakdown

Managed AI services and self-hosted AI expand the identity surface

Cloud AI creates two overlapping identity problems. Managed AI services add third-party control dependencies, while self-hosted AI software becomes part of the enterprise attack surface and must be governed like any other workload identity. In practice, identity teams cannot stop at asset discovery. They need to know which identities each AI component uses, what data those identities can reach, and whether the permissions are explicit or inherited from surrounding applications. That distinction matters because AI systems are now embedded in normal delivery pipelines, not isolated labs.

Practical implication: Inventory AI components as identities, not just workloads, and map their permissions before they enter production.

MCP servers turn AI from a model problem into a tool-access problem

Model Context Protocol servers act as brokers between agents and tools, data sources, and APIs. That makes them an authorization boundary, not just an integration layer. When an MCP server is internet-facing, the risk is not simply exposure of metadata. It is uncontrolled access to actions that an AI system can invoke on demand. The security question becomes who can call which tool, for which resource, and on whose behalf. Without scoped tool permissions, MCP becomes a broad capability catalog that attackers can abuse.

Practical implication: Treat MCP as a policy enforcement point and scope every tool permission explicitly.

Runtime authorization is the missing control plane

The article’s central architecture point is that visibility tools can tell you what exists, but they do not decide whether an identity may act right now. Runtime authorization is the control layer that evaluates identity, action, and context in real time. That is especially important when AI systems generate or request actions dynamically, because the decision boundary shifts from static provisioning to continuous enforcement. If the policy layer lives only in code reviews or post-incident analysis, the enterprise is relying on after-the-fact governance for a real-time problem.

Practical implication: Move AI permissions into policy evaluated at runtime, with full logging and explicit deny-by-default behavior.

Threat narrative

Attacker objective: The attacker’s objective is to reuse trusted AI tooling and broad non-human access paths to reach data, invoke actions, and move faster than human-paced review can contain.

1. Entry occurs when AI systems arrive through managed services, self-hosted software, or transitive third-party components that were not explicitly enrolled in governance.
2. Credential access or abuse happens when agents and MCP servers run under broad service accounts or inherited permissions that let them reach tools, data, and APIs without scoped authorization.
3. Impact follows when those identities invoke actions at machine speed, expanding blast radius across systems that were never designed for AI-driven execution.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

AI systems are becoming non-human identities before governance has recognized them as such. Managed services, self-hosted models, agents, and MCP servers all consume permissions, call APIs, and influence business processes. Once those systems are allowed to act, they need identity, lifecycle, and authorization treatment that matches the privilege they hold. IAM teams should stop assuming the workload boundary is enough to define trust.

MCP introduces a tool-broker trust model that most enterprises have not governed. The article makes clear that MCP servers are production orchestration layers, not experimental adapters. The named concept here is tool-broker exposure: when a broker can invoke multiple capabilities on behalf of an identity without tight scoping, the broker itself becomes part of the privilege surface. Practitioners should recognize that this shifts control responsibility upward into the broker layer.

Self-hosted AI inherits the same privilege sprawl that service accounts already created. The report’s strongest governance signal is not that AI is new, but that it amplifies old identity mistakes at higher speed and scale. Broad permissions, inherited access, and weak review cycles now affect model endpoints, assistants, and agents as well as traditional workloads. The implication for practitioners is that AI governance and NHI governance are now the same programme at different layers.

Continuous authorization becomes mandatory once AI can execute independently. Static approvals and quarterly reviews assume that privilege remains stable long enough to be observed and certified. In AI-driven environments, the control surface changes too quickly for that model to hold. Practitioners need to reframe policy from session-level trust to action-level enforcement, because the decision point has moved into runtime.

From our research:

• 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.
• For a governance baseline, review Top 10 NHI Issues alongside the agentic risk model to align inventory, authorization, and audit.

What this signals

Authorization will become the differentiator between AI adoption and AI governance. Organisations can accumulate managed services, self-hosted models, and agents quickly, but that does not mean they can explain or constrain what those systems are allowed to do. The programme signal is simple: if runtime decisions are not policy-driven, the enterprise is relying on post hoc review for real-time behaviour.

With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the control problem will scale faster than most review cycles. That pressure will push IAM and security teams toward continuous authorization, stronger identity binding, and better audit logging for non-human actors.

Identity teams should expect AI governance to converge with workload identity governance. The same questions now apply across agents, APIs, service accounts, and model endpoints: who can act, under what context, and with what evidence? The organisations that answer those questions consistently will be able to govern AI without building a separate security stack for every new use case.

For practitioners

• Inventory AI as an identity surface Map managed AI services, self-hosted models, agents, and MCP servers alongside service accounts, tokens, and API keys. Record which identities each component uses, what data they can touch, and where permissions are inherited rather than explicitly granted.
• 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. Default to deny when tool scope is unclear or when a server is accessible outside trusted networks.
• 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. Keep the policy versioned, testable, and auditable like any other security control.
• Separate visibility from enforcement in programme design Use CNAPP and similar platforms to discover AI exposure, then pair them with an enforcement layer that can stop unauthorised actions. Do not treat inventory, posture, and runtime control as interchangeable outcomes.

Key takeaways

• AI adoption has outpaced the authorization layer needed to govern it, turning visibility into an incomplete control strategy.
• MCP servers and self-hosted AI expand the non-human identity surface, so broad or inherited permissions now create direct execution risk.
• Runtime policy is the practical answer: decisions must follow identity, action, and context at the moment of execution.

Key terms

• Runtime Authorization: Runtime authorization is the decision layer that approves or denies an action at the moment it is requested. For AI workloads, it evaluates identity, context, and intended action together, so a model, agent, or tool broker cannot rely on broad standing permission alone.
• MCP Server: An MCP server is a tool-brokering service that connects an AI system to tools, data sources, and APIs. In identity terms, it becomes an authorization boundary because it decides which capabilities are reachable and under what context they can be invoked.
• Authorization Gap: The authorization gap is the space between AI safety controls that shape behaviour and security controls that enforce actions. It exists when an enterprise can observe AI activity but cannot reliably constrain what a model, agent, or workflow is allowed to do in production.
• 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

AI workload authorization and runtime policy are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for agents, MCP servers, and self-hosted models, it is worth exploring.

This post draws 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. Read the original.