NerveLoop: The Effect Firewall for AI Agents

• 

  The proof boundary: what is demonstrated locally and what remains open validation.

• 

  The system: planner, host-owned firewall, worker, recovery guard, and evidence receipt.

• 

  The promise: deny one unsafe effect and keep the useful session alive.

• 

  The measured result: prevention, bounded recovery, and mutation-tested policy behavior.

An autonomous engineer should be free to think broadly without being free to do anything it can describe. NerveLoop is the control layer between those two facts.

It lets the agent propose work, but keeps authority in the host application. If one proposal is unsafe, NerveLoop removes that effect without throwing away the agent, its context, or the safe work it already completed.

What the demo shows

The demo is one continuous agent session, not four unrelated screenshots:

1. A normal repository change runs and is kept.
2. The same agent proposes a protected delete.
3. NerveLoop rejects that delete before a worker starts. No capability is issued, no file changes, and the receipt records that nothing needed to be restored.
4. In a separate recovery test, an allowed worker writes outside its declared scope. RunGuard detects the change, restores the bounded checkpoint, and withholds the worker's output. A later safe run still succeeds on the same agent.

That distinction matters. "The bad action never ran" and "the damage was repaired" are not the same result. NerveLoop records them separately.

Why the architecture is different

NerveLoop treats an agent run as a controlled process, not a trusted chat:

• the Planner proposes an exact effect;
• the host-owned Effect Firewall admits or denies it;
• the Worker receives only a short-lived, one-use capability for the exact admitted action;
• RunGuard verifies the terminal workspace and restores or holds if it drifted; and
• the Receipt binds the proposal, decision, dispatch and outcome into one causal record.

The model never becomes the authority. Prevention, recovery and safe continuation remain separate system states, each with its own proof.

How it works

The Effect Firewall uses a closed, monotone policy over operation and target classes. If a proposal is allowed, NerveLoop issues a short-lived capability tied to that run, agent, file and payload. The cooperative Effect Sink accepts only that exact write. RunGuard then keeps the final workspace, restores the bounded checkpoint, or holds the agent for review.

The agent can plan freely, but it cannot grant itself authority.

What improved in the local tests

• All 28 denied admission cases dispatched zero workers.
• All 36 protected-path mutations were detected and restored.
• Across six repeated runs, reset-all touched a median of 32 logical targets, pre-dispatch prevention touched 0, and bounded rollback touched 1.
• The policy test covered all 20 action/target cells and 130 monotonicity relationships, and it caught 20 out of 20 deliberately broken policies.
• The capability lab rejected 32,767 out of 32,767 mutated envelopes and 63 out of 63 mutated request contexts.

These are deterministic local fixture results. They are not TikTok-scale or production benchmarks.

What this prototype does not prove

NerveLoop is user-space middleware, not an operating-system sandbox. The demo uses a fixed no-model runner and makes no Ark or provider calls. It does not prove hostile-process isolation, production security, TikTok access, model quality, or performance gains. The exact cooperative sink covers one declared fixture write; ambient file APIs can bypass it, which is why the separate RunGuard recovery line still exists.

The prototype's claim is deliberately narrower: for this working local flow, known forbidden work is denied before dispatch, admitted drift is restored after execution, and later safe work can continue on the same agent.

Built With

• codex
• fastify
• node.js
• react
• typescript
• vite
• vitest