Ai4 was two weeks ago, and I’m still thinking about it.
We spent three days at The Venetian, mostly at our booth, as twelve thousand people moved through the show. What has stayed with me is a specific conversation that kept repeating, with different faces on it.
Someone would walk up and say, in one version or another: “We’ve got developers using Cursor and Claude Code. Someone’s already built an MCP server. My CISO is nervous. I don’t know what my plan is.” Then we’d talk for fifteen or twenty minutes, and I’d realize the person on the other side of the table hadn’t yet decided whether to lean in or shut it down. Most of them were hoping we’d give them a reason to lean in.
That was the show, for me: Not the keynotes. Not the robot demos. A slow-motion realization that most of the Fortune 1000 is somewhere between “we should probably do something about this” and “we’re doing something about this, but we’re not sure it’s right.” What I took away from those conversations is that AI governance has moved from a policy problem to an operational one. The tools are already deployed. Now teams have to figure out how to govern what’s actually happening.
The AI Tools are Already Inside the Enterprise
The tools that came up most were exactly the ones you’d expect: Claude Code, Cursor, VS Code with Copilot, Microsoft Copilot, ChatGPT Enterprise. These clients are already deployed inside enterprise walls, running against enterprise data. None of the conversations were hypothetical. They were about clients IT had already approved, or was about to approve, and about the MCP servers and Skills that people were already downloading whether or not a policy existed for them yet.
Shadow AI Is a Device-Level Governance Problem
One thing came up more than I expected. When I described what device-level control looks like in Obot, people got noticeably more interested. The centralized gateway story is well understood at this point; what teams haven’t figured out is what to do about the local surface. A developer’s laptop is running a coding agent, three MCP servers, a couple of Skills pulled from a public registry, and a CLI or two. A gateway can only see what passes through it. The laptop is where the shadow lives.
The ability to scan endpoints, see what’s actually running, and apply audit and policy at the device layer was the single capability that most consistently turned a browsing passerby into an engaged conversation. That’s a real gap for CISOs right now, and I didn’t fully appreciate how wide it was until Ai4.
A Free Tier that Landed as a Shock
Our Obot Community Edition landed even better. We made Obot free for up to 100 users, fully open source, no strings attached. I said this to the first few people who stopped by, expecting it to register as a nice-to-have. It didn’t. It landed as a shock. More than one team stood there and said some version of, “Wait, we can just deploy this?”
You could watch it happen over the course of the week. A handful of teams that stopped by on Tuesday came back Wednesday saying they’d installed Obot the night before. By Thursday, a few had turned on the MCP gateway, connected the LLM gateway, and stood up their first hosted agents, right at the conference, without a sales cycle or a POC agreement. They were running it in a sandbox, which is exactly the point.
I’ve been to enough of these events over the last two decades to know how rare that is. Enterprise infrastructure vendors don’t usually watch attendees adopt the product mid-show. That we did tells me something about where the market is right now: teams don’t want a six-month evaluation. They want to try the thing, see if it works, and then talk. The fact that a genuine free tier moved the needle at a Vegas booth tells you something about where this is heading. Teams are tired of long evaluation cycles for tools they don’t yet know they need. Let them try it. If it’s good, they’ll come back.
What Ai4 Taught Me About AI Governance
Six months ago, I was still having conversations that started with “What’s MCP?“
At Ai4, nobody needed that explained. What people needed was permission to move, and tools that would let them move without breaking something, with effective AI governance giving teams a way to manage risk instead of forcing a choice between blocking or enabling adoption.
And the teams that seemed furthest ahead weren’t treating policy and platform as separate tracks. They were building them together, one team, one plan. The ones who had split the two were the ones stuck.
What This Means for Enterprise Teams
If there’s one practical takeaway from Ai4, it’s that waiting for AI adoption to slow down while governance catches up probably isn’t a strategy. The tools are already being used, and the local AI surface is expanding faster than most security teams can track it.
For enterprise teams, that means AI governance has to move closer to where the work is actually happening. A centralized gateway is part of the answer, but it isn’t the whole answer when developers are running agents, MCP servers, Skills, and CLIs locally. Teams need visibility into both centralized and device-level activity, with policies that can follow those tools wherever they run.
It also means security and platform teams can’t solve this independently. The organizations that seemed furthest ahead at Ai4 were giving developers a supported path to use AI while building governance into that path from the beginning. The goal wasn’t to eliminate experimentation. It was to make experimentation visible, governed, and easier to do safely.
That’s the shift I expect we’ll see more of in 2026: AI governance becoming less about deciding whether employees can use AI and more about giving them a secure way to use the tools they’ve already started adopting.
If you were at Ai4 and we didn’t connect, or if you weren’t there but this sounds like your team, give Obot a try. The Community Edition of Obot is available at github.com/obot-platform/obot, and our 90-day Enterprise MCP Quick Start Guide is available here. Otherwise, I’ll see you at the next one.
