1
1 Comment

The part of AI agent governance I kept getting stuck on

AI Agents gap to solve with NullRun

When I started building NullRun, I thought the main problem was controlling what an AI agent can do. After working on it for months, I think the harder problem is who actually has the authority to decide whether an action runs.

An agent can decide:

“I should refund this customer.”

But should the agent itself be the final authority to execute the refund?

Or:

“I should delete this database record.”

“I should deploy this change.”

“I should call this external API.”

The agent can request the action. The application can expose the tool.
But neither should automatically mean the action is authorized.

That's the gap I'm trying to solve with NullRun.
The agent sends an execution request to NullRun, and an external policy layer makes the runtime decision:

  • allow -> execute

  • require approval -> wait for a human decision

  • block -> don't execute

The important part is that the policy isn't just sitting in documentation or in a dashboard.
It is enforced at the point where the action is about to happen.

This also changes how I think about “AI governance”.
A lot of governance work is about policies, monitoring, logs, evaluations, and compliance evidence.

Those are useful.
But eventually you still need an answer to a very simple runtime question:

“Should this specific action execute right now?”
That's what I'm building toward with NullRun: an enforcement layer between AI agents and production systems.

I'm curious how other teams handle this today.

If your agent can call production tools, where does the final execution authority actually live?

Inside the agent?
Inside application code?
In middleware?
Or somewhere else?

posted toAvatar for product NullRun
NullRun
  1. 1
    Anatolii — I think there's a second control boundary immediately downstream of what you've built. Suppose NullRun correctly authorizes a consequential action and the agent executes it. The tool then times out. NullRun can establish that the call was permitted. The trace may establish that it was dispatched. But neither necessarily establishes whether the external consequence actually occurred. For something like a payment, access change or infrastructure action, blindly retrying from there could duplicate the very consequence the authorization layer was protecting. That's the boundary I've been building OpsWatch around: consequence evidence → reliance → whether retry, continuation or the next dependent action is actually permitted. I'd be interested in taking one NullRun-protected consequential workflow and independently testing that downstream boundary. If it exposes a material gap, I'd want to scope the control between us commercially rather than turn it into another free technical exercise. Is that a problem you'd actually pay to solve if we can demonstrate it against NullRun?