The AI-surface censuswhat 10,092 real websites actually expose

Published with the full dataset behind every figure — recompute anything yourself.

The headline numbers

We passively scanned 10,092 real, randomly-sampled websites (not our own leads, not a hand-picked list) for what their public-facing surface reveals about AI exposure. Every number below regenerates directly from the dataset behind this report — see Methodology.

ELEVATED means a passive, single-request check found something worth a closer look — not a confirmed vulnerability. This census never logged in, never sent a payload, and never touched anything beyond what one ordinary GET request reveals.

Methodology

• Sample: a disclosed, log-stratified sample of the free, public Majestic Million domain-rank list, drawn from rank 2,000–500,000 (excluding the top 2,000 — dominated by CDN/ad-tech/social-platform infrastructure, not individual organizations — and a documented infrastructure-substring blocklist further down the tail), deduplicated against every domain already in SEB's own lead lists.
• Two batches, zero overlap: a 492-domain validation batch (2026-09-02) and a 9,600-domain production batch (2026-09-03), confirmed to share zero domains before merging.
• One GET request per domain. robots.txt respected and not overridden. No login attempts, no forms submitted, no active exploitation of any kind. Timeouts, DNS failures, and TLS errors on dead or expired domains are reported as "unreachable," not excluded silently.
• Well-known-path checks: /.well-known/mcp.json, /.well-known/agent-card.json, and /llms.txt are fetched the same passive way as the rest of the scan.

A known data-quality note, carried word-for-word (do not summarize this away)

the llms.txt count fluctuated more than expected across repeated passes over the same 492-domain validation batch (41 → 39 → 31 across three runs within ~24 hours) — batch2's 9,600-domain llms.txt count was far more stable in relative terms (813 → 809 → 818) and showed roughly balanced gains and losses when diffed host-by-host, consistent with ordinary network-level noise (timeouts, transient DNS/TLS hiccups) rather than systematic blocking. Batch1's swing is proportionally larger than that noise rate would predict for its sample size, and its earlier runs' raw per-domain logs weren't preserved to diff the way batch2's were, so the exact cause isn't nailed down. Practical impact is small (the combined llms.txt rate moves by about 0.1 percentage points depending on which batch1 run is used) and doesn't change any conclusion in this section — flagged here rather than quietly picking whichever number looked best, and worth keeping in mind if a repeated scan of the same small set of domains is ever depended on for a precise month-to-month delta rather than a population-level rate.

We found real bugs in our own checker before publishing this. Here they are.

We're disclosing this because finding your own bugs before publishing is the actual credibility claim — not something to bury in a footnote.

1. The MCP/agent-card/llms.txt checks didn't exist at all at first. Our original passive-assessment tool never looked at these three paths. We built a dedicated checker for them.
2. A generic error page produced a false positive. One site's PHP error handler returned HTTP 200 for every path, with enough HTML-looking markup to fool a naive "does this look like a real page" check. Fixed by actually parsing the response as JSON instead of pattern-matching on its shape.
3. A large real file got truncated mid-read and failed its own parse — a false negative on a genuine positive. Fixed by reading further before giving up.
4. Two more false positives (a privacy-consent declaration file, a bare empty JSON object) slipped past a "parses as JSON" check at the full 10,000-domain scale. Fixed by requiring the file to actually declare a name.
5. That fix then wrongly excluded three genuinely real hits, whose files structured that same field differently than we'd assumed. Fixed by searching the whole document, not just the top level, and re-verified against every real and false example found so far.

The confirmed hits, named — because their disclosure is already public

Every one of the following was individually fetched and read by a person, not accepted on the checker's word alone. We're naming them because what we're citing is a file each company already chose to publish at a well-known, standard path on their own public site — a factual observation of a public artifact, not a claim about anyone's security posture. None of this characterizes any of these as vulnerable; several (any AI-native company running a public MCP server) are simply disclosing AI infrastructure the same way a robots.txt discloses crawl policy.

Live MCP servers (/.well-known/mcp.json), 11 domains: postman.com, opensea.io, sentry.io, builtwith.com, marketresearchfuture.com, completesports.com, cryptopolitan.com, pydantic.dev, expertphotography.com, thorchain.org, posteverywhere.ai.

Agent cards (/.well-known/agent-card.json), 6 domains: leadpages.net, opensea.io, builtwith.com, vidyard.com, yippy.com, pydantic.dev. (opensea.io, builtwith.com, and pydantic.dev appear in both lists — 11 + 6 = 17 total hits, across 14 unique domains, not 17 unique companies; both counts are reported plainly here rather than picking whichever sounds bigger.)

One qualifier that must travel with its example: yippy.com's agent-card file itself declares "status":"coming" — it's a genuine disclosure of intent, not a live production capability. If yippy.com is cited anywhere this report is quoted or excerpted, that qualifier goes with it.

Data availability

The full dataset behind every number in this report — _assessment_census_combined.json, 10,092 records, each tagged with its source batch — is available for direct download here. Anyone can recompute every figure above directly from it.

---

Published 2026-09-14 · Secure Environment Basics · How our passive assessment works · Privacy · Terms