Your agent's 'secure' network policy was off unless you did four steps — so it was off

The enclave project released version 0.8.0, fixing several security and reliability issues in its sandboxed runtime for autonomous LLM agents. The update addresses a network egress policy that was effectively off unless users performed a four-step manual activation, a read-only mount that did not prevent secret reads, and a health check that reported API keys as present even when they were invalid. The release also includes a scanner for an allowlist that had no enforcer, and new tools for measuring token costs.

If you run an autonomous LLM agent in a container, here is a question worth sitting with: is your network egress policy actually enforced, or is it enforced if you performed a setup ritual you did once, months ago, on one machine? We shipped enclave https://github.com/wartzar-bee/enclave 0.8.0 Apache-2.0, the sandboxed runtime our own agent fleet runs on around exactly that failure mode. The short version: a safety control with a four-step activation cost is, in practice, off — and "off unless you opt in" reads on a Mounting your secrets/ directory read-only :ro feels like scoping. It isn't. :ro stops writes ; it does nothing about reads . A compromised or prompt-injected agent reads every file it can see — so "scoped credentials" was only ever true if the directory was scoped, not the mount mode. 0.8.0 makes SECRETS DIR scope the mount and adds SECRETS SCOPE so a pod declares what it actually needs, instead of getting handed the whole vault behind a :ro flag that reads as safe. Same theme across the release: enclave new --unsafe-network opts out . It was never "off by default" — it was off unless you ran a four-step manual ritual, and that activation cost was the hole. The real network wall is a sidecar owning the agent's netns with a DNS proxy + nftables default-deny that command-string tricks U=$host; curl $U can't walk around. web chat refuses to start on a non-loopback bind with an empty token 0.0.0.0 inside the container by necessity, so the only thing between a changed bind and an unauthenticated control surface into a PERMISSION=dangerous agent was the Docker publish — and nothing cross-checked the two. .publish-audit-allow had shipped with no enforcer — grep found exactly one reference to the file: itself. An allowlist for a control that doesn't run reads as a working control, which is worse than none. 0.8.0 ships the scanner, in CI, failing closed if the allow file goes missing. exists , not works The one I like most is smaller. Our image-capability preflight returned path.exists on the API key file. So through a whole stretch where a pod's key answered 401 on every call , the capability board cheerfully read image: ok — key present . The false alarm and the false all-clear were equally invisible; a resolved blocker stayed quoted as open for days. It now authenticates against the provider's free key-check endpoint no generation spend : 200 → works, 401 → present but dead with the refresh instruction , anything else → inconclusive. "Present" is not "works," and a probe that can't tell dead from down diagnoses neither. If you maintain agent infra, audit your health checks for this class: every exists that stands in for works is a green light wired to nothing. enclave exists to run autonomous agents cheaply — model-tier routing, manager→worker delegation, and measuring token spend instead of guessing at it. Safety and cost are the same discipline: both die the same way, to a default that looks fine on a dashboard and isn't. The same cost discipline ships as two standalone tools you can drop into any project, no runtime required: npm i -g @wartzar-bee/tokenscope — measures the token cost of prompts, files, and diffs so you see what a change costs Full changelog: enclave 0.8.0 https://github.com/wartzar-bee/enclave/blob/main/CHANGELOG.md 080--2026-08-22 . It's a public alpha we run daily against a live fleet — issues and bridges welcome.