Mantén las claves API fuera del modelo: lista de verificación de OpenClaw 2.0

Si operas un asistente de IA autoalojado y estás a punto de migrar a OpenClaw 2.0, trata la actualización como un punto de control de seguridad. OpenClaw anunció la versión 2.0 el 31 de agosto de 2026 como la mayor actualización en la historia del proyecto. Las horas que dedicas antes del reinicio son más baratas que las que pierdes después de una clave filtrada.

Una gran liberación cambia los valores predeterminados, los permisos y los lugares donde pueden aparecer secretos. Aún puedes mantener el margen: menos piezas móviles, menos puertos expuestos, menos credenciales en el contexto del modelo.

La magnitud del cambio es la razón para ir con calma

OpenClaw 2.0 fue construido por 933 colaboradores, incluidos 569 colaboradores primerizos, y contenía más de 16.000 pull requests. También contenía aproximadamente la mitad de todos los pull requests que se han fusionado en el proyecto. Ese tipo de cambio puede mejorar el asistente, pero también puede desplazar la frontera entre tu máquina y el mundo exterior.

El salto de versión no tomará estas decisiones por ti

Antes de ejecutar la actualización, haz una copia de las cosas que odiarías perder. Archivos de configuración, estado, ajustes de herramientas y cualquier nota local que el asistente pueda leer forman parte del radio de impacto. Una copia de seguridad no es un control de seguridad en sí misma, pero te da una vía de regreso cuando una configuración no se comporta como esperabas.

La lista de verificación a continuación es la parte de la actualización que te corresponde a ti. Cada elemento es lo suficientemente pequeño para revisarlo en un minuto. Los tres primeros se refieren a la recuperabilidad y la visibilidad: una copia, un punto de entrada conocido y una lectura de diagnóstico antes de que el asistente empiece a trabajar. El resto se trata de mantener las credenciales fuera de alcance.

• Copia el archivo de configuración y la carpeta de datos locales a una carpeta separada antes de reiniciar.
• Verifica que el gateway sea accesible solo desde la interfaz que pretendes.
• Ejecuta el comando de diagnóstico y lee la salida antes de darle al asistente cualquier tarea nueva.
• Activa las credenciales protegidas para cualquier credencial que pases a un agente en un entorno compartido.
• Activa el sandbox para código no confiable.
• No uses sesiones compartidas como frontera de seguridad.
• Verifica que solo tu usuario pueda leer el directorio de estado.
• Enumera los puertos abiertos y confirma que cada uno tenga una razón para ser accesible.
• Confirma que una regla de egress limite los destinos salientes.
• Desactiva las herramientas sin usar y exige aprobación para acciones que eliminen, envíen o gasten.

Las sesiones compartidas son fáciles de malinterpretar. Los controles de sesión en la nube compartidos en 2.0 no proporcionaban aislamiento de inquilino ni aislamiento entre usuarios distintos, y no constituían una frontera de seguridad. Si dos personas, dos agentes o dos espacios de trabajo comparten una sesión, trátala como una sala común, no como una privada.

Las credenciales protegidas importan porque un entorno compartido puede mostrar más de lo que pretendes. OpenClaw 2.0 añadió una función de credenciales protegidas que permite a los usuarios dar credenciales a agentes en entornos compartidos sin mostrarlas en el chat. Si una credencial aparece en el chat, se convierte en parte del contexto que el modelo puede repetir, resumir o filtrar en un registro. Las credenciales protegidas son útiles, pero no sustituyen mantener la credencial fuera del alcance del modelo desde el principio.

El código no confiable no debería obtener los mismos derechos que tus propios scripts. El sandbox para código no confiable en 2.0 no estaba activado por defecto. Si el sandbox está desactivado, una instrucción maliciosa puede tocar archivos, llamar herramientas o mover datos.

El directorio de datos locales es parte del modelo de seguridad

Los valores almacenados en el Secret Store no estaban cifrados en reposo en 2.0, y el almacén dependía de los permisos del sistema de archivos del directorio de estado. Si otro usuario, servicio o proceso puede leerlo, los valores almacenados quedan expuestos aunque la ventana de chat parezca limpia.

Luego verifica que las copias de seguridad, los registros y las carpetas de sincronización no copien el directorio de estado a un lugar con permisos más laxos. Un secreto que está oculto para el modelo pero visible para el sistema de archivos sigue siendo un secreto que puede filtrarse.

Termina revisando la red. El asistente debería poder alcanzar solo los servicios que necesita. Una regla de firewall o una lista de permisos puede impedir que una instrucción maliciosa llegue a un host desconocido. La regla debe ser lo suficientemente estricta para que puedas enumerar los hosts permitidos y explicar por qué cada uno está ahí.