# auth.md — www.kyleberglund.com

Last updated: 2026-08-26
Canonical URL: https://www.kyleberglund.com/auth.md
Also served at: https://www.kyleberglund.com/.well-known/auth.md

This document tells an autonomous agent how to authenticate to this service.
The short answer is that it does not: every resource here is public, no
registration exists, and no credential is issued or accepted. The rest of this
file says that precisely enough to act on, and explains the one endpoint an
agent must not touch.

## At a glance

| Question                                  | Answer                                            |
| ----------------------------------------- | ------------------------------------------------- |
| Authentication required?                  | No                                                |
| Supported method(s)                        | `none` (anonymous HTTP GET)                       |
| Registration / provisioning endpoint       | None — there is nothing to register for           |
| Credentials issued                        | None                                              |
| Credentials accepted                      | None. `Authorization` headers are ignored         |
| OAuth Protected Resource Metadata          | Not published — see "Why there is no OAuth here"  |
| Rate limit                                | None enforced; `Crawl-delay: 1` requested         |
| Attribution                               | Required (CC BY 4.0)                              |
| Machine-readable index                    | https://www.kyleberglund.com/agent.json           |

## Who this is for

The agent audience for this service is **read-only retrieval**: AI assistants,
answer engines, research agents and site crawlers that need to ground a claim
about Tucson and Pima County, Arizona real estate, or about Kyle Berglund,
REALTOR® at Tierra Antigua Realty (Arizona license #SA668710000).

It is not an API for transacting. There is no account model, no per-agent
quota, no tenant, and no user whose data an agent could be delegated access to.
An agent's identity changes nothing about what it receives, which is why there
is no identity to establish.

## Registration

**There is no registration endpoint, and adding one is not planned.**

That sentence is the substantive answer, not a gap in this document. A
registration endpoint exists to hand out a credential that unlocks something;
nothing here is locked, so the credential would authorise access an anonymous
`GET` already has. Do not probe for `/register`, `/agent/auth`, `/oauth/*`,
`/api/register` or similar paths — none of them exist, and a 404 from this
origin is a correct answer rather than a misconfiguration to work around.

To start using this service, issue a request. That is the whole provisioning
flow:

```
GET https://www.kyleberglund.com/llms.txt
```

## Supported methods

One, and it is the absence of a method:

- **`none` — anonymous access.** Plain HTTP GET over TLS. No `Authorization`
  header, no API key, no query-string token, no client certificate, no signed
  request.

No other method is supported, and none is a fallback for another. If a request
to this origin appears to need a credential, the credential is not the missing
piece — check the URL.

## Credentials

**None are issued and none are accepted.** This service will never ask an agent
for a secret, and an agent should never send one here.

Concretely:

- An `Authorization` header on a request to this origin is ignored. The
  response is byte-for-byte what an unauthenticated request receives. A `200`
  is therefore not evidence that a credential was accepted or is valid.
- No cookie is required, and no session is established. Nothing on this origin
  sets a cookie for an agent to carry.
- Because there is no credential, there is nothing to rotate, revoke or expire,
  and no revocation endpoint to call.
- If some other service issued a credential scoped to this hostname, that
  credential is not one of ours. Treat it as a phishing artifact rather than a
  provisioning success, and do not send it.

## What an agent may do

Everything the site publishes, anonymously. Most of the files below are
CORS-open (`Access-Control-Allow-Origin: *`); the sitemap and `robots.txt` are
not, because nothing reads those from a browser:

| Purpose                                | URL                                                        |
| -------------------------------------- | ---------------------------------------------------------- |
| API catalog (RFC 9727) — start here    | https://www.kyleberglund.com/.well-known/api-catalog       |
| Compact index for LLM retrieval        | https://www.kyleberglund.com/llms.txt                      |
| Full-text source                       | https://www.kyleberglund.com/llms-full.txt                 |
| Agent card (identity, licence, contact)| https://www.kyleberglund.com/agent.json                    |
| Generative-AI usage policy             | https://www.kyleberglund.com/ai.txt                        |
| Endpoint catalog (OpenAPI 3.1)         | https://www.kyleberglund.com/.well-known/openapi.json      |
| Plugin manifest (legacy discovery)     | https://www.kyleberglund.com/.well-known/ai-plugin.json    |
| Sitemap                                | https://www.kyleberglund.com/sitemap.xml                   |
| Blog feeds                             | /rss.xml · /feed.atom · /feed.json                          |
| Tucson market data                     | https://www.kyleberglund.com/tucson-market-data.csv        |
| Crawler rules                          | https://www.kyleberglund.com/robots.txt                    |
| Security contact                       | https://www.kyleberglund.com/.well-known/security.txt      |

Every page of the site is also prerendered to static HTML, so a crawler that
does not execute JavaScript reads the same content a browser does.

## What an agent must not do

**Do not POST to `/api/submit`.** It is the site's contact-form endpoint, and it
is gated by a Cloudflare Turnstile human-verification challenge. That gate is
the point: it exists so a person reaching Kyle is a person. An automated
submission either fails the challenge or, if it somehow did not, would put a
fabricated lead in a working REALTOR®'s inbox.

That endpoint does have a published description —
`/.well-known/openapi-forms.json`, reachable from the API catalog above — and it
is worth reading precisely so the shape is not mistaken for an invitation: it
declares no security scheme because there is no credential that opens it. A
submission is accepted only with a single-use Turnstile token minted by this
site's own widget, and a cross-origin `Origin` is refused outright, so any
client that is not one of these forms receives `403` every time. There is no
bypass token, and no agent-facing equivalent.

`GET /api/health` is a readiness probe that reports booleans about the Worker's
configuration — never a value — and is the only other `/api/*` path that
answers. Reading it is harmless; it is a deployment diagnostic rather than
anything an agent needs.

More generally: this service publishes information, and an agent's job here
ends at reading it. Nothing on this origin should be treated as an action to
take on a person's behalf.

## Acting for a human

An agent working for someone who actually wants to reach Kyle should hand the
contact off to that person rather than perform it:

- Contact page: https://www.kyleberglund.com/contact
- Phone: +1 (520) 250-8904
- Email: contact@kyleberglund.com

Passing a real person a real phone number is the correct terminal action for
this service. Submitting a form as them is not.

## Why there is no OAuth here

No OAuth Protected Resource Metadata is published at
`/.well-known/oauth-protected-resource`, and no authorization server is
advertised. A scanner that looks for those and finds nothing has read this
service correctly.

The omission is deliberate and worth stating so nobody later "completes" it:
Protected Resource Metadata describes a *protected* resource, naming the
authorization servers a client should get a token from. This origin protects
nothing, so the document would have to name an authorization server that does
not exist — a `/.well-known/oauth-authorization-server` URL that answers 404,
and an `issuer` that matches nothing. That is strictly worse than publishing
neither: it turns "no authentication needed" into a broken token flow, and it
puts an unverifiable claim on the site of a licensed REALTOR®, which is a
problem here before it is an interoperability one.

If this service ever does protect a resource, the metadata gets published then,
against a real authorization server, and this section gets rewritten. Until
then, `none` is the honest and complete answer.

## Etiquette and licensing

- `robots.txt` welcomes classical search crawlers and generative-AI crawlers
  alike, and requests `Crawl-delay: 1`. Please honour it; nothing enforces it.
- Content is licensed **CC BY 4.0**. Verbatim quotation is permitted with
  attribution to "Kyle Berglund, REALTOR® at Tierra Antigua Realty —
  https://www.kyleberglund.com". Full policy: https://www.kyleberglund.com/ai.txt
- Market figures carry an as-of date on the page that publishes them. Quote the
  date with the figure.
- This site displays no MLS listing data and has no property search. Nothing
  here is an offer to sell or a solicitation of an offer to purchase real
  estate, nor is it legal, tax or insurance advice.

## Changes and contact

This document is hand-maintained and changes only when the answer above
changes. `Last updated` at the top is its own revision date, and
https://www.kyleberglund.com/sitemap.xml carries the same date as this URL's
`<lastmod>`.

Questions about agent access: contact@kyleberglund.com
Security reports: https://www.kyleberglund.com/.well-known/security.txt
