Blog
·4 min read·VAIBot

AI governance that doesn't ship your work to a cloud

architectureprivacysigned-policy

Most tools sold as “AI governance” are dashboards. You route your agent's traffic through their proxy or SDK, and they show you charts of what happened. Two things are wrong with that shape, and they are related.

Observation is not enforcement

A chart that lights up after your agent exfiltrated a file or ran a destructive command is a smoke detector that emails you the next morning. If the control does not sit in front ofthe action with the authority to stop it, it is not governance — it is analytics with a compliance logo.

To watch everything, they have to see everything

The second problem is the cost of that visibility. To render those charts, the product has to ingest the traffic: your prompts, model outputs, file contents, the secrets your agent handles. You closed one risk (an unsupervised agent) by opening another (a third party with a copy of everything the agent touched). For a lot of teams that trade is a non-starter, and they end up governing nothing.

Invert it: ship policy, not data

VAIBot puts enforcement at the client — the point where an action actually leaves the machine — and inverts what crosses the network. Instead of the client streaming your data up to be judged, the control plane sends a signed policy and mode down to be enforced locally.

  • The control plane issues an Ed25519-signed policy bundle and an effective mode (observe / enforce) scoped to your account.
  • The local enforcer — @vaibot/guard and the gateway — verifies that signature, then makes every allow/deny decision on your machine, against the policy it just verified.
  • Your prompts and commands do not get shipped anywhere to be scored. The network carries instructions, not your workload.

The signature is the load-bearing part. The policy is the only thing that has to be trusted, so it is the thing we make tamper-evident: a compromised network or a spoofed endpoint can't hand the guard a quietly-more-permissive policy, because an unsigned or mis-signed bundle is rejected. Trust the math, not the transport.

The chokepoint is a local proxy

For model traffic specifically, the enforcement point is the VAIBot gateway: a local-first LLM proxy (written in Rust) that any agent can point at, no VM required. It is agent-agnostic and it runs next to your work, so the egress decision happens where the egress happens. Same idea as the guard, one layer down.

What you give up, and what you get

The honest tradeoff: you lose the “single pane of glass that sees all traffic,” because we deliberately don't collect your traffic. The control plane still coordinates — it distributes policy, flips modes, and collects the receipts you choose to publish — but it does so by sending signed instructions, not by slurping your session. You can even run fully local and let it coordinate nothing.

Yes, we have telemetry — no, it's not the same thing

Worth being precise, because the distinction is the argument. VAIBot collects anonymous, aggregate product telemetry — which version, which platform, whether a command ran. No prompts, no file contents, nothing that ties back to you, and the CLI honors DO_NOT_TRACK. That is ordinary analytics, and it is a categorically different act from what “AI governance” usually means: routing your workload through someone's cloud so it can be read and enforced. This post is about the second thing. Counting installs and ingesting your session are not the same, and we don't pretend they are.

Enforcement belongs where the action is, and the action is on your machine. That is the whole argument. Try it, or see the concrete version of “stop the action” in the circuit-breaker post.

Put a brake on your AI stack.

One command installs the guard across the agents you already use — free, no signup to start.

$ curl -fsSL https://vaibot.io/install.sh | sh