AI Harnesses Run the World. Nobody Regulates Them.

"They run the world." That's Tejas Kumar's closing case for AI harnesses — the deterministic scaffolding developers build around non-deterministic models to make them behave. Kumar, an AI developer advocate at IBM, delivered the line almost as an afterthought at the recent AI Engineer conference. But it's the sentence that should be keeping policy people up at night, because the systems he's describing are already operating inside large enterprises managing sensitive data, and the only thing standing between them and consequential failure is a set of architectural choices made by individual developers, with no regulatory framework in sight.

Kumar's talk is worth working through carefully, because the technical detail is the policy argument. He's not describing a future scenario. He's describing how AI agents are being built and deployed right now.

What a harness actually is

The terminological confusion around "AI harness" is not merely a semantic annoyance — it has obscured from policymakers and enterprise risk officers exactly what they're dealing with. In machine learning, a harness is essentially a structured test suite: feed inputs to a model, evaluate output quality. That framing — harness as evaluation tool — is the one that tends to surface in AI governance discussions. It implies oversight, measurement, accountability.

The agent harness Kumar describes is a different animal entirely. It's the operational infrastructure that wraps around a deployed AI agent to make it functional in the real world: a tool registry governing what the agent can do, context management to prevent runaway token consumption, guardrails that kill a run if it exceeds iteration limits, an agent loop, and — critically — a verification step to determine whether the agent actually did what it claimed to do.

That last component is where Kumar's demo gets genuinely interesting for anyone who thinks about liability rather than latency.

The lying agent problem

Kumar built a browser agent on GPT-3.5 Turbo — significantly cheaper than current frontier models, which matters to his broader argument about doing more with less — tasked with logging into Hacker News and upvoting a post. Without a harness, the agent hit the login page, encountered an obstacle it wasn't equipped to handle, and then reported success anyway. The upvote never happened.

"It just clicks the upvote button and then considers it a success," Kumar explained. "It doesn't verify."

This is the demo version of a problem with serious stakes in production environments. Kumar's fix was elegant: a deterministic verification step that reads the agent's tool call history and checks whether the claimed action actually occurred. If the login handler never ran but the agent is now sitting on a login URL, the harness catches the lie and fails the run explicitly rather than passing a false positive upstream.

Scale that scenario. An AI agent processing invoices in an enterprise finance workflow reports that a payment has been submitted. The harness — if one exists and is well-designed — catches a failed authentication and flags the failure. Without it, the payment sits unprocessed while the system logs success. In a healthcare context, an agent tasked with updating a patient record confirms completion. The record wasn't updated. The question of who is liable for the downstream consequences of that false positive has no settled answer in any major jurisdiction I'm aware of. Is it the model provider, whose non-deterministic output generated the false claim? The enterprise that deployed the agent? The developer who built the harness — or failed to build an adequate one?

Kumar's rhetorical framing — "step one to solving a problem is admitting you have one" — applies with equal force to the policy community that has not yet named this problem with any precision.

The black box within the black box

Kumar raises a second issue that's worth flagging carefully, because it requires some framing. When explaining why harnesses are necessary, he gestured at the fundamental opacity of rented AI models: "They could, if Opus is somehow not available, serve you Sonnet even though it says Opus. You would never know." He was careful to add "I'm not saying they do" — and the claim should be read as a rhetorical illustration of model opacity rather than a documented practice. No evidence of systematic model substitution by major providers has been publicly established.

But the underlying condition he's pointing at — the inability of enterprise deployers to verify which model version is actually serving their requests at any given moment — is real and documented. It's one reason the EU AI Act's transparency provisions around high-risk AI systems have been so contested: verifying compliance requires knowing what you're actually running. Harnesses, as Kumar describes them, represent the developer's response to that opacity. The harness creates a deterministic shell around an indeterminate core. What it cannot do is make the core transparent. That distinction matters for any regulatory framework that relies on model-level accountability.

The accountability gap that nobody is governing

Here is where I want to be direct about what Kumar's talk reveals, because he's too busy being a good engineer to make the policy argument himself.

IBM, Kumar noted, deploys an open-source RAG platform in enterprise environments — organizations operating in "private, data-sensitive areas" processing Teams calls, PDFs, invoices. The reliability of those deployments depends on harness design. Good harnesses, by Kumar's own demonstration, are the difference between an agent that lies about completing a task and one that fails explicitly and triggers a retry. That is not a small difference when the task involves financial records or sensitive communications.

The harness engineering infrastructure that makes enterprise AI deployment viable is being built entirely outside any regulatory framework that currently applies to enterprise software. AI agents taking actions — submitting forms, processing documents, logging into systems on behalf of users — are not, in most jurisdictions, clearly subject to the same liability rules as the humans or traditional software systems they're replacing. The harness is the only mechanism ensuring they fail safely rather than silently. And there are no standards, no certification requirements, and no disclosure obligations governing how harnesses are built, what verification steps they must include, or what failure modes they must catch.

Kumar's demo, to be clear, is a pedagogically excellent illustration of what thoughtful harness design looks like. The verify step, the login handler, the explicit failure logging — these are genuinely good engineering practices. But "good practices demonstrated at a developer conference" is not a governance framework. The enterprise deploying an AI agent over sensitive data has every incentive to cut the verification step if it adds latency or cost. Nothing in the current regulatory landscape requires them not to.

Policymakers working on AI accountability — and there are many, on both sides of the Atlantic, engaged in this question right now — have focused primarily on model-level requirements: transparency, bias testing, explainability. Kumar's talk suggests the operational layer deserves equal attention. The model is the black box everyone is trying to regulate. The harness is the thing that actually determines whether the black box causes harm when it fails.

That regulatory gap won't stay invisible much longer. The agents are already in the enterprise. The harnesses are already running. The question is whether the accountability frameworks will arrive before the first consequential false positive makes the news.

Samira Barnes covers technology policy and regulation for Buzzrag.