Technical guide · original methodology
Public readiness is not permission to expose customer data
Design a machine-readable public surface without leaking operational records, credentials, or confidential identities.
Inventory the data before the endpoints
A public audit needs publishable identity, declared policies, documented capabilities, and reproducible technical evidence. It does not need order histories, raw email addresses, session tokens, customer preferences, support messages, or payment records. Start by writing down which fields belong in each evidence lane. A publicly reachable website is not automatically approved as an identifiable case study.
Use three lanes
The public lane contains specifically approved observations suitable for publication. The connected lane contains authorized operational evidence with access controls and retention rules. The private review lane contains material needed to investigate a disputed observation. Moving a record between lanes requires explicit release review rather than a convenient serializer.
Treat returned documents as untrusted
A fetched page can contain instructions aimed at the observer. Its text is evidence to inspect, not authority to send credentials elsewhere or invoke another endpoint. The same principle applies to machine manifests and source documents: a declaration may describe a service, but it cannot grant itself access to the auditor’s environment.
Minimize evidence exports
A public record can include an approved subject reference, observation period, response class, methodology version, evidence state, and sanitized explanation. Do not publish raw headers by default. Cookies, authorization values, source-domain hashes, distinctive asset paths, private query strings, and small-cohort metrics can reveal a confidential participant even when its name has been removed.
Verify the boundary
Test that public endpoints reject unsupported methods, do not accept secrets as query parameters, and do not return connected account data. Test that noindex or robots rules are not being mistaken for authentication. A public report should explain its evidence limitations without exposing private source records or encouraging a reviewer to cross an access boundary.
Sources and scope
OWASP: server-side request forgery · IETF: Robots Exclusion Protocol, RFC 9309
Provider documents support the referenced technical facts. The interpretation, examples and proposed checks are AIWebSignals methodology, not provider endorsement or measured industry results.
Review the assessment method and its limits · Request a correction privately · Read the JSON version