Lab 06: the grant that cannot be enumerated

Every capability written up here so far had a grant you could tabulate — a scope with a published list, and a delta whose length was the finding. This one does not, and saying so breaks a measure this site has been building on.

• Lab 06 — every routable address is in the grant↗. Do not attack anyone is the easiest line in any policy to agree, and it is the one where the grant is every address the process can route to, nobody granted it, and it is the residue of the machine having a network interface. The delta is an unbounded complement rather than a set of items, so the connector-counting measure from Lab 04↗ does not apply. What can be measured instead is whether a barrier exists, at which layer, and which egress paths it covers.
• A destination list is a property of an egress path, not of an agent. The page renders that as a matrix — shell subprocesses, in-process fetch, connector servers, hooks, name resolution — and the badge should be the minimum across it. An agent with a perfectly written domain list and an unsandboxed connector server earns the glyph for the connector server, because that is the path an attacker uses.
• A guardrail belongs to one deployment; the capability does not. Controls on some models, hosted services and interfaces are a statement about those deployments. The same capability is reachable through the raw interface, another provider, an open-weight model, a fine-tune, or a router failing over. So the two published incident reports read the other way round from the way a security reader reaches for them: as first-party, dated capability evidence.
• A barrier has a position, and some have an expiry. A vendor refusal layer sits above the deployer and formally passes the enforcer test, while being probabilistic, unevidenceable by the party relying on it, and voided by a model, provider, version or routing change that nobody classifies as a security change. So compute the minimum barrier twice and publish the pessimistic number.
• And the prohibition is worth writing anyway, for an evidential reason rather than a technical one. Liability in two regimes attaches to causing an act to be done, one of them on a recklessness standard. But a prohibition published without its enforcer establishes foresight without mitigation — which is a recklessness argument handed to the other side. The resolution is the rule this site already runs on: never publish a prohibition without publishing what enforces it in the same row.

Seven load-bearing quotations were fetched and checked rather than relayed. Among them, a vendor stating plainly that “using WebFetch alone doesn't prevent network access”, that “permission rules are enforced by Claude Code, not by the model”, that the strict allow list “has no effect” when set in a repository, and that the sandbox “shows a warning and runs commands without sandboxing” if it cannot start. We also read the published reference container firewall line by line: it is a genuine default-deny egress firewall that nonetheless permits name resolution to any address, secure shell to any address, a code host's full address ranges, and the entire /24 around the host — which on a laptop is the office network.

Two departures from the brief, both stated on the page. It reports observing an agent's two egress paths diverge in one session; in ours they did not, and the finding therefore rests on the vendor's own sentences rather than on that observation. And in its place we published a measurement of this machine's own egress: a raw outbound socket to an arbitrary public address, working name resolution, and no allow list standing in either path. A page arguing that the barrier is a property of the deployment should say what its own deployment does.

The brief register now carries six documents and four instructions, with D6 marked partly — Lab 06 exists, and the two proposals it makes to the model site are not yet on the request list in Lab 03↗.