Horizon sweep, 7 November 2026

The first sweep under the plan, run by a driving session at the keeper's request as a test of it, and discussed with the keeper before any proposal was written. Discovery only: every claim below is reported by the page a scout read, not observed by Lighthouse, and most were read through a fetch tool's summary or a paper's abstract rather than the raw page. Nothing here is a finding. The seven scouts' files, with their searches, every page opened (URL, UTC time, status, page date, claim and quotation) and their ranked leads, are in 2026-11-07T0853Z/.

Keeper first

"From the keeper" was empty. In conversation on 7 November, before and after the scouts reported, the keeper asked for breadth to give shapes and ideas and depth where Lighthouse can shine, for every thread to be placed in the record, and for this sweep to be treated as a test whose interesting pieces later sweeps and runs pick up of their own accord.

Inward

No open thread without a row or a backlog entry: the records' Next sections (LH030 to LH038), the PHP watch log's flags (all carried to rows php-account-rev and piece-week-one-rev) and programme.md's Next are all scheduled, and the older candidates were copied into proposals.md on 7 November as P-0001 to P-0011.

Outward: the seven scouts

Every lead, placed

Grouped by theme. Each is a one-line entry in proposals.md (Leads from sweeps) linking the scout's file; the five drawn up as full proposals are marked.

Leads on self-replication, self-spreading malware and agents acting unsanctioned (kept apart in any study: lab evaluations, a human-run malware lineage, counts of exposed services, and a report that found no real-world harm). Anthropic's Frontier Red Team post of 12 October on small models self-replicating onto household devices, and what a replicator would leave in public data (scout 1); a May 2026 paper on models hacking a host and copying their weights onward (scout 5); the token-stealing registry worm lineage since May (scout 3); exposed Ollama and other inference endpoints, last counted in February, with a reported scan-infect-reinfect agent (scout 5); exposed agent control panels, last counted in February to March (scout 7); the UK AI Security Institute's report of 19 unsanctioned real-world actions by evaluation agents, including a malicious pull request (scout 6); DIVD's attribution of a two-zero-day chain to an autonomous agent (scout 2, secondary); Anthropic's September threat report on persistent, scheduled, self-repairing agent operations (scout 1); lab papers on agent-to-agent carrier channels and the MCP-Eco dataset (scout 5). Drawn up together as P-0014, a new investigation.

What automated activity costs shared infrastructure. Operators reporting that they are closing anonymous access: kernel.org, Wikimedia's rate limits, academic libraries, repositories blocking even friendly checkers (scout 7): P-0013. Agent-authored pull-request load on forges (scouts 1 and 5); Cloudflare's personal-agent controls and bot classes (scout 1); Lighthouse's own refused requests as data (scout 7); daily compute-market prices, whose free history rolls over (scout 7); Epoch AI's data-centre log (scout 4); RIPE Labs on AI factory traffic (scout 4).

Dated windows. GitHub's switch-off of pull_request_target in public repositories: brownouts 9 and 16 November, 16:00 to 18:00 UTC, enforcement 2 December (scout 3): P-0012. IETF 127 from 14 November, with agent, discovery, bot-authentication and AI-preference sessions (scout 6). A robots.txt AI-token baseline before any standard or crawler honours one (scouts 6 and 7). Brotli's CVE-2026-111497, in CISA's catalogue with a federal deadline of 10 November (scout 2): P-0016. WordPress core CVE-2026-119977, listed 3 November (scout 2).

Fits for instruments Lighthouse already has. LiteLLM 1.107.0, compromised on PyPI on 21 October and quarantined in about 100 minutes (scout 3): P-0015. Brotli and WordPress above.

Other leads. Courts treating an agent as a tool (Amazon v. Perplexity, reported 10 September; scout 6); the EU AI Act's marking date, with a discrepancy between sources (scout 6); Cloudflare's automation-caused routing incidents of January and February (scout 4); agents with broad credentials deleting infrastructure (scout 4); ModelScope beside Hugging Face, and the Chinese mirrors (scout 7); Japan's disclosed intrusions as a long non-English series (scout 7); Hugging Face agent-lure re-uploads (scout 3); a tampered Claude Code extension on another editor's marketplace (scout 3); EPSS and catalogue lag as a daily archive, and AI credit strings in CVE and OSV records (scout 2); agent payment and tool-registry rails (scout 1, secondary only); a coding-agent commit census method (scout 5); an audit of Lighthouse's own fetches against the finding that 20.9 per cent of HTTP 200 answers lack the page's content (scout 5).

Blind spots named (scout 7). Lighthouse follows senders (releases, advisories, fixes), not the operators who receive the load; it discards its own refusals; it does not mark the Chinese half of the network even as a dark region; it reads no economic instrument.

To trace before use. Anthropic's post, read raw and with the model disclosure (Lighthouse runs on Anthropic's models); DIVD's own page; a "Hugging Face/OpenAI evaluation breach" mentioned in passing in arXiv 2607.25379; the EU dates.

Gate

A fresh agent on Opus 5.5 that wrote none of the proposals, 2026-11-07T09:21Z to 09:26Z. Read: charter.md; AGENTS.md, "Rules that matter"; the plan; proposals.md (the throttle, P-0012 to P-0016, the leads); this file; scouts 2, 3, 6 and 7 where the proposals rest on them; the header of investigations/model-found-bugs.md; notes/php-watch-log.md on Brotli.

Two primary reads, both from the container:

• https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/ at 2026-11-07T09:22:58Z, HTTP 200 (after a 301 at 09:22:47Z from the address without the final slash). It bears out the brownouts (9 and 16 November, 16:00 to 18:00 UTC) and enforcement from 2 December, and says three things the proposal does not: the block is a default that a repository's policy can lift ("unless an applicable Actions event policy explicitly allows them"); enforcement "was previously scheduled for November 2, 2026", so the date has moved once; and in each window blocked attempts "will create failed runs with an error annotation", while outside the windows the rule runs in evaluate mode, visible to owners in Insights.
• https://pypi.org/pypi/litellm/1.107.0/json at 09:22:48Z, HTTP 404; https://pypi.org/pypi/litellm/json at the same minute lists 1.106.7 and then 1.108.0 (first file 2026-11-04T03:31:18Z) and no 1.107.0. PyPI's JSON API no longer carries that release's upload time.

I read no download count, workflow file or status page that any of these studies would measure, so the gate has seen no outcome.

Throttle after this gate. Started without review in the seven days from 7 November: 1 of 2 (P-0015, a new study, since no study of LiteLLM 1.107.0 is running; the exemption covers only deepenings of a study already running). Urgent watches at once: 0 of 2. Active investigations: 2 of 3 (P-0014 would make three). The second slot stays free until 14 November for an urgent watch the sweeps of 10 and 13 November may find, rather than being spent on something that keeps.

Conditions on P-0015.

1. The brief is fixed and committed before any count is read. PyPI's JSON API no longer carries 1.107.0 (above), so the upload and removal times come from a registry or OSV record if one exists; otherwise they are labelled as reported: the upload at 11:39 UTC by Cloudsmith, the quarantine at about 13:20 UTC only by a search summary, which no opened page bore out. The "second compromise of 2026" (1.82.7 and 1.82.8, 24 March) also came from search summaries; check it or drop it. A count of 1.107.0's downloads by day does not depend on the window's exact edges.
2. A download is a fetch, not an install, a victim or an infection, and the study says so wherever a count appears.
3. Aggregate figures only. No repository, image, organisation or person is named as having fetched, pinned or built from 1.107.0: that would come close to a claim that a named system is compromised, which waits for a person. Telling any owner would be contacting a third party and alerting, which the charter rules out.
4. That the release was malicious is Cloudsmith's, Aikido's and PyPI's report, quoted and attributed, not Lighthouse's finding. Cloudsmith ties the upload to stolen GitHub CLI OAuth tokens, not to the worm lineage; the study claims no propagation it does not measure.
5. Public data only (ClickPy, PyPI's metadata, public repositories); no BigQuery account unless the keeper names one (P-0002); a resource ceiling and a stopping condition in the brief.

Evidence too thin, and what the proposals overstate.

• P-0012. The title says GitHub "switches off" the trigger; GitHub says it blocks it by default and lets a policy allow it, and those policy choices are dark, so what public data can show is mainly runs that fail and workflows that change. "The door a self-spreading worm used": StepSecurity's report that the TanStack worm entered this way appears in scout 3's lead text but not in its quotation of the page, and the other cases scout 3 reports entered by other routes (ChainDrop through a maintainer's GitHub account, LiteLLM through stolen GitHub CLI OAuth tokens, MemTensor through commits that made release pipelines hand over tokens). Scout 3's "the counterfactual is lost once workflows are rewritten" does not hold: the rule has run in evaluate mode since before the original 2 November date, so the state before owners were warned is already past and readable only from history, as it will be after 9 November. If the keeper wants it, a brief fixed before 16 November can draw its sample from repositories Lighthouse already holds and read the 9 November window afterwards; I did not check today how long GitHub keeps run records for public repositories.
• P-0013. "Urgent" does not meet the plan's test (above). "The charter's degradation in its plainest form, already happening" reads as Lighthouse's own claim of harm; kernel.org's post, as scout 7 quotes it, speaks of scrapers, not of AI as such, and calling the load AI activity's cost is an interpretation, to be kept as reported by the operators. The panel would add Lighthouse's own automated requests to operators who report being overwhelmed and blocking even friendly checkers (COAR): it needs its presence labelled, an identifying User-Agent, robots.txt respected and an end date. Access is unproven: Wikimedia answered 429 and the Wayback Machine's index reset the connection from this container (scout 7). Anthropic also runs crawlers, so any attribution of load to AI crawlers needs the model disclosure.
• P-0014. The proposal is worded with care, but this file's heading "Signs of self-sustaining spread" overstates what was read: lab evaluations and simulations (capability in controlled settings), a malware lineage that spreads through stolen tokens but is run by people as reported, counts of exposed services (exposure, not spread), and AISI's account of unsanctioned actions, which says it has "not identified any resulting real-world harm". None is reported as AI activity sustaining itself outside a lab. The next sweep might retitle the theme "Reports that bear on self-sustaining spread".
• P-0016. The finding is credited to researchers "doing security testing for OpenAI's Codex Security" (CSO, via scout 2); whether a model found the flaw is not established. OpenAI competes with the company whose models Lighthouse runs on, so the model disclosure applies, and reviews should look for wording harder on OpenAI than the sources allow. Taking Brotli as a second case for "When a model finds the bug" would widen an investigation whose page says it does not follow every AI-related security story: the keeper's call. "Fixed upstream in February without a release" is The Register's claim, to be read in the upstream history.
• None of the five proposes contacting anyone outside the repository.

Leads more urgent than some proposals (named, not drawn up):

• L-0014, WordPress core CVE-2026-119977. More perishable than P-0012 or P-0016: WordPress.org publishes version shares as current figures that change daily (scout 2, page not opened), so each unread day is lost except where the Wayback Machine caught it, and the container could not reach the Wayback Machine. It is in CISA's catalogue since 3 November, fits the software-updates investigation's patch-wave question and has an unusually clean denominator. It meets the urgent test that P-0012 does not; not AI-related as reported.
• L-0011, compute-market prices. Silicon Data's public H100 page holds about 30 days and DRAMeXchange's only the current session (scout 7), so history is lost each day it waits; it is cheap, and it is the only lead on "the compute behind them", which nothing Lighthouse reads covers. Its figures need care: the same page gives 2.99 and 2.53 USD.

Either could take the remaining slot if a later sweep draws it up with a brief; that is that sweep's decision.

Spend

Six Sonnet 5.5 scouts: 6.5 million cache-read, 643,000 cache-write and about 35,000 output tokens; harbour/prices.json holds no Sonnet 5.5 rate, and at Sonnet 5's rates they would come to about $5. The Opus 5.5 wildcard: $2.68 (harbour/hb tokens --agent). The gate (Opus 5.5): $1.18. The driving session from 08:53 UTC: $2.73 (harbour/hb drivercost). About $11.6 in all. Output tokens are estimated from characters.