· via dev.to (home feed)
enclave 0.8.0 scaffolds default-deny egress for LLM agents after opt-in safety gap
enclave 0.8.0 makes default-deny network egress the scaffolded default for new agent sandboxes, because the egress wall previously only took effect after a four-step manual setup.

Default-deny egress moves into the scaffold
enclave, an Apache-2.0 sandboxed runtime for autonomous LLM agents, has shipped version 0.8.0 with a fix for a failure mode its maintainers describe as leaving a security control effectively disabled while it still looks enabled. According to the release post on dev.to, the project's kernel-level default-deny egress firewall was never formally switched off — but it only became active after a four-step manual setup procedure, so deployments that skipped those steps ran with no egress enforcement at all. The new release generates the default-deny configuration automatically as part of enclave new, and operators now have to pass an explicit --unsafe-network flag to opt out.
The enforcement mechanism, as described in the post, is a sidecar that owns the agent's network namespace and pairs a DNS proxy with nftables rules that deny traffic unless it is allowed. The maintainers claim this closes a familiar workaround in which a shell command assembles a blocked hostname inside a variable, so that a filter matching literal command strings never sees the destination address.
Secrets scoped by what a pod needs
A second change targets credential exposure. The post argues that mounting a secrets directory read-only offers misleading comfort: the flag prevents writes but does nothing about reads, so a compromised or prompt-injected agent could still read every credential file it could see. In 0.8.0 the SECRETS_DIR setting determines the scope of the mount itself, and a new SECRETS_SCOPE variable lets each pod declare the specific credentials it needs rather than being handed the entire secrets store.
Hardening elsewhere in the release
Three smaller fixes follow the same theme:
- The bundled web_chat server now refuses to start when it is bound to a non-loopback address with no auth token set, including cases where the bind variable is simply unset. The server necessarily binds 0.0.0.0 inside its container, the post explains, so the Docker publish setting was previously the only thing standing between a changed bind configuration and an unauthenticated control surface into an agent running with permissions set to "dangerous".
- An allowlist file, .publish-audit-allow, had shipped for an audit scanner that was never implemented; the post says a codebase search turned up the file referenced only by itself. The scanner now exists, runs in CI, and treats a missing allow file as a failure.
- The image capability preflight previously reported success whenever the API key file existed, so a key rejected with 401 responses still produced a green "image: ok" status, and a resolved blocker stayed listed as open for days. The check now calls the provider's free key-validation endpoint — with no billed generation — and separates working keys from present-but-invalid ones.
Why it matters
The broader lesson generalises beyond one project. A control that only takes effect after an opt-in procedure is indistinguishable from an active control on a status dashboard, and health checks that verify a file exists rather than whether it actually works belong to the same category of false assurance. For teams running LLM agents in containers, where prompt injection can effectively hand an attacker the container's credentials and network access, an unenforced egress policy is a live risk rather than a paperwork problem.
There are caveats to weigh. This is a first-party announcement on dev.to: the claims about the egress wall and the audit tooling come from the maintainers themselves, running a public alpha against their own live agent fleet, and have not been independently reviewed. The release also ships two standalone companion tools — tokenscope, an npm package that measures the token cost of prompts, files and diffs, and ci-guardrail, a GitHub Action that estimates a pull request's token-cost delta and fails the build on regressions. They reflect the project's framing that cost control and safety fail the same way: through defaults that look fine until someone checks.
- #llm-agents
- #security
- #containers
- #sandboxing
- #open-source