centrol enterprise

A local-first accountability layer for coding agents (Claude Code, Cursor, Windsurf, or anything else you run from a terminal or point at an MCP server).

Centrol doesn't control everything your agent can do — only what passes through the two main interfaces it wraps, the filesystem and MCP tool calls. Within those, it blocks what violates policy and gives you an append-only, hash-chained audit record of everything else, so you can review it, verify it hasn't been tampered with, and roll it back.

Central Control of your agents. Record, Restore, Guard.

When you let an AI agent work on your machine — running commands, editing files, calling tools — the only record of what it did is usually the agent's own log. But if an agent goes off the rails, its own log is the one thing you can't trust, because the agent wrote it about itself.

Centrol sits completely outside the agent. It writes an independent, tamper-evident record that the agent cannot touch or alter. When something goes wrong, you can see what actually happened and prove it — to a manager, an auditor, or an insurer — without asking anyone to take the agent's word for it.

This gives you the management, insight and visibility you're missing — through a truth ledger you can use to assess decisions, direction, stages, and deviations, and to build confidence and trust in your agents.

AI is a black box. Centrol clears the ambiguity.

Eliminate agent blind spots before they catch up to you.

Free. Runs entirely on your machine. No cloud, no account, no telemetry. Nothing leaves your computer.

Functions:

The proxy is the part that acts

The record tells you what happened. The proxy is what changes what's allowed to happen. It sits between your agent and every MCP server it talks to. Every tool call passes through it before anything executes — that's where allowlists and blocks happen. A call that violates policy doesn't run. It gets recorded as having been refused.

That's the difference between watching and governing. You decide what's allowed, once. The proxy enforces it on every call, without you being in the loop each time.

Setup is one command. centrol proxy install <client> rewrites your MCP config so every server launches through the proxy. You run it once. After that it's automatic — no wrapper around your agent, no changes to your servers, nothing to remember before you start a session. It backs up your original config first, and it's safe to re-run: anything already wrapped is left alone.

What you get day to day:

• A gate that runs whether you're watching or not

• A record of both what ran and what was refused

• The ability to loosen or tighten access without touching your agent or your servers

• Nothing left running when you're not — no daemon, no service, no port

Guard is what you run agents under

There's no reason not to. Guard doesn't slow the agent down, change what it does, or add a step to your workflow — you run the same command with one word in front, and the run is recorded.

Two things happen when it starts. Every action gets recorded out-of-band — commands, file mutations, tool calls — so there's a record independent of the agent's own. And a snapshot is taken, so whatever the run produces, there's a state to return to.

When it goes sideways, you have the record of what happened and centrol undo to get back to before it started. When it doesn't, you still have the record — which is the part you'll want three weeks from now when you're trying to remember what an agent actually did.

Guard and undo are one workflow. Guard takes the snapshot; undo is how you get back to it. Run something under guard and you can reverse it.

Undo doesn't mean "revert everything"

Most rollback tools work the same way: restore the snapshot, lose whatever happened since. That's fine if the only thing that changed was the agent's work. It's a problem if you also touched something while the agent was running.

Centrol's undo is scoped to what the agent did. Your own work in progress is left alone.

Here's how it goes. You run the rollback, it confirms the restore succeeded, and then it shows you what the snapshot didn't have — the files and paths that appeared while the agent was running. Those are the ones the rollback couldn't account for, so it doesn't guess. It lists them, and you decide: keep, delete, move, whatever's right for that file.

Nothing is destroyed on your behalf. The decision stays with you.

That matters more than it sounds. If undo could silently eat an hour of your own work, you'd never reach for it — which means the agent's changes would just stay there. Undo is only useful if it's safe to run. This one is, because it hands you the list instead of making the call.

centrol undo --list shows what snapshots exist. centrol undo --from <id> restores a specific one instead of the most recent.

Why it matters:

1. The record is produced outside the agent's process.
Separate process, separate identity, separate storage, separate code path. The agent has no write path to the record. An agent's own logging has a conflict of interest built in — if the agent is compromised, its log is compromised. This is the same trust topology every evidence-producing domain converged on: you don't accept a company's own security report as a SOC 2.

2. Nothing to install, nothing to keep running.
No daemon. No service. No port. No "is it up." It activates when the agent invokes it and is gone when the agent ends. Nothing persists between runs, which means there's nothing left running to patch, monitor, or attack.

3. It works with no network at all.
Single Go binary. Same code on a laptop and in a SCIF. No cloud, no account, no telemetry, no phone-home, no license check. Air-gap compatibility is the default posture, not a feature bolted on.

4. It's free and complete — not a demo of the paid version.
The free tier does the whole job for one developer on one machine. It isn't a teaser, and it doesn't expire. There's an enterprise tier for fleet-scale governance, but nothing in the free tool is artificially limited to sell it.

5. It doesn't just record. It can refuse, and it can undo.
Most logging tools are passive. Centrol sits in the call path and inspects calls before they execute — allowlists and blocks happen pre-flight. When something does get through, rollback restores state with provenance, so the ledger shows what changed and why.

6. Setup is one command.
It rewrites your client's MCP config so every server launches through the proxy. Setup is one command, and it's idempotent.

7. Anyone can verify it, offline, without trusting you or the vendor.
centrol audit --verify checks the hash chain across every ledger segment. No network, no vendor involvement, no account. A third party with a copy of the ledger can confirm the record is intact and unaltered.