Tratamiento de datos y seguridad

Entrega esta página a una revisión de seguridad. Expone qué sale de una máquina que ejecuta el cliente, qué se queda en ella, cuánto tiempo se conserva cada registro y cómo se controla el acceso a la consola.

OpenLatch controla un agente que se comporta mal: uno que entra en bucle o gasta presupuesto en un trabajo que nadie pidió, uno al que se le ha inyectado algo a través de su contexto y actúa en consecuencia con sus herramientas, y uno que incumple una política aunque por lo demás se comporte como se diseñó. Esos fallos causan incidentes reales, y son lo que el bucle de control intercepta antes de que la acción se ejecute. OpenLatch no afirma resistir a un agente diseñado para evadirlo.

Principios

Principio	Qué significa
La decisión se toma en la máquina	Cada veredicto se calcula en la máquina, antes de que la acción se ejecute. La consola no está en el camino de decisión
OpenLatch no está en ningún camino de red	El cliente no es una pasarela y no inspecciona el tráfico de tu organización. Tus agentes llegan a sus puntos de acceso de modelos exactamente como antes
Datos mínimos	Los valores se enmascaran y las cadenas se truncan antes de que nada salga de la máquina, y se envían metadatos siempre que el contenido no sea necesario
Ninguna credencial sale de la máquina	Las claves que usan tus agentes se quedan en la máquina. Las contraseñas de proxy las guarda el sistema operativo, nunca en un archivo de configuración ni en un registro

Inventario de datos

Lee primero la segunda columna.

Dato	Sale de la máquina	Enmascaramiento y límites	Dónde se guarda	Conservación
Metadatos de la acción (nombre de herramienta, sesión, veredicto, momento)	Sí	Ninguno. Los metadatos no contienen texto libre	Consola	180 días
Comandos de shell y argumentos de herramientas	Sí	Credenciales enmascaradas con marcadores etiquetados. Cada cadena limitada a 4 KB	Consola, y en forma de hash en los agregados de uso	180 días; agregados 30 días
Rutas de archivo	Sí	Enmascaradas de la misma forma, y con hash con una clave propia de la organización en los agregados de uso	Consola, y en forma de hash en los agregados de uso	180 días; agregados 30 días
Contenido de archivos	Configurable	Filtrado por defecto, o solo hash. Captura en línea limitada a 64 KB	Consola	180 días
Prompts	Solo metadatos	Aparición, momento, sesión y longitud. El texto del prompt no se envía salvo que tu organización lo active	Consola	180 días
Peticiones y respuestas de modelos	No	El contenido nunca se envía. Se registran el número de tokens, el modelo usado y el reparto de caché	Consola	90 días
Identidad del usuario	Sí	Usuario del sistema operativo y correo de git, para atribuir una acción a una persona	Consola	180 días, con el registro
Identidad de la máquina	Sí	Sistema operativo, arquitectura, direcciones IP local y pública, versiones de software, un identificador de instalación	Consola	180 días, con el registro
Identificador de cuenta de modelo	Sí	Un identificador de cuenta, o una marca que indica que se usa una clave compartida. Nunca un token ni una clave	Consola	180 días, con el registro
Políticas	Solo descendente	Se envían a la máquina, nunca se suben desde ella	En la máquina	Hasta que un conjunto más reciente las sustituye
Veredictos y anomalías	Sí	Ninguno	Consola	180 días

Figura 1. Flujo de datos y límites de confianza: los registros enmascarados suben, las políticas bajan y el tráfico de modelos nunca pasa por OpenLatch.

Enmascaramiento y lo que se queda en la máquina

El enmascaramiento se ejecuta en el cliente, en la máquina, antes de que un registro entre en la cola de envío. Recorre el contenido y sustituye los valores con forma de credencial por un marcador etiquetado que conserva el prefijo público reconocible y elimina el secreto, con la forma [AWS_KEY:AKIA***]. Solo se enmascaran los valores de cadena; los nombres de campo nunca. El enmascaramiento se ejecuta antes del truncamiento, así que cortar una cadena en el límite de 4 KB no puede revelar el final de un secreto parcialmente enmascarado. Se ejecuta después del veredicto, así que el texto depurado nunca cambia qué políticas coinciden. Tu organización puede añadir sus propias formas de credencial a la configuración del cliente, y se aplican junto con las integradas.

Conservación

Dato	Periodo	Configurable	Exportación
Registros de acciones	180 días	No	—
Registros de decisiones y anomalías	180 días	No	CSV
Agregados de uso	30 días	No	Consola
Archivos con hash	90 días	No	Consola
Registros de coste y tokens	90 días	No	Consola
Registro de auditoría	90, 180, 365 o 730 días, o un periodo personalizado	Sí, con purga automática	CSV o JSON

El registro de auditoría es el único periodo que defines tú, en la consola, con purga automática; Configurar la organización muestra dónde. Todos los demás periodos son fijos. Las políticas guardadas en la máquina no tienen periodo de conservación: se sustituyen cuando el cliente obtiene un conjunto más reciente y se eliminan cuando el cliente se desinstala con --purge.

Alojamiento

La consola es un servicio alojado en Estados Unidos, en la región US-East. Los datos de cada organización están separados de los de todas las demás por la propia base de datos: la seguridad a nivel de fila se impone en cada tabla de cliente, sin ningún rol de ejecución que la eluda. La lista de subencargados está disponible bajo petición.

En tránsito, el cliente y la consola se comunican con TLS validado frente al almacén de confianza del sistema operativo, con la opción de confiar en una autoridad de certificación adicional donde tu entorno termina TLS con la suya, y sin ninguna opción que desactive la verificación. En reposo, los secretos almacenados están cifrados.

Identidad y acceso

La consola admite el inicio de sesión único SAML 2.0 por organización. Proporcionas el identificador de entidad del proveedor de identidad, su URL de inicio de sesión y un certificado de firma o una URL de metadatos, y después defines los dominios de correo permitidos. Una prueba realiza el intercambio e informa del resultado antes de que la conexión entre en servicio. Microsoft Entra ID, Okta, PingOne y Active Directory Federation Services se conectan así.

Dos puertas controlan quién se une. Los dominios de correo permitidos restringen qué direcciones acepta la consola, y las invitaciones controlan quién es admitido. Una conexión SAML propia de la organización es la única fuente de identidad que admite a un miembro sin invitación, así que un inicio de sesión social nunca sirve para eludir el aprovisionamiento.

Rol	Qué permite
owner	Todo lo que permite admin, más la propiedad de la propia organización
admin	Ajustes de identidad, políticas, credenciales del cliente y ajustes de conservación
editor	Políticas y sustituciones del propietario de un agente
viewer	Acceso de lectura a agentes, ejecuciones, decisiones y el registro de auditoría. Las personas invitadas empiezan aquí

Una credencial de cliente hereda el rol de la persona que la emitió. Una emitida por un editor no puede cambiar un ajuste de identidad, y revocar la credencial o rebajar el rol de la persona cierran la misma puerta.

El registro de auditoría es de solo anexado y está encadenado por hash, así que una fila eliminada o modificada rompe la cadena. Cada cambio de política escribe una fila que nombra al autor, con el estado antes y después. El registro se exporta en CSV o JSON, su periodo de conservación es configurable con purga automática, y la propia exportación escribe un evento de auditoría.

Proteger el cliente y sus políticas

Las actualizaciones del cliente se comprueban en integridad antes de sustituir nada: el resumen SHA-512 de la descarga debe coincidir con el que publica el registro de paquetes para esa versión. Esa comprobación detecta daños y truncamientos; no protege frente a un registro comprometido.

Las políticas guardadas en la máquina se comprueban antes de usarse, y de nuevo en cada carga, no solo cuando se obtienen. Un conjunto que no supera la comprobación se descarta y se notifica, y la máquina funciona sin política hasta que llega un conjunto más reciente. Ese estado queda marcado en cada registro en lugar de silenciarse, y lo mismo ocurre cuando nunca se ha obtenido ninguna política: la acción se permite y el registro dice por qué. OpenLatch nunca bloquea una acción porque falte una política.

El material secreto lo guarda el almacén de credenciales del sistema operativo cuando existe y, si no, un archivo que solo puede leer su propietario. Una credencial pasada en una línea de comandos se rechaza, porque otros procesos de la máquina pueden leer una línea de comandos.

Telemetría de producto e informes de fallos

La telemetría de producto trata del software de OpenLatch, no de los agentes de tu organización. Contiene nombres de comandos, duraciones, el agente, códigos de error y volúmenes, y nunca texto de comandos, rutas de archivo, contenido de archivos ni prompts. El consentimiento se pide en la instalación, se puede cambiar después y está desactivado por defecto en integración continua. Los informes de fallos contienen un mensaje de error depurado y nada más, y se envían salvo que los desactives.

Ambos viajan a app.openlatch.ai con el tráfico que el cliente necesita para funcionar, así que una regla de red no puede pararlos sin aislar el cliente de la consola. Los ajustes están en el cliente: rechaza la telemetría en la instalación o ejecuta openlatch system telemetry disable, y desactiva los informes de fallos con OPENLATCH_CRASH_REPORTING=0. Desactivados, el cliente se comporta exactamente igual que con ellos activos. Privacidad y telemetría los explica con más detalle.

Informar de una vulnerabilidad

Envía los avisos de seguridad a security@openlatch.ai. OpenLatch confirma la recepción en un plazo de dos días hábiles y trabaja el caso con quien lo comunicó.

En resumen

Salen de la máquina los metadatos de las acciones, los comandos y rutas de archivo enmascarados, los veredictos y las anomalías. El texto de los prompts se queda en la máquina salvo que tu organización lo active, y las peticiones y respuestas de modelos nunca se envían.
Un único directorio contiene la configuración y los registros locales, en texto claro, protegidos por los permisos de archivo del usuario y tu cifrado de disco. Las credenciales las guarda el sistema operativo, o un archivo solo para su propietario.
Los registros de acciones y decisiones se conservan 180 días, los agregados de uso 30 días, los archivos con hash y los registros de coste 90 días. El registro de auditoría es el único periodo que defines, con purga automática, y se exporta en CSV o JSON.
La consola está alojada en Estados Unidos (US-East), con los datos de cada organización aislados por la base de datos. SAML 2.0 por organización, cuatro roles de owner a viewer, credenciales de cliente que heredan el rol de quien las emite, y un registro de auditoría de solo anexado y encadenado por hash.
Las actualizaciones se comprueban en integridad antes de instalarse, y las políticas de la máquina se comprueban antes de usarse y en cada carga. Una máquina sin política utilizable permite la acción y lo indica en el registro.