AI model adoption is reshaping cloud security governance in 2025

At a glance

What this is: This is Orca Security’s 2025 ranking of the most popular AI models in cloud estates, showing rapid adoption growth, OpenAI dominance, and wider distribution of model usage across organisations.

Why it matters: IAM, cloud security, and platform teams need to treat AI models as governed enterprise assets, because model sprawl changes visibility, access boundaries, and operational ownership across cloud programmes.

By the numbers:

• AI model usage in cloud environments jumped from 56% of organisations in 2024 to 84% in 2025.
• GPT-4o appeared in nearly 45% of cloud environments in 2025, at 44.72%.

Context

AI model adoption is no longer a niche cloud experiment. In this article, AI model sprawl is the governance problem: organisations are adding managed and unmanaged AI services, packages, and foundation models faster than most cloud control sets can inventory them.

The primary IAM issue is not model quality, but identity and boundary control around who can deploy, invoke, and connect models to enterprise data. As AI workloads become routine in cloud estates, access governance has to extend beyond human users and into model usage, service integrations, and policy scope.

Key questions

Q: How should IAM teams govern AI models in cloud environments?

A: Treat AI models as part of the cloud control plane, not as isolated tools. Give every model, workspace, and service path an owner, a business purpose, and an access boundary. Then recertify the surrounding identities, data connections, and deployment permissions on the same cadence used for other high-risk cloud assets.

Q: Why does AI adoption create governance risk even when individual tools seem inexpensive at first?

A: AI adoption creates governance risk because low-friction access encourages widespread use before controls are in place. Small, cheap tools can become embedded in workflows, making usage hard to track and review. Once teams depend on them, spending, data exposure, and quality risk scale quickly. The challenge is not the initial price, but the speed at which dependency grows.

Q: When does AI model governance usually fail in practice?

A: It usually fails when documentation begins after deployment. At that point, model inventories are already stale, relationships to use cases are missing, and engineering teams have moved on to newer versions. Governance is weakest when it depends on manual follow-up instead of capturing model details at the moment the asset is created.

Q: Should organisations standardise on a small number of AI platforms?

A: Standardisation can simplify oversight, but only if the platform stack comes with clear ownership, service scoping, and data access rules. Without those controls, standardisation simply concentrates risk in fewer services and makes governance failures harder to spot.

Technical breakdown

Why model sprawl becomes a cloud governance problem

An AI model is not just an application feature. In cloud environments it often sits inside a managed service, custom workspace, or embedded workflow that pulls in data, permissions, and operational dependencies. That makes each model deployment part of the control surface, not a separate innovation layer. When usage rises from a minority pattern to a mainstream one, asset inventory, ownership, and policy enforcement all become harder to sustain. The governance challenge is therefore not model intelligence alone, but the number of deployment paths and trust relationships created around it.

Practical implication: Treat AI models as governed cloud assets with explicit ownership, inventory, and policy scope.

Managed AI services change the identity boundary

The article highlights Azure OpenAI and Azure Machine Learning Workspace as major contributors to model adoption. That matters because managed AI services collapse several control decisions into one platform layer, including provisioning, invocation, data access, and operational oversight. In identity terms, the question becomes who can create, connect, and use the service, and what downstream permissions those actions inherit. This is a classic boundary problem for cloud governance: the model is visible, but the identities and entitlements around it are often more diffuse than the model itself.

Practical implication: Review how cloud IAM, service principals, and workspace permissions extend into AI service usage.

Embeddings and retrieval expand the hidden access surface

The article shows that embedding models are among the most widely adopted AI workloads. That is important because embeddings are frequently used in search, retrieval-augmented generation, deduplication, and recommendation pipelines, where they quietly touch sensitive content and metadata. These systems do not look like traditional applications, but they can still expose enterprise data through indexing, retrieval, and grounding paths. For security teams, the risk is not only model misuse, but the data and permissions that the surrounding pipeline inherits from the cloud environment.

Practical implication: Assess embedding and RAG pipelines as data-access paths, not just AI features.

Threat narrative

Attacker objective: The objective is to exploit weakly governed AI service relationships to reach data, workflows, or cloud permissions that were not intended for broad model access.

1. Entry occurs when AI services, packages, and model endpoints are introduced into cloud estates through managed platforms and development workflows.
2. Credentialed access and policy scope then expand as workspaces, service identities, and data connections are granted to support training, inference, and orchestration.
3. Impact follows when model sprawl obscures ownership and visibility, allowing sensitive data flows and permissive integrations to persist outside normal governance review.

NHI Mgmt Group analysis

Model sprawl is now an identity governance problem, not just an AI adoption metric. Once AI models move from pilot use to broad cloud deployment, the primary risk shifts from experimentation to control boundary erosion. The article’s adoption data shows that visibility alone is no longer enough if the organisation cannot assign ownership, access scope, and review responsibility for each model and service path. Practitioners should treat model inventory as a governance prerequisite, not a reporting output.

Managed AI services create inherited trust chains that most IAM programmes do not model explicitly. Azure OpenAI and Azure Machine Learning illustrate how AI capability is delivered through cloud services that borrow existing cloud identities, permissions, and data access. That means the control problem is not whether a model is approved in the abstract, but whether the service path that reaches it is properly authorised and constrained. IAM teams should re-examine how service principals, workspaces, and data-plane permissions interact in AI deployments.

Embedding-heavy AI architectures widen the hidden access surface. Search, retrieval, and grounding functions often sit outside the centre of AI governance even though they determine which enterprise information the model can reach. This is where permission creep becomes operational rather than theoretical: a model may be approved, but the retrieval path can still overexpose content. The result is a governance gap between model approval and data access enforcement.

Named concept: model governance drift. This is the gap that appears when AI adoption outpaces the organisation’s ability to keep model ownership, service trust, and access boundaries aligned. It is not solved by a single policy statement because the drift accumulates across cloud services, data pipelines, and operational teams. The practical conclusion is that AI governance has to be continuous, identity-aware, and tied to the cloud control plane.

OpenAI prominence signals standardisation pressure across enterprise AI estates. When one model family becomes dominant, organisations tend to standardise around a smaller set of services, which can improve control consistency but also concentrates risk if those services are not well governed. That makes the control question strategic: practitioners need to decide which AI services belong in the standard stack, who owns them, and how exceptions are reviewed. The programme implication is to govern AI platform sprawl before it hardens into default infrastructure.

From our research library:

• 13% of organisations suffered breaches of their AI models, according to IBM's Cost of a Data Breach 2025 report.

What this signals

Model governance drift: when AI adoption scales faster than ownership and access boundaries, the organisation ends up governing models by exception rather than by design. That weakens cloud security programmes because approval and oversight no longer follow the same trust chain that the model uses in production.

AI governance now sits at the intersection of cloud IAM, data access, and service ownership. Practitioners who separate those domains will miss the real control problem, which is how the model, the workspace, and the data path authorize each other in practice.

For practitioners

• Inventory AI models as governed cloud assets Map every model, workspace, and managed AI service to an owner, business purpose, and data classification. Include both sanctioned deployments and shadow usage in the same register.
• Reassess service identities and workspace permissions Review the identities that create, invoke, or connect AI services, especially in Azure OpenAI and Azure Machine Learning environments. Verify that service-to-service access is limited to the smallest viable scope.
• Classify retrieval paths as data-access channels Treat embedding, retrieval, and grounding pipelines as pathways to enterprise data rather than neutral model plumbing. Apply policy checks to the source systems feeding those pipelines.
• Define AI governance ownership across cloud and security teams Assign clear accountability for approving, monitoring, and recertifying AI model usage so that model decisions do not sit between cloud platform and IAM teams.

Key takeaways

• AI model adoption in cloud estates is now broad enough that governance has to cover inventory, ownership, and service trust, not just experimentation.
• Managed AI services and embedding-heavy pipelines create hidden access paths that can expand the cloud attack surface if they are left outside IAM review.
• The most useful control shift is to govern model usage as a continuous cloud identity problem, with clear ownership and explicit access boundaries.

Key terms

• AI Model Sprawl: The rapid spread of multiple AI models across an organisation's cloud estate, often through managed services, embedded copilots, and custom workflows. It becomes a governance issue when each model introduces new identities, data paths, and permissions that security teams must inventory and control.
• Model Governance Drift: Model governance drift is the gap that forms when AI usage expands faster than the organisation can keep ownership, access scope, and accountability aligned. In practice, the model remains approved while the surrounding cloud service paths and data connections become harder to govern.
• Managed AI Service: A packaged service in which an MSP or IT provider administers AI tools for a client under defined configuration, provisioning, and governance rules. It is not just software resale. The service includes access control, adoption support, and ongoing oversight of how AI is used across users and data.
• Embedding Pipeline: An embedding pipeline turns text or other content into vectors for search, retrieval, clustering, or grounding. It matters to identity security because it often touches sensitive enterprise data and can create indirect access paths that are easy to overlook during governance reviews.

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.