Domain (DNS · .well-known)
Pairing a domain proves that you control the place your work lives on the open web: a personal site, a project domain, an institutional address. Two attestation paths sit on the same pairing: a DNS TXT record (T1) or a signed .well-known/alter file (T2).
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Make any change to your DNS zone. Every query is a public-API read, never an authenticated zone-edit.
- •Modify, deploy to, or upload anything to your web origin. The .well-known fetch is a plain HTTPS GET.
- •Issue, request, or revoke TLS certificates on your behalf.
- •Transfer the domain, change registrar, or alter WHOIS contact records.
- •Read or transmit the contents of anything served from your domain outside the /.well-known/alter/<your-handle> path.
- •Use the domain attestation to claim authority over you to a third party without your separate consent.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- The TXT record at _alter._handle.<your-domain> when you publish it. The member-pairing record _alter._handle.<domain> is distinct from the org identity record _alter.<domain> - both are correct; they serve different purposes.
- The contents of https://<your-domain>/.well-known/alter/<your-handle> when that path responds.
- The TLS certificate served on the apex hostname, for fingerprint-and-rotation tracking only.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Anything outside _alter._handle. Other DNS records (A, AAAA, MX, SPF) are never queried.
- The body of any HTML, CSS, or JS served from the domain.
- WHOIS records or registrar metadata.
- Subdomain enumeration. We do not scan, sweep, or zone-transfer.
- Traffic, analytics, or referrer data.
Where it lives
The TXT or .well-known evidence is stored in ~alter's pairing ledger keyed to your ~handle, with a tier badge (T1 DNS or T2 file-signed). Re-verification runs at most every 90 days for signed records; you can trigger a recheck on demand. Removing the TXT record or returning 404 at .well-known unpairs the domain automatically at the next check.
How to revoke
Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter unpair websitePairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.