Evidence note: this article rests mostly on primary material published by the parties involved — vendor engineering blogs, a project’s own documentation, and platform figures the platforms published about themselves, dated through late October 2026. None of it has been independently verified here, and several of the products described are new enough that no third-party reporting exists yet. A small number of figures come from this site’s own pipeline records; those are measurements of one system by its operator, not independent corroboration. Where the only source for a claim is the party that benefits from it, the text says so at that claim rather than once in a disclaimer.
What landed this cycle: one policy gate, two always-on platforms, two vendor security architectures
Five releases in the same few weeks point at the same problem from different distances.
The closest in is a small open-source tool called Rampart, which its author describes as evaluating every AI agent tool call against a policy file the user writes, before the call executes, and classifying each action as allowed, denied, or flagged (project repository). That description comes from the project itself; no independent audit of the behaviour has been published, and the accompanying discussion thread is community commentary rather than verification.
A step out are two platforms built to keep agents running without a human present. LiberClaw is presented as an open-source platform that gives each agent its own dedicated virtual machine with its own filesystem, database, and HTTPS endpoint — agents defined by a plain markdown skills file, with persistent memory across conversations, a heartbeat for background work, and tools for shell, files, web fetch, web search, and spawning subagents. Every part of that description is the project’s own and remains uncorroborated. Computer Agents describes a similar shape commercially: one isolated cloud computer per agent, a workspace where files, code, and memory survive across sessions so a project can be iterated on for weeks, work triggered by cron schedules, webhooks, or a "keep working until done" mode, and results delivered by email, Telegram, or on-demand check-in. It also advertises code execution in isolated containers with automatic package installation, a research skill that cites dozens of sources, and multi-agent orchestration in chain, parallel, map-reduce, and conditional patterns. These are vendor claims on a product page, not tested results.
Furthest out are the enterprise architectures. Google Cloud describes Project Chrysalis as combining its enterprise agent platform, its Agent Development Kit, and BigQuery behind a four-gate defence-in-depth stack — prompt and output screening, key management, binary authorisation, and a policy engine (Google’s own engineering post). NVIDIA published two pieces in the same register: one on a runtime security component built on the premise that an agent can finish its assigned task and still cross a security boundary, and one on a reference architecture for governing agent workloads at scale, written around agents that run for hours touching files, tools, and the internet, and spawning further agents. Docker, meanwhile, documents MicroVM sandboxes for running coding agents with custom network policies, an eval harness that puts every task inside one, and a catalogue of top agent security risks including prompt injection, excessive autonomy, and credential exposure. All of these are first-party descriptions of first-party products.
Why it matters for a one-person team
Docker’s write-up of the 2026 Stack Overflow Developer Survey reports that only 7% of developers trust AI output for important decisions (Docker’s summary). This article has not cross-checked that figure against the survey’s own published tables, so treat it as a single-source number — but the direction is the interesting part. Trust is low while delegation is high.
Two other first-party datapoints from the same cycle sharpen that gap, both uncorroborated. Unity says telemetry covering more than 200 million command-line events shows 98% of runs come from AI coding agents and automation rather than humans (Unity’s own blog). Microsoft, arguing for a discipline it calls Agent Experience, states that coding agents now choose the SDK, the version, and the pattern on a developer’s behalf (Microsoft’s framing, with a practitioner playbook for measuring it).
For a solo developer, the practical consequence is that "I’ll review it in the morning" is not a control. It is a hope. The question is not whether to trust the output; it is where the boundary goes so that distrust does not require being awake.
Three shapes of containment on record
Lined up, the releases describe three distinct placements.
A check before every tool call. The policy gate sits between the agent and the operating system: each shell command, file read, and file write is matched against a written rule set and either runs or does not. According to its own documentation, Rampart’s integration with one coding agent installs hooks that intercept Bash commands, file reads, and file writes before execution. Independent confirmation of that mechanism is open.
A dedicated machine per agent. The always-on platforms move the boundary outward: the agent gets root on something that is not yours. LiberClaw’s per-agent VM and Computer Agents’ per-agent cloud computer are both described this way by their makers. Neither description has been verified here.
A MicroVM per task. Docker’s sandboxes are the per-task version of the same idea — a disposable, network-policed environment created for one piece of work, which its documentation says can host agents such as Claude Code, Codex, and Cursor, with isolated agents optionally connected so they can collaborate across environments under managed access. Vendor description; not independently tested.
The three are not competitors so much as different answers to "what is the unit I am willing to lose?" — a command, a machine, or a task.
What the always-on platforms count about themselves
LiberClaw reports 61 agents running on the platform across 578 conversations with 99.7% uptime, and offers a free tier of two agents. These are self-reported platform statistics with no independent audit, and it is worth being precise about what they would establish even if exact.
Sixty-one agents and 578 conversations describe a small, early deployment — useful as evidence that the thing runs, not that it holds up under adversarial load. A 99.7% uptime figure, with no stated measurement window or definition of an outage, is not comparable to a service-level agreement. None of the three numbers says anything about whether an agent with shell access on its own VM did something destructive inside that VM, which is the question a reader actually has. The same reservation applies to Computer Agents’ description of weeks-long persistent workspaces: persistence is the selling point and also the risk surface.
The reason the policy gate exists
Rampart’s author states that the tool was built after running an AI agent around the clock on a home lab — managing a small Kubernetes cluster, issuing shell commands, editing configuration — unsupervised, with full visibility into every command the agent issued and no way to stop a bad one before it executed. That origin story is the project’s own account, and it is the most instructive part of the release precisely because it names the failure mode: observability without interdiction. Independent corroboration of the account is open.
A log tells you what happened. For an agent operating while you sleep, "what happened" and "what you can still prevent" are the same sentence only if something sits in front of execution. This site has made a related point from its own records before, in a piece on how agent execution records can be replayed without the models — a record is an instrument of reconstruction, not of restraint.
What a blocked action looks like from both sides
Per the project’s documentation, when a command is denied the command never runs and the agent receives an error instead. That asymmetry is the design’s whole content: the operating system sees nothing, and the agent sees a tool failure it must now reason about.
The tool is also documented as writing agent activity to a hash-chained audit trail, viewable live through a watch command or rendered as HTML reports. Both the enforcement path and the chained trail are described only by the project; neither has been independently verified.
Two consequences follow, and they are general rather than specific to this tool. First, an agent that receives an error will frequently try another route — a different flag, a different path, a script that wraps the same call. A deny rule is only as strong as its coverage of equivalent phrasings. Second, a hash-chained log is tamper-evidence, not prevention: it makes after-the-fact deletion detectable and tells you nothing in the moment. Our earlier reporting on what outranks an agent’s self-report lands in the same place: the independent record is the arbiter, after the event.
Google’s four gates, and the figure that leaves no room for a person
Google’s post on governed, self-evolving agents reports that agents in the described architecture remediate live production outages in 1.8 seconds (Google’s engineering blog). This is a vendor figure with no stated benchmark methodology published alongside it, and no independent reproduction; treat it as a marketing marker rather than a measured latency.
As a marker, though, it settles the article’s central question. If remediation completes in under two seconds, no approval queue fits inside the loop. Nothing a human types arrives in time. Which is why the same post pairs the capability with four gates that are all pre-decided: content screening on the way in and out, managed keys, authorisation of which binaries may run at all, and a policy engine evaluating actions against rules written earlier. The enterprise answer to speed is not supervision. It is pre-authorisation.
What changes once approval has to be written in advance
The artefact a one-person team maintains therefore shifts. It is not a notification inbox and not an approval rota; it is a policy file in version control that says which commands are permitted, which are refused, and which are merely flagged for later reading.
This has a maintenance cost that the announcements understate. A policy file is code: it drifts, it over-blocks until the agent stalls on legitimate work, and it under-blocks in exactly the paths nobody thought to enumerate. Writing it is a design exercise in naming the destructive verbs of your own stack — the package manager, the migration runner, the deploy command, the credential store.
The same pattern is visible higher up the stack. Google describes an extension system for its agent command line that lets platform teams author custom extensions enforcing deployment policies, automated software bill-of-materials scans among them, while developers keep using frameworks such as LangChain or LangGraph (Google’s post on the extension system). That description is Google’s own and uncorroborated, but the structural claim is the same one: the gate is authored once, by someone, in advance.
The same logic applied to credentials
Credentials are where pre-authorisation becomes concrete, because a leaked long-lived token is the one failure an audit trail cannot undo. Google announced support for Demonstrating Proof-of-Possession on its OAuth platform, binding refresh tokens to the client that obtained them — which, per the announcement, neutralises infostealer malware and adversary-in-the-middle theft, while short-lived access tokens remain standard bearer tokens (Google’s announcement). The security benefit is Google’s claim about its own platform; it has not been independently assessed here.
The companion piece for agent chains is token delegation: Google points developers building multi-agent or Model Context Protocol workloads toward its Secure Token Service for passing scoped authority down a chain of agents rather than handing every hop the same credential. Also a first-party recommendation, and worth reading with the question "what happens when hop three is prompt-injected?" held open, since the announcements do not answer it.
A gate that writes verdicts in one real pipeline
This site runs a written gate over its own output, which makes it possible to say what such a gate does and does not catch.
In this site’s own pipeline runs — 196 runs between 28 August and 25 October 2026, counted as of 25 October 2026 — the quality gate reviewed 1,964 drafts and issued three kinds of verdict: 1,656 published, 191 sent back for revision, and 117 rejected outright. That is an own-measurement of one pipeline by its operator, not an independent benchmark, and it is a gate over text, not over execution.
The distinction matters for this article. A gate that reads drafts and refuses them establishes that pre-written rules can be enforced mechanically at volume, with roughly one in six drafts stopped or returned in that sample. It establishes nothing about shell commands. Nothing in those 1,964 verdicts inspected a rm, a kubectl apply, or a credential read. Whether the same discipline survives contact with destructive system calls is untested here.
Taking the API key out of the always-on agent
A smaller thread in the same cycle is relevant to anyone leaving an agent running for hours: the cost and credential exposure of the model itself. LiberClaw’s makers say the platform runs inference through open models — naming Qwen3 Coder and GLM-4.7 — so that no commercial API key is required at all. That is the project’s own claim and unverified, but it is the architectural point: an agent with no frontier API key cannot leak one or run up a bill.
Two supporting releases, both first-party. Ollama lists NVIDIA’s Nemotron 3.5 Lightning as a 30-billion-parameter open model with 3 billion active parameters, built for agents that stay running, gather context, call tools, and work through multi-step tasks on local hardware (model announcement). Together AI says its Link product brings frontier open models, including GLM 5.3 and Kimi K3, into coding harnesses developers already use, and claims it cuts model spend by over 50% (Together’s post). The spend figure is a vendor claim with no disclosed workload mix behind it. Readers weighing local inference may also find our earlier piece on the three requirements for putting a model inside a local app useful on the hardware side.
Decision criteria: gate, sandbox, or both
Choose by what the agent is allowed to touch, not by what the agent is for.
Sandbox alone is sufficient when everything the agent can reach is reconstructible — a checked-out repository, a scratch database, a disposable container. If the worst outcome is deleting work that exists elsewhere, a MicroVM or a dedicated VM absorbs it, and a per-call policy adds friction for little gain. Docker’s own documentation of its sandboxes positions them for exactly this case; the positioning is theirs, untested here.
A gate is required, sandbox or not, the moment the agent holds something that is not reconstructible: production credentials, a payment key, a published package registry token, a live cluster. Isolation does not help when the dangerous capability is reachable by design from inside the box — which is precisely the situation the policy gate’s author describes from managing a home cluster.
Both is the honest answer for an agent that runs unattended with any network-reachable authority. The sandbox bounds the blast radius; the written policy bounds the actions that leave it. Docker’s own list of agent risks — prompt injection, excessive autonomy, credential exposure — maps onto this split: injection and autonomy are what the gate addresses; blast radius is what the sandbox addresses.
What neither buys you is confidence. The hash-chained trail, the per-agent VM, and the uptime percentage are all read after the fact. The only control that operates at the 1.8-second timescale Google advertises is a rule written before the agent started.
A proposed follow-up, not yet run
The obvious test has not been performed, and nothing in this article should be read as having performed it.
The proposal: put the shell steps of this site’s own publishing pipeline behind a written policy file — the deploy command, the git push, the file deletions — run the pipeline unchanged for a fixed number of cycles, and count three things. How many actions are allowed, how many are flagged, and how many legitimate steps are wrongly denied, which is the number that decides whether such a gate is usable by one person. A second measurement worth taking is how often the agent, on receiving a denial error, attempts an equivalent command by another route, since that rate is what tells you whether the rule set has coverage or only phrasing.
No run of this exists. No figures from it are available, and any result would be a measurement of one pipeline rather than a general finding.
How we apply this in Vision
Vision’s own records are the only place this article has numbers it produced itself, and they bear on the article’s argument in a specific, limited way: they show what pre-written rules do at volume when the thing being gated is text.
In Vision’s pipeline runs across 196 runs from 28 August to 25 October 2026 (counted as of 25 October 2026), 41,176 topic candidates were discovered across four categories from 224 distinct source hosts. Of 49,449 scored topics in the same records, 20,676 were rejected and 19,417 were held before production, leaving 9,356 that went forward. That is roughly four candidates stopped for every one admitted — the throughput cost of a gate placed early, measured on one pipeline by its operator rather than independently verified.
The evidence discipline shows the same shape. Across 7,228 research dossiers holding 37,422 claims in those 196 runs, 2,238 claims were independently cross-checked and 8,855 were primary-attested. Most claims in the record, in other words, qualify as neither — which is why an article like this one hedges so much of what it reports, and why the gate’s draft verdicts in the same period (1,964 drafts reviewed, 191 returned for revision, 117 rejected) are not evidence that the output is correct, only that the rules fired. Over the same 196 runs the pipeline recorded 1,720 published posts, logged as 408 new and 435 updated; the figures are reproduced as recorded, and the discrepancy between the totals and the breakdown is unexplained in the records themselves.
The decision this leads to for Vision is the one the article recommends to its reader. The boundary that matters is written in advance and lives in version control; the audit trail is for reconstruction afterwards, as the earlier account of why these systems were rebuilt twice already made plain. What is still missing — and stays open until someone runs it — is the same discipline applied to the shell, where a wrong verdict costs more than a rejected draft.