# Investigar llamadas bloqueadas de agentes de IA sin debilitar los controles Las llamadas bloqueadas de agentes de IA no son una molestia que haya que eliminar. Son la parte del sistema de control que muestra dónde dejaron de coincidir las instrucciones del agente, la interfaz de la herramienta, la configuración del acceso o su comportamiento con la realidad. Si tratas cada denegación como una petición de más permisos, acabarás concediendo a un agente la autoridad más amplia justo cuando tienes menos motivos para confiar en su siguiente movimiento. He visto equipos convertir una denegación útil en una excepción permanente porque el plazo apremiaba y las pruebas estaban dispersas. La primera aprobación parece inofensiva. La segunda se vuelve rutinaria. Pronto un agente puede llegar a producción con una credencial que nunca necesitó ver, a través de una herramienta que nadie sabe explicar con claridad. Eso no es eficiencia. Es una investigación que decidiste no realizar. Investigar llamadas bloqueadas de agentes de IA significa responder, en el orden correcto, a unas pocas preguntas: ¿qué solicitó exactamente el proceso?, ¿qué control lo rechazó?, ¿la tarea justificaba esa solicitud? y ¿cuál es la reparación mínima que permite continuar el trabajo legítimo? El orden importa. Si empiezas ampliando el acceso, todos los registros posteriores serán más difíciles de interpretar. ## Un registro de denegación es una prueba, no un mensaje de error Una solicitud bloqueada registra un desacuerdo entre la acción que el agente intentó realizar y la autoridad que pretendías concederle. Conserva ese desacuerdo el tiempo suficiente para entenderlo. Una denegación puede revelar una credencial ausente, un proceso no aprobado, una herramienta demasiado vaga, un entorno incorrecto o una solicitud que nunca debió hacerse. La palabra «bloqueada» mezcla dos sucesos distintos. Una acción puede fallar porque el gateway no la autoriza, o puede llegar a un servicio externo y fallar allí porque el servicio la rechaza. El primer suceso indica que tu control detuvo la solicitud. El segundo indica que permitiste que saliera y el destino la rechazó. Investiga el primero antes de que se convierta en el segundo. Un registro útil responde preguntas que una transcripción de consola normalmente no puede responder: - ¿Qué proceso de agente hizo la solicitud y cómo se identificó? - ¿Qué operación HTTP o comando SSH exacto solicitó? - ¿Qué destino y referencia de credencial seleccionó? - ¿Qué control o condición de aprobación la denegó? - ¿Qué instrucción de la tarea o contexto del repositorio llevó a esa solicitud? No aceptes «el agente necesitaba acceso al despliegue» como respuesta. El acceso al despliegue es una categoría. Una investigación necesita una operación, un objetivo y un resultado esperado. «Leer el estado de la versión actual desde la API de staging» es una afirmación comprobable. «Acceso al despliegue» invita a aprobar lo que aparezca después. NIST Special Publication 800-92, Guide to Computer Security Log Management, señala que los registros ayudan a responder a incidentes y a resolver problemas operativos. Lo que muchos equipos omiten es la conservación: el registro debe guardar contexto suficiente para distinguir un error normal de una solicitud anómala. Una ventana emergente de aprobación no es un registro. Una línea copiada de la terminal tampoco. Conserva la ejecución completa y la llamada individual antes de cambiar ninguna configuración. Las denegaciones tienen otra ventaja: obligan al operador a explicar qué autoridad pretendía conceder. Esa explicación se convierte en una prueba para la siguiente ejecución. Si nadie puede expresarla sin palabras amplias como «admin», «producción» o «acceso al repositorio», la tarea no está lista para una ejecución autónoma. ## Nombra la acción solicitada antes de cambiar el acceso No puedes investigar una llamada bloqueada hasta reducirla a una frase que otro ingeniero pueda reproducir. La frase debe nombrar al actor, la acción, el destino, la referencia de autenticación y el resultado esperado. Si falta una de esas piezas, deja de tratarla como una simple solicitud de permisos. En HTTP, registra el método, la ruta, el nombre de host y si la llamada lee o modifica el estado. `GET /releases/current` y `POST /releases` pueden usar el mismo servicio y credencial, pero presentan riesgos muy distintos. Un token bearer que puede leer un endpoint de estado también podría activar un despliegue. No deduzcas el alcance seguro a partir de una etiqueta amigable de credencial. En SSH, registra el alias del host, el comando solicitado, el directorio de trabajo si la herramienta lo muestra y el artefacto esperado. «Ejecutar pruebas en el host de compilación» sigue siendo demasiado impreciso. «Ejecutar `git status --short` en el repositorio ya descargado» ofrece al revisor algo concreto que comparar con la tarea. Los comandos con redirecciones de shell, sustitución de comandos, instalación de paquetes, borrado o transferencia de red merecen más atención, porque su verbo visible puede ocultar la parte peligrosa. Usa esta nota breve mientras la ejecución siga disponible: ```text Run identity: Task instruction: Requested operation: Target host or API path: Credential reference: Control that denied it: Expected result: Why this request belongs to the task: Smallest safe repair: ``` La nota evita el fallo habitual en las transferencias: una persona ve el prompt, otra una tarjeta de aprobación y una tercera el error del destino. Cada una tiene un fragmento plausible y alguien termina aprobando por confianza. Sallyport muestra primero la autoridad de firma de código del proceso en la autorización de sesión. Ese es el dato correcto que hay que revisar antes de aprobar una ejecución nueva. La identidad del proceso no demuestra que la solicitud sea sensata, pero impide tratar todos los procesos locales como equivalentes. Una terminal iniciada por la aplicación firmada esperada y un ejecutable desconocido que pide la misma acción son casos distintos. No uses la descripción libre de la tarea como prueba suficiente. Los agentes pueden interpretarla mal, las instrucciones heredadas pueden entrar en conflicto y un repositorio malicioso puede incluir instrucciones que parezcan una guía normal del proyecto. Compara la acción solicitada con una fuente de tarea que controles, como un ticket revisado o una instrucción explícita del operador. El texto del repositorio es una entrada, no una autoridad. ## El origen de la denegación cambia la investigación Los controles deniegan por razones distintas y cada razón requiere una reparación diferente. Tratar todas las denegaciones como un único «permiso denegado» produce arreglos deficientes porque oculta dónde se tomó la decisión. Una denegación de la bóveda bloqueada significa que no debe continuar ninguna acción. No respondas moviendo la credencial a una variable de entorno, copiándola en un prompt o creando otra ruta de código. Esas medidas eluden exactamente la protección que detectó el problema. Confirma que la persona frente al Mac quiere desbloquear el acceso para esa tarea y reanuda solo después de que haya revisado el contexto de la ejecución. Una denegación de sesión nueva significa que el proceso de agente aún no ha recibido autoridad para su ejecución actual. Revisa la identidad del proceso y los límites de la tarea. Si coinciden con el trabajo iniciado, la aprobación por sesión es adecuada porque tiene una duración limitada: cuando termina la ejecución, termina también esa autoridad. Si la identidad sorprende, no la apruebes solo porque la llamada parezca inofensiva. Un proceso desconocido puede usar una primera llamada inocua para crear una falsa sensación de confianza. La aprobación por llamada significa que el propietario de la credencial marcó cada uso para una decisión humana. No elimines esa condición porque el agente haga varias solicitudes parecidas. Pregúntate si la tarea está mal planteada. Una operación por lotes puede necesitar un flujo deliberado separado, no una serie de aprobaciones automáticas que haga que el revisor deje de leer. Una credencial ausente o incompatible es otra situación. El agente puede solicitar una operación que sí pertenece a la tarea, pero la bóveda no tiene una credencial para ese destino o la credencial carece del alcance requerido en el servicio externo. Primero confirma que el destino sea el correcto. Después añade o corrige la asignación limitada de la credencial. Nunca entregues el secreto al agente para diagnosticar el problema. El gateway puede autenticar la llamada mientras el agente solo ve el resultado. Un fallo de autorización externo requiere otra respuesta. La llamada pudo salir correctamente a través del gateway, pero el servicio la rechazó con una respuesta como `401`, `403` o un error específico del dominio. Conserva la forma de la solicitud y el resultado devuelto. Corrige el alcance de la cuenta de servicio solo después de confirmar que la operación pertenece a la tarea. Cambiar el rol antes de comprobarlo convierte un problema de configuración en acceso amplio permanente. La diferencia tiene una consecuencia práctica: una denegación del gateway protege el límite que estableciste, mientras que un rechazo externo indica que ese límite ya permitió el intento. No llames «bloqueados» a ambos sucesos en las notas del incidente. Usa etiquetas separadas. En el futuro necesitarás saber si la solicitud se detuvo localmente o si simplemente falló después. ## Reconstruye la intención a partir de la tarea, no de la explicación del agente Un agente puede explicar por qué hizo una solicitud, pero su explicación es una prueba sobre su razonamiento, no una justificación del acceso. El responsable de la tarea decide si la acción corresponde. Esto parece evidente hasta que un agente dice que necesita un comando amplio «para inspeccionar el entorno» y el operador se cansa de bloquearlo. Empieza por el resultado solicitado. Si la tarea consiste en corregir una prueba fallida, una llamada que lee el estado de la compilación puede encajar. Una llamada que rota una credencial de despliegue no encaja salvo que la tarea trate explícitamente de credenciales. Si la tarea es actualizar documentación, una solicitud SSH que instala paquetes en un host compartido necesita una explicación mucho más sólida que «la compilación lo requiere». Después examina el camino más corto hacia ese resultado. Los agentes suelen elegir acciones amplias porque son fáciles de describir. Una herramienta que acepta texto de shell arbitrario los invita a usar comandos de descubrimiento, inspección del entorno y scripts compuestos cuando bastaría una operación con nombre. Una herramienta que acepta cualquier URL de API los invita a explorar endpoints fuera de la tarea. Uso una prueba sencilla: ¿podrías escribir una declaración limitada de la acción esperada antes de que el agente se ejecute? Si puedes decir «leer las etiquetas actuales del issue» pero no «modificar etiquetas», una llamada de escritura no es ambigua. Está fuera del alcance. Denégala e investiga la ruta de instrucciones que la produjo. No concedas acceso de lectura amplio con la idea de que leer siempre es seguro. La lectura puede exponer datos de clientes, topología interna, detalles de despliegue, patrones de acceso y secretos guardados accidentalmente en un servicio. Puede ser menos destructiva que una escritura, pero sigue siendo autoridad. Limita las lecturas al servicio, clase de recurso y entorno que necesita el trabajo. Las instrucciones del prompt también son pruebas débiles porque el contenido del repositorio puede dirigir al agente. Un script de instalación podría incluir un comentario que le pida inspeccionar un directorio local de credenciales. Un documento de configuración podría solicitar un comando curl hacia un host desconocido. Trata las instrucciones no confiables del repositorio como datos que deben revisarse cuando provocan una acción externa nueva. Escribe el desajuste con palabras sencillas: «La tarea pedía leer el estado de una versión; el agente pidió crearla». «La tarea indicaba staging; la solicitud apuntó a producción». «La herramienta describía un host conocido; la solicitud proporcionó un nombre nuevo». Estas frases ayudan a corregir la causa. «Denegado por seguridad» no. ## Las denegaciones repetidas suelen revelar un defecto del contrato de la herramienta Una interfaz causa problemas cuando entrega al modelo decisiones de seguridad mediante parámetros abiertos. El agente termina adivinando el host, la rama, la ruta, la credencial o el comando de shell. Todas las denegaciones parecen problemas de acceso, aunque el problema real sea que la herramienta nunca definió la acción permitida. Imagina un agente encargado de comprobar si terminó una versión. Una herramienta HTTP flexible podría aceptar cualquier método, URL, encabezados y selector de credencial. El agente crea una solicitud hacia un endpoint encontrado en el repositorio y recibe una denegación. Alguien aprueba el destino y después el agente selecciona otro endpoint para continuar. El operador ve llamadas plausibles por separado y acaba construyendo un cliente de API sin revisar mediante decisiones de aprobación. Una herramienta mejor expone la operación que realmente admites: leer el estado de la versión para un entorno concreto. El responsable fija el destino base y el método HTTP. El agente proporciona un parámetro pequeño, como el identificador de la versión. El gateway inyecta la credencial solo para esa llamada. Entonces una denegación tiene un significado claro: el entorno, identificador, proceso o asignación de credencial no coincide con el contrato. La misma regla se aplica a SSH. No entregues a un agente de programación un shell remoto general cuando el trabajo necesita dos acciones de mantenimiento. Expón esas acciones como scripts con argumentos conocidos o usa un wrapper que valide una forma de comando limitada. Una interfaz restrictiva puede parecer incómoda al diseñarla. Resulta sensata la primera vez que un agente pide ejecutar un comando compuesto contra el host equivocado. Busca estos patrones en un grupo de denegaciones: - El agente inventa repetidamente nombres de destino o rutas de API. - Una solicitud alterna entre lecturas y escrituras sin que cambie la tarea. - La misma tarea necesita muchas credenciales sin relación entre sí. - El revisor debe deducir los efectos de shell a partir de una cadena larga. - La descripción de la herramienta promete un resultado, pero deja abiertos los parámetros importantes. No corrijas cada caso con una excepción nueva. Cambia el contrato de la herramienta. Las herramientas limitadas también mejoran la fiabilidad del agente porque eliminan decisiones que los modelos de lenguaje gestionan mal. El agente debe elegir entre operaciones admitidas, no construir su propio límite de seguridad a partir de cadenas. Sallyport conserva los secretos en una bóveda cifrada y ejecuta acciones HTTP o SSH sin entregar las credenciales al agente. Esa separación solo sirve si la interfaz de acción es lo bastante específica para que una persona pueda juzgarla. El aislamiento de credenciales evita la filtración del secreto, pero no convierte en aceptable una solicitud demasiado amplia. ## Sigue una ejecución fallida hasta el final Una investigación debe conservar la secuencia, porque la primera llamada extraña suele explicar todas las posteriores. Revisar solo la última acción bloqueada crea una historia falsa en la que el agente parece haberse vuelto sospechoso de repente. Considera este ejemplo. Un agente recibe la tarea de actualizar las notas de versión de un servicio después de una compilación correcta en staging. Empieza leyendo archivos del repositorio y solicita una llamada HTTP para obtener el estado de la compilación. La llamada encaja y funciona tras la autorización esperada. Después pide acceso SSH a un host de compilación para inspeccionar un artefacto generado. Puede estar justificado, pero es un canal nuevo y debe compararse otra vez con la tarea. El host devuelve un error porque falta el artefacto. El agente lee un script del repositorio que dice que un operador puede reconstruirlo ejecutando un comando remoto. Entonces solicita un comando que borra un directorio de salida, instala dependencias y ejecuta la compilación. La solicitud recibe una denegación por llamada. No apruebes el comando solo porque la primera llamada HTTP era legítima. La tarea original no pedía reconstruir, modificar un host compartido ni instalar dependencias. El flujo pasó de comprobar el estado a modificar remotamente el sistema. La investigación correcta pregunta: 1. ¿Una persona autorizó reconstruir el artefacto o el agente lo dedujo del repositorio? 2. ¿El host de compilación admite cambios autónomos o el agente debe informar de la ausencia? 3. ¿Puede una operación de compilación específica sustituir al comando de shell remoto compuesto? 4. ¿El directorio de salida pertenece a esta tarea o borrar su contenido podría afectar otra ejecución? 5. ¿La tarea necesita otro flujo porque la compilación de staging no terminó correctamente? La reparación puede consistir en detenerse e informar de la ausencia del artefacto, añadir una acción de compilación revisada con un espacio de trabajo aislado o corregir la canalización que debía producirlo. Conceder autoridad SSH general es la peor opción, porque oculta las tres posibilidades bajo un único permiso amplio. Esta secuencia también explica por qué la fatiga de aprobación es un fallo de diseño. Una persona que ve una llamada normal seguida de varias solicitudes técnicas empieza a aprobar por inercia. El control sigue funcionando técnicamente, pero la calidad de la revisión cae. Coloca las decisiones en límites importantes: un proceso nuevo, una credencial de consecuencias altas o un cambio de alcance. No obligues a nadie a interpretar un programa de shell nuevo cada pocos segundos. ## Confía en el registro de auditoría solo después de comprobar su integridad Los registros solo ayudan si puedes saber si alguien los cambió después del hecho. Decir que son de solo adición no basta cuando el equipo que ejecuta el agente está comprometido o un operador tiene motivos para eliminar un registro incómodo. Un registro de auditoría encadenado mediante hashes conecta cada entrada con la anterior. Cambiar un cifrado previo modifica la relación de la cadena que le sigue, lo que permite detectar la manipulación durante la verificación. No hace correcto el suceso original ni impide que un atacante cause daños antes de registrar el evento. Úsalo para lo que ofrece: confianza en que la secuencia conservada no ha cambiado silenciosamente. Ejecuta la verificación antes de una revisión larga y repítela si exportas registros para un incidente. Sallyport puede verificar sin conexión su cadena de auditoría cifrada con este comando: ```text sp audit verify ``` El comando no necesita una clave de la bóveda para realizar la comprobación. Conserva el resultado junto con la nota de investigación, la hora de la verificación y el conjunto de registros revisados. Si falla, deja de tratar la secuencia afectada como una narración completa. Conserva los archivos originales, restringe el acceso al equipo y compara pruebas independientes, como registros del servicio de destino, historial del repositorio y sistema de tareas. No exageres lo que resuelven los registros independientes. Un servicio de destino puede registrar que llegó una solicitud, pero quizá no sepa qué proceso local del agente la inició. El control de versiones puede mostrar un commit, pero no por qué el agente eligió ese cambio. La correlación funciona cuando conservas identificadores y orden temporal entre fuentes, no cuando reúnes capturas de pantalla después. Separa dos preguntas en tus notas. Primero: «¿Esta ejecución del agente solicitó realmente esta acción?». Segundo: «¿Era apropiada la acción solicitada?». La integridad de la auditoría ayuda con la primera. El alcance de la tarea y el criterio humano deciden la segunda. Un registro íntegro puede demostrar que ocurrió una mala solicitud, pero no puede convertirla en una buena. ## Corrige la causa limitada y demuestra la reparación La reparación correcta permite que continúe la tarea prevista y conserva el motivo por el que el control denegó la solicitud original. Toda reparación que simplemente haga desaparecer la ventana emergente merece sospecha. Si falta acceso, añade una referencia de credencial asignada al servicio correcto y confirma que el alcance externo solo admite la operación necesaria. Repite la misma solicitud limitada. No pruebes el arreglo intentando una acción amplia «para asegurarte». La prueba debe demostrar que funciona el caso específico y que las solicitudes no relacionadas siguen fallando. Si el problema es un proceso inesperado, vuelve a iniciar el punto de entrada conocido del agente y compara su identidad con la del proceso denegado. Si cambió por una actualización o un wrapper, documenta el cambio y revisa por qué difieren las identidades. Si nadie puede explicarlo, no lo ocultes con una aprobación permanente. Las herramientas de agentes pueden iniciar procesos hijos, pero no todos merecen la autoridad del proceso padre. Si la herramienta tiene un defecto, cambia la interfaz antes de la siguiente ejecución autónoma. Sustituye los destinos arbitrarios por uno fijo siempre que sea posible. Sustituye el texto de comando arbitrario por una operación con nombre. Retira del control del agente los parámetros sensibles. Después prueba ambos lados del límite: - La solicitud admitida funciona con el proceso y la tarea previstos. - Un destino, comando u operación de escritura diferente se deniega. - El registro identifica lo ocurrido con suficiente claridad para un revisor. - El registro de sesión permite revocar la ejecución si cambia su comportamiento. Si la solicitud es sospechosa, no continúes mientras discutes el alcance. Revoca su autoridad, conserva los registros de sesión y llamadas e inspecciona las fuentes de instrucciones que precedieron a la solicitud. Una tarea normal puede volverse insegura después de leer contenido no confiable. Que el proceso empezara como una ejecución aprobada no le concede carta blanca para acciones posteriores. Sallyport proyecta los diarios de ejecución y llamadas desde un único registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura, y permite revocar de inmediato una ejecución desde el diario Sessions. Usa esa revocación cuando la secuencia deje de tener sentido. Es una medida de contención, no un juicio sobre la persona que inició la ejecución. Termina la investigación con una frase que pueda orientar al siguiente operador: «Al agente le faltaba la credencial de lectura del estado de staging, que añadimos para la operación aprobada» o «El agente intentó una reconstrucción remota no aprobada después de seguir texto del repositorio, así que detuvimos la ejecución y expondremos una acción de compilación revisada». Si no puedes escribir esa frase, todavía no has encontrado la causa. ## Haz que entender las denegaciones sea más fácil que eludirlas Las personas eluden los controles cuando investigar cuesta más de lo que parece valer la tarea. La respuesta no son controles más débiles, sino registros e interfaces que hagan evidente el camino legítimo y visible el inusual. Mantén delimitadas las instrucciones de la tarea. Indica el entorno, la acción externa prevista y la condición de parada. «Investiga el despliegue fallido en staging e informa de la causa» deja espacio para un informe. «Haz que producción coincida con staging» invita discretamente a realizar escrituras, usar credenciales y cambiar sistemas sin una revisión previa. Da a los revisores contexto suficiente para tomar bien una decisión. La aprobación de sesión debe mostrar quién inició el proceso y a qué ejecución pertenece. La aprobación de una acción sensible debe mostrar la operación y el destino en términos comprensibles. Si el revisor debe descifrar un nombre de credencial, seguir una URL opaca y ejecutar mentalmente una canalización de shell, has convertido el trabajo de seguridad en un clic apresurado. Mide las denegaciones recurrentes por causa, no por volumen. Diez solicitudes bloqueadas porque el agente eligió un endpoint no admitido indican un problema de herramienta. Diez porque aparece un proceso nuevo en cada ejecución indican un problema de identidad o invocación. Diez porque la tarea se amplía continuamente indican un problema de planificación. El número por sí solo dice poco. No intentes que los agentes autónomos parezcan scripts normales. Los scripts suelen recibir autoridad porque una persona revisó su comportamiento exacto. Un agente elige su comportamiento durante la ejecución y puede incorporar contenido nuevo del repositorio, resultados de herramientas y errores. Por eso un gateway de acciones necesita una vía de decisión humana y un registro que sobreviva al momento. La siguiente llamada denegada debería producir una tarea mejor o una herramienta mejor, no una excepción más amplia. Si tu equipo adopta esa regla, las denegaciones disminuirán por el motivo correcto: el agente recibirá una autoridad clara y limitada, y los bloqueos restantes señalarán comportamientos que merece la pena detener.