The Agent Governance Gap Nobody's Fixing — What VB Transform 2026 Revealed

VB Transform 2026, held 14-15 July at Hotel Nia in Menlo Park, was supposed to be about agentic orchestration. And it was, on stage. But the conversations that actually mattered — the ones in roundtables, over coffee, in the hallway between panels — were about something far less glamorous.

Governance.

The numbers VentureBeat surfaced from their Pulse survey of 101 enterprises should make every ops leader pause. 71% admitted that a quarter or fewer of their deployed "agents" are actual orchestrated multi-step workflows. The rest are chatbot wrappers wearing a bigger label. 27% have no real-time mechanism to stop a runaway agent — no kill switch, no circuit breaker, no emergency off button. And 70% are handing agents service-account-level access. Not scoped identities. Not least-privilege tokens. Full access, same permissions as the human who set them up.

And then there's the Merck story. Their agent started hallucinating test functions that didn't exist anywhere in their codebase. Inventing API calls, confidently, and attempting to execute them. Their fix wasn't better governance. It was deploying a second AI model to supervise the first one. That's not a governance framework. That's an arms race. And it's a losing one, because now you have two agents to monitor instead of one, and the second one hallucinates too.

Why the "agent" label is doing actual harm

The word "agent" implies autonomy and competence. What most enterprises have deployed doesn't meet either bar. They have chatbots with tool access. The distinction matters because governance requirements for a chatbot are fundamentally different from governance requirements for an agent that can initiate financial transactions, modify customer records, or send external communications.

A chatbot that gives a wrong answer is a customer experience problem. A chatbot that confidently fabricates policy details is embarrassing but contained. An agent that approves a £47,000 purchase order based on a hallucinated discount is an audit finding, a liability, and possibly a regulatory matter. Conflating the two under the same label means governance frameworks are being designed for the wrong threat model.

The regulator question is the one that should keep ops directors awake. VB Transform's governance roundtable surfaced this repeatedly: most enterprises couldn't explain their agent architecture to a regulator if asked. Not couldn't explain it well. Couldn't explain it at all. The audit trails don't exist. The permission boundaries are blurry. The kill switch is the engineer who deployed it, and only if they're awake and near a laptop.

The five things every ops team needs before deployment

I've spent the last year talking to teams that shipped agents to production and teams that pulled them back. The successes share five things. None of them are optional.

Identity. Every agent needs its own distinct identity. Not a borrowed human account. Not a service account with elevated privileges. A unique, auditable identity tied to the human who authorised its deployment. When something goes wrong at 2 a.m., "a service account did it" isn't an acceptable answer. You need to know which agent, triggered by whom, with what permissions, made which decision.

Audit trail. This means logging every tool invocation, every data access, every decision the agent makes, with full context. Not just "Agent called Salesforce API." You need to know what it called, what it returned, and why it made that call in the first place. Most agent platforms log outputs. Almost none log the reasoning chain that led to the action. That reasoning chain is the difference between "we have a bug" and "we have a liability."

Permissions. Least privilege. Scoped by capability, not by system. Instantly revocable. If the agent only needs to read invoices and draft responses, it shouldn't be able to approve payments, delete records, or modify user roles. Permissions should be granular enough that you can say: this agent can read Orders, create Draft Responses, and nothing else. Not: this agent has Sales-system access.

Data boundaries. Agents should only see the data they need for the task at hand. This is harder than it sounds when enterprise data is scattered across six systems with inconsistent access controls. If your agent can't distinguish between "customer PII the support team can see" and "customer PII the billing team needs," it's going to leak. Data boundary failures — not model failures — were the root cause of most production incidents discussed at Transform.

Kill switch. Not just "we can turn the agent off." The ability to halt execution mid-task, roll back completed actions, and quarantine session data for forensic review. If killing the agent also kills the service it powers, you've designed yourself into a corner. The kill switch should stop the agent, not the business process.

Why structured platforms have a five-year head start

Here's the part that gets interesting for anyone building on no-code. Platforms that were designed around structured data, permissions, and user roles — Bubble, Stacker, Retool — have an architectural advantage for agent governance that AI-native platforms completely lack.

Stacker's permission model determines exactly which records any user (human or agent) can access based on role. If an AI agent is triggered by a customer service rep, it inherits customer-service-level data boundaries, not admin-level access. The audit trail is built into the platform, not bolted onto the agent. The kill switch is platform-native. You're not designing governance from scratch for each agent. You're extending existing governance to a new category of user.

Bubble's role-based access controls work the same way. An agent operating within a Bubble app inherits the app's existing permission structure. The governance was built before the agent existed.

Compare this to AI-native agent platforms — CrewAI, LangGraph, AutoGen — where governance is entirely DIY. You're wiring up identity, permissions, audit, and kill switches yourself, usually after you've already deployed something to production. That's not governance. That's incident response waiting to happen.

The question every ops team should ask this quarter

Not "which AI agent platform should we buy?" That's putting the cart three miles ahead of the horse. The right question is: "Do our existing access controls, audit systems, and identity infrastructure extend to AI agents, or do we need new infrastructure?"

If the answer is "we need new infrastructure," you're not ready to deploy agents to production. Build the governance layer first. The agents will still be there when you're done. And the ones deployed without governance? They'll be the case studies at next year's Transform — the ones everyone nods solemnly about before going back to their own ungoverned deployments.

The governance gap isn't a technical problem. It's an incentives problem. Governance doesn't ship features. Governance doesn't make the demo reel. Governance is the thing you skip when the VP is asking why the agent still isn't in production. Until skipping governance has consequences as visible as shipping features has rewards, the gap stays.

What changed at VB Transform 2026 is that enough incidents have piled up — enough hallucinated purchase orders, enough runaway token burns, enough service-account breaches — that the consequences are starting to become visible. Whether they're visible enough to change behaviour is the question that'll define the next twelve months of enterprise AI.