"Wait, Who Deployed This AI Tool?" — Shadow AI Is No Longer Just Watercooler Talk
"We've got AI tools running somewhere in this company that nobody signed off on." That sentiment is becoming more common, not less. Shadow AI — employees adopting AI tools without IT's blessing — is no longer a problem confined to a handful of bleeding-edge companies.
According to Deloitte's 2026 research, employee AI usage jumped 50% year-over-year in 2025 alone, yet only one in five organizations has a mature governance model in place. And this isn't limited to unauthorized SaaS apps — the same pattern is spreading directly into engineering teams' hands, inside Kubernetes clusters themselves.
This article reframes shadow AI as more than a SaaS-layer issue. It's a "rogue deployment" problem happening in day-to-day Kubernetes operations, and we'll walk through the technical fix: Admission Control.
The "Rogue Deployments" Happening Inside Your Cluster — Nobody Knows Who's Running What
Plenty of alarm bells have already been raised about shadow AI in SaaS. But the exact same pattern is playing out inside Kubernetes clusters.
The more enthusiastic a team is about experimenting with generative AI, the more likely its members are to kubectl apply inference endpoints, AI agents, and batch jobs on their own judgment. Pods that multiply without an administrator's knowledge create three risks simultaneously.
Resource Contention
Rogue pods consume GPU and memory, leaving legitimate workloads stuck waiting for scheduling they never expected to need.
Security Gaps
Pods deployed in a hurry often skip securityContext configuration entirely, frequently running in privileged mode or as root.
Cost Overruns
Workloads that nobody budgeted for quietly inflate the monthly cloud bill.
You can detect the existence of these rogue workloads by continuously scanning container registries and Kubernetes namespaces for ML frameworks and model artifacts. But there's a wide gap between "we can detect it" and "we've actually prevented it."
A managed K3s platform like Kubo gives you a dashboard view of overall cluster state, making it easier to spot signs of rogue deployment. But visibility alone can't stop the moment of deployment itself.
Detection Alone Isn't Enough — Stopping Things at the "Front Door" with Admission Control
As long as your response to shadow AI workloads relies on detection, you're structurally always playing catch-up. One study comparing detection coverage across methods found manual review caught roughly 40%, a CASB (Cloud Access Security Broker) alone caught about 70%, while a dual-gate approach — reviewing at both build time and runtime — achieved 100% detection (per a paper published in AIJCST).
The Kubernetes mechanism that realizes this "stop it at the front door" approach is Admission Control. According to the official Kubernetes documentation, an Admission Controller is a component that intercepts requests to the API server immediately after authentication and authorization, before the resource is persisted. It only acts on create, update, and delete requests, and processes them in two stages: Mutating (modifying content) and Validating (checking validity).
Dynamic Admission Control goes further, letting you flexibly configure which resources are subject to which webhook via ValidatingWebhookConfiguration and MutatingWebhookConfiguration.
Kyverno and OPA Gatekeeper — The Two Leading Policy Engines
The two flagship implementations are Kyverno and OPA Gatekeeper.
Kyverno can automatically audit or reject pods that run in privileged mode, use root, omit securityContext, or mount sensitive host directories — exactly the kind of pod an AI agent, its accompanying MCP server, or a gateway container might try to deploy. In fact, Kyverno's policy library ships with a "disallow privileged containers" policy that outright rejects the creation of any pod with securityContext.privileged set to true. CNCF's blog also highlights Kyverno as a case study in flexibly implementing Kubernetes governance through declarative Policy as Code.
OPA Gatekeeper, on the other hand, defines violation logic in Rego or CEL through a resource called ConstraintTemplate, then applies concrete constraints to the cluster as Constraint objects. It has a steeper learning curve than Kyverno's declarative YAML, but its strength is extensibility — the same policy engine can be reused for systems beyond Kubernetes.
Either approach lets you shift from "noticing a rogue AI workload after it's deployed" to "stopping it before it's deployed." That design principle holds just as true on a lightweight Kubernetes distribution like K3s, and adopting Admission Control remains the team's responsibility even on a managed Kubernetes platform.
Governance Without Visibility Isn't Governance
Admission Control is a "seal the entrance" measure — it doesn't complete governance on its own. One survey found that 83% of healthcare, 86% of financial services, and 91% of public sector respondents recognize unapproved AI tool usage as a serious business and security risk (per Nutanix's research announcement). Despite that level of concern, governance still lags because organizations have a mechanism to "stop" things but no mechanism to "see" them.
Governance that actually works requires at least three elements.
- RBAC audits: Regularly review who can deploy to which namespace
- Audit logging: Make it possible to trace after the fact who deployed what and when
- Resource quotas: Cap CPU/memory/GPU per namespace to prevent unbounded growth
Managing these elements separately with disconnected tools just brings you back to the original problem: nobody can see the full picture. This is where a unified view like Kubo's Captain UI — which visualizes the entire cluster's state on a single screen — delivers real practical value. Running EKS or AKS yourself means building and maintaining separate tools for visibility, auditing, and policy enforcement; Kubo delivers that same operational foundation on top of full K3s-based Kubernetes functionality, starting at roughly $320/month.
For organizations running AI workloads, pairing this with an AI agent execution platform like Captain.AI makes it realistic to manage, end to end, exactly which approved AI agent is running on which cluster and how.
Summary
Shadow AI is usually framed as employees using unapproved SaaS tools, but the same dynamic holds true inside Kubernetes clusters. Since the root cause is a governance failure — not knowing who deployed what, where — the fix needs to happen at the infrastructure level too.
- Front-door defense: Stop deployments before they happen with Admission Control (Kyverno / OPA Gatekeeper)
- Operational defense: Secure visibility with RBAC, audit logs, and resource quotas
- Platform choice: Pick a managed Kubernetes platform that makes visibility and operations easy
Building your own governance foundation on top of the cost and complexity of EKS/AKS is a heavy lift. Kubo, built on K3s, delivers full Kubernetes functionality with visualized governance at dramatically better cost efficiency. If you're not sure what's actually happening inside your cluster right now, reach out and let's talk.