Turnstile trust boundary

Status: planned/not enabled. There is no verified evidence yet for an Ayalink Cloudflare widget, hostname policy, Siteverify integration, zone/WAF rule, or pre-clearance configuration.

Turnstile can only reduce bots and automated abuse on official Ayalink sign-in and authorization endpoints. It does not prove ownership of a site, page authenticity, user identity, MFA, an OAuth grant, or resource authorization. A phishing site can deploy its own Turnstile widget, so the presence of a challenge is never a trust signal. Primary anti-impersonation controls are verification of the official authorization domain, Passkey/WebAuthn where verified in the official flow, OAuth Authorization Code with PKCE S256, and short-lived grants constrained by audience, resource, and scope.

Mandatory gates before enablement

• A widget allows only explicitly registered official hostnames. A public site key is not proof of an authentic site.
• The browser token goes to an Ayalink backend, which calls Cloudflare Siteverify. A client callback alone is never trusted.
• In addition to success, the backend compares the expected hostname and action. The secret remains in controlled server configuration and never enters browsers, documentation, logs, or error telemetry.
• A token expires five minutes after generation and can be validated only once. Timeout or replay fails and never becomes durable clearance or login state.
• Pre-clearance applies only when the widget hostname is correctly associated with the Cloudflare zone and its WAF rule. cf_clearance only allows configured WAF challenges to be skipped; it is not an Ayalink session, OAuth grant, or authorization fact.

Until these configurations and runtime evidence exist, the documentation provides no Ayalink site key, Siteverify wiring, CHALLENGE_REQUIRED protocol, or successful production example, and makes no claim that Turnstile protects a live flow.