Chatbot Access defines the public floor for agents that can only fetch URLs and read small records. It keeps low-capability clients useful without letting them infer permissions they do not have.
Access model
- Minimal Access Tier: public-safe read-only GET requests with no body, no auth, no custom headers, and a two-field response.
- GET-Action Pattern: bounded fallback for simple idempotent actions when POST is unavailable to an L0/L1 client.
- Advanced Agent Support: schema-aware, POST-first, consent-bound, evidence-bearing behavior for capable clients.
Live GET boundary
Some chatbot fetch tools can read indexed or cached public pages but cannot execute an unindexed dynamic GET URL. If an action route needs live dynamic HTTP GET, the route record should declare that fetch class and provide a live-GET-blocked fallback such as a no-op review URL or higher-capability handoff.
Safe reading order
/agent-start/for the public entry point./ai-summary/for a compact site summary./claim-boundary-faq/for support and non-claim boundaries./ecosystem-overlay/for related layers without treating them as UAIX authority.
What chatbots should do
- Prefer the lowest capability tier that answers the request.
- Cite the public URL returned by Minimal Access and stop when action is not supported.
- Use the listed fallback when a route requires live dynamic GET but the client only has search-indexed or cached fetch.
- Never invent authentication, private context, hidden POST bodies, custom headers, or write authority.
- Escalate to a human or a higher-capability agent when code
428, consent, POST JSON, live GET, or verification is required.
Route family
- Minimal Access TierRead-only public-safe URL-only floor.
- GET-Action PatternRequired for bounded fallback configuration, separate from Minimal Access.
- Agent Capability LadderL0-L5 progressive access view.
- Progressive Agent AccessHow clients graduate to POST, schemas, and handoffs.
- Advanced Agent SupportConsent, memory, workflow, and audit boundaries.