WebFetch's internal sub-model appears to receive org-level system instructions it can't act on

What's happening

Our organization has an org-level system instruction (set in Organization
settings > Organization instructions) telling Claude to load a specific
skill before writing anything a person will read. WebFetch calls in
Claude Code are printing text that responds to that instruction — even
though WebFetch's own tool description says it "processes the content
with the prompt using a small, fast model" that has no Skill tool and no
way to load one.

Example (org instruction says to load a skill called wolfe-comms-standard
before writing anything a person will read):

Loading `wolfe-comms-standard`.

No action needed.

[... otherwise normal answer to the WebFetch prompt ...]

What we tested

Three rounds, across two days, testing whether the org instruction text is
reaching WebFetch's internal sub-model:

• Round 1 (day 1): 9 WebFetch calls, 3 sites, 3 prompt styles ("extract

facts," "summarize for a reader," "list headings only"). The false
skill-load line appeared in 4 of 9 calls (44%).

• Round 2 (day 2, before any instruction change): 6 WebFetch calls

(identical prompts/URLs to a subset of round 1, some repeated verbatim).
Appeared in 4 of 6 calls (67%).

• **Round 3 (day 2, after adding a "Scope" clarification to the org

instruction, and waiting ~85 minutes for it to propagate):** same 6
calls. Raw rate unchanged at 4 of 6 (67%), but every leaked response this
round correctly reasoned that the skill didn't apply (rather than trying
to load it) — see below.

The strongest single data point: fetching the same URL with the same
prompt twice, back to back (round 2), produced two different results:

• Run 1 opened with: "I'm skipping the wolfe-comms-standard skill because

this is searchable reference material, which is one of the three
exemptions." That sentence matches our org instruction's exemption clause
almost verbatim — it isn't a generic-sounding fragment, it's the
sub-model applying a specific rule from our account's instruction text to
itself.

• Run 2, same URL and prompt, opened with: "Loading wolfe-comms-standard."

instead.

Two things this rules out: a one-time fluke (it recurred across sessions
and days), and a line injected by the fetched page itself (identical
URL+prompt gave different results on different runs, and the line also
appeared on a plain, mechanical request — "list the section headings only,
no other commentary" — that has nothing to do with the instruction's
subject matter).

Workaround attempted (partially effective)

We added a paragraph to our org instruction scoping the skill-load
requirement to "content Claude itself authors as a final message... not
tool calls, web-page fetches, [or] search-result processing," and later
moved that paragraph to the very start of the instruction (testing whether
the leak is order-sensitive, since the original skill-load mandate
preceded it in the text).

Result: this did not reduce how often the instruction text reaches the
sub-model (raw leak rate unchanged at 4/6 across all three rounds so far),
but it did change the failure mode — after the fix, every leaked response
correctly recognized the exemption and answered normally, instead of
printing a false "Loading [skill]" line and getting confused about a rule
it has no way to act on. So the visible symptom is largely fixed, but the
underlying issue (instruction text reaching a sub-model that was never
supposed to receive it) is not.

What this tells us, and what it doesn't

Best explanation: account-level org instructions are being attached to
WebFetch's internal sub-model's prompt, at some rate, on calls that were
never meant to receive them. Wording changes to the org instruction itself
can change how that sub-model responds to the leaked text, but can't stop
the text from reaching it in the first place.

We have no visibility into WebFetch's implementation, so we can't confirm
the exact mechanism. We also haven't tested whether the same thing happens
with WebSearch or other tools that use an internal sub-model.

Confidence in the leak itself: moderate-to-high, given the exemption-clause
match in the strongest data point, reproduced across three independent test
rounds. Confidence in the exact mechanism: low — that would need visibility
into how WebFetch is built.

What we did not cover

Tested WebFetch only, not WebSearch or other tools. Three rounds, two days,
21 total calls. Don't know if the rate holds at larger scale, or whether
it's specific to accounts with unusually long org-level instructions versus
any account with org-level instructions at all.

Ask

An investigation into whether/how org-level account instructions reach
WebFetch's internal content-processing model, and whether that's intended.
No fixed deadline for a reply — happy to provide the full raw call-by-call
data if useful.