¿Qué debes comprobar antes de dar acceso a un Agent de IA?

Antes de dar acceso a un Agent de IA, comprueba ocho cosas: quién puede darle instrucciones, qué recursos alcanza, dónde se ejecutan las acciones, cómo se limitan las credenciales, qué plugins son de confianza, qué requiere aprobación, dónde van los datos y cómo revocar el acceso.

Empieza con los permisos mínimos para completar la tarea. Amplía el acceso por una necesidad real, no solo porque exista la opción.

Por qué debes revisar juntos los mensajes y las herramientas

Un Agent puede recibir mensajes grupales, páginas web, correos, archivos, resultados de herramientas y contenido de plugins. Cualquiera de esas entradas puede influir en su siguiente acción.

El riesgo práctico es la combinación de entrada y autoridad. No es lo mismo un Agent de solo lectura que uno con shell, sesiones del navegador, archivos privados y capacidad de enviar mensajes.

1. ¿Quién puede hablar con el Agent?

Decide si es privado, usa pairing o allowlist, pertenece a un equipo o está abierto al público. Revisa por separado los mensajes directos y los grupos.

La guía oficial Gateway Security de OpenClaw recomienda controlar primero la identidad mediante pairing o allowlists. La política oficial Hermes Agent Security Policy también exige autorización en las superficies de mensajería de red.

2. ¿A qué archivos y herramientas accede?

Enumera solo las capacidades necesarias. Leer un proyecto no exige acceso a toda tu carpeta personal, y enviar un estado no requiere comandos de shell ilimitados.

Prefiere un workspace restringido, acceso de solo lectura o ningún acceso al sistema de archivos. Activa shell, escritura, navegador o automatización solo cuando el flujo lo necesite.

¿Cómo limitas un Agent de IA a una sola carpeta?

Crea un directorio de trabajo dedicado que contenga únicamente los archivos necesarios. Configura el framework y el sistema operativo para que las rutas externas no se puedan leer ni modificar. Si el Agent solo necesita revisar archivos, expón el workspace como solo lectura.

Revisa rutas indirectas que puedan saltarse el límite, como enlaces simbólicos, carpetas montadas, comandos de shell, descargas del navegador, directorios temporales compartidos o credenciales guardadas dentro del workspace.

Prueba el límite con datos desechables. Pide al Agent que lea, cree, edite y elimine un archivo dentro del workspace y que intente hacer lo mismo fuera. Las acciones externas deben fallar y cualquier carpeta o herramienta nueva debe requerir otra aprobación.

3. ¿Dónde se ejecutan los comandos?

Comprueba si se ejecutan directamente en el host, en un sandbox de herramientas, en un contenedor o dentro de un aislamiento completo del proceso.

Hermes señala que su backend local puede ejecutar comandos en el host y que el aislamiento fuerte depende del sistema operativo. OpenClaw también separa policy, sandbox y aislamiento del host.

4. ¿Qué credenciales puede alcanzar?

Haz inventario de claves de modelos, tokens cloud, claves SSH, sesiones del navegador, correo y cuentas de servicios. No guardes en el host más secretos de los necesarios.

Usa credenciales separadas, de alcance limitado y fáciles de sustituir.

5. ¿En qué skills, plugins y connectors confías?

Un plugin puede ejecutarse con los privilegios del Agent. Revisa su código, licencia, responsable, scripts de instalación, red y actualizaciones.

Los connectors de ClawChat para OpenClaw y Hermes son integraciones independientes mantenidas por Clawling. Eso no convierte en fiable cualquier plugin de terceros.

6. ¿Qué acciones necesitan aprobación humana?

Pide aprobación para acciones que cambian cuentas, publican, envían mensajes, gastan dinero, borran datos o modifican producción.

La documentación de permisos de ClawChat describe Ask every time, Allow y Deny para acciones compatibles dentro de ClawChat. No sustituyen los controles de archivos, shell, navegador o credenciales del host.

Una política práctica de Allow, Ask y Deny

Clasifica los permisos según su impacto, reversibilidad y alcance. No muevas una capacidad de Deny a Ask, ni de Ask a Allow, hasta que un flujo real la necesite y el límite haya sido probado.

• Allow: trabajo reversible y de bajo impacto dentro del workspace dedicado, como leer archivos aprobados o transformar una copia.
• Ask every time: escribir o borrar archivos, enviar mensajes, publicar, instalar software, usar el navegador o shell, cambiar cuentas o abrir una carpeta nueva.
• Deny: directorios no relacionados, credenciales sin protección, billing, sistemas de production, comandos destructivos y acciones externas irreversibles, salvo que exista un flujo específico revisado.

Aplica esta política en todas las capas relevantes. Los permisos del mensajero, la policy de herramientas, el filesystem, el alcance de credenciales, el sandbox y el aislamiento del sistema operativo protegen límites diferentes.

7. ¿Dónde van mensajes, memoria y metadata?

Dibuja la ruta: cliente, servicio de mensajería, connector, runtime, proveedor de modelo, herramientas y memoria. Cada capa puede procesar datos diferentes.

La Privacy Policy de ClawChat explica el tratamiento de metadata operativa y señala que la memoria privada del Agent está en su runtime o proveedor de hosting. Revisa también las políticas del modelo y del host.

8. ¿Cómo probarás y revocarás?

Prueba primero con una carpeta, cuenta y conversación de bajo riesgo. Confirma que las acciones denegadas fallan y que un remitente no autorizado no activa el Agent.

Debes saber detener el proceso, desactivar el connector, revocar credenciales, rotar claves y eliminar pairing o allowlist.

Lista breve de permisos

• Solo las personas y grupos previstos pueden enviar instrucciones.
• El Agent ve únicamente los archivos y herramientas necesarios.
• La ejecución de alto impacto está aislada correctamente.
• Las credenciales son separadas, limitadas y reemplazables.
• Se han revisado skills, plugins y connectors.
• Las acciones sensibles requieren aprobación o están denegadas.
• Se entiende la ruta de mensajes, modelo, memoria y metadata.
• Puedes probar denegaciones y revocar acceso rápidamente.

Cómo se aplica al conectar un Agent a ClawChat

Trata ClawChat como la capa de conversación y el framework del Agent como la capa de ejecución. Configura quién participa y después qué puede hacer el Agent en su host.

Consulta cómo chatear con un Agent que ejecutas tú mismo y qué es un mensajero para Agent de IA.

Preguntas frecuentes

¿Debo dar acceso total a un Agent personal?

Solo si un flujo real lo necesita y las entradas, el aislamiento, las credenciales y la recuperación corresponden a esa autoridad.

¿Un mensaje de aprobación es una barrera de seguridad?

Es una protección útil, pero no siempre es contención fuerte. Combínalo con aislamiento del sistema operativo, sandboxing y credenciales limitadas.

¿El self-hosting resuelve los permisos?

No. Ofrece más control del runtime, pero también te hace responsable del host, la red, las credenciales, los plugins y las copias de seguridad.

Conecta de forma deliberada

Empieza con poco acceso, prueba los límites y añade una capacidad cada vez.

Cuando el modelo de permisos esté claro, conecta tu Agent a ClawChat y verifica la primera conversación con datos de bajo riesgo.