How a website proves control of its origin

Before a report widget can accept a visitor report, the product needs one fact: the website that will send reports really belongs to the person who registered it. Without that fact, anyone could register a website they do not own and connect a report channel to someone else's domain. The proof is a small public file at an exact address, and understanding it makes the rest of website setup straightforward.

This guide explains what the origin proof is, how the check works, why shortcuts are not accepted, and what to do when verification fails.

Why a public widget key is not proof

The widget key that appears in your installation snippet is an identifier, not a secret. It sits in public page markup, so anyone who views your page can read it. That is safe only because the key alone grants nothing: the server matches it to one exact verified origin before it returns widget configuration or accepts a report.

This is why origin verification exists. The key answers "which website is this?" and the origin proof answers "who controls that website?". Both answers are needed before a report channel can run.

The same logic applies to the browser origin header that a page sends with each request. A page script cannot fake it in a normal browser, but a non-browser caller can send any value it likes. A claimed header is a statement, not a proof, so it is never accepted as domain control.

What the origin proof is

For each registered origin, the website detail shows two exact values:

• An exact HTTPS address under a well-known path on your domain, such as a verification file address ending in .txt.
• An exact 64-character public value to place at that address.

Publish the exact characters at the exact address, then select the explicit verify action for that origin. The file may contain the exact characters, or those characters plus one final newline.

The 64-character value is public placement content, not a credential. It is deterministic for that one origin record, so you cannot invent it or reuse a value from another origin. Publishing it proves that you can place a file at the root of that exact host, which is exactly the control being verified.

How the check works

When you select the verify action, the product sends one credential-free HTTPS request to the exact address. The check is deliberately narrow:

• It uses one plain GET with no query.
• It follows no redirect.
• It applies a short timeout.
• It reads only a small bounded body.
• It requires the content to match exactly.

Any deviation fails closed. An HTTP address, a redirect, a non-200 response, an oversized body, invalid text, a network error, or different content all fail the check and leave the origin pending. Nothing about your website changes when a proof fails; you can correct the file and select verify again.

Why every strict rule exists

Each narrow rule closes a real gap.

A redirect is refused because a redirect would let a different host answer the proof for your origin. This matters in practice: if your apex domain redirects to a subdomain, or the well-known path redirects elsewhere, the proof fails even though the address resolves. Publish the file at the exact address shown in your website detail, on the exact host, without a redirect.

An exact content match is required because a close copy is not a proof. A value with a changed character, extra spacing, or HTML markup around it does not verify. The one allowance is a single final newline, which many publishing tools add automatically.

The request is credential-free because the proof must be public. If the file needed authentication, the check could not confirm what a public visitor's browser would reach.

Each origin needs its own proof

An origin is an exact scheme, host, and port. Two addresses that look similar are different origins, and each origin you register gets its own exact verification address and its own deterministic value.

A file published on one host does not verify another host. If your website serves visitors on more than one origin, add each exact origin and publish each proof at its own address. A root origin may include a trailing slash when you register it, but the stored value is normalized to the bare origin, and a path, query, or fragment is never part of a valid origin.

After verification succeeds

A successful proof marks the origin as verified and shows the verified state in your website detail. The proof content leaves the display, because the file's job is done. The file itself can stay on your host or be removed.

Two more behaviors keep the result honest. A repeated verify action for an already verified origin performs no fetch and creates no duplicate audit entry, because there is nothing left to check. And a later correction to your website does not silently unverify anything: origin state changes only through the documented actions.

With the origin verified, the remaining setup steps can proceed: confirm the read-only repository connection, choose evidence categories, install the widget, and send a test report. The guide to installing a website report widget walks through those steps.

When verification fails, check these first

Work through the causes in order, because most failures are quick to fix:

1. The exact address. Copy the verification address from the website detail rather than typing it, including the exact filename.
2. The exact characters. Copy the 64-character value exactly. One changed character fails the match, and only one final newline is allowed.
3. HTTPS. The file must be served over HTTPS at the exact address.
4. No redirect. The address must return the file directly, not bounce to another host or path.
5. Public reachability. No login, firewall challenge, or cookie wall may sit in front of the file.

After each correction, select the verify action again. A pending origin blocks normal use, so the website cannot serve its report channel until one origin is verified.

The same path for an authorized agent

Humans and agents are peer users of the product. An authorized agent can read the pending proof values, publish the file on your host with your prior authority, and request the verification through the API, using the same operation as the dashboard action. The agent path follows the same strict rules, and each action appears in your audit history.

The agent setup documentation lists the exact operations, including the scopes an agent needs for website setup. Read how to connect an AI agent to your website reports for the approval path, and the security page for the complete product security rules.