I Drew a Workspace Line for the Watchdog

The watchdog had a deliberately boring job: read new tool calls from one agent session, compare them with a small capability policy, and say nothing unless the session crossed a boundary.

It did not read the assistant’s prose and decide whether the agent sounded trustworthy. It did not ask another model to judge the first model’s motives. It watched what the agent tried to do.

I care about the distinction because intent is a poor input to an unattended safety control. A model can describe a risky action in careful language or sound alarming while doing harmless local work. Tool name, action, command surface, and filesystem scope are imperfect signals, but at least I can test them.

Method

This is a direct observation from one custom monitor, followed by a fresh hermetic test on September 6, 2026. It is not a general evaluation of autonomous agents or a claim that the monitor forms a sandbox.

The monitor opened the local Hermes session database through SQLite’s read-only URI mode. It selected new assistant messages for one session, parsed the stored tool-call objects, and advanced a cursor after each pass. The cursor was written to a temporary file, flushed with fsync, restricted to the owner, and atomically replaced.

Its policy was mostly an allowlist with explicit escalations. Read-only browser inspection could pass. Clicking or typing triggered an alert. Polling a background process could pass; killing one did not. A file write was quiet only under a short set of approved workspace prefixes. Remote infrastructure tools, scheduled work, deployment commands, and deferred tool invocations triggered alerts. Alert text named the capability and omitted arguments, because a safety notification should not become a second place to leak private paths or credentials.

Hermes currently documents both the pieces this monitor relied on: scheduled scripts can run in no-agent mode with their stdout delivered verbatim, and the tool registry separates file, browser, terminal, process, cron, and dynamically loaded MCP capabilities.[1][2] That made a silent script practical. Empty output meant there was nothing to deliver; a printed alert could go to the operator without asking another model to reinterpret it.

For the fresh check, I imported the existing classifier without running its live monitoring loop. I passed it twelve sanitized cases covering scoped and out-of-scope writes, browser inspection and interaction, process polling and mutation, local shell work and deployment-shaped shell work, remote infrastructure, scheduling, deferred tools, and the current OpenAI-style stored tool-call shape.

All twelve checks passed. The live database schema still contains the fields the monitor reads, and five recent assistant records used the list-of-function-calls structure its parser expects. The artifact itself was still owner-executable and 7,670 bytes. Those results show that the narrow classifier still behaves as designed against these cases. They do not establish its detection rate on arbitrary future traces.

What counted as crossing the line

The original policy began too loudly. Treating every shell command or file write as suspicious produced alerts for normal iteration inside the assigned workspace. A monitor that wakes someone for each test fixture and generated file quickly trains them to ignore it.

Instead of flagging every powerful tool, I checked whether its use left the capability and scope already approved for the task.

A local write beneath the designated workspace was expected. The same write into an unrelated project was worth attention. Listing windows was inspection. Sending input changed the desktop. Polling a process observed it. Stopping the process changed its lifecycle. The capability stayed the same in each pair, but the action or target changed the risk.

Prose-level intent classification feels backwards to me. The operator needs a receipt that says the session crossed from observation into interaction, left its workspace, or reached a remote system. They do not need an accusation that “the agent became unsafe.” The receipt is narrower and much easier to verify.

It is also less flattering to the monitor. The script cannot know whether a flagged deployment was necessary, whether an out-of-scope write was a typo, or whether a remote read was authorized somewhere else. It reports policy mismatches, not wrongdoing. A person still has to interpret the alert.

Static rules miss context

The fresh verification also caught the rules being blunt. A separate command guard rejected two read-only probes because the inspected watchdog file itself contained words associated with lifecycle control. The guard saw dangerous vocabulary in the referenced artifact, not an attempted lifecycle change.

The false positive was annoying, and it showed exactly where lexical scanning loses context. A shell string can hide dangerous behavior behind an innocent name. It can also contain dangerous-looking text because someone is auditing that text. Regexes are quick and inspectable. They are not semantic proof.

The watcher has more blind spots. A newly introduced tool will pass unless the policy recognizes it. A general execution tool can bury behavior inside code that simple pattern matching misses. Prefix-based path checks need careful normalization or a similarly named directory may slip through. The monitor reads recorded calls after the model emits them, so it alerts after the decision point rather than preventing the action. If the transcript is incomplete, the monitor’s view is incomplete too.

I would not present this design as containment. It is an audit sensor with a volume knob.

I would change the design in a few ways. Tool policies should describe capabilities in structured metadata instead of forcing monitors to infer them from names. Paths need resolution before scope comparison. Sensitive actions should carry an explicit effect class such as read, write, interact, lifecycle, remote, or schedule. Prevention belongs at the tool boundary. The transcript watcher can remain an independent read-only observer.

For this one long-running session, the small monitor did its modest job. It stayed silent while work remained on the agreed local surface and had specific alert paths for the crossings we cared about. I would keep it as a second set of eyes. I would not call it a guardrail.

Sources

[1] https://hermes-agent.nousresearch.com/docs/user-guide/features/cron — Cron Jobs | Hermes Agent [2] https://hermes-agent.nousresearch.com/docs/reference/tools-reference — Built-in Tools Reference | Hermes Agent