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

Cuando un agente deja de hacer algo que hasta ayer hacía con normalidad, hay una explicación que aparece casi automáticamente: ha perdido permisos.

Parece razonable. Si ya no puede editar un archivo, ejecutar una herramienta o realizar una acción que antes estaba disponible, nuestra primera reacción suele ser buscar una política más restrictiva, una aprobación nueva, una lista de permisos incompleta o algún cambio de seguridad.

El problema es que “no puede hacerlo” describe un síntoma, no la causa.

Un agente puede terminar exactamente en ese mismo síntoma porque no tiene autorización para utilizar una herramienta, pero también porque esa herramienta ni siquiera se le ha entregado, porque está ejecutándose bajo un perfil distinto del esperado, porque existe una configuración más específica que sustituye a la general o porque el recurso al que intenta acceder está fuera de su ámbito.

Desde fuera todos esos casos pueden parecer iguales. Desde dentro son problemas completamente diferentes.

Tener una capacidad y tener permiso para usarla no es lo mismo

Cuando pensamos en permisos solemos imaginar una capacidad que existe y una regla que impide utilizarla. La herramienta está ahí, el agente intenta usarla y alguna capa de seguridad responde que no.

Ese es solo uno de los posibles escenarios.

También puede ocurrir que la herramienta nunca llegue al agente. En ese caso no existe ninguna acción que autorizar o denegar porque, desde la perspectiva del modelo, esa capacidad sencillamente no forma parte de su entorno.

La diferencia es importante:

herramienta disponible
+
política que impide utilizarla

no es lo mismo que:

herramienta no disponible

En el primer caso tiene sentido investigar permisos. En el segundo, modificar esos permisos no puede solucionar nada.

Es una distinción sencilla, pero cambia completamente el diagnóstico.

Un agente atraviesa varias capas antes de hacer algo

Cuanto más capaces se vuelven los agentes, más fácil resulta hablar de “sus permisos” como si existiera una única barrera entre el modelo y el sistema.

En realidad suele haber varias.

De forma simplificada, una operación puede depender de que la herramienta exista, de que esté expuesta al agente, de que el perfil activo permita utilizarla, de que una política autorice su ejecución, de que el sistema operativo conceda los permisos necesarios y de que el recurso se encuentre dentro del alcance previsto.

Podemos imaginar algo parecido a esto:

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

Un fallo en cualquiera de esos puntos puede terminar produciendo prácticamente el mismo mensaje para el usuario: el agente no puede hacer algo.

Pero cada capa exige una solución distinta.

Si la herramienta no está disponible, ampliar privilegios de ejecución no sirve. Si está disponible pero requiere una aprobación, cambiar el perfil tampoco resuelve el problema. Si todo lo anterior funciona pero el sistema operativo rechaza la operación, entonces estamos ante otra frontera diferente.

Por eso “problema de permisos” es muchas veces una categoría demasiado grande para resultar útil.

La configuración que vemos puede no ser la que está actuando

Existe además otra fuente frecuente de confusión: los sistemas modernos rara vez tienen una única configuración.

Tenemos valores por defecto, configuración global, perfiles, ajustes específicos para determinados componentes, excepciones, variables de entorno y, en algunos casos, configuración asociada a una sesión o ejecución concreta.

Eso significa que consultar un valor correcto no demuestra que ese sea el valor responsable del comportamiento que estamos observando.

Podemos tener:

configuración global
→ perfil A

configuración específica
→ perfil B

y comprobar una y otra vez que la configuración global contiene exactamente lo que esperamos mientras el sistema continúa comportándose según el perfil B.

Las dos observaciones son compatibles.

El problema no está en que el sistema ignore su configuración, sino en que está aplicando una configuración más específica.

Este patrón no tiene nada de particular de los agentes. Aparece constantemente en desarrollo de software: CSS, configuración de aplicaciones, permisos cloud, servidores web, redes, sistemas de CI/CD y cualquier entorno donde existan herencia y precedencia.

Por eso, cuando hay varias capas, la pregunta útil deja de ser “¿cuál es la configuración?” y pasa a ser “¿cuál es la configuración efectiva en este punto concreto?”

El estado efectivo importa más que el estado declarado

Esta diferencia entre configuración declarada y configuración efectiva me parece especialmente útil cuando trabajamos con sistemas complejos.

Un archivo puede decir que una capacidad está habilitada. Una interfaz puede mostrar que existe una política determinada. Una configuración global puede parecer perfectamente correcta. Ninguna de esas cosas garantiza por sí sola que el componente que está fallando esté utilizando exactamente esos valores.

Lo que necesitamos conocer es el estado resultante después de aplicar defaults, herencias, excepciones y overrides.

Es una idea muy familiar en programación. No solemos depurar una aplicación preguntándonos únicamente qué valor asignamos originalmente a una variable. Queremos saber qué valor tiene cuando aparece el fallo.

Con un agente ocurre lo mismo.

La configuración que recordamos no necesariamente es la configuración que está actuando.

Los overrides son útiles, pero también crean deuda

Cuando encontramos una configuración específica que sustituye a otra más general, la tentación puede ser corregirla asignándole explícitamente el valor adecuado.

Funcionaría, pero no siempre es la mejor solución.

Si el comportamiento general ya expresa exactamente lo que queremos, mantener una excepción que repite ese mismo comportamiento introduce un segundo lugar desde el que controlar la misma decisión. Y cada nuevo lugar añade estado.

Ese estado tendrá que entenderse cuando algo cambie dentro de seis meses. Tendrá que actualizarse si cambia el valor global. Podrá volver a ocultar una configuración correcta y convertirse en una nueva fuente de inconsistencias.

Por eso, si una excepción deja de ser necesaria, muchas veces la solución más limpia no consiste en modificarla.

Consiste en eliminarla.

Las excepciones deberían existir porque representan comportamientos realmente excepcionales, no para repetir aquello que el sistema ya sabe hacer por defecto.

Diagnosticar también significa no tocar lo que funciona

Cuando el síntoma parece un problema de permisos, existe además un riesgo especialmente incómodo: intentar solucionarlo haciendo el sistema más permisivo.

Podemos ampliar listas de herramientas, reducir requisitos de aprobación, relajar políticas de ejecución o conceder privilegios adicionales. Cada uno de esos cambios puede parecer razonable si estamos convencidos de que alguna capa de seguridad está bloqueando la operación.

Pero si el problema está en otro nivel, ninguna de esas medidas resuelve la causa. Y algunas empeoran el sistema.

Hemos aumentado superficie de acceso sin obtener ninguna capacidad nueva, simplemente porque estábamos intentando reparar la capa equivocada.

Ese es uno de los aprendizajes que considero más importantes de este tipo de incidentes: antes de ampliar permisos conviene demostrar que el bloqueo está realmente en los permisos.

No es solo una cuestión de seguridad. También es una cuestión de calidad del diagnóstico.

Cambiar cinco cosas hasta que una combinación termina funcionando puede devolvernos un sistema operativo, pero no necesariamente un sistema que entendemos.

“Aceptar todo” también es una decisión técnica

Las interfaces de muchas herramientas hacen muy fácil resolver la fricción de otra manera: aceptar la siguiente petición, conceder acceso permanente, permitir todas las operaciones o seleccionar la opción más amplia para evitar que el sistema vuelva a preguntar.

Como experiencia de usuario es comprensible. Una persona que simplemente quiere utilizar una herramienta puede preferir comodidad y continuidad antes que estudiar cada frontera de permisos que aparece delante.

En un entorno profesional creo que deberíamos exigirnos algo más.

No porque haya que convertir cada aprobación en una auditoría de seguridad, sino porque conceder sistemáticamente el máximo acceso tiene dos costes. El más evidente es aumentar innecesariamente la superficie de riesgo. El menos visible, y quizá más importante a largo plazo, es renunciar a entender cómo funciona realmente el sistema con el que estamos trabajando.

Si ante cada bloqueo nuestra respuesta es ampliar permisos hasta que desaparezca, dejamos de saber qué capacidades eran realmente necesarias, qué capa estaba actuando y qué frontera acabamos de eliminar.

La comodidad empieza entonces a sustituir al conocimiento del sistema.

Y para alguien que trabaja profesionalmente con tecnología esa debería ser, como mínimo, una señal de advertencia.

Un agente capaz de modificar archivos, ejecutar procesos, utilizar servicios externos o actuar sobre otros sistemas no debería convertirse en una caja negra a la que concedemos acceso creciente simplemente para evitar interrupciones. Entender dónde termina cada permiso forma parte de entender la herramienta.

No siempre necesitamos elegir la opción más restrictiva.

Sí deberíamos saber por qué estamos eligiendo una más permisiva.

Una hipótesis razonable sigue siendo una hipótesis

Durante un diagnóstico solemos construir explicaciones parciales con la información disponible. Eso es inevitable y necesario.

El problema aparece cuando olvidamos qué parte observamos realmente y qué parte hemos inferido.

Si un agente no muestra determinadas herramientas, eso es una observación. Que una actualización las haya retirado es una hipótesis. Que alguien modificara accidentalmente una configuración es otra. Que una política de seguridad esté bloqueándolas es otra distinta.

Podemos investigar todas ellas, pero no deberíamos convertir una explicación plausible en un hecho únicamente porque encaje bien con la historia.

Esta separación entre evidencia e interpretación resulta especialmente importante cuando trabajamos con IA porque tanto nosotros como el propio modelo somos muy buenos construyendo relatos coherentes alrededor de información incompleta.

Una buena historia causal puede ayudarnos a investigar.

No sustituye la evidencia.

Resolver el problema tampoco termina al encontrar la causa

Hay otro detalle que creo que merece más atención de la que suele recibir.

Durante una investigación hacemos cambios provisionales. Añadimos permisos, modificamos configuraciones, activamos opciones, introducimos excepciones o probamos caminos que finalmente descubrimos que no estaban relacionados con el fallo.

Cuando encontramos la causa verdadera resulta tentador celebrar que el sistema vuelve a funcionar y dejar todo lo demás como está.

Eso convierte cada incidencia en una pequeña capa de deuda.

Si una modificación se introdujo para probar una hipótesis que después descartamos, conviene retirarla. De lo contrario terminamos acumulando configuración cuyo propósito ya nadie recuerda y que puede convertirse en la causa del siguiente problema.

Depurar no consiste únicamente en encontrar qué cambio hace desaparecer el síntoma.

También consiste en dejar el sistema en un estado que sigamos entendiendo.

Aplicado no significa verificado

Incluso después de corregir la causa queda una última diferencia importante: que la configuración parezca correcta no significa todavía que el problema esté resuelto.

Podemos revisar el estado efectivo, comprobar que las herramientas esperadas vuelven a aparecer y verificar que las políticas tienen los valores correctos. Todo eso constituye evidencia útil.

Pero la comprobación definitiva debería parecerse, siempre que sea posible, al uso que había fallado.

Si el agente debía leer información, transformarla, ejecutar una operación y producir un resultado, lo razonable es comprobar precisamente esa secuencia.

cambio aplicado
≠
problema verificado como resuelto

En desarrollo hacemos esto constantemente. Que el código compile no demuestra que la funcionalidad funcione. Que un servicio arranque no garantiza que responda correctamente. Que una configuración sea válida sintácticamente no significa que produzca el comportamiento esperado.

Con los agentes no debería ser diferente.

Pensar por capas evita muchas soluciones falsas

Este tipo de diagnóstico vuelve a mostrar una ventaja de aplicar conceptos de ingeniería de software a los sistemas de IA.

Ante un síntoma ambiguo, podemos intentar arreglarlo directamente o podemos modelar las capas que intervienen.

¿Qué capacidad debería existir? ¿Está realmente disponible? ¿Qué configuración efectiva recibe el componente? ¿Qué política se aplica después? ¿Qué permisos tiene el proceso? ¿Qué recurso intenta alcanzar? ¿Dónde aparece exactamente la primera diferencia entre lo esperado y lo observado?

Son preguntas bastante más útiles que empezar modificando opciones hasta que algo cambia.

Y tienen otra ventaja: producen conocimiento reutilizable. Una vez entendemos qué capa era responsable, la próxima incidencia empieza desde un modelo mental mejor.

Un agente que dice «no puedo» todavía no nos ha dado el diagnóstico

Los agentes hacen que muchas capas técnicas parezcan una única interfaz conversacional. Eso es cómodo cuando todo funciona, pero puede ocultar bastante complejidad cuando algo falla.

El modelo puede decir que no puede realizar una acción, pero esa frase no nos explica si la herramienta no existe, si no se le ha entregado, si una política la bloquea, si el sistema operativo la rechaza o si estamos intentando utilizarla fuera de su alcance.

La interfaz resume todos esos estados en una experiencia parecida.

Nuestro trabajo consiste en volver a separarlos.

Por eso, cuando una capacidad desaparece, cada vez me interesa menos empezar preguntando cuánto acceso debería darle al agente. Prefiero empezar por algo anterior: qué puede ver realmente, qué configuración está actuando y en qué capa exacta deja de cumplirse lo que esperamos.

Solo después tiene sentido hablar de permisos.