Human-gated AI for infrastructure / a Volenti project
Put an AI to work on your
infrastructure. Never let it
act alone.
Watchling reads your hosts, finds what is actually wrong, and proposes a real fix. Then it stops and waits for a person. Every action is approved by a named human and signed into a ledger you can read. Not automation that replaces your team. Instrumentation that makes them harder to argue with.
The premise
An LLM is genuinely useful here. It is also wrong often enough that you cannot hand it your estate.
Both halves of that are true, and most tools in this space only believe the first one. Watchling is built around the second.
A model is very good at reading ten thousand lines of log and telling you which forty matter. It is good at noticing that a firewall rule opened six months ago no longer has anything behind it. It is good at writing the runbook nobody had time to write.
It is also confidently wrong, susceptible to whatever it just read, and has no idea
which box is load-bearing at 2am. So it does not get a shell. It proposes a typed
action from a catalog you own, and anything outside that catalog is not blocked, it is
inexpressible. Denylisting dangerous commands does not work: rm -rf /
is easy to catch, and a base64 heredoc, a two line Python script or find / -delete
all walk straight through. You cannot denylist a Turing-complete input.
Then a person decides. Not a policy engine standing in for a person. A person, by name, whose approval is bound to the state of the world it was granted against. If the world moves before it runs, the approval is void and it comes back to you.
What it does
Expose. Resolve. Record. Improve.
One loop, run against real hosts. The audit trail rides underneath as the safety rail, not as the headline.
Find what is actually wrong
A host-native scan, on the machine itself: errors buried in journalctl,
firewall rules and what they really leave reachable, updates you are missing, security
holes worth someone's attention. Sorted into two lenses, Problems and
Security, kept separate on purpose.
It also reconciles what is on the wire against what your records claim, so the inventory stops rotting. That part is useful. It is not the point.
Propose a fix, in proportion
The AI drafts a resolution as a typed action and explains its reasoning. Crucially it is allowed to say it is not sure: for a risky finding it can propose observing first, instrumenting the thing for a day and coming back with evidence, rather than confidently closing a rule that something you forgot about depends on.
Nothing runs until a human approves it. Consequential actions are approved per system, never in a fleet-wide batch.
Write it down where it cannot be edited
Every proposal, approval, refusal and execution is signed into an append-only, hash-chained ledger on the machine itself, and the scan notation is kept encrypted on the endpoint as well as in Watchling's own database.
The ledger is readable by the administrators whose work it records, not only by auditors and management. That is a deliberate choice and it is in the source tree.
Leave the place better than you found it
What was learned does not evaporate. The assistant keeps operational memory across sessions, so the same gotcha is not rediscovered every quarter, and it drafts the runbooks and how-tos a good administrator would have written if there had been time.
The AI drafts. A human approves before anything publishes. Plain sentences, no decoration, written so a new admin can act on it.
What using it looks like
The interesting part is where it says it is not sure.
$ watchling scan web-01 host-native scan . agent . 4 findings . no plugins required [ 1/4 ] SECURITY nftables: inbound 0.0.0.0/0 → tcp/5432 observed 14d . 3 distinct source ASNs . none of them yours assist proposes "Postgres looks reachable from anywhere. I can't tell what depends on it, so I'm not proposing to close it. Measure first:" 1. capture matching flows for 24h net.capture.timed 2. re-evaluate and report back schedule.reevaluate risk low . writes none . reversible . expires in 4h (a)pprove (e)dit (d)eny (w)hy (s)kip > a approved by [email protected] . scheduled ledger 0f3a91c . signed . chained to 8b2e04f [ 2/4 ] PROBLEM 38 identical unit failures since 03:14 postfix/smtp: connect to relay timed out assist proposes service.restart postfix, plus a note that this is the third time this month, so the relay is the real bug (a)pprove (e)dit (d)eny (w)hy (s)kip > a executed . exit 0 . ledger 1c77b20 runbook draft queued for review: "postfix relay timeouts"
Plugins
Bring what you already run. Or bring nothing.
The source of truth is the host, so the core never depends on any of these being present. Connect one and it gets richer, in that tool's own language.
State and maintenance windows become part of the picture, and of the gate.
Your intent, read as intent. Disagreement surfaces as a finding, never a silent update.
Runbooks and how-tos, drafted from what was actually observed, published on approval.
Where you already run it, that host is the jumpbox too, and the wizard scaffolds it in.
Start at zero. Suggestions come from real evaluation of your hosts and real results, never from a plugin's say-so. Add a plugin later and the assistant applies what it already learned to make genuine suggestions in that plugin's domain. Enrichment, never a prerequisite.
Human in the loop
This is not a tool for having fewer administrators.
We are not asking you to believe that. Most of what follows is enforced by the software or by a test that fails the build, and the rest is checkable against how we charge.
No flag, no environment variable, no API parameter and no database column moves a consequential action to automatic. No auto-approve, no trusted mode, and no remediation on a cron either, because unattended remediation on a timer is just replacing the on-call rotation. A test enumerates every configuration surface and fails the build if one ever appears. We expect to be asked. The answer is no.
One person approving five thousand actions in a batch is ten administrators' throughput routed through one, which is precisely the substitution this product exists not to enable. Approvals are rate limited per person, and consequential actions are approved per system. The target is one administrator doing their job better, never one administrator doing twelve people's jobs.
Who approved something is a forensic field, so you can answer what happened and who agreed to it. It is never a grouping dimension. No throughput counts per person, no leaderboards, no ratios, no dashboard that ranks your staff by how fast they click approve. There is no endpoint that will return it.
The record of an administrator's work is readable by that administrator, not held above them for review. An audit trail that only management can read is not transparency, it is surveillance with better branding. Nothing is ever rewritten: a correction is a new signed entry that supersedes the old one, and both remain.
No HR integrations, no personnel-event correlation, no termination keyword detection. Not as a feature, not as telemetry, not as a configuration hook. Deliberately absent, and named here so its later arrival would be a visible act rather than a quiet one.
Scanning a network carries real legal exposure, and deploying software is not consent. Before anything is probed you sign a scope: the ranges, the exclusions, the expiry. The scanner verifies that signature against the scope's own contents on every run, so widening it behind the software's back makes it refuse to start and write down that it refused.
The part that costs us money
Watchling is priced per approving human, not per managed system. Per-node pricing earns the same whether a team has twenty people or two, which makes the substitution arithmetic trivial for someone to write. Per-seat pricing means we are sold as equipment for a team, and it means something more useful to you than any promise we could make: our revenue shrinks if you cut your team.
We will also say the honest part out loud. Any tool that reduces the hours needed to run infrastructure can end up cited in somebody's layoff justification, and a company that swears otherwise is lying to you. What we can do is refuse to build the features that make it easy, put those refusals in the source tree where a test enforces them, and state them publicly at version one, so that abandoning them later would have to be a visible act.
The full policy, including what would break it, ships in the repository as HUMANITY.md.
Where it actually is
In development. Here is the honest state of it.
A limitation dressed as a feature is a lie with better lighting. So, plainly:
The trust substrate is built and is the part that took the time: the signed ledger, the typed action catalog, the approval gate and its re-validation, consent and tenancy, operational memory. Discovery runs against real hosts, with signed scope enforcement and a walkthrough that survives a lost connection. It stores to PostgreSQL and reads NetBox as intent where you keep one.
The host-native scan, the assisted resolution loop and the plugin waterfall are being built now, on top of that substrate rather than beside it. There is no packaged release, no installer, no hosted version, no pricing page and no signup.
Unattended execution of consequential actions. Metrics that count what individual people approved. Any collection of data about your staff. These are refusals, named now, before there is money on the table to change our minds.
Get in touch
If you run this stuff for a living, we want to hear from you.
We would rather build the rest of this against real estates than imagined ones. Tell us what you run, what wakes you up, and what would have to be true before you would let a model anywhere near it. If you think we have the balance wrong, that is the most useful message you could send. Every one is read by a person.
[email protected]There is no signup form here, and no tracking on this page. When there is
something to try, this is where it will be announced.
Security disclosure: [email protected]