Seguridad y aislamiento

Qué se redacta antes de subir, cómo se mantienen separados los tenants, cómo expiran los links de medios y qué puede y no puede alcanzar un agente de IA.

Estás a punto de grabar las sesiones de tus usuarios — requests de red con bodies, salida de consola, clicks — y entregar las grabaciones a un tercero. Las dos preguntas que importan son qué sale de la página y quién puede verlo alguna vez. Esta página responde ambas, y cada afirmación está aplicada en código, no en política.

Nada se sube hasta que alguien reporta

El SDK mantiene un ring buffer en memoria con capacidad limitada y lo envía solo cuando se llama a report() — por tu usuario, tu código, o un trigger de auto-reporte que hayas habilitado. No hay envío en segundo plano. data-mode="always" existe para los equipos que quieren cada sesión, pero es opt-in, nunca el valor por defecto.

Redactado en el origen, no al llegar

La redacción corre dentro del navegador, antes de que se suba cualquier cosa — así el valor sensible nunca cruza el cable, en lugar de ser eliminado del lado del servidor después de que ya lo recibimos:

Headers: Authorization, Cookie, Set-Cookie y similares se reemplazan con [redacted], y cualquier header cuyo nombre contenga secret o token recibe el mismo tratamiento aunque no esté en la lista exacta.
URLs: los query parameters que transportan credenciales (token, key, secret, …) se redactan dentro de las URLs grabadas.
JSON bodies: campos como password, access_token y refresh_token se redactan dentro de los bodies de requests y responses — iniciar sesión mientras se graba no debe convertir la grabación en una credencial.

Las reglas exactas viven en el módulo de redacción de @espejo/core y corren para cada ruta de captura — red, consola y navegación por igual.

Un tenant nunca puede ver a otro

Cada grabación pertenece a un proyecto, y cada proyecto a exactamente un tenant (tu cuenta). Las paredes entre tenants son estructurales:

Cada consulta filtra a través de la relación de tenant. No existe ningún camino en el código que busque una sesión solo por id: el scope del tenant es parte de la consulta misma, nunca una lista de ids que podría quedar desactualizada.
Un miss es indistinguible de una grabación inexistente. Pedir la sesión de otro tenant devuelve el mismo 404 que pedir una que nunca fue creada — tanto en la API de consola como en las herramientas MCP. Ningún 403 confirma jamás que un id existe.
El acceso de soporte no suplanta identidades. La clave de operaciones internas es rechazada en cualquier lugar donde el acceso se otorga en nombre de una persona — no puede usarse para entrar a la cuenta de un tenant.

Los links de medios están firmados y tienen vida corta

Los artefactos de grabación (eventos, replay del DOM, video) nunca se sirven desde URLs predecibles. Cuando un viewer — o un agente de IA vía MCP — solicita uno, la API genera un link firmado con HMAC que expira a los 10 minutos. Un link filtrado caduca antes de llegar lejos, y la firma cubre la sesión, el artefacto y la expiración, por lo que ninguno de ellos puede intercambiarse.

Qué puede alcanzar un agente de IA vía MCP

El servidor MCP usa OAuth 2.1 con PKCE, y el scope de una conexión se fija una sola vez, en el momento en que la aprobás — desde la cuenta en la que estabas autenticado, nunca desde algo que el agente envíe después. Todas las herramientas MCP son de solo lectura, y cada una de ellas pasa por las mismas consultas con scope de tenant que la consola. Revocar la conexión corta el acceso en la siguiente llamada.

La retención se aplica, no se promete

Las grabaciones se eliminan automáticamente cuando superan la ventana de retención de tu proyecto o cuando los límites de cantidad/minutos desalojan las más antiguas — el proceso corre de forma continua en el servidor, y eliminar una sesión se propaga en cascada a cada artefacto almacenado. Lo que dice el plan es lo que hace el disco.