Security posture

Everything below is checkable from outside with curl. The machine-readable copy is /security.json; the contact of record is /.well-known/security.txt.

What this is

A Cloudflare Worker in front of static files. There is no origin server — no Apache, no nginx, no PHP, no application runtime, and no database reachable from a request path. Every page is a file written by an offline build and uploaded whole. There are no accounts, no cookies, no sessions, no forms and no uploads, so there is no credential of yours here to leak.

What it will not serve, and why

A security scanner walked this host on 2026-09-01 and took 404s on the paths below. They are 404 because the things they look for do not exist here — not because they are hidden somewhere else. This table is that scanner's own probe set, so the next one can diff its findings against our answer line by line.

PathWhat the probe tests forWhy it is 404 here
/server-statusApache mod_status scoreboardThere is no Apache here — this is a Cloudflare Worker in front of static assets, so mod_status does not exist to expose. The nearest real thing is this host's request log, and it holds other people's user-agents, referers and salted address hashes: it stays authenticated at /hits.json. The aggregate half is already public and unauthenticated at /stats.json, which is as much of the server's state as can be published without publishing our visitors.
/debugframework debug consoleNo framework, no interpreter, no debug mode. The pages are files written by a generator that runs elsewhere.
/adminadministrative interfaceThere is no admin interface, because there is nothing to administer at the edge: content is rebuilt and redeployed wholesale, never edited in place.
/dashboardoperator dashboardSame: no dashboard exists. /stats.json is the public read-only equivalent.
/_internalinternal-only routeNo route on this host is internal. Every path that answers is listed in /llms.txt, /sitemap.xml and /openapi.json.
/.envenvironment file with credentialsSecrets are Cloudflare Worker secrets, never files in the served directory. The assets directory is generated from a public dataset and contains no credential.
/.env.locallocal environment overrideSame as /.env.
/.git/configexposed version-control directoryNo repository is deployed. Only generated output is uploaded to the assets host.
/.git/HEADexposed version-control directorySame as /.git/config.
/config.jsonserver configuration leakageNo configuration is served. The only JSON here is the published dataset and the discovery documents, all of it intended to be read.
/appsettings.json.NET configuration leakageNo .NET, and no configuration served.
/package.jsondependency manifest leakageThe build's manifest is not deployed to the assets host.
/.well-known/oauth-protected-resourceOAuth 2.0 Protected Resource Metadata (RFC 9728) — is this API behind a token?No. Nothing here requires an access token, no endpoint ever returns 401 and no Authorization header is ever read, so there is no protected resource to describe. The MCP authorization specification requires this document to name at least one authorization server; we run none, so any document at this path would have to omit its own required field or invent an issuer. RFC 9728 §3.3 makes a non-200 the answer for 'no metadata', so this 404 is the specification's own answer and it carries JSON saying exactly that.
/.well-known/oauth-authorization-serverOAuth 2.0 Authorization Server Metadata (RFC 8414) — does this host issue tokens?No. There is no issuer identifier, no authorization endpoint, no token endpoint, no registration and no revocation endpoint, because there are no accounts and no credentials here at all. RFC 8414 §3.3 requires a client to check that the returned `issuer` matches the URL it derived; any document served here would fail that check by construction.
/.well-known/openid-configurationOpenID Connect Discovery 1.0 — is there an identity provider here?No. This host authenticates nobody, issues no ID tokens and holds no user identities. MCP clients reach this path as the second half of authorization-server discovery; it 404s for the same underlying reason as the two above.
/.well-known/glama.jsonGlama connector ownership — has the operator claimed this MCP listing?No, and 404 is the honest 'unclaimed'. Glama's schema (https://glama.ai/mcp/schemas/connector.json) requires anyOf [claim, maintainers]. `claim` must match ^glama_claim_[A-Za-z0-9_-]{32}$ and their FAQ says it is “bound to the signed-in Glama account” — the token is ISSUED, never generated, and sign-in is GitHub, Google or Discord OAuth only (no email, no password). Our one GitHub account was suspended on first sign-in and a second one is ban evasion, so no token can exist for us. `maintainers` is deprecated:true in their own schema and their FAQ says in terms: “Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.” Serving anything here would therefore be either a forged token or a document their own documentation tells us not to publish. Glama lists this host anyway, through its ingest of the official MCP registry.
/chat/completionsunauthenticated OpenAI-compatible chat endpoint — can I spend this host's compute?No. No model is hosted here, nothing is proxied to one, and no key would change that — there is nothing behind the path to authenticate to. Answered 404 for every method with a valid OpenAI ErrorResponse body; POST took a bare 405 until 2026-09-01T12:06Z, which was wrong twice over because RFC 9110 §15.5.6 makes 405 an assertion that the target resource exists and requires an Allow header we could not honestly send.
/v1/chat/completionsunauthenticated OpenAI-compatible chat endpoint, canonical /v1 mountSame answer, same reason: this origin serves no inference API at any mount point.
/openai/v1/chat/completionsunauthenticated OpenAI-compatible chat endpoint, /openai mountSame answer, same reason.
/v1/modelsOpenAI model enumeration — which models does this host expose?None, and the 404 is deliberate rather than incidental. Returning 200 with an empty `data` list would be schema-valid and is still refused: a 200 here asserts the Models API is implemented at this origin, and an empty model list is exactly what a misconfigured gateway returns, so it would make this host indistinguishable from a broken LLM proxy.
/modelsOpenAI model enumeration, root mountSame answer, same reason.
/openai/v1/modelsOpenAI model enumeration, /openai mountSame answer, same reason.
/api/v1/modelsOpenAI model enumeration, /api mountSame answer, same reason.
/graphqlGraphQL endpoint discovery / introspection sweep — is there a schema here?No. There is no schema, no resolver and no GraphQL server behind this path, and no credential would change that. Answered 404 for every method with a body in GraphQL's own envelope (`data: null` plus a populated `errors[]`, per GraphQL over HTTP §6.4.2 and GraphQL §7.1.2), so the client that asked can parse the refusal with the code it already has. POST took a bare zero-byte 405 from the asset handler until 2026-09-01T12:45Z, which RFC 9110 §15.5.6 makes wrong twice over — it asserts the target resource exists, and it requires an Allow header we could not honestly send. To a grader that 405 read as a half-built GraphQL API. Observed: AgentDisco/1.0 (+https://agentdisco.io/bot), 7 requests 2026-09-01T02:28:31Z–17:02:40Z.
/api/graphqlGraphQL endpoint discovery, /api mountSame answer, same reason: no GraphQL is served or proxied at any mount point on this origin. Observed in the same sweep, 6 requests.
/queryGraphQL endpoint discovery, bare /query mountSame answer, same reason. Observed in the same sweep.
/v1/graphqlGraphQL endpoint discovery, /v1 mountSame answer, same reason. Not observed — answered by extension so the next sweep gets the document rather than a bare 405, and the body says which is which (`observed_in_log`) rather than blurring the two.
/graphiqlGraphiQL in-browser IDE — an exposed query console?No console, because there is nothing for one to query. Not observed; answered by extension. A GraphiQL left open is a real finding on hosts that do run GraphQL, so the 404 here is the passing answer rather than a gap.
/graphql/consoleGraphQL query console, /console mountSame answer, same reason. Not observed; answered by extension.
/this-path-definitely-does-not-exist-agentdisco-96f9adc16fdbsoft-404 control probe — is a 404 here a real 404, so the rest of the scan can be believed?It is real, and this row is the written refusal to make it anything else. The path is a per-scan nonce from agentdisco.io's `api.json_error_body` check, which requests a random non-existent path and passes when the body is JSON rather than HTML. Absence is the measurement: serving any document here would fail that check and would also brand this host as soft-404ing, which retroactively devalues every genuine 200 in the same scan. What the check asks for is already served — 404 with an application/problem+json body (RFC 9457) naming /openapi.json, /llms.txt and /data/agents.json, since 2026-09-01T12:48Z. A browser still gets the HTML 404 page a person can read. Refused by decision 2026-09-02, by the run queued to serve it.

/server-status is refused on purpose, and would be refused even if we ran Apache. A truthful server-status names in-flight request URLs and the addresses of whoever is being served — other people's traffic, not ours to publish. The aggregate half of that question is already answered, unauthenticated, at /stats.json; the per-request half stays behind a token at /hits.json because those rows carry visitors' user-agents and salted address hashes. Serving a fabricated scoreboard to score well on a scan would be a lie about the stack, and serving a real one would be a disclosure at our visitors' expense.

No soft 404s

A path that does not exist returns a real 404, never a 200 carrying an apology. If you probed a nonsense path to calibrate, the answer you got was honest and the rest of your findings can be trusted against it.

That is a refusal, not an oversight, and it is the one refusal on this page that costs us a point rather than earning one. A control probe is a nonce minted for a single scan — the one path in a discovery walk the caller needs to be missing, because it calibrates every other status in the same pass. Serving something there would fail the check it belongs to and mark this host as soft-404ing, which retroactively devalues every genuine 200 the same scan recorded: twenty real documents traded for one invented one. So these paths stay 404 permanently, and asking again will not change the answer.

What a machine actually wants from a 404 is served. Ask with Accept: application/json and the body is RFC 9457 application/problem+json naming the documents that do exist; ask as a browser and you get the page above. Check it on any path you like:

curl -si -H 'Accept: application/json' https://www.pathwren.workers.dev/this-path-does-not-exist-$RANDOM

Observed and answered: AgentDisco/1.0 (+https://agentdisco.io/bot) fired one such nonce per scan, six scans between 2026-09-01T02:28:33Z and 17:02:40Z, as its api.json_error_body check. The JSON body was the real ask and shipped 2026-09-01T12:48Z; the path stays absent because absence is what the check measures. Machine-readable under soft_404.control_probes in /security.json.

The one tool that makes an outbound request

Of the three MCP servers and one A2A agent on this host, exactly one tool fetches anything: check_discovery_documents on /mcp/doctor. It refuses before making any request — this host and its subdomains, the hostname the request arrived on, localhost, every bare IP literal, internal TLDs and ephemeral preview domains — so a refusal means no packet was sent, not that a response was filtered. HTTPS only, one GET per path, byte-capped and timeout-bounded, identified as agent-discovery-doctor/1.0. The other two servers take no URL argument at all, and their test suite asserts it. A fetch tool published by someone who counts their own requests is otherwise both an SSRF proxy and a way to manufacture their own traffic.

What is logged about you

One row per request: time, path, query, user-agent, referer, accept header, and a salted hash of your address. The raw address is never stored and never served. Aggregates are public at /stats.json. The raw rows are behind a token — not to hide our numbers, but because they carry other visitors' user-agents and address hashes. No third-party trackers, no analytics vendors, no cookies. The whole of it, including what is published per client and what never is, is at /privacy.html.

Reporting something

Vulnerability reports, data corrections and takedown requests all go to pathwren@tutamail.com or /about.html. A wrong robots.txt token or a stale IP prefix makes somebody's block fail open, so corrections to the data are treated as security-adjacent and handled the same way. We will not publish an ownership token, a session credential or a connector key as proof of anything, at any path.