The console tells 10 of 34 instances they have "no tool that reaches outside the platform" while fetch_url is allowed on every one of them

[serge-ivo]

The console tells the owner an agent cannot reach outside the platform, while fetch_url is switched on

Measured on the deployed API, 2026-08-15, over all 34 instances on the operator account:
10 of them render

"This agent can change its own data — its memory, tasks and stored documents — but has no tool
that reaches outside the platform."

and fetch_url is allowed: true on every one of the ten (and on all 34 — it is a BASE
tool). fetch_url takes a caller-chosen method and body
(workers/api/src/lib/tools.ts:368-376), so it POSTs arbitrary payloads to arbitrary public HTTPS
hosts. The ten: Repo Chat, AIPA repo chat, Job Application Assistant, Language Buddy, Lead Outreach
Assistant, Creator OS, Facebook Friends, Fridges, Google Drive Doc Chat Test, Codex MCP Browser Test.

The other 24 render the "…each one also needs its connector granted below" sentence, which is
correct. Nothing renders the read-only sentence — that is #577's finding and it is confirmed
separately in a comment there.

This is the sentence an owner reads when deciding what to put in an agent's knowledge base. It is
rendered by store/console/src/components/ToolPermissions.tsx:123, directly above the tool
switches, in the Settings tab of every instance.

Where it is

store/console/src/lib/toolPolicy.ts:122-130:

export function toolScopeSummary(policy: readonly ToolPolicyEntry[]): string {
	if (writeConnectors(policy).length > 0) { … }
	if (writesOwnData(policy)) {
		return " This agent can change its own data — its memory, tasks and stored documents — but has no tool that reaches outside the platform.";
	}
	return " This agent has no tools that can change anything — it can only read.";
}

and :90-94:

export function writeConnectors(policy: readonly ToolPolicyEntry[]): string[] {
	const out = new Set<string>();
	for (const t of listedTools(policy)) if (t.connector && mayWrite(t)) out.add(t.connector);
	return [...out];
}

Mechanism — two correct decisions composing

1. writeConnectors uses "names a connector" as the proxy for "reaches outside the platform."
   That was exactly true while the listing held connector tools and nothing else, and the function's
   own docstring still describes its job as "other people's systems".

2. list_instance_tools says "a tool absent from the allowed set cannot be invoked, by chat or by call_instance_tool" — 11 tools every agent runs in chat are absent, and 2 of them ran on the audited instance #525 made the listing exhaustive. The built-in facilities now appear too, and they carry
   connector: null. So connector-less no longer implies platform-internal. Measured on the live
   listing for 6d3b28f1-… (Language Buddy):

   • fetch_url — {scope:"read", mutates:true, allowed:true, connector:null, tier:"base"}
   • send_to_cli — {scope:"write", mutates:true, allowed:true, connector:null, tier:"runtime"}
     (it is in FULL, so every agent that declares no capabilities.tools receives it)
   • submit_job_application — {scope:"write", mutates:true, allowed:true, connector:null, tier:"standard"}

   None of the three is visible to writeConnectors, and all three reach outside the platform:
   arbitrary outbound HTTP, typing into a CLI on the owner's machine, and posting a form on a
   third-party site.

#525's own regression note anticipated the mirror of this — "a base tool with no connector
resolves to writeConsent:"n/a" … so it must not start rendering as ungated external access".
The listing was made exhaustive without a corresponding change to the predicate that reads it, and
the error shipped in the opposite direction: not "internal shown as external", but external shown
as absent.

What to do — cheapest first

1. Stop claiming the negative. Delete the "…but has no tool that reaches outside the platform"
   clause and state only what the agent has. One line, no new data on the wire, cannot be wrong,
   ships today. The claim it removes is the one an auditor should never have taken from a field that
   does not answer it.
2. Then make the claim answerable, server-side. Add a reach fact to each listing row
   ("platform" | "machine" | "internet") beside mutates, and derive the sentence from it. This
   is list_instance_tools reports nine mutating tools as scope: "read" — one field carries two incompatible meanings, and its sibling deliberately fails the other way #563's precedent applied again: when the console needs a fact the server owns, the server
   sends it rather than the console inferring it from a field that means something else.
   writeConnectors keeps its existing job — deciding which connectors get a write-access
   checkbox — untouched.

Alternatives considered and rejected

• Derive it in the console from tier. Fails on the most common case: fetch_url is
  tier:"base", the same tier as write_memory, so tier separates send_to_cli (runtime) from
  platform tools but cannot separate "reaches the internet" from "writes my memory". Measured on the
  live listing, not assumed.
• Add fetch_url to a hardcoded name list in the console. Puts a fact about the tool catalog in
  the UI, where it will drift the first time a base tool is added — the failure mode list_instance_tools reports nine mutating tools as scope: "read" — one field carries two incompatible meanings, and its sibling deliberately fails the other way #563 and list_instance_tools says "a tool absent from the allowed set cannot be invoked, by chat or by call_instance_tool" — 11 tools every agent runs in chat are absent, and 2 of them ran on the audited instance #525
  both ended in.
• Fold this into The console's read-only claim is derived from scope, which #563 established does not mean 'does not mutate' #577. Same 8-line file, different mechanism, and the fixes collide: The console's read-only claim is derived from scope, which #563 established does not mean 'does not mutate' #577 asks
  writesOwnData to derive from mutates, which would move fetch_url (mutates:true) into the
  own-data list and leave this clause false in exactly the same place. Two issues, one file, stated
  order: The console's read-only claim is derived from scope, which #563 established does not mean 'does not mutate' #577's is latent, this one is on screen today.

Acceptance criteria

1. No instance renders a sentence asserting the agent has no reach outside the platform while it
   holds fetch_url, send_to_cli or submit_job_application.
2. A test builds a policy containing fetch_url (allowed:true, connector:null) and no
   connector tool, and asserts the rendered sentence does not claim the negative. It must fail on
   today's code.
3. writeConnectors's output is unchanged for every policy — the grant checkboxes it feeds are
   [bug] The tool listing reports write-gated tools as allowed=true, reason=ok — agents burn a turn discovering the consent gate #351's promise and are not part of this change.

Regression risk

writeConnectors feeds both the sentence and the write-access checkbox set
(toolPolicy.ts:90-94, consumed by ToolPermissions.tsx). Changing the sentence must not change
which connectors get a checkbox, or #351's fix ("http_request gets a switch for the grant its
mutating calls are refused for") regresses silently. store/console/src/lib/toolPolicy.test.ts is
the guard; it currently has no case with a connector-less outward-reaching tool.

Verified vs inferred

• Verified: the 10/34 and 24/34 split, and fetch_url: allowed:true on all ten — measured live
  via GET /v1/instances/:id/tools for every instance on the account; the three tool rows quoted
  above, from that same response; every file:line; that the sentence renders in the Settings tab.
• Inferred: nothing load-bearing. send_to_cli on a runtime:null instance would refuse at
  call time for want of a runner — but it is listed allowed:true, and the sentence is a claim
  about what the agent holds. fetch_url alone falsifies the clause on all ten regardless.

Related: #577 (the read-only clause of the same function — latent, not observed), #525 (made the
listing exhaustive), #563 (mutates, the precedent for sending the fact instead of inferring it),
#351 (the write-consent chip and checkbox set this must not disturb).

[serge-ivo]

Fixed in 31194df — and the enumeration is now 0 of 34 rather than 10 of 34

Shipped with #577 in one commit, because the two clauses collide exactly as this issue's
"Alternatives considered" said they would.

The fix taken was option 2, not option 1

Option 1 (delete the clause) was rejected: it removes a sentence that is worth telling an owner and
leaves the console with no way to say it. The server now sends the fact instead —
reach: "platform" | "machine" | "internet" on every listing row, derived in the new
workers/api/src/lib/tool-reach.ts.

Reach is defined once, in that file's header, so it is not re-derived as a proxy: the outermost
boundary a single call can cross. Two rules make it decidable — (1) the call, not its consequences
(start_work writes a run row and is platform; its executor's tools are rows in the same listing
with their own reach), and (2) where the answer depends on the input, take the outermost one
(enrich dispatches whatever tool it is handed → internet).

Both tables are exhaustive and fail CLOSED at internet; tool-reach-report.test.ts fails when any
tool or connector reaches the listing without a declared entry, so the default is unreachable.

"Names a connector" is wrong in BOTH directions — that is why no better proxy was possible

The issue documents the under-reporting half. The enumeration turned up the other half: every
supervision tool names a connector and never leaves the platform — its own registry entry says
so ("internal to the platform and to ONE owner (both instances are theirs), so there is no external
system and no credential"). Deriving reach from connector reports external access to a system that
does not exist. Both directions are pinned by name.

tier, scope and mutates were each measured and rejected at the declaration site:
fetch_url/write_memory share a tier; http_reachable is mutates:false and GETs any URL;
web_search is a read that reaches Google.

Verified live, on the deployed API, over all 34 instances

Same method as the report — GET /v1/instances/:id/tools for every instance on the account, with
the real store/console/src/lib/toolPolicy.ts (transpiled, not re-derived) computing the
sentence:

	before	after
render "…no tool that reaches outside the platform"	10	0
render "…reach outside the platform … and can change things there"	0	34
rows arriving with no reach	104	0
false negative claims	10	0

All 34 land on the same sentence, and it is true on all 34 for the structural reason #577's comment
established: BASE is seeded into every branch of toolNamesFor, and BASE contains fetch_url.
Reach distribution on a 104-row listing: 50 platform · 23 machine · 31 internet.

The sentence is also specific about where, which the old one could not be:

• Repo Chat → …— other systems — and can change things there. (outward: fetch_url only)
• Job Application Assistant → …— your own computer, and other systems — … (fetch_url,
  submit_job_application, read_terminal, send_to_cli)
• Coder → same, plus Each one behind a connector also needs it granted below. (grants: github)

AC by AC

1. Met — 0 of 34, verified live above.
2. Met — never tells an agent holding fetch_url that nothing reaches outside the platform
   builds exactly that policy (fetch_url allowed, no connector anywhere) and asserts
   writeConnectors is empty first, so the test states that the old predicate's input was blind.
   Watched fail (ADR 0002 G4): restoring the two old clauses turns 9 console tests red.
3. Met — writeConnectors is untouched, and pinned over all 256 combinations of eight
   fixtures against an independent expression of the same rule. [bug] The tool listing reports write-gated tools as allowed=true, reason=ok — agents burn a turn discovering the consent gate #351 does not move.

One defect found while writing it

An agent that writes its own memory and only READS your machine ended on "…but can only read there",
which is read as read-only — the claim #525 removed, coming back through the other clause. Caught by
#525's own existing test. The reach clause no longer swallows the own-data one; there is a case for
it.

Sharper than the issue — a second live copy of the same false proxy, NOT fixed here

workers/mcp/src/instance-tools/base.ts:59, the list_instance_tools description an operator reads
over MCP, ends:

"To audit reach into EXTERNAL systems specifically, filter on connector."

That is this issue's mechanism, stated as advice, on the surface whose whole purpose is auditing —
and it is now also out of date, because the row carries reach. Left alone deliberately: another
agent is live in workers/mcp/ and it is separable scope. Worth its own issue; descriptions are
excluded from the #573 surface hash, so it needs no version bump.

Gates

Full suite 8831/8831, pnpm typecheck (all projects), biome --error-on-warnings, all eight
check-*.mjs, docs:drift, console tsc --noEmit + vite build, and e2e/console.spec.ts on
both chromium (193) and webkit (115). Listing payload 54,000 → 55,882 bytes, inside #569's 64 KiB
budget; reach added to the audit fields that survive the schema drop. CI, Deploy API and Deploy
Host all green on 31194df.