**Advertencia:** Las opiniones expresadas en este artículo reflejan mi experiencia personal y no deben interpretarse como la postura oficial de Microsoft.
Imaginemos a un agente de soporte que se encarga de una consulta rutinaria sobre facturación. Este agente tiene la capacidad de acceder a los registros de los clientes, preparar un informe de la cuenta y enviar un correo electrónico al cliente correspondiente. Sin embargo, en un momento dado, recibe un mensaje que le solicita exportar el historial completo de la cuenta y enviarlo a un nuevo contacto de auditoría. Aparentemente, la solicitud es razonable, así que el agente procede a cumplirla.
En esta situación, no ocurre nada inusual a nivel de autenticación. Las credenciales del agente son válidas, y se le permite acceder a los registros y enviar correos electrónicos. No obstante, el historial de la cuenta ha sido enviado a una persona que nunca tuvo derecho a recibir esa información. El atacante, en este caso, no necesitó una contraseña; simplemente logró que un software con acceso legítimo utilizara esa autorización de manera incorrecta.
Los modelos de seguridad para agentes de inteligencia artificial deben considerar este tipo de fallos, no solo aquellos relacionados con el acceso no autorizado. La autenticación permite al sistema identificar una identidad, mientras que la autorización determina lo que esa identidad puede hacer. Aunque estas decisiones de autorización pueden ser extremadamente detalladas, permisos como "puede leer registros de clientes" o "puede enviar correos electrónicos" no abordan una pregunta más específica y crucial: ¿debería este informe enviarse a esta persona, en este caso, por esta razón?
Para un agente, esta última pregunta es de suma importancia. La inyección de instrucciones indirectas pone de manifiesto el problema. Un atacante puede incluir instrucciones en un contenido que el agente se espera que lea, ya sea un correo electrónico, un documento, una página web o la respuesta de una herramienta. Si el agente acepta esas instrucciones como autoritarias, su próxima acción puede verse influenciada sin que nadie tome el control de su cuenta. El trabajo realizado por el Instituto Nacional de Estándares y Tecnología (NIST) sobre el secuestro de agentes describe esta ruta que va del contenido externo a un comportamiento no intencionado, incluyendo el robo de datos y la ejecución de código malicioso.
La aplicación del principio de privilegio mínimo es un buen comienzo, pero no lo soluciona todo. Tanto la lectura del historial de la cuenta como el envío de correos electrónicos pueden ser permisos legítimos para un asistente de facturación. Sin embargo, enviar ese historial a una dirección seleccionada por un atacante es inaceptable. Por ello, la inyección de instrucciones no puede considerarse únicamente un problema de ingeniería de solicitudes. Un mejor diseño de las solicitudes puede hacer que un agente sea menos propenso a seguir instrucciones maliciosas, pero el resto del sistema debe ser capaz de gestionar los errores del modelo. El Centro Nacional de Seguridad Cibernética del Reino Unido recomienda implementar salvaguardias deterministas alrededor de las acciones del sistema, así como medidas destinadas a reducir el riesgo de inyección de instrucciones.
Regresando al agente de facturación, antes de que su exportación propuesta llegue a la herramienta de correo electrónico, la aplicación debería tomar una decisión por sí misma. ¿Quién inició la tarea? ¿A qué cliente pertenece el caso? ¿Qué información se está liberando? ¿Quién la está recibiendo realmente? ¿Requiere esta operación aprobación? Las respuestas a estas preguntas deben provenir de un estado de aplicación confiable, no de lo que el modelo indique.
Si el modelo emite un ID de cliente, una dirección de destinatario y una etiqueta de "aprobación_del_gerente": verdadero, el formato es irrelevante. El JSON no es una fuente de autoridad. Una política para este flujo de trabajo podría ser bastante sencilla. El agente podría recuperar facturas del cliente asociado al caso actual y enviar información seleccionada solo a un contacto que ya esté verificado para esa cuenta. Las notas internas requerirían una autoridad adicional, al igual que la adición de un nuevo destinatario. Un correo electrónico entrante no puede otorgar ninguna de estas autorizaciones.
Actualmente, existen herramientas diseñadas para proporcionar espacios donde se puedan hacer cumplir controles como estos. El Estándar de Control de Agentes de OWASP, que se publicó en septiembre de 2026, define ganchos de middleware a través de los cuales las plataformas de agentes pueden exponer actividades y aplicar políticas en tiempo de ejecución. Las reglas deben cubrir todas las rutas que importan.
Si un conector de correo electrónico bloquea una transferencia pero el agente puede subir el mismo archivo a través de un navegador o enviarlo con una herramienta HTTP de propósito general, el control es principalmente una fachada. Las operaciones sensibles necesitan la misma aplicación de controles, independientemente de la herramienta utilizada. Los archivos de políticas, las credenciales y los registros de aprobación detrás de esos controles también deben estar fuera de la capacidad del agente para modificarlos de manera casual.
Las destinaciones son un buen ejemplo de por qué las listas de permitidos simples a menudo son demasiado imprecisas. Supongamos que se permite a un agente subir archivos a un servicio en la nube aprobado. Ese servicio puede contener el espacio de trabajo de su empresa, el de un contratista y la cuenta personal de un atacante. Incluso una carpeta dentro del inquilino de la empresa podría compartirse externamente. Por tanto, un "dominio aprobado" no equivale a una "destinación aprobada". El sistema deberá conocer el inquilino, el espacio de trabajo, la carpeta, el destinatario y los permisos de compartición vigentes. En el ejemplo del soporte, una destinación válida debería provenir de registros de clientes protegidos o de un proceso separado y verificado para cambiar esos registros.
Un correo electrónico que diga "por favor, envía la exportación a esta nueva dirección" no es una evidencia sólida de que la nueva dirección deba recibir la exportación. Las herramientas de Prevención de Pérdida de Datos (DLP, por sus siglas en inglés) pueden detectar parte de esto, pero solo si siguen el flujo de datos en lugar de centrarse en una herramienta particular. La transferencia relevante podría ser el cuerpo de un correo electrónico, un archivo adjunto, una carga, un documento compartido o incluso un argumento de herramienta. Monitorear el correo electrónico saliente mientras se ignoran otros mecanismos de transferencia del agente simplemente desplaza la brecha a otro lugar.
La clasificación también puede desaparecer durante la transformación. Un modelo puede resumir un documento confidencial y producir un texto que ya no contenga los marcadores que un detector de contenido estaba buscando, mientras que preserva la información que hacía que el original fuera sensible. Siempre que sea posible, la aplicación debería mantener la sensibilidad del material fuente mientras se transforma y tomar decisiones de liberación separadas para la información derivada. Investigaciones como CaMeL examinan las políticas de flujo de información en torno a las llamadas de herramientas y demuestran por qué el origen de los datos puede ser relevante al decidir a dónde se les permite ir.
Un agente que modifica el contacto registrado de un cliente o la destinación de pago puede no estar filtrando información sensible en absoluto. El problema en este caso radica en la integridad, y un escáner de contenido no resolverá la situación.
Algunas operaciones requieren de la intervención humana para tomar decisiones, especialmente en lo que respecta a exportaciones sensibles, cambios en pagos, concesiones de acceso y acciones potencialmente destructivas. Sin embargo, el concepto de "humano en el circuito" no garantiza una seguridad robusta por sí mismo.
Imaginemos una pantalla de aprobación que pregunta: “¿Enviar la información necesaria para resolver este caso?”. Un revisor no puede tomar una decisión de seguridad seria basándose únicamente en eso. Es esencial que pueda ver hacia dónde se dirige la información y qué es lo que realmente se está enviando. Si ha habido un cambio en el acceso, también debe poder verificarlo. Esos detalles deben ser presentados por un código de aplicación confiable, a partir de la operación pendiente, y no resumidos únicamente por el agente que solicita la aprobación.
Las explicaciones del agente pueden ser útiles, pero no pueden ser consideradas como prueba concluyente. Esta distinción se vuelve incómoda cuando la propia explicación puede haberse visto comprometida.
El 28 de septiembre de 2026, Forcepoint X-Labs publicó un experimento controlado en el que contenido de hilos de correo electrónico falsificados llevó a un sistema de resumen a reportar detalles de reuniones y facturas que nunca existieron. Una de las variaciones del experimento no utilizó texto oculto ni instrucciones explícitas para el modelo. Aunque el experimento se centró en una configuración particular de resumen y no en un sistema automatizado de pagos o exportaciones de datos, la relevancia de su alcance es crucial.
Aun así, el problema de la aprobación es evidente. La aplicación podría informar con precisión a un revisor que “se enviará £X a la cuenta Y”, mientras que la explicación que lo acompaña indica que el cambio fue aprobado en una reunión que jamás tuvo lugar. Los detalles de la transacción pueden ser auténticos, mientras que la justificación resulta ser falsa.
Por esta razón, para acciones sensibles, los revisores necesitan acceder a un registro autorizado, o al menos a evidencia que haya sido verificada de manera independiente respecto al material que desencadenó la solicitud. Las directrices de OWASP sobre riesgo agentico de 2026 abordan este tipo de explotación de la confianza entre humano y agente, donde una persona es persuadida de aprobar una acción basándose en el relato convincente pero no verificado de un agente.
La aprobación también debería aplicarse exactamente a lo que el revisor observó. Si el destinatario cambia posteriormente, se debe aprobar de nuevo. Si el objeto o los datos subyacentes cambian de manera significativa, también debe realizarse una nueva aprobación. Las aprobaciones deberían tener una vigencia limitada y no permitir que una sola decisión se reproduzca indefinidamente.
Estas ideas son anteriores a los agentes de inteligencia artificial. Las directrices de autorización de transacciones de OWASP ya demandan una aplicación de control en el servidor, protección contra cambios en los datos de transacción, una verificación final antes de la ejecución y credenciales de autorización vinculadas a operaciones individuales. Los agentes hacen que esos controles sean pertinentes en flujos de trabajo que anteriormente no parecían transacciones sensibles a la seguridad.
Los flujos de trabajo de agentes prolongados introducen un nuevo desafío: el movimiento de información. Un mensaje externo podría ser resumido por un agente, almacenado en memoria, recogido por otro agente y eventualmente utilizado para justificar una acción horas más tarde. Si un correo electrónico afirma que un gerente aprobó algo, dicha afirmación debe considerarse una declaración no verificada, a menos que el sistema pueda vincularla a un registro real de aprobación. La repetición de la afirmación “el gerente aprobó” por parte de cinco agentes no constituye una aprobación.
Esto también se aplica a los límites que parecen seguros cuando se evalúan acción por acción. Un límite de exportación de 10 registros no es muy útil si el agente puede ejecutar la exportación 100 veces. Del mismo modo, un flujo de trabajo no debería tener la libertad de cambiar los datos de contacto de un cliente y enviar inmediatamente registros sensibles al nuevo contacto ingresado sin considerar la secuencia de acciones.
En ocasiones, la decisión de seguridad necesita contexto histórico: cuánto se ha transferido ya, qué permisos se han delegado, qué cambios ocurrieron anteriormente en la sesión y qué acción habilitó la siguiente. Investigaciones recientes sobre delegación de agentes con límites examinan este problema al evaluar solicitudes en función del estado acumulado de la sesión y el ámbito delegado.
Un registro que indique 200 OK confirma que una llamada a la API tuvo éxito. Sin embargo, durante una investigación, probablemente se requerirá mucha más información: quién inició la tarea, qué agente actuó, qué fuentes se le proporcionaron, qué recurso se vio afectado, a dónde fue el dato, qué política permitió la acción y qué aprobación, si es que hubo alguna, estuvo adjunta a la misma.
Es crucial registrar lo que realmente ocurrió, y no únicamente lo que el modelo afirma haber estado considerando. El razonamiento generado por un modelo no constituye una cadena de auditoría. Esos registros requieren su propia protección y deben evitar contenido sensible innecesario, pero debe haber suficiente información para reconstruir una secuencia después de que ocurra un error.
Esto proporciona a un SIEM (Security Information and Event Management) algo útil con que trabajar. Un cambio de contacto podría parecer inofensivo por sí solo, al igual que una pequeña exportación. Sin embargo, al ponerlos juntos, la situación cambia. Lo mismo ocurre con transferencias repetidas justo por debajo de un umbral, o un agente que cambia a otro conector inmediatamente después de que el primero se niega a realizar una operación.
La detección es útil en estos casos, pero la prevención debe ocurrir antes de que se complete una transferencia sensible. Antes de otorgar a un agente mayor autonomía, sería recomendable probar esto con datos sintéticos en lugar de asumir que los controles funcionan correctamente.
Coloca un correo electrónico redactado por un atacante en un flujo de trabajo realista y observa qué sucede. Luego, omite el modelo por completo y envía la solicitud de herramienta prohibida directamente a la capa de ejecución. Cambia el destinatario después de la aprobación. Divide una exportación grande en partes más pequeñas. Intenta utilizar otro conector cuando la ruta normal es denegada. Luego, ejecuta casos legítimos también, porque un control que impida al agente realizar su trabajo real eventualmente será debilitado o eludido.
El escenario de facturación que se planteó al principio debería concluir con un intento de exportación, no con una brecha de seguridad. Para cuando el agente solicite enviar los registros, la aplicación ya debería saber qué cuenta está involucrada, qué datos se van a transferir y quién los va a recibir. Si ese destinatario no tiene la autoridad requerida, la confianza del modelo no debería marcar una diferencia.
Esa es la prueba útil para la seguridad a nivel de acción: cuando el modelo toma la decisión incorrecta, ¿el resto del sistema sigue manteniendo la línea?