Usa esta página para responder a las preguntas que plantea un despliegue. Cuando otra página trata una pregunta a fondo, la respuesta remite a ella.
| Pregunta | Respuesta |
|---|
| ¿Qué necesitan de nosotros para empezar? | Tres cosas: una organización en la consola con un administrador que pueda invitar a todos los demás, HTTPS saliente en el 443 hacia app.openlatch.ai, y el perímetro, es decir, qué máquinas van en la primera oleada. Los scripts de instalación traen el cliente consigo, así que una máquina no necesita ningún entorno de ejecución. Requisitos previos lo convierte en una lista de comprobación |
| ¿Necesita derechos de administrador en la máquina? | No. El cliente se instala y se ejecuta a nivel de usuario, no carga ningún controlador y no abre ningún puerto entrante |
| ¿Podemos desplegarlo con nuestras herramientas de gestión actuales? | Sí. Como el cliente se ejecuta en contexto de usuario, se entrega como un script a nivel de usuario y no como un instalador a nivel de dispositivo, con la credencial pasada desde tu almacén de secretos por el entorno y nunca escrita en un script, un paquete ni una línea de comandos. Crea una clave por oleada de despliegue y revócala cuando termine la oleada. Consulta Desplegar el cliente |
| ¿Qué agentes cubre? | La instalación detecta los agentes presentes en una máquina y conecta cada uno que encuentra. Niveles de control enumera los agentes conectados hoy, plano por plano. Cada agente aparece en la consola con su nivel de control, Enforced, Monitored o Known, que indica cuánto control tienes sobre él |
| ¿Tiene que hacer algo el desarrollador? | Normalmente no. Algunos agentes piden al desarrollador que confirme la conexión una vez, la primera vez que se ejecutan tras la instalación, y openlatch status muestra qué agentes siguen pendientes. Consulta Verificar y desplegar |
| Pregunta | Respuesta |
|---|
| ¿A qué necesita llegar OpenLatch y abre algo? | Un único destino, saliente: app.openlatch.ai en TCP 443 por HTTPS, permitido por nombre porque no hay ningún rango de direcciones estático. Nada de entrada: el cliente solo escucha en la interfaz de bucle local. Consulta Requisitos de red |
| Nuestra única salida es un proxy con autenticación. ¿Qué se admite? | HTTP y HTTPS CONNECT, SOCKS5, proxies transparentes, y PAC o WPAD donde lo evalúa el resolvedor del sistema operativo. Se admiten las autenticaciones Basic y Kerberos (Negotiate). NTLM no, por diseño; Negotiate es la vía en esos entornos. Las credenciales de proxy se guardan en el almacén de credenciales del sistema operativo |
| ¿La inspección TLS lo rompe? | No, siempre que la autoridad de certificación de interceptación sea de confianza. Instálala en el almacén de confianza del sistema operativo, o indícasela al cliente, en cuyo caso se combina encima del almacén del sistema. La verificación nunca se desactiva, y OpenLatch no emite ningún certificado propio |
| ¿Cambia el tráfico propio de nuestros agentes? | No. Tus agentes llegan a sus puntos de acceso de modelos exactamente como antes. Esos puntos de acceso deben seguir siendo accesibles y quedar exentos del almacenamiento en búfer de respuestas y de la inspección de flujos |
| ¿Qué pasa cuando una máquina está sin conexión, o la consola no es accesible? | Las políticas siguen vigentes en la máquina, porque la decisión se toma localmente. Los registros se guardan en la máquina y se envían cuando la consola vuelve a ser accesible. Consulta Arquitectura |
| Pregunta | Respuesta |
|---|
| ¿Es un proxy o una pasarela delante de nuestros agentes? | Ninguna de las dos cosas. OpenLatch se ejecuta dentro del propio ciclo de vida del agente, y la decisión se toma en la máquina antes de que la acción se ejecute. Nada nuestro está en tu camino de red, y OpenLatch no termina ninguna conexión TLS |
| ¿Qué sale de la máquina? ¿Nuestros prompts? ¿Nuestro código fuente? | Los prompts se capturan como metadatos por defecto: que hubo uno, cuándo, en qué sesión y su longitud. El texto del prompt no se envía salvo que tu organización lo active, y las peticiones y respuestas intercambiadas con un modelo nunca se envían a OpenLatch. Lo que sale son los metadatos de las acciones con las credenciales y las rutas de archivo enmascaradas, más las señales de identidad necesarias para atribuir una acción; el contenido de los archivos se filtra por defecto. OpenLatch no se conecta a ninguno de tus repositorios. Consulta Tratamiento de datos y seguridad |
| ¿Dónde está alojada la consola? | En Estados Unidos, en la región US-East, con los datos de cada organización aislados de los de todas las demás. Los veredictos se producen en tus propias máquinas, así que el lugar donde se guardan los registros no afecta a la aplicación. La lista de subencargados está disponible bajo petición |
| ¿Quién puede iniciar sesión en la consola y quién ve qué? | El inicio de sesión único SAML 2.0 se configura por organización, y el acceso dentro de la consola sigue cuatro roles. Cada cambio administrativo se escribe en un registro de auditoría de solo anexado que puedes exportar. Consulta Configurar la organización |
| ¿Puede alguien desactivarlo en su propia máquina? | OpenLatch se dirige a un agente que se comporta mal: que entra en bucle, malgasta presupuesto, sufre una inyección y actúa con sus herramientas, o incumple una política aunque por lo demás funcione con normalidad. El cliente se instala a nivel del propio usuario, así que una persona con control sobre su máquina puede quitarlo. Lo que pierde es la cobertura, no la discreción: la cobertura se informa máquina a máquina, y una máquina que deja de enviar datos aparece como un hueco en lugar de pasar por cubierta |
| Pregunta | Respuesta |
|---|
| ¿Ralentiza al agente? | La decisión se toma en la máquina, sin llamada de red ni modelo en el camino, así que una acción cubierta no aguarda ningún viaje de ida y vuelta. OpenLatch no publica ninguna cifra de latencia. Lo que afirma es que cada acción cubierta llega al punto de decisión de las políticas, y que el veredicto producido por una política explícita es el que se aplica |
| ¿Cómo confirmamos que una máquina está realmente conectada? | openlatch status indica si la máquina está conectada, si hay políticas presentes y si los agentes están conectados, y openlatch doctor demuestra cada uno de esos puntos. Después, los agentes de la máquina aparecen en el registro de agentes de la consola con un propietario. Consulta Verificar y desplegar |
| ¿Cómo funcionan las actualizaciones y podemos fijarlas? | El cliente puede actualizarse, y cada descarga se comprueba en integridad antes de sustituir nada. Déjalo activado en las instalaciones de los desarrolladores. Un entorno gestionado lo desactiva, deja activada la comprobación y entrega la nueva versión en su propia ventana de mantenimiento. Consulta Operar |
| ¿Cómo llevamos las notificaciones y los registros a nuestras herramientas? | Las notificaciones van por correo, a un canal de mensajería como Slack o Microsoft Teams, o a un webhook tuyo, y el registro de auditoría se exporta en CSV o JSON según la conservación que definas. Consulta Configurar los canales de notificación |
| ¿Cómo lo desinstalamos? | openlatch uninstall desconecta el cliente de cada agente de la máquina y deja cada uno como estaba. Añadir --purge elimina además el directorio local y la credencial guardada. Consulta Operar |
| ¿Cómo abrimos un caso de soporte? | Contacta con tu responsable técnico de OpenLatch por el canal acordado con tu organización. Ejecuta openlatch doctor --rescue en la máquina afectada y adjunta el archivo depurado que genera, con el sistema operativo y la hora del problema con su zona horaria. Los avisos de seguridad van a security@openlatch.ai |
