Review Nerudo before connecting your code
A public security reference, standard reporting contact and repeatable discovery checks help developers and security teams inspect Nerudo.
Scripted demonstration
A corporate firewall block can prevent someone from evaluating a legitimate developer service. We did not have the affected company's vendor, policy or block reason. This change makes the facts under Nerudo's control easier to inspect and gives its operator a repeatable way to check public delivery.
PR 376 landed this change as 2cbb861a4cbcc8d183f6c9fd60baecd2cf165864. The page, contact and discovery screenshots show the actual compiled product in local workerd with scripted public source data. Their feature source blobs are unchanged by sequencing, and the exact landed app was rebuilt and checked again. The operator screenshot records a separate run against live production before deployment; it does not establish a production rollout or external approval.
A public reference before connecting code
Nerudo already explained its product and privacy practices, but evaluators had no single security entry point. The page uses the existing application shell. It identifies Patrick Deutsch as the operator, distinguishes browser identity from repository authority, and links the documentation that explains account export, deletion and tool access. The network table identifies the website/Git/API origin and optional MCP origin without pretending to cover every provider used by a workflow. The contact is the address already published in the privacy notice.
The compiled local security page rendered the operator, account and repository boundaries, data controls, first-party network entry points and reporting contact without sign-in.

Scripted local-source demonstration: actual compiled candidate page. The desktop and 390px layouts were inspected in Modern and Retro. The narrow network table preserves hostnames and supports keyboard scrolling.
A contact researchers can discover
The new RFC 9116 route serves a small plain-text contact file. Its expiry is fixed in source rather than extended on each request, so the operator must review and renew it. The root security.txt alias redirects to the canonical well-known location. This is vulnerability contact discovery, not a certification or permission to test other accounts.
The compiled canonical security contact route returned HTTP 200 text/plain with the existing operator address, policy URL, canonical location and explicit April 28, 2027 expiry.

Scripted local-source demonstration: the actual compiled contact route, with original screenshot bytes retained.
Public facts in the existing discovery paths
The public sitemap and optional llms navigation now include the security reference. About and the account menu link to it, and the page has its own title, description and canonical URL. The existing public-crawler policy and training preferences are unchanged. Sensitive request variants, private review routes and previews retain their existing noindex policy and separate access controls. Local workerd checks exercised those headers and responses; user-agent probes do not establish access from a real crawler IP or search inclusion.
The compiled sitemap and optional navigation file included the security reference, search user-agent probes retrieved it, and selected sensitive URLs retained noindex.

Scripted local-source demonstration: original optional navigation-file screenshot. The corresponding anonymous compiled HTTP captures retain sitemap, robots, metadata and selected sensitive-route observations.
An audit that keeps failures visible
The operator command makes bounded anonymous requests, writes a structured report and exits nonzero when checks fail. The recorded production run preceded deployment: it reported 30 passing checks out of 49 and named the missing trust/contact paths rather than claiming success. In the compiled candidate, all 49 audit checks passed, together with contact HEAD and preview noindex checks. The operator guide gives the official Google/Bing ownership and sitemap steps and vendor classification review entries. Search Console still requires the owner account; no successful indexing, vendor appeal or company approval is asserted.
The actual audit command against production returned exit status 1 with 30 of 49 checks passing and explicitly identified the undeployed security page and contact discovery failures.

Recorded command against live production before deployment. The screenshot displays a summary computed from the actual CLI JSON and its exit status; the original report is retained separately. The shell initialization warning above it is unrelated to this anonymous audit.
The public Palo Alto lookup observed during this work listed Computer and Internet Info, Newly Registered Domain and Low Risk. That is one vendor observation, not the affected company's decision and not a malware audit. The new-domain flag and search-account ownership are external to this implementation. Public content, real source references and honest reports help a reviewer make a decision; none guarantees an AI recommendation or an allowlist entry.
Walkthrough details
Actual compiled product UI and Worker routes, using explicitly scripted anonymous documentation/blog sources in local workerd with outbound network disabled. Separately recorded CLI run against live production before deployment. Product source landed in PR 376; this evidence does not claim production deployment or external approval.
- Build the T-307 product source and run the compiled Worker with a labelled scripted anonymous public source; repeat its audit on the exact native landed source.
- Open the actual local Security and trust page and inspect desktop/mobile layout and both existing interface styles.
- Retrieve the canonical security contact file and public discovery navigation; retain original response hashes and screenshots.
- Run the actual anonymous audit CLI against production before deployment; preserve its nonzero result and all reported failures.
Captured · Product view · Verification source