NullRun
AI Agent Governance
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?
Hey Indie Hackers
For the past 7 months I've been building NullRun - a runtime authorization layer that sits between your AI agents and the outside world.
The problem I'm solving:
Companies are shipping AI agents everywhere (LangChain, CrewAI, MCP-based), but most have zero control over what those agents actually do at runtime: an agent can blow through budget, trigger an unsafe tool call, or delete something in production - and nobody finds out until it's too late.
What NullRun does:
1 - statefull caps spend at the agent level
2 - blocks unsafe tool calls before they execute
3 - requires human approval for critical actions
4- logs and audits every decision the agent makes
It's a drop-in layer in front of any agent framework (LangGraph, CrewAI, OpenAI/Anthropic/Gemini agents) - no need to rewrite agent logic.
Status:
The product is production-ready, but revenue is still $0
I'm looking for my first pilot customers to validate whether teams already running agents in production are ready to pay for this kind of governance layer now, or if the market just isn't there yet.
Question for you:
If you're deploying AI agents to production right now - how are you handling budget control and unsafe actions? Duct-tape scripts, custom middleware, or nothing at all?
Would really appreciate any feedback, especially from anyone who's already gotten burned on agent spend or safety.
-
1
The “blocks unsafe tool calls before they execute” boundary is the part I’d be most interested in pressure-testing.
Where exactly do you consider execution to begin?
If NullRun blocks before the request leaves an enforceable boundary, you can make a pretty strong prevention claim. But once a request has been accepted, queued or dispatched into an external system, a local BLOCK record may only prove what NullRun decided — not that the downstream consequence was prevented.
The nasty case would be: action is authorised → dispatched → authority changes → external outcome becomes ambiguous.
Does NullRun preserve that as an unresolved outcome, or is the audit model currently primarily recording the authorization/enforcement decision?
I’d be genuinely interested in how you’ve handled that edge.
-
1
Fair. The useful boundary is narrower than “the system prevented the outcome.” NullRun governs the action before it crosses the enforcement boundary, the gate makes the authorization decision, reserves the relevant budget, and binds the execution to that decision before the downstream call is allowed.
If the action is blocked, it doesn't leave that boundary.
If it is allowed, the execution carries its server-owned identity and policy snapshot into the execution path, while tracking records what happened after authorization.NullRun doesn't claim control over an external system once that system has accepted the request.
So the audit model separates authorization from downstream execution outcome; the gate proves what authority was granted, not that an external system can never produce an ambiguous result.-
1
Yes — that boundary makes sense to me.
If NullRun can prove that a blocked action never crossed its enforcement boundary, that’s a strong claim because the gate actually owns the decision point.
The interesting case starts on the other side.
Suppose the gate authorizes A1, binds the policy snapshot and server-owned identity, and A1 crosses the boundary. The external system accepts it — perhaps even returns 202 — but the eventual consequence is delayed, duplicated, partially applied, or cannot yet be observed.
At that point I think we agree the authorization record remains valid, but it cannot inherit truth about the consequence.
That separation is exactly what I’m interested in:
NullRun can establish what was authorized to leave the controlled boundary.
The downstream evidence has to establish what actually happened after it left.
There may actually be a useful test at that seam. If you're interested, we could freeze one bounded action before running it and independently classify what each system can prove at authorization, dispatch and consequence. No integration required — just compare the evidence claims afterward.
That would tell us pretty quickly whether the two models overlap or are solving different halves of the same problem.
-
-
-
1
The $0 revenue is less interesting than the urgency question. Have you found teams already running agents that consider spend limits or unsafe tool calls painful enough to pay for now, or are most treating governance as a future problem?
-
1
That urgency question is still the validation gap for me.
I’ve found the problem is easy to recognize once agents can spend money or invoke sensitive tools, but recognition and budget approval are different things.
NullRun doesn't assume that future need becomes present demand, the current goal is turning that distinction into paid pilot evidence.
So I’m treating willingness to pay for runtime enforcement as the question to answer next, rather than assuming the market is already there.-
1
That distinction between recognizing the problem and actually getting budget approved is exactly the part I’d be interested in digging into. If you’re open to it, what’s the best email to reach you on?
-
-
Comment