Estado: Completado
Cuando ampliar permisos no arregla un agente
Un caso real de diagnóstico en el que el agente parecía haber perdido permisos, pero la causa estaba en un perfil efectivo distinto del esperado.
Etiquetas: agentes · diagnóstico · permisos · configuración
¿Qué haces cuando un agente parece haber perdido permisos, pero la capa de permisos no está bloqueando nada?
STATUS COMPLETED
AREA AGENTES / DIAGNÓSTICO
SÍNTOMA CAPACIDADES DESAPARECIDAS
HIPÓTESIS PERMISOS
CAUSA OVERRIDE DE PERFIL
CORRECCIÓN ELIMINAR LA EXCEPCIÓN
RESULTADO CAPACIDADES RESTAURADASEl síntoma
El agente llevaba tiempo trabajando con un conjunto de herramientas que le permitían realizar tareas habituales de desarrollo: leer y modificar archivos, ejecutar procesos y utilizar otras capacidades asociadas a ese tipo de trabajo.
En un momento determinado, algunas de ellas dejaron de estar disponibles.
No había un error especialmente descriptivo. Desde la conversación, el comportamiento se parecía simplemente al de un agente al que ya no se le permitía hacer determinadas cosas.
La primera hipótesis fue bastante natural:
antes podía
+
ahora no puede
→ probablemente ha cambiado algún permisoEsa hipótesis era razonable.
Lo importante fue no convertirla todavía en diagnóstico.
El primer riesgo: arreglar el síntoma concediendo más acceso
Cuando una herramienta deja de funcionar por lo que parece una restricción de permisos, hay varias respuestas rápidas posibles: ampliar una lista de autorizaciones, reducir aprobaciones, relajar una política o conceder más capacidad al proceso.
Todas tienen algo en común: hacen el sistema más permisivo antes de haber demostrado que la seguridad sea realmente la causa del problema.
En este caso llegamos a probar cambios en esa dirección durante la investigación. Tenían sentido bajo la hipótesis inicial, pero no resolvían la causa real.
Eso obligó a separar la pregunta genérica:
¿Por qué no puede hacerlo?
en otras mucho más concretas:
¿la herramienta existe?
¿el agente puede verla?
¿su perfil la incluye?
¿la política permite ejecutarla?
¿el sistema operativo permite la operación?Solo entonces empezó a aparecer una diferencia importante entre no tener una herramienta y tenerla pero no estar autorizado a utilizarla.
Primera comprobación: la política de ejecución
Una de las primeras capas que revisé fue la política encargada de decidir si una herramienta de ejecución podía utilizarse.
Si el problema estaba ahí, esperaba encontrar una restricción nueva, una aprobación obligatoria o algún otro cambio que explicara el comportamiento.
No ocurrió.
La política efectiva permitía la operación.
Eso no demostraba todavía dónde estaba el problema, pero sí permitía descartar una parte importante de la hipótesis inicial:
POLÍTICA DE EJECUCIÓN
→ no está bloqueando la acciónSeguir ampliando esa política habría sido inútil.
Y, además, habría reducido una frontera de seguridad sin resolver el incidente.
Segunda comprobación: qué herramientas veía realmente el agente
El siguiente paso fue dejar de preguntar qué permisos tenía el agente y comprobar algo más básico:
¿qué herramientas le estaban llegando realmente?
Ahí apareció la primera diferencia clara respecto al estado esperado.
Determinadas herramientas asociadas al trabajo de desarrollo simplemente no estaban disponibles en la sesión.
Eso cambiaba por completo el problema.
Si una herramienta no se entrega al agente, la política que regula su ejecución nunca llega a intervenir.
El flujo real termina antes:
herramienta
↓
¿se expone al agente?
↓
NO
finNo importa cuánto relajemos la capa posterior.
Es como cambiar la cerradura de una puerta que no existe.
El perfil efectivo no era el esperado
El sistema utilizaba perfiles de herramientas para decidir qué conjunto de capacidades debía recibir un agente.
La configuración general indicaba un perfil orientado a trabajo de desarrollo:
GLOBAL
tools.profile = codingA primera vista parecía exactamente lo que esperábamos.
Sin embargo, la inspección del estado efectivo del agente mostraba otro perfil.
AGENTE
tools.profile = messagingAhí estaba la discrepancia.
El sistema no estaba ignorando la configuración global. Tampoco había una política de seguridad bloqueando herramientas individuales.
Existía una configuración más específica aplicada únicamente a ese agente.
Conceptualmente:
DEFAULT / GLOBAL
coding
↓
OVERRIDE ESPECÍFICO
messaging
↓
CONFIGURACIÓN EFECTIVA
messagingY esa configuración específica tenía prioridad.
Configuración declarada frente a configuración efectiva
Esta fue la parte más útil del diagnóstico porque explica por qué mirar únicamente la configuración general no había sido suficiente.
Podíamos comprobar una y otra vez esto:
tools.profile = codingy la información era correcta.
Simplemente no era toda la información.
En un sistema con herencia y overrides, el valor relevante no es necesariamente el primero que encontramos en un fichero o una interfaz. Es el resultado después de aplicar todas las capas.
La pregunta correcta pasó de ser:
¿Qué perfil está configurado?
a:
¿Qué perfil está recibiendo este agente concreto?
Ese cambio de pregunta encontró la causa.
La corrección más pequeña no fue cambiar el perfil
Una vez localizado el override había dos formas evidentes de resolverlo.
La primera era modificarlo:
messaging
→
codingEso habría restaurado las herramientas esperadas.
Pero habría dejado esta estructura:
GLOBAL
coding
AGENTE
codingDos lugares expresando la misma decisión.
La segunda opción era eliminar la excepción.
GLOBAL
coding
AGENTE
sin override
↓
hereda codingElegí la segunda.
La configuración global ya representaba exactamente el comportamiento deseado, así que no había ninguna razón funcional para mantener una copia específica del mismo valor.
La corrección consistió en retirar estado, no en añadirlo.
Por qué eliminar era mejor que sobrescribir
La diferencia puede parecer pequeña, pero afecta al mantenimiento futuro.
Supongamos que dentro de unos meses el perfil global cambia deliberadamente. Si existe además un override idéntico en un agente concreto, ese agente dejará de seguir la configuración común y quizá nadie recuerde por qué.
Cada excepción crea una nueva fuente de verdad potencial.
En este caso no necesitábamos una excepción, así que mantenerla habría conservado precisamente el mecanismo que había provocado la confusión.
El cambio más pequeño conceptualmente era:
eliminar configuración innecesaria
→ recuperar herencia normalNo siempre eliminar será la solución correcta, pero cuando un override no expresa una diferencia intencionada, su existencia necesita una justificación.
Volver a mirar el sistema después del cambio
Eliminar el override no cerró automáticamente el incidente.
Primero había que comprobar que el estado efectivo había cambiado realmente.
La secuencia de verificación era sencilla:
antes
→ perfil efectivo inesperado
→ herramientas ausentes
corrección
→ eliminar override
después
→ perfil esperado
→ herramientas disponiblesEso demostraba que la configuración se había aplicado.
Todavía faltaba demostrar que el agente podía completar el tipo de trabajo que anteriormente había fallado.
Es una distinción que intento mantener explícita:
INTENTADO
≠
APLICADO
≠
VERIFICADOUn comando ejecutado no demuestra que el cambio haya surtido efecto, y un estado de configuración correcto tampoco demuestra que la funcionalidad completa funcione.
La prueba final tenía que parecerse al fallo real
Para cerrar el diagnóstico no bastaba con comprobar una pantalla de configuración.
El agente tenía que volver a realizar una tarea que utilizara las capacidades recuperadas.
La prueba combinaba varias de ellas: acceder a información, modificar contenido, ejecutar procesos y producir un resultado final.
La tarea se completó correctamente.
Solo entonces podía considerar el incidente resuelto:
configuración corregida
+
estado efectivo correcto
+
uso real correcto
→ VERIFICADOLa última prueba era importante porque verificaba el comportamiento completo y no únicamente una capa interna.
Después hubo que limpiar las pruebas equivocadas
Durante la investigación habíamos hecho cambios basados en la hipótesis inicial de que existía un problema de permisos.
Una vez demostrado que esa hipótesis era incorrecta, mantener aquellos cambios ya no tenía sentido.
Se retiraron.
Esto forma parte del diagnóstico aunque ocurra después de encontrar la causa.
Una investigación puede dejar detrás excepciones, autorizaciones temporales y configuraciones que solo existieron para comprobar una hipótesis. Si permanecen en el sistema después de descartar esa hipótesis, el incidente termina produciendo deuda técnica.
El estado final debería contener la corrección necesaria.
No todas las pruebas realizadas para encontrarla.
Lo que sabemos y lo que no sabemos
La causa técnica inmediata quedó demostrada.
Existía un override de perfil específico.
Ese override sustituía al perfil global.
El perfil resultante no exponía determinadas herramientas.
Al eliminar la excepción, el agente volvió a heredar el perfil esperado y las capacidades reaparecieron.
Lo que no quedó demostrado fue cómo se había creado originalmente aquella excepción.
Había explicaciones plausibles, pero ninguna evidencia suficiente para convertir una de ellas en hecho.
Y para resolver el incidente tampoco era necesario saberlo.
DEMOSTRADO
override presente
→ perfil efectivo distinto
→ herramientas ausentes
NO DEMOSTRADO
por qué se creó originalmente el overrideMantener esa separación evita terminar un diagnóstico técnico con una historia causal inventada para rellenar la única pieza que nos falta.
Qué habría ocurrido si simplemente hubiéramos dado más permisos
Este caso permite comparar dos enfoques.
El primero habría sido:
no puede ejecutar
↓
ampliar permisos
↓
sigue sin funcionar
↓
ampliar más permisos
↓
seguir probandoIncluso si alguna combinación hubiera terminado modificando indirectamente el comportamiento, habríamos acabado con un sistema más permisivo y con una comprensión peor de la causa.
El enfoque que terminó funcionando fue otro:
síntoma
↓
separar capas
↓
comprobar estado efectivo
↓
localizar primera discrepancia
↓
cambiar una sola causa
↓
verificar
↓
retirar pruebas innecesariasNo es una técnica específica de agentes.
Es diagnóstico de sistemas.
Qué dejó este incidente
El resultado inmediato fue recuperar las capacidades esperadas del agente.
El resultado más útil fue otro: una forma mejor de investigar problemas similares.
Desde entonces, cuando una capacidad parece bloqueada, el orden de preguntas es aproximadamente este:
1. ¿qué debería poder hacer?
2. ¿qué herramientas recibe realmente?
3. ¿qué configuración efectiva está utilizando?
4. ¿qué política se aplica a esas herramientas?
5. ¿qué permite después el sistema operativo?
6. ¿dónde aparece la primera diferencia?Solo cuando la diferencia está realmente en una capa de autorización tiene sentido ampliar permisos.
Eso reduce el número de cambios durante el diagnóstico, evita debilitar fronteras que estaban funcionando correctamente y deja una explicación bastante más precisa de lo ocurrido.
Resultado
El incidente empezó pareciendo una pérdida de permisos.
La política encargada de autorizar la ejecución, sin embargo, ya permitía la operación. El problema estaba una capa antes: una configuración específica hacía que el agente recibiera un perfil distinto del esperado y determinadas herramientas ni siquiera llegaban a estar disponibles.
La corrección consistió en eliminar esa excepción, recuperar la herencia de la configuración global, comprobar el nuevo estado efectivo y ejecutar después una tarea real para verificar la recuperación.
El caso terminó siendo bastante pequeño.
Pero precisamente por eso resulta útil.
No hizo falta conceder más acceso.
Hizo falta mirar una capa antes.