We’ve been here before.
Not with AI specifically. But with the pattern — the way powerful new technology lands in the enterprise, gets adopted bottom-up faster than anyone planned for, and creates a governance crisis that takes years to clean up.
We watched it happen with cloud. Then again with Kubernetes. Now we’re watching it happen with AI — and this time, the stakes are higher and the timeline is shorter.
Act One: The Cloud Era
In the early 2010s, the public cloud changed everything. Developers could spin up infrastructure in minutes without going through IT. The productivity gains were real and immediate. The governance problems came later.
Shadow IT exploded. Teams were running workloads on personal credit cards, using unauthorized SaaS tools, storing data in personal Dropbox accounts. Finance had no visibility into cloud spend. Security had no visibility into what was running or where data was going. IT was perpetually three steps behind.
The cleanup was painful. Cloud governance frameworks, FinOps practices, CASB tools, data classification policies — all of it built reactively, after the sprawl had already happened. Enterprises that got it wrong spent years and millions of dollars bringing ungoverned cloud usage back under control.
| The lesson from the cloud era: developer velocity without governance doesn’t create a productivity problem. It creates a cost, security, and compliance problem — that arrives years later with a very large invoice. |
Act Two: The Kubernetes Era
A few years later, the same pattern repeated with Kubernetes.
Platform engineers fell in love with (Docker) containers and orchestration. Deployment speed improved dramatically. Teams were shipping faster than ever. And once again, governance came last.
At Nirmata, we had a front-row seat to this. We watched Kubernetes adoption stall inside large enterprises — not because the technology wasn’t ready, but because security and compliance teams couldn’t get comfortable with what was running, who had access to what, and how to prove any of it to an auditor.
Workloads were being deployed with over-provisioned permissions. There was no consistent policy enforcement across clusters. No audit trail that meant anything to a compliance team. Developers had figured out how to work around guardrails that slowed them down.
It took years — and the emergence of policy-as-code tools like Kyverno — before enterprises had a governance layer they could actually trust. Before CISOs felt confident enough to give Kubernetes the green light at scale.
The pattern: fast adoption, slow governance, painful remediation.
Act Three: The AI Era
We are now in the early innings of Act Three. And the pattern is identical — except the velocity is higher, the surface area is larger, and the consequences of getting governance wrong are more severe.
AI tools are everywhere. Developers are using Claude Code, GitHub Copilot, Cursor, and a dozen other AI assistants daily. Teams are building LLM-powered applications and autonomous agents. Business units are buying AI SaaS tools that the security team has never reviewed. Executives are asking why the company isn’t moving faster.
And the governance layer is nowhere near ready.
The Three Problems Nobody Has Solved
- The Cost Problem
AI spending is growing faster than any enterprise budget process was designed to track.
Anthropic recently confirmed a $30B annualized run rate — growing from $9B just six months prior. A recent analysis by Madrona noted that the 1,000+ enterprise customers each spending $1M+ annually are driving almost entirely token-based revenue — every API call metered, every token counted. One developer tracked the equivalent of $15,000+ in API usage over eight months on a flat-rate subscription. That arbitrage window is now closing.
Inside most enterprises today, nobody can answer the basic cost governance questions:
- Which teams are spending the most on AI models?
- Which developers are calling expensive models when a cheaper one would do?
- Which features or products are driving the largest token consumption?
- Who approved that $2,000 spike in the ML team’s budget last Tuesday?
These are not exotic questions. They are the questions every VP of Engineering and every FinOps team will be asking within the next twelve months — and most enterprises have no way to answer them today.
- The Security and Data Leakage Problem
Shadow AI is the new Shadow IT.
Developers are pasting proprietary code, internal documents, and customer data into AI tools — not because they are careless, but because the tools are genuinely useful and there are no guardrails in place to prevent it. The Samsung incident — where engineers accidentally leaked proprietary source code via ChatGPT — was not an anomaly. It was an early preview of a problem that is now happening at scale, quietly, across every enterprise that has given developers access to AI tools without governance.
The challenge for security teams is that AI tools don’t look like traditional data exfiltration. There is no file transfer, no unusual outbound connection, no alert in the SIEM. A developer sends a prompt containing a database schema, an internal API spec, or a customer record. The AI responds. The data is gone. Nothing triggers.
And it’s not just individual developer tools. AI agents — autonomous systems that call APIs, access databases, and take actions without a human in the loop — are being built and deployed with permissions that nobody explicitly approved. The service account a developer configured for a prototype becomes the production agent’s identity. Broad database access granted for experimentation becomes the access the agent runs with in production.
| The CISO question is no longer “are our developers using AI?” They are. The question is: “Do we have any visibility into what they’re sending, what models are being called, and what data is leaving the building?” For most enterprises today, the honest answer is no. |
- The Productivity and Control Problem
Engineering leaders are caught between two pressures that pull in opposite directions.
On one side: the productivity gains from AI tools are real. Developers using AI coding assistants ship faster. Teams with AI-powered workflows complete work in hours that used to take days. The pressure to enable AI broadly and quickly is intense — from developers who want access, from executives who want speed, from competitors who are moving fast.
On the other side: nobody has visibility or control. Which models are being used? What are they being used for? Are developers building dependencies on expensive frontier models that could be replaced with cheaper alternatives? Are there teams running experiments that are burning through budget with no business case? Is anyone tracking whether the AI usage is actually driving productivity, or just driving spend?
The result is a familiar pattern for anyone who lived through cloud or Kubernetes adoption: a window of ungoverned usage that feels fine right now, followed by a reckoning when the cost, security, or compliance problems surface at the worst possible moment.
The Pattern in One Table
| Era | How It Started | The Governance Gap | The Reckoning |
| Cloud (2010s) | Developers spin up AWS on personal cards. SaaS tools bought without IT review. | No spend visibility. No data classification. Shadow IT at scale. | Years of FinOps remediation. CASB tools. Cloud governance frameworks built reactively. |
| Kubernetes (2015+) | Platform teams deploy clusters. No consistent policy enforcement across environments. | Over-provisioned permissions. No guardrails. Compliance teams can’t get comfortable. | Adoption stalls. Policy-as-code tools emerge. Years of retrofitting governance onto running infrastructure. |
| AI (Now) | Developers use Claude Code, Copilot, Cursor daily. Agents built and deployed without review. | No spend attribution. Data leakage via prompts. Agents with ungoverned permissions… | TBD — but the pattern says: painful, expensive, and avoidable if governance is built now. |
Why This Time Is Different — And More Urgent
Each iteration of this pattern has moved faster and created more exposure than the one before it.
The cloud era played out over the better part of a decade. Kubernetes governance took three to five years to mature. AI is moving faster than both — driven by tools that are genuinely useful, pricing that has made broad access affordable, and organizational pressure to adopt quickly or fall behind.
But the surface area of the problem is also larger. Cloud governance was primarily a cost and infrastructure problem. Kubernetes governance was primarily a security and compliance problem. AI governance is all three simultaneously:
- Cost: token spend is metered, accelerating, and poorly attributed
- Security: data leakage through developer tools and ungoverned agent permissions
- Compliance: audit trails that don’t exist, model usage that can’t be proven, regulatory exposure that’s building quietly
And unlike cloud or Kubernetes, AI governance spans two distinct layers that need to be governed differently:
- the developer layer (who is calling which model, at what cost, with what data)
- the agent layer (autonomous systems making decisions and taking actions without human oversight).
Both layers are ungoverned in most enterprises today. Both are accumulating risk.
The Window to Get This Right
| The enterprises that navigated the cloud and Kubernetes governance challenges successfully were not the ones that moved slowest. They were the ones that built governance into their adoption motion early — before the sprawl made remediation painful. |
We are in that early window with AI. Most enterprises are still in the experimentation phase. Developer AI tooling is spreading but not yet fully embedded. Agents are in pilots, not production. The governance layer is not yet urgently needed – which is exactly when it is least expensive to build.
That window will close. The question is whether governance gets built into the AI adoption motion now, or retrofitted onto it later at significantly greater cost.
We’ve seen this movie twice. We know how it ends.
For a technical perspective on how to govern AI agents at the infrastructure layer — from AIBOM attestation at build time to Kyverno admission policies at runtime — read: Shadow AI Is the New Shadow IT: Governing AI Agents from Code to Runtime.
Next in this series: What good AI agent governance looks like — and then, what it looks like for developers.
