Quién puede llegar a tu Hollware, con qué, y las protecciones delante de cada solicitud.

Tokens, OAuth y passkeys

Tres tipos de tokens

Token	Empieza con	Llega a	Se crea con
Personal	`hw_pat_`	MCP, la API de lectura, las operaciones por HTTP	`hollware token create`, el admin
De lectura	`hw_read_`	solo la API de lectura, contenido publicado	`hollware token create --read`
De acceso OAuth	(opaco)	lo que la persona permitió	un cliente OAuth y una página de consentimiento

Hollware guarda el SHA-256 de un token, nunca el token, y muestra uno nuevo una sola vez. Un token es de un sitio, vence después de los días que le indiques (de 1 a 365), o nunca si no indicas ninguno, y se puede revocar desde la CLI o el admin; un token revocado deja de funcionar en la siguiente solicitud.

Un token vale lo que vale hoy su persona: en cada solicitud, sus scopes se intersecan con el rol actual de la persona.

Passkeys

Las personas inician sesión solo con passkeys. El primer dueño configura una con el enlace que imprime hollware init; los demás, con una invitación. En Tu cuenta, cada persona les pone nombre a sus passkeys y elimina una que perdió, nunca la última; y cambia su propio nombre, que nadie más puede cambiar. El admin es un cliente OAuth del propio Hollware, y guarda su token de acceso solo en memoria.

Secretos

Los envíos de un webhook se firman con un secreto que crea Hollware (make_webhook_secret, o Sitio en el admin), que se muestra una sola vez y se guarda en la base de datos sellado con AES-GCM bajo el secreto del Worker HOLLWARE_SECRET, así que la base de datos sola nunca guarda uno en claro. hollware deploy crea HOLLWARE_SECRET cuando el Worker no lo tiene, y nunca reemplaza uno que ya existe: uno nuevo dejaría los secretos sellados sin poder abrirse, y los webhooks necesitarían secretos nuevos.

Cambiar la estructura de un sitio requiere schema:admin, que solo otorga el rol de dueño, tenga quien tenga el token: una persona en el admin o un agente.

Protecciones

Host y Origin. Hollware responde solo a las solicitudes para el host de HOLLWARE_PUBLIC_URL. Una solicitud desde una página de otro origen se rechaza, salvo las lecturas de la API de lectura desde los orígenes que un sitio lista en cors.origins.
Sin cookies en las APIs. /mcp y /v1 leen el encabezado Authorization y nada más. La cookie de sesión de una persona solo la leen las páginas de inicio de sesión.
Sin indexación. Cada respuesta lleva X-Robots-Tag: noindex, nofollow y /robots.txt lo prohíbe todo: el admin, las APIs y las imágenes no son para buscadores. Tus sitios sí.
Imágenes que no ejecutan nada. Un SVG se acepta solo cuando nada en él se ejecuta ni sale del archivo, y se sirve con una política que no ejecuta nada (ver Imágenes).
Metadatos de clientes por internet pública. El servidor OAuth obtiene los documentos de metadatos de los clientes con global_fetch_strictly_public, así que un cliente no puede hacer que apunte a tu propia red.

Registro de actividad

Cada cambio de un sitio y cada rechazo queda como una línea en su registro de actividad: quién lo hizo, tal como Hollware lo verificó (una persona en el admin, un token personal, una app que una persona autorizó, o Hollware mismo al publicar lo programado), lo que el cliente dijo de sí mismo (su cliente MCP y su modelo, que se muestran aparte porque es lo que el cliente declara), la acción, sobre qué actuó y cómo terminó: realizada, denegada por falta de un permiso, o fallida.

Incluye cada operación que no es de lectura, los tokens creados y revocados, los roles, los miembros quitados, las invitaciones creadas y aceptadas, el inicio y el cierre de sesión, las passkeys renombradas y quitadas, los nombres cambiados, las apps autorizadas y revocadas, y las publicaciones programadas. Las lecturas no se registran. El registro solo admite agregar líneas: ninguna se modifica, y ninguna se borra antes de que se cumpla la retención de su sitio.

Los dueños lo leen en el admin, en Actividad, lo filtran por acción, persona y fechas, y lo descargan como CSV. El dueño decide qué guarda, en Sitio, Registro de actividad:

Direcciones IP: no se guardan por defecto. Una dirección es un dato personal; si decides guardarlas, Hollware guarda solo un hash de cada dirección con una clave propia del sitio, nunca la dirección, de modo que se puede saber que varias solicitudes vinieron de la misma dirección sin poder saber cuál es.
Retención: indefinida por defecto, o de 30 a 3650 días, tras los cuales Hollware borra las líneas.

hollware init y npm create hollware aceptan las mismas opciones como --ip-addresses hashed y --audit-retention-days 365.

Reporta una vulnerabilidad

Repórtala en privado por los avisos de seguridad del repositorio de GitHub, nunca en un issue.