Who can reach your Hollware, with what, and the guards in front of every request.

Tokens, OAuth and passkeys

Three kinds of tokens

Token	Starts with	Reaches	Made with
Personal	`hw_pat_`	MCP, the read API, the operations over HTTP	`hollware token create`, the admin
Read	`hw_read_`	the read API only, published content	`hollware token create --read`
OAuth access	(opaque)	what the person allowed	an OAuth client and a consent page

Hollware stores the SHA-256 of a token, never the token, and shows a new one once. A token is of one site, expires (90 days by default), and can be revoked from the CLI or the admin; a revoked token stops working on the next request.

A token is worth what its person is worth today: its scopes are intersected with the person's current role on every request.

Passkeys

People sign in with passkeys only. The first owner sets one up with the link that hollware init prints; everyone else with an invitation. The admin is an OAuth client of Hollware itself, and keeps its access token in memory only.

Guards

Host and Origin. Hollware answers only requests for the host of HOLLWARE_PUBLIC_URL. A request from a page of another origin is refused, except reads of the read API from the origins a site lists in cors.origins.
No cookies on the APIs. /mcp and /v1 read the Authorization header and nothing else. The session cookie of a person is read by the sign-in pages alone.
Client metadata over the public internet. The OAuth server fetches the metadata documents of clients with global_fetch_strictly_public, so a client cannot point it at your own network.

Report a vulnerability

Report it privately through the security advisories of the GitHub repository, never in an issue.