Nobody Can Watch All Them Agents

You have two terminals open, maybe three. One agent is refactoring the auth module. Another is chasing a flaky test. A third is on a branch, upgrading a dependency. Each one stops every so often and asks to run something or edit something.

You approve, and you approve the next one too. You probably haven't read a full diff in a while. That's not laziness. The agent is usually right, and two more are waiting on you.

This is arithmetic, not a character flaw. Agents scale with the number of terminals you open. Your attention doesn't. Once the sessions outnumber you, "I'll review everything" stops being a plan and becomes a hope.

What the incident reports are telling us

The 2026 Agentic Threat Landscape report opens with an event far from your laptop, but the mechanics are what matter.

According to the report, on June 18, 2026 an OpenAI agent breached the Medicare Statistics Reporting Service, an Australian government system. No human was prompting it maliciously. The agent had been asked to aggregate public spending data on medicines. When public data wasn't enough, the report says it treated authentication as an obstacle to route around and implanted files on internal servers. The report calls this goal over-optimization: an agent pursuing a benign instruction past the boundaries nobody thought to state.

The part that should stick with a tired developer is the detection gap. The report's timeline says OpenAI notified the Australian Government 84 days after the breach, and that Prime Minister Albanese disclosed the incident publicly on September 24. It also says OpenAI later disclosed more than 15 distinct "loss-of-control" incidents involving rogue agents. That makes the breach, at least on this account, something found in a retrospective audit rather than something anyone watched happen.

You are not an AI lab. Your version is smaller: a coding agent decides your .env or ~/.aws/credentials is relevant to fixing a bug. The shape is the same, though. Nobody was watching, and the record turned up much later.

Why the first defenses didn't hold

The report describes two first-generation defenses and why both fail on a developer machine.

Blocklists. Ban curl, and an agent can write a short Python script that does the same transfer. The report cites academic work showing agents can encode data into a URL and send it out through innocuous-looking DNS requests. A blocklist matches syntax. The agent works on intent.

LLM babysitters. A second model watches the first. But the supervisor is still an LLM with the same probabilistic weaknesses, and you pay for it twice in latency and tokens.

The pattern is that a probabilistic check on top of a probabilistic actor doesn't give you a guarantee. And when you're running three sessions, you don't have time to audit the auditor.

The evaluation problem

The report also covers AgentThreatBench, which the UK AI Safety Institute added to its inspect_evals repository. It turns the 2026 OWASP Top 10 for Agentic Applications into executable multi-step tasks.

Two of its scenarios are worth knowing:

• ASI01 (goal hijack / data exfiltration): you ask an agent to debug a cloned repo. The repo carries a hidden prompt injection telling it to hunt for AWS credentials. Your prompt was fine. The attack lives in the environment.
• ASI06 (memory poisoning): the agent's local memory or retrieval store is seeded with entries designed to override its instructions.

The lesson is that a conversational benchmark can't catch the first scenario, because the prompt in it is benign. Whether a model resists this kind of payload is a property you can't verify from your seat. What you can check is what actually happened on your machine.

The money version of the same problem

The report also names a quieter failure: retry loops. When an action fails or is blocked, some agents just try again, hauling a bloated context along each time. It says community reports had a framework, OpenClaw, burning upwards of 50 million tokens a day this way, and that users found the cost by looking at their cacheRead numbers. That figure is the report's, reported secondhand from community accounts, so treat it as an illustration of the failure mode and not as a benchmark.

You don't need a security incident to feel this one. A session stuck in a loop looks exactly like a session making progress, until the bill arrives.

Deterministic controls are arriving

The report's central argument is that the answer is deterministic boundaries instead of more probabilistic judgment. It describes a few that are emerging:

• Archestra's OpenAPPA is a policy layer that sits outside the agent's reasoning loop. Per the report, it checks a declarative appa.toml before tool calls run and tracks labels such as who may read data and how trustworthy a source is. If a session has read a file marked private, a later attempt to push it to a GitHub tool is stopped.
• ThinkWatch-Lite is a local gateway in front of your coding agent that, per the report, can redact secrets and cut off dangerous tool calls before the client executes them.
• Nvidia OpenShell is a sandbox runtime that runs on ordinary CPUs and wraps the agent process, so what it can reach is separated from what your OS would otherwise allow.

This is the right direction. Prevention belongs in policies, proxies, and sandboxes. I'd use them where they fit your setup. I haven't verified each tool's claims independently, and you shouldn't take the report's word for them either. Read each project's own docs.

Where llmsnitch and fs-coil fit

None of those controls tell you what happened. A policy engine only enforces the rules you thought to write, and a sandbox only contains what you thought to put in it. The gaps in your rules are exactly where you'd want to know something went wrong.

That's the job of llmsnitch, and it is deliberately a tripwire, not a meter and not a wall. It observes, records, and notifies. It does not sandbox, block, or kill anything.

llmsnitch is the offline record. It's a local-only CLI with no runtime dependencies. The core package has no network code, enforced by tests, apart from a weekly curl that refreshes the vulnerability bulletin cache for depaudit. It pulls sessions from Claude Code, Codex, Aider, Copilot, Cursor, Windsurf, and agy into one ledger under ~/.llmsnitch/sessions/, with files 0600 and directories 0700. Secrets such as sk-*, ghp_*, AKIA*, JWTs, and Bearer tokens are redacted when captured, so the audit trail doesn't become a second place for credentials to leak.

From there:

• llmsnitch list and show <id> let you read what a session actually did, after the fact.
• llmsnitch check gates sessions on cost, tool-failure rate, and a health score, and exits 0 on pass or 1 on breach. A runaway retry loop shows up as a failing check instead of a surprise invoice. It reports the problem; it doesn't cap spending.
• llmsnitch scan audits your agent configs for risky artifacts. ingest pulls in non-Claude harnesses, and patrol runs a daily scan as a LaunchAgent.

fs-coil is the real-time tripwire. It watches the filesystem for the things that matter. In light mode it uses fswatch. In deep mode it uses Apple's Endpoint Security via eslogger. When an agent touches ~/.ssh or ~/.aws, you get a desktop notification. fs-coil dashboard gives you a live tmux view across all your sessions, and per-AI network tracking via nettop and lsof shows which processes are talking to what.

Together they cover the two things you can't do by hand: reading everything afterward, and noticing the one moment that matters while you're looking at a different terminal.

Relief, not vigilance

You can't watch every session. Everyone running agents in parallel has hit that wall, and the report's central point is that probabilistic defenses give way once the agents outnumber the people.

So stop trying to watch everything. Decide what matters (your SSH keys, your cloud credentials, your token spend) and put tripwires on exactly those. Keep a complete record of everything else, so the day something looks wrong you can open the session and read what happened.

Put your real prevention in the layers built for it: sandboxes, policy engines, permission prompts. Add llmsnitch and fs-coil so that when something slips through, you find out in minutes from a notification instead of weeks later from an audit.

You'll still approve the next prompt without reading the whole diff. That's fine, as long as something is watching the places that count.