## 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](lab-network-reach.html)**. *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](lab-shape-collector.html) 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](lab-abp-requests.html).