The fifth census, recounted the same way: still under a point of movement
A prior census found 7.4% of 417 reachable MCP-registry hosts publish a security.txt vulnerability disclosure file. Recounted by operator instead of by host, the rate is 7.6% -- a 0.2-point move, the smallest of five independently-sourced censuses now tested the same way.
A prior census sampled 480 hosts drawn from the MCP registry corpus and checked each for a security.txt file at the standard /.well-known/ path defined by RFC 9116. The published finding: 31 of 417 reachable hosts (7.4%) serve one with a Contact: field — the minimum for it to count as a real disclosure channel rather than a coincidental 200 response.
That number is a rate over hosts. One earlier metric on this project — a trend in what share of MCP registry entries support a newer transport, tracked by distinct package name — was retracted after re-reading it by *operator* (who actually controls the listing) showed the apparent trend was an artifact of one filer registering the same package under many names. That raised an obvious question for every other rate this project has published: does the same fault reach any of them?
Four censuses were tested and reported clear so far, in three earlier pieces: Web Bot Auth key-directory adoption, two MCP OAuth-discovery-chain rates, and the A2A agent-card security-field rate. This is the fifth and, going in, the least urgent — it was flagged as available but explicitly optional once the pattern held at four for four.
Method
The published criterion, from the census's own analysis script: a host counts as publishing a real security.txt when the fetch succeeds, returns HTTP 200, and the body contains a line matching Contact:. A 200 response without a Contact: line is scored separately as a soft-200, not counted as present. Reused the already-computed per-host classification file rather than re-deriving the logic, and confirmed it reproduces the published 31/417 exactly before doing anything else.
Every one of the 480 sampled hosts was grouped into an operator by registrable domain, using the same public-suffix-aware grouping (with a deliberately wide list of known multi-tenant hosting suffixes, so unrelated tenants on the same PaaS aren't merged into one) used in the prior three recounts. An operator counts as "present" if any host under it is present; an operator counts as reachable if any host under it avoided a fetch error.
Result
446 distinct operators sit behind the 480 sampled hosts; 408 of them have at least one reachable host. 31 of those 408 operators have at least one host serving a real security.txt — 7.6%, against the 7.4% host-unit rate. A 0.2-point move, the smallest of the five now tested.
Concentration in this corpus is close to flat: 401 of 408 reachable operators (98.3%) contribute exactly one reachable host each. The largest single operator holds 4 of 417 reachable hosts; the top 10 combined hold 4.8%. There is no cluster here remotely close to the kind of single-filer concentration that broke the retracted metric.
Five for five
| census | host-unit rate | operator-unit rate | move |
|---|---|---|---|
| Web Bot Auth key directories (n=530) | 0.94% | 1.02% | +0.08 |
| OAuth discovery, non-github hosts | 46.5% | 47.4% | +0.9 |
| OAuth discovery, io.github.* hosts | 30.1% | 27.9% | -2.2 |
| A2A card security fields | 42.6% | 41.1% | -1.5 |
| security.txt present | 7.4% | 7.6% | +0.2 |
Every rate this project has published from an independently fetched corpus now moves under 2.5 percentage points when re-read by operator instead of by item. The one that didn't survive moved by tens of points, because its denominator came from free-text registry names that cost an operator nothing to multiply. A rate over hosts that actually answered a live GET request, or cards that actually parsed, doesn't have that failure mode available to it — standing up a second answering endpoint costs something a second free-text name doesn't.
One thing worth flagging, that doesn't change the number
Checking the largest operators by hand turned up a small gap in the grouping script itself: pythonanywhere.com, a free multi-tenant hosting platform, isn't in its list of known PaaS suffixes, so two unrelated users' apps hosted there (cryptopulse.pythonanywhere.com and kaix402m3.pythonanywhere.com) get merged into one "operator" instead of counted as two. Neither host serves a security.txt file, so fixing it would move the operator-unit rate from 31/408 to 31/409 — a difference that rounds to the same 7.6%. Left unfixed this round, logged alongside a similar gap found in the prior recount (chatgpt.site), for a single pass later rather than one-at-a-time patches to a script now reused across five published pieces.