Ledgerline canaliza la solicitud de soporte de un empleado a través de una API de asistente, un proveedor de modelos y una herramienta de reembolso. Un ticket de Jira contenía texto que solicitaba un reembolso para un cliente; el asistente interpretó dicho texto como una instrucción y, posteriormente, el ejecutor de la herramienta utilizó una cuenta compartida del servicio de pagos para procesar la operación. Quien realizó la solicitud carecía de permisos para gestionar reembolsos, pero el backend nunca verificó la identidad del solicitante en el momento de ejecutar la acción. No fue necesario utilizar malware ni credenciales robadas. El texto no confiable del ticket ingresó en el flujo del agente y llegó a una operación privilegiada que la aplicación ya tenía habilitada.
Este fallo combina la inyección de prompts (donde texto no confiable altera el comportamiento de la aplicación dirigido por el modelo) con la autonomía excesiva (donde la aplicación otorga a dicho comportamiento una autoridad que trasciende los derechos del empleado que originó la solicitud). OWASP denomina a estos problemas LLM01 (Inyección de prompts) y LLM06 (Autonomía excesiva) en su guía de 2025, publicada por el proyecto OWASP GenAI Security en noviembre de 2024. El contenido del prompt no puede autorizar un reembolso, ya que el modelo solo genera texto; es el servidor quien decide si se ejecuta la acción de pago.
El reembolso se procesó porque Ledgerline permitió que una solicitud atravesara varios límites de confianza sin preservar la información sobre quién la había originado. Un mensaje de un empleado se considera no confiable. Un documento de soporte recuperado tampoco es confiable, incluso si fue almacenado por Ledgerline. El resultado de una herramienta constituye una entrada no confiable para la siguiente llamada al modelo. La salida del modelo tampoco es confiable, ya que una acción de reembolso propuesta no demuestra que el empleado tenga autorización para realizarla.
La API del asistente autentica al empleado antes de componer el prompt. La autorización de recuperación restringe los documentos al tenant y a los derechos de acceso del empleado antes de que el texto del documento se incorpore al prompt. El ejecutor de la herramienta recibe la identidad autenticada y los parámetros solicitados, y aplica la política de acción correspondiente antes de contactar con el sistema de pagos. El registro de auditoría almacena la identidad del solicitante, la acción requerida, la decisión tomada y el resultado. El proveedor del modelo genera una acción candidata, pero nunca otorga el permiso para ejecutarla. La ruta de la solicitud hace visible cada límite:
El flujo separa el procesamiento de texto de la autoridad. La autenticación puede rechazar a un solicitante desconocido, la recuperación de datos puede retener el registro de un cliente no autorizado y el filtro de herramientas puede denegar un reembolso incluso cuando el modelo lo recomienda encarecidamente. Un registro de auditoría no puede impedir la acción, pero permite a Ledgerline determinar qué entidad (principal), decisión de política y parámetros produjeron el resultado.
Dado que cada límite (o etapa de control) rechaza fallos distintos, Ledgerline devuelve un contrato de estado estable en lugar de tratar cualquier denegación como un error del modelo. 401 Unauthorized indica que la solicitud presenta una credencial ausente, inválida, revocada o comprometida. 403 Forbidden significa que un empleado autenticado carece del alcance necesario; por ejemplo, al solicitar un reembolso sin tener autorización para ello o al intentar recuperar datos fuera de sus permisos asignados.
Otras etapas utilizan resultados más específicos:
409 Conflict: la primera solicitud que utiliza una clave de idempotencia sigue en ejecución.422 Unprocessable Content: la salida del modelo no cumple con el esquema de acción requerido por Ledgerline, o se ha reutilizado una clave de idempotencia con parámetros diferentes.429 Too Many Requests (con Retry-After): un inquilino (tenant) ha agotado un límite de tasa o de gasto.503 Service Unavailable: Ledgerline no puede aplicar un contador obligatorio o un interruptor de circuito abierto bloquea una llamada al proveedor.504 Gateway Timeout: el proveedor del modelo ha excedido el plazo límite establecido por Ledgerline.Un código de estado identifica el límite que tomó la decisión. Si se deniega la búsqueda de un cliente antes de ensamblar el prompt, Ledgerline devuelve 403 Forbidden; ningún documento recuperado llega al proveedor. Si un reembolso propuesto contiene parámetros mal formados, el servidor devuelve 422 Unprocessable Content antes de que el ejecutor de herramientas contacte con el sistema de pagos. Estos resultados convierten el rechazo en un comportamiento observable del backend, en lugar de una simple frase dentro de un prompt del sistema.
Regla de autoridad Una identidad de servicio compartido puede transportar una solicitud, pero no debe reemplazar a la entidad (principal) del empleado utilizada para autorizar la acción.
El incidente inicial es un caso de “delegado confundido” (confused deputy). El ejecutor de reembolsos de Ledgerline disponía de amplios privilegios de servicio y los utilizó en nombre de un empleado que carecía del permiso correspondiente. Si bien la API de pagos puede validar las credenciales de servicio de Ledgerline, no tiene forma de recuperar la autorización faltante del empleado a menos que Ledgerline transmita y verifique la identidad de dicho usuario. Trasladar el control a una etapa anterior, como la composición del prompt, deja abierta la posibilidad de que el texto posterior, los resultados de la herramienta o la salida del modelo alteren la acción propuesta.
El punto de control fiable es el gestor de herramientas en el servidor; allí, Ledgerline dispone de los dos datos necesarios para tomar una decisión: la identidad autenticada del empleado y los parámetros concretos del reembolso. Las reglas del prompt pueden orientar el comportamiento del modelo y el proveedor puede devolver una propuesta de llamada a la herramienta, pero ninguno de estos mecanismos aplica la política de autorización de Ledgerline. ¿Qué etapa debería detener en primera instancia el reembolso asociado al ticket de Jira: las reglas del prompt, el modelo, el gestor de herramientas o la API de pagos?