Cuando un agente «no tiene permiso» y el problema no son los permisos

Cuando un agente deja de hacer algo que hacía con normalidad, una explicación aparece casi sola: ha perdido permisos.

Eso fue lo primero que pensé cuando KITT (sí, el nombre es un pequeño homenaje a El coche fantástico; era difícil resistirse) dejó de disponer de algunas de sus capacidades habituales en OpenClaw.

No editaba archivos. No ejecutaba comandos. No podía utilizar herramientas que hasta entonces formaban parte de su trabajo ordinario.

El síntoma era real.

La interpretación era equivocada.

El problema no estaba en los permisos de ejecución. Esas herramientas ni siquiera estaban llegando al agente.

La diferencia parece pequeña hasta que intentas arreglar la capa incorrecta.

El problema estaba bien descrito, pero mal nombrado

La instalación tenía unas fronteras bastante claras.

KITT se ejecutaba dentro de una máquina virtual dedicada y podía trabajar como un usuario Linux normal. Leer y escribir archivos, editar, ejecutar procesos o utilizar Git formaban parte de ese espacio de trabajo.

Eso no significaba darle acceso indiscriminado al sistema. root, sudo, Proxmox, el router u otros equipos seguían siendo fronteras distintas.

Por eso, cuando desaparecieron capacidades tan básicas, sospechar de los permisos parecía razonable.

Podía haber cambiado una política de ejecución. Una actualización podía haber endurecido alguna regla. Quizá una allowlist estaba bloqueando comandos. Tal vez alguna aprobación que antes no existía se había activado.

Todas eran hipótesis plausibles.

El problema fue agruparlas demasiado pronto bajo una misma palabra:

permisos

Porque un agente puede dejar de hacer algo por motivos muy diferentes.

Tener una herramienta y poder utilizarla son preguntas distintas

La primera comprobación desmontó buena parte de la hipótesis.

La política efectiva de ejecución seguía siendo permisiva:

security = full
ask = off

También lo era dentro de la sesión problemática.

Es decir, si KITT hubiera recibido una herramienta de ejecución, esa capa no habría impedido utilizarla.

Pero seguía sin poder ejecutar.

La pista apareció al comprobar qué herramientas veía realmente el agente.

Su perfil efectivo era:

messaging

y herramientas como Exec, Process o Edit no estaban disponibles para el modelo.

Ahí cambió el diagnóstico.

No teníamos esto:

herramienta disponible
+
política que impide utilizarla

Teníamos esto:

herramienta no expuesta al agente

Modificar permisos de ejecución no podía resolverlo.

Es como cambiar los permisos de una puerta que ni siquiera existe en la habitación en la que estás.

Los agentes tienen más de una frontera

La experiencia me obligó a separar varias capas que, vistas desde fuera, producen síntomas muy parecidos.

De forma simplificada:

la herramienta existe
↓
la herramienta se expone
↓
el perfil la permite
↓
la política de ejecución la autoriza
↓
el sistema operativo permite la acción
↓
el recurso está dentro del alcance

Un fallo en cualquiera de esos puntos puede terminar con una respuesta equivalente a:

No puedo hacer eso.

Pero no son el mismo problema.

Si una herramienta no se expone al modelo, relajar la política de ejecución no sirve.

Si está expuesta pero necesita aprobación, cambiar el perfil tampoco lo arregla.

Si puede ejecutarse como usuario normal pero la operación requiere root, estamos ante otra frontera distinta.

Y si técnicamente puede ejecutar un comando pero el recurso está fuera del alcance autorizado, la limitación vuelve a ser otra.

Cuanto más capaces se vuelven los agentes, menos útil resulta utilizar permiso como explicación genérica.

La configuración global decía una cosa

Había otro detalle que hacía el diagnóstico menos evidente.

La configuración global era la esperada:

tools.profile = coding

Sin embargo, el agente veía:

Profile: messaging

Las dos cosas eran ciertas.

La explicación apareció al inspeccionar la configuración específica de KITT:

GLOBAL
tools.profile = coding

KITT
agents.entries.main.tools.profile = messaging

Existía un override.

La configuración global decía que los agentes debían utilizar el perfil de herramientas de programación. KITT tenía una excepción más específica que lo convertía en un agente de mensajería.

Y la configuración específica ganaba.

OpenClaw no estaba ignorando la configuración.

Estaba aplicándola correctamente.

Eso cambia bastante la forma de interpretar el incidente.

Desde fuera parecía:

KITT ha perdido permisos

La descripción más precisa era:

KITT está heredando un perfil distinto del que esperaba
y por eso determinadas herramientas no se le exponen

La segunda formulación abre hipótesis mejores.

La configuración efectiva importa más que la configuración que recuerdas

En un sistema sencillo solemos preguntar:

¿Cuál es la configuración?

En uno con defaults, perfiles, herencia y excepciones, la pregunta importante es otra:

¿Qué configuración está siendo efectiva aquí?

Puedes mirar un valor global completamente correcto y seguir sin estar viendo el valor que determina el comportamiento.

Eso no ocurre solo con agentes.

Aparece en configuración de aplicaciones, permisos cloud, CSS, políticas de red, servidores web, CI/CD o prácticamente cualquier sistema con herencia.

Hay un valor por defecto.

Después una configuración global.

Después una excepción para un componente.

Quizá otra para una sesión.

Y al final lo que importa no es cuál de esos valores existe, sino cuál gana.

En nuestro caso, la configuración global era correcta y, por tanto, modificarla habría añadido otro cambio sin tocar la causa.

La solución fue eliminar configuración

La corrección podía haberse hecho cambiando el perfil específico de KITT de:

messaging

a:

coding

Habría funcionado.

Pero también habría dejado dos lugares configurando lo mismo.

El perfil global ya era el correcto. No necesitábamos otra excepción.

La solución fue eliminar el override específico y permitir que KITT volviera a heredar la configuración global.

Es un detalle pequeño, pero me parece una buena regla de mantenimiento.

Cada override añade estado.

Y cada nuevo estado es otra cosa que habrá que recordar cuando la configuración cambie en el futuro.

Si un valor común ya expresa el comportamiento deseado, heredar suele ser más limpio que duplicarlo.

Las excepciones deberían existir porque son excepciones, no para repetir el default.

Arreglar no es lo mismo que verificar

Después del cambio, las comprobaciones internas ya eran coherentes.

El agente volvía a mostrar el perfil coding. Las herramientas esperadas aparecían otra vez. La política de ejecución seguía siendo la prevista.

Pero eso solo demostraba que la configuración parecía correcta.

Faltaba probar el comportamiento.

Le pedimos a KITT una tarea real que necesitaba leer un archivo, transformarlo, ejecutar procesos y producir un PDF.

La completó de principio a fin.

Ese fue el momento en que el cambio pasó de aplicado a verificado.

Esta distinción parece obvia, pero se pierde con facilidad durante un diagnóstico:

he cambiado algo
≠
el problema está resuelto

Una configuración válida, un servicio arrancado o un test aislado pueden ser necesarios sin ser suficientes.

La última comprobación debería parecerse, siempre que sea posible, al uso que había fallado.

También tuvimos que deshacer nuestras propias hipótesis

Durante los primeros intentos habíamos añadido entradas a una allowlist.

Era una reacción coherente con el diagnóstico inicial: si el agente parece no tener permiso, ampliar una lista de permisos parece una prueba razonable.

Después supimos que aquella capa no era la responsable.

Las entradas se retiraron.

Me parece una parte importante del trabajo y una que muchas veces se olvida.

Un diagnóstico no termina únicamente cuando encuentras la causa.

También conviene limpiar los cambios experimentales que fuiste dejando por el camino.

De lo contrario, cada incidencia deposita pequeñas capas de configuración provisional hasta que, algún día, una de ellas se convierte en la siguiente incidencia.

Hay una parte de la historia que no conocemos

Nunca demostramos cómo apareció exactamente aquel override messaging.

Es posible que procediera de alguna interacción posterior con la interfaz. Es una explicación plausible.

No es un hecho demostrado.

Y no hacía falta convertirla en uno para resolver el problema.

Sabíamos dos cosas suficientes:

el override existía
+
el override provocaba el comportamiento observado

Eso bastaba para corregir el sistema.

Buscar causalidad más allá de la evidencia habría producido una historia más redonda, pero no un diagnóstico mejor.

También aquí hay una lección reutilizable: una explicación plausible no gana precisión por repetirla suficientes veces.

Dar más acceso habría empeorado el sistema

Lo más interesante del incidente no es que una línea de configuración ocultara tres herramientas.

Es lo fácil que habría sido responder al síntoma aumentando privilegios.

Ante:

El agente no puede ejecutar.

podríamos haber reaccionado con:

más allowlist
menos aprobaciones
una política más permisiva
más privilegios del sistema

Ninguna de esas medidas atacaba la causa.

Algunas, además, habrían reducido las fronteras de seguridad que habíamos establecido deliberadamente.

Ese es el aprendizaje que me parece realmente reutilizable:

Antes de aumentar permisos, conviene identificar qué capa está impidiendo la acción.

Porque no puede hacerlo describe un síntoma.

No un diagnóstico.

Antes de preguntar cuánto acceso necesita, preguntaría qué ve

Desde entonces intento separar dos cosas durante un problema técnico:

lo que observo

y

la explicación que estoy dando a lo observado

KITT realmente no podía utilizar Exec, Process o Edit.

Eso era evidencia.

Que hubiera perdido permisos era una hipótesis.

La diferencia fue suficiente para evitar tocar capas que funcionaban correctamente y terminar encontrando una excepción de configuración que estaba haciendo exactamente aquello para lo que había sido configurada.

Un agente puede parecer bloqueado por seguridad cuando el sistema simplemente no le ha entregado la capacidad que esperamos que utilice.

Así que la próxima vez que uno diga «no puedo», antes de darle más permisos, empezaría con una pregunta más básica:

¿Qué puede ver realmente?