Los frameworks de agentes de IA convierten la inyección de prompts en un fallo de seguridad

Google News planteó esta semana un argumento de seguridad contundente: la inyección de prompts no es el fallo de raíz, pese a años de defensas construidas en torno a ella. El problema más profundo reside en los frameworks de agentes de IA que convierten resultados inciertos del modelo en acciones privilegiadas.

Esa distinción cambia lo que los equipos de ingeniería deben proteger. Un chatbot manipulado puede producir absurdos. Un agente manipulado puede leer archivos privados, llamar a APIs, modificar código, enviar mensajes o contaminar memoria compartida.

El enfoque de The Register cuestiona una suposición habitual. Los desarrolladores suelen tratar el texto malicioso como la vulnerabilidad y prompts más robustos como la solución. La pregunta de mayor calado es qué permite el sistema circundante después de que el modelo acepte ese texto.

Esto no implica que la inyección de prompts sea inocua. Sigue siendo una forma fiable de influir en los modelos mediante solicitudes directas o contenido externo no confiable. Sin embargo, la inyección solo se convierte en una brecha operativa cuando la arquitectura proporciona autoridad, datos y una vía ejecutable.

Por tanto, la contienda emergente es clara. Un bando depende de que los modelos reconozcan instrucciones peligrosas dentro de lenguaje ambiguo. El otro asume que ese reconocimiento acabará fallando y restringe lo que cualquier modelo comprometido puede lograr.

Google News sitúa el framework de agentes en el centro

El cambio importante es trasladar la responsabilidad del comportamiento del modelo a la arquitectura del sistema.

La inyección de prompts se ha descrito normalmente como un problema de seguridad del modelo. Un atacante inserta instrucciones en un prompt, documento, sitio web, correo electrónico, imagen o respuesta de una herramienta. El modelo sigue entonces esas instrucciones en lugar de la petición real del usuario.

Esa descripción es correcta, pero incompleta. Identifica el método usado para influir en el modelo sin identificar el fallo de control que produce daños reales. El texto no confiable no puede, por sí solo, eliminar un archivo, recuperar el registro de un cliente o publicar código fuente.

Un framework de agentes aporta esas capacidades. Conecta un modelo con herramientas, credenciales, memoria, bases de datos, navegadores, intérpretes de código y otros agentes. También puede decidir si el modelo puede actuar sin una nueva autorización humana.

La arquitectura puede convertir una interpretación errónea en una secuencia de efectos secundarios. Una página web envenenada se convierte en una solicitud de herramienta. La solicitud de herramienta se convierte en una consulta a la base de datos. El material recuperado aparece después en un mensaje saliente generado por el mismo agente.

La inyección indirecta de prompts es especialmente importante aquí. El atacante no necesita acceder a la interfaz de chat. Las instrucciones maliciosas pueden permanecer en contenido que el agente encuentra durante una tarea ordinaria.

Un agente de investigación podría encontrar las instrucciones en una página web. Un asistente de programación podría hallarlas en la descripción de una incidencia o en un archivo del repositorio. Un agente de oficina podría incorporarlas desde un correo electrónico, una invitación de calendario o un documento compartido.

En todos los casos, el modelo se enfrenta a un difícil problema de clasificación. Debe distinguir entre texto que describe una instrucción y texto que debe obedecerse. Ambos llegan como tokens de lenguaje natural dentro del contexto de trabajo del modelo.

La definición de riesgo de OWASP reconoce tanto la inyección directa como la indirecta. También señala que el impacto depende en gran medida del contexto empresarial y de la capacidad de actuación concedida al modelo.

Esa última condición importa más de lo que parece a primera vista. La misma frase maliciosa puede producir resultados radicalmente distintos en dos implementaciones. Un resumidor de solo lectura podría generar un párrafo corrompido, mientras que un agente privilegiado podría exponer información confidencial.

Google News es útil como canal de descubrimiento para este debate, pero no es la autoridad subyacente. El titular apunta a un conjunto más amplio de trabajos de seguridad que cada vez trata más el secuestro de agentes como una amenaza arquitectónica.

NIST describe el secuestro de agentes como una inyección indirecta de prompts que provoca que un agente ejecute acciones dañinas no previstas. Sus evaluaciones de secuestro utilizan espacios de trabajo simulados, servicios de viajes, sistemas de mensajería y herramientas bancarias.

Estos entornos revelan por qué la seguridad de los agentes difiere de la seguridad de los chatbots. El modelo no se limita a responder una pregunta. Está seleccionando acciones dentro de un flujo de trabajo que implica permisos y consecuencias reales.

Este replanteamiento también afina la notificación de vulnerabilidades. «Inyección de prompts» describe cómo entró la influencia en el sistema. Un hallazgo de seguridad útil también debería identificar el impacto resultante, como acceso no autorizado a datos o ejecución de código no aprobada.

Los equipos de seguridad tradicionales ya hacen distinciones similares. La entrada controlada por el usuario no constituye automáticamente una brecha. La vulnerabilidad surge cuando el software transmite esa entrada a un intérprete inseguro o confía en ella al cruzar un límite de seguridad.

Los modelos de lenguaje complican la analogía porque las instrucciones y los datos comparten una representación flexible. No existe un equivalente universal de una consulta de base de datos parametrizada para todas las tareas de lenguaje natural. Esto hace que la contención alrededor del modelo sea todavía más importante.

Por tanto, el acontecimiento clave es conceptual, pero operativamente significativo. El trabajo de seguridad se aleja de las promesas de un filtrado perfecto de instrucciones. Se orienta hacia límites que siguen siendo eficaces después de que el modelo tome una decisión equivocada.

La inyección de prompts es el detonante, no el radio de impacto

Una instrucción inyectada genera influencia, mientras que el framework determina si esa influencia se convierte en un incidente.

Pensemos en un agente encargado de revisar tickets de soporte entrantes. Necesita acceso al texto de los tickets, a los datos de los clientes y quizá a una base de conocimiento interna. También podría disponer de herramientas para emitir reembolsos o enviar mensajes a cuentas.

Un atacante inserta una instrucción oculta en un ticket. La instrucción indica al agente que recupere el registro de otro cliente y lo incluya en una respuesta. El modelo sigue esa indicación creyendo que está completando el flujo de trabajo asignado.

Deben producirse varios fallos antes de que los datos salgan de la empresa. El agente debe recibir un acceso más amplio del que requiere el ticket actual. Su capa de herramientas debe aceptar parámetros generados por el modelo. La acción saliente debe continuar sin autorización independiente.

El texto malicioso inició la cadena. No creó los permisos excesivos, los límites de datos inexistentes ni la falta de una puerta de aprobación. Esas decisiones procedían de la aplicación y del framework.

Esta distinción es fundamental para la seguridad de los agentes de IA. Un sistema debe asumir que el criterio del modelo es falible, especialmente cuando procesa contenido controlado por atacantes. Los controles de seguridad deben mantenerse fuera de ese ciclo de juicio.

Los esquemas de herramientas por sí solos no resuelven el problema. Un esquema puede exigir una dirección de correo electrónico o un identificador de documento válidos. No puede determinar si el modelo tiene un motivo legítimo para contactar con esa dirección o recuperar ese documento.

Una acción maliciosa bien formada sigue siendo maliciosa. El framework necesita aplicación de políticas vinculada a la identidad del usuario, la propiedad de los datos, el alcance de la tarea, la procedencia y el estado actual de autorización.

La procedencia implica registrar de dónde procede la información y conservar esa etiqueta durante todo el flujo de trabajo. El contenido de una página web desconocida no debería adquirir estatus de confianza porque un agente lo haya resumido.

Esa regla se vuelve más difícil en sistemas multiagente. Un modelo podría investigar un tema, otro planificar una respuesta y un tercero ejecutar herramientas. Las instrucciones maliciosas pueden transformarse a medida que los resultados pasan entre ellos.

El agente receptor puede ver una prosa pulida sin ver la fuente no confiable que la influyó. Si el framework descarta la procedencia, blanquear la instrucción a través de otro agente puede aumentar efectivamente su autoridad.

La memoria persistente crea otra vía. Un atacante puede persuadir a un agente para que almacene una regla dañina, un hecho falso o una preferencia alterada. Sesiones posteriores pueden recuperar esa entrada después de que el contenido malicioso original haya desaparecido.

Los equipos que crean una base de conocimiento personal se enfrentan a una cuestión de confianza relacionada. La información recuperada debe conservar su fuente y su contexto de acceso, especialmente cuando un agente puede actuar sobre ella.

La memoria no debería convertirse en un plano de control invisible. Las operaciones de escritura necesitan restricciones, registros de auditoría y una separación clara entre las preferencias aprobadas por el usuario y las observaciones generadas por el modelo.

La navegación añade su propio riesgo. Una página puede contener instrucciones visibles, texto oculto, metadatos, contenido de imagen o material adversarial diseñado para un modelo en lugar de una persona. El agente procesa ese contenido porque navegar es su función prevista.

Google informó de que supervisaba la web pública en busca de patrones conocidos de inyección indirecta. Su investigación sobre amenazas web trató esos patrones como una prioridad porque los agentes de navegación consumen habitualmente páginas controladas por atacantes.

Esto crea una disyuntiva estructural. Cuanto más amplio sea el acceso de un agente a la información, más contenido no confiable encontrará. Cuanta más autoridad reciba, mayor será el impacto potencial de una sola interpretación errónea.

Eliminar todo el contenido externo haría inútiles a muchos agentes. Dar a todo el contenido externo la misma influencia los vuelve inseguros. Los frameworks deben conservar la utilidad mientras imponen límites que el lenguaje por sí solo no puede garantizar.

Eso implica separar la planificación de la autorización. Un modelo puede proponer una acción, explicar su motivo y preparar parámetros. Un servicio de políticas determinista debe decidir si la acción está permitida.

La decisión debe tener en cuenta el usuario actual, la tarea solicitada, el recurso objetivo, la sensibilidad de los datos y la procedencia del contenido. Las acciones de alto impacto deben requerir una confirmación que muestre claramente lo que ocurrirá.

La confirmación no debe ser redactada por completo por el modelo potencialmente comprometido. De lo contrario, un atacante puede influir tanto en la acción propuesta como en la descripción mostrada al usuario.

Una interfaz fiable debería construir los detalles críticos a partir de parámetros de herramientas validados. Debería identificar el destino, los registros afectados, los permisos solicitados y cualquier dato programado para salir del sistema.

Así es como el radio de impacto se vuelve medible. Incluso si la inyección de prompts tiene éxito en la capa de lenguaje, el atacante encuentra controles independientes en cada límite importante.

El resultado se parece más a una seguridad de aplicaciones madura que a una ingeniería ingeniosa de prompts. El principio de mínimo privilegio, el aislamiento, la autorización explícita, la validación de salidas, el registro y la respuesta a incidentes siguen siendo esenciales.

Por qué unos prompts de sistema más robustos no pueden sostener el límite de seguridad

El refuerzo de prompts reduce los ataques exitosos, pero los fallos residuales hacen que no sea adecuado como capa final de autorización.

Los prompts de sistema pueden indicar a un agente que ignore instrucciones encontradas dentro de contenido externo. Pueden etiquetar el material de origen como no confiable y recordar al modelo que siga únicamente el objetivo del usuario.

Estas medidas merece la pena utilizarlas. Pueden bloquear ataques simples, reducir desviaciones accidentales y obligar a los adversarios a invertir más esfuerzo. También ayudan a los modelos a explicar contenido sospechoso en lugar de actuar inmediatamente sobre él.

Los investigadores de Google probaron prompts de seguridad en un framework de programación multiagente. Su estudio multiagente abarcó más de 150 escenarios de ataque de un solo turno y 32 de varios turnos.

Un reforzador de seguridad de aproximadamente 500 tokens redujo las tasas de fallo en un solo turno del 19,48 % al 2,60 %. Las tasas de fallo en varios turnos cayeron del 75 % al 46,88 %.

Estos resultados respaldan el refuerzo de prompts, pero también dejan al descubierto su límite. Una tasa de fallo del 46,88 % en varios turnos sigue siendo inaceptable cuando el agente puede ejecutar código, acceder a credenciales o modificar recursos de producción.

Incluso la menor tasa en un solo turno crea un riesgo significativo a escala. Las interacciones repetidas brindan a los adversarios oportunidades adicionales, y los atacantes pueden ajustar su lenguaje tras observar el comportamiento del modelo.

El estudio también descubrió que los ataques exitosos se orientaron hacia envoltorios funcionales. Estos ataques ocultan intenciones dañinas dentro de tareas que se asemejan a funciones ordinarias del agente. Las instrucciones estáticas tienen dificultades para rechazarlos sin bloquear también el trabajo legítimo.

Este es el problema central de situar el perímetro de seguridad dentro del modelo. El modelo debe interpretar una solicitud abierta mientras predice si dicha solicitud viola otra instrucción igualmente abierta.

No evalúa una regla de permisos estable de la manera en que un sistema operativo comprueba el acceso a archivos. Produce una respuesta probabilística influida por cada token relevante de su contexto.

Explicar la inyección de prompts únicamente como «ignorar instrucciones anteriores» pasa por alto esta ambigüedad. Los ataques eficaces no siempre anuncian un conflicto. Pueden presentar contexto falso, imitar el lenguaje de flujos de trabajo confiables o dividir la intención entre varios pasos.

Un agente que revisa código podría encontrarse con texto que parece describir una prueba requerida. La prueba descarga o ejecuta discretamente un componente externo. Cada paso individual puede parecer plausible dentro de un flujo de desarrollo.

A un agente de navegación se le puede indicar que una acción específica es necesaria para acceder a la página solicitada. Un asistente de oficina podría leer un documento que afirma que la política de la empresa exige reenviar contenido para una revisión de cumplimiento.

El modelo carece de conocimiento independiente de las políticas reales de cada organización. Si el framework permite que afirmaciones generadas por el modelo autoricen acciones generadas por el modelo, el sistema se vuelve circular.

Los filtros enfrentan una limitación similar. Un detector puede buscar frases conocidas o estimar si un texto parece adversarial. Los atacantes pueden parafrasear instrucciones, dividir cargas útiles, ocultarlas en distintos formatos o hacer que parezcan datos normales.

Bloquear todas las frases imperativas destruiría flujos de trabajo habituales. Los documentos, correos electrónicos, comentarios de código y tickets de soporte contienen legítimamente instrucciones. El agente a menudo necesita comprender esas instrucciones sin adoptarlas como sus propios objetivos.

El ajuste fino puede mejorar la resistencia, pero no elimina el conflicto arquitectónico. Los modelos aún deben interpretar lenguaje no confiable, y los nuevos patrones de ataque pueden quedar fuera de su distribución de entrenamiento.

La generación aumentada por recuperación tampoco elimina el conflicto. RAG recupera material externo y lo añade al contexto del modelo. Si la fuente está contaminada, la recuperación puede entregar la instrucción del atacante justo cuando parece relevante.

Las actualizaciones de modelos incluso pueden cambiar el riesgo de forma inesperada. Un modelo más capaz podría detectar mejor los ataques, pero también podría usar herramientas con mayor eficacia después de que un ataque tenga éxito.

Por eso las puntuaciones de los benchmarks necesitan contexto. Que un modelo rechace la mayoría de las inyecciones en un conjunto fijo de pruebas no demuestra que un agente desplegado sea seguro. Los sistemas reales contienen herramientas personalizadas, permisos, memoria e integraciones.

El objetivo defensivo debería ser el fallo controlado. Cuando el modelo clasifica mal el contenido, el sistema circundante debe contener el resultado, hacer visible el intento y conservar evidencia para su revisión.

Un agente de solo lectura aún puede inducir a error a un usuario, por lo que la calidad de la salida importa. Sin embargo, las consecuencias más graves suelen surgir cuando los frameworks combinan razonamiento incierto con autoridad ilimitada.

Por tanto, los prompts de seguridad deben formar parte de un diseño por capas. Son un control, no el control que decide si los datos privados cruzan un límite o si el código ejecutable llega a una estación de trabajo.

La seguridad de los agentes de IA depende de las capacidades, el contexto y el consentimiento

Los frameworks deben tratar al modelo como un planificador no confiable cuyas propuestas requieren verificaciones exigibles.

El primer control arquitectónico es la minimización de capacidades. Un agente debe recibir únicamente las herramientas necesarias para la tarea actual, no todas las integraciones disponibles para el usuario o la organización.

Un resumidor de calendarios rara vez necesita permiso para enviar correo. Un asistente de investigación no necesita automáticamente acceso a la shell. Un revisor de código puede necesitar acceso de lectura al repositorio sin permiso para fusionar cambios.

El principio estático de mínimo privilegio es útil, pero las concesiones específicas para cada tarea son mejores. Una herramienta puede estar disponible para una operación delimitada y desaparecer cuando esa operación termina.

Las credenciales también deben permanecer fuera del contexto del modelo. El modelo debe solicitar una operación mediante un intermediario, en lugar de manejar directamente secretos reutilizables. Los registros deben ocultar los tokens sensibles de los prompts y las respuestas de herramientas.

El segundo control es la autorización contextual. Las comprobaciones de acceso tradicionales suelen responder si un usuario puede acceder a un recurso. Los sistemas de agentes también deben preguntar si ese acceso respalda la solicitud actual del usuario.

Un usuario que puede leer dos cuentas de clientes no ha autorizado necesariamente a un agente a combinarlas. Un desarrollador con acceso de despliegue no ha autorizado a todos los agentes de revisión de código a desplegar.

La intención no puede inferirse perfectamente a partir del lenguaje, pero los frameworks pueden acotarla mediante declaraciones explícitas de tareas. Pueden vincular las herramientas a un objetivo declarado, un conjunto de recursos, una ventana temporal y un flujo de datos permitido.

El tercer control es el consentimiento para acciones con consecuencias. La aprobación humana es especialmente importante antes de enviar información al exterior, gastar dinero, modificar accesos, eliminar datos o ejecutar código no confiable.

El consentimiento debe ser significativo. Las ventanas emergentes vagas y repetidas entrenan a los usuarios a aprobar sin revisar. La interfaz debe identificar la acción exacta y destacar las desviaciones respecto de la tarea original.

Las acciones reversibles y de bajo riesgo pueden usar controles más ligeros. Las acciones de alto riesgo o irreversibles necesitan una confirmación más fuerte y, en entornos empresariales, posiblemente un segundo aprobador.

El cuarto control es el aislamiento. La ejecución de código debe ocurrir dentro de un sandbox con acceso restringido a red, sistema de archivos y credenciales. Las sesiones del navegador deben separar las páginas no confiables del estado de aplicaciones sensibles.

La salida de las herramientas debe tratarse como datos, en lugar de como instrucciones automáticamente confiables. Los frameworks deben validar el tamaño, el formato, el destino y el contenido permitido de la salida antes de devolverla al modelo.

El quinto control es la preservación de la procedencia. Cada documento, mensaje, página web, elemento de memoria y respuesta del agente debe llevar su origen y clasificación de confianza.

Cuando un agente resume una página no confiable, el resumen debe seguir siendo no confiable. La transformación no debe borrar el linaje. Entonces, un motor de políticas posterior puede impedir que material de baja confianza autorice acciones de alto impacto.

El sexto control es la separación entre propuesta y ejecución. Un planificador puede decidir que debe enviarse un correo electrónico, pero un componente distinto debe validar los destinatarios y los archivos adjuntos.

Esta separación limita los ataques de delegado confundido. Un delegado confundido ocurre cuando un sistema con autoridad legítima es manipulado para usar esa autoridad con el propósito de otra persona.

El séptimo control es la observabilidad. Los equipos necesitan registros que muestren qué fuente influyó en una decisión, qué modelo propuso una acción, qué política la permitió y qué herramienta la realizó.

Sin esos registros, una organización no puede reconstruir un incidente de agente. Los registros habituales de aplicaciones pueden capturar llamadas a API y, al mismo tiempo, omitir el prompt, el contenido recuperado, el estado de la memoria y los mensajes entre agentes.

La monitorización también debe centrarse en el comportamiento. Las señales de alerta incluyen combinaciones inusuales de recursos, fallos repetidos de autorización, nuevos destinos salientes, escrituras inesperadas en memoria o herramientas utilizadas fuera de su secuencia habitual.

El octavo control son las pruebas adversariales en flujos de trabajo completos. Probar únicamente el modelo base ignora el framework donde residen los permisos y los efectos secundarios.

El enfoque de NIST utiliza herramientas y tareas realistas porque la seguridad de los agentes es contextual. Un modelo podría resistir un ataque en un chat sencillo y, sin embargo, fallar cuando la misma instrucción aparece dentro de un objeto empresarial de apariencia confiable.

Los equipos rojos deben insertar contenido malicioso en cada fuente que consuma un agente. Esto incluye sitios web, correos electrónicos, documentos, repositorios de código, rastreadores de incidencias, metadatos de herramientas, resultados de búsqueda y memoria compartida.

También deben probar rutas de varios turnos y varios agentes. Un comando directo bloqueado podría tener éxito después de ser reformulado por un agente intermediario o almacenado para su recuperación posterior.

El objetivo no es publicar una única tasa de éxito de inyección de prompts. Es identificar qué inyecciones exitosas alcanzan datos sensibles, herramientas privilegiadas u operaciones irreversibles.

Esto permite una mejor priorización. Una inyección frecuente que solo corrompe un borrador temporal merece atención. Una inyección menos frecuente que alcanza credenciales de producción exige primero controles más sólidos.

OWASP recomienda mínimo privilegio, segregación del contenido externo, aprobación humana, validación de salidas y pruebas adversariales. Estas medidas reflejan un modelo de defensa en profundidad, en lugar de la fe en un único detector.

La taxonomía de ataques más amplia de NIST también hace hincapié en gestionar las consecuencias además de identificar los ataques. Ese enfoque se ajusta a los sistemas de agentes porque la prevención completa sigue siendo incierta.

Ninguno de estos controles hace que el modelo sea confiable. Hacen que el sistema dependa menos de la confiabilidad del modelo, que es un objetivo de ingeniería más defendible.

Qué deberían vigilar a continuación los lectores de Google News

La evidencia decisiva provendrá de los valores predeterminados de los frameworks, una contención medible y una comunicación transparente de incidentes.

La primera señal es si los principales frameworks hacen de la ejecución restringida la opción predeterminada. Los controles opcionales de sandboxing y permisos ayudan a los equipos experimentados, pero los valores predeterminados configuran miles de despliegues ordinarios.

Observe cómo las plataformas de agentes gestionan las concesiones de herramientas, el acceso a la red, las escrituras en el sistema de archivos y las credenciales reutilizables. Un framework que expone primero capacidades amplias y documenta el refuerzo después mantiene el riesgo subyacente.

El valor predeterminado más sólido no concedería automáticamente ninguna herramienta sensible. Los desarrolladores añadirían capacidades de alcance limitado mientras observan las consecuencias de cada permiso.

La segunda señal es si las evaluaciones miden el impacto de extremo a extremo. Las tasas de rechazo de ataques son útiles, pero no revelan si un ataque exitoso alcanzó datos confidenciales o completó una acción peligrosa.

Las mejores evaluaciones informarán tanto sobre la vulneración del modelo como sobre la vulneración del sistema. Distinguirán una respuesta manipulada de una lectura no autorizada, una transferencia saliente, la ejecución de código o un cambio persistente en la memoria.

También deberían publicar resultados de intentos repetidos. Una defensa que tiene éxito una vez pero falla tras varias variaciones ofrece protección limitada en un servicio expuesto a Internet.

Los resultados de la investigación de Google ilustran esta necesidad. El refuerzo de prompts mejoró sustancialmente la resistencia, pero los ataques de varios turnos mantuvieron una elevada tasa de fallo. Los controles arquitectónicos determinan qué significan esos fallos residuales.

La tercera señal es la calidad de la divulgación. Los incidentes específicos de IA a menudo carecen de los artefactos habituales empleados en la gestión convencional de vulnerabilidades. Los equipos pueden recibir una publicación de blog del proveedor sin un identificador estándar, un rango de versiones afectadas ni una vía de remediación clara.

Los proveedores de frameworks deberían publicar avisos de seguridad que describan toda la cadena de ataque. Los usuarios necesitan conocer la fuente de contenido requerida, el comportamiento del modelo, los permisos, las herramientas, las versiones afectadas y las mitigaciones disponibles.

Las afirmaciones vagas de que un modelo recibió «salvaguardas adicionales» no son suficientes. Los clientes necesitan saber si el proveedor modificó el modelo, la política del framework, el sistema de permisos, el sandbox o el flujo de aprobación del usuario.

El mismo estándar debería aplicarse a las decisiones sobre recompensas por errores. Si un informe demuestra una inyección de prompts pero ningún efecto significativo, una gravedad baja puede ser razonable. Si la inyección alcanza una acción privilegiada, descartarla como comportamiento esperado del modelo evita abordar el problema real.

Google News seguirá mostrando demostraciones de inyección de prompts porque son llamativas y fáciles de reproducir. Algunas serán jailbreaks menores, mientras que otras expondrán fallos graves del framework.

Los lectores deberían separar tres preguntas. ¿El atacante influyó en el modelo? ¿Qué capacidad quedó disponible tras esa influencia? ¿Qué control independiente debería haber detenido la acción resultante?

Esa secuencia ofrece una evaluación de riesgos más útil que preguntarse si la inyección de prompts por fin se ha resuelto. La evidencia actual no ofrece base para asumir una solución universal.

Los desarrolladores deberían revisar cada ruta entre contenido no confiable y herramientas sensibles. Los compradores empresariales deberían exigir permisos delimitados por tarea, procedencia, sandboxing, controles de aprobación y registros de ejecución auditables.

Los trabajadores del conocimiento deberían comprobar a qué puede acceder un agente antes de conectar correo electrónico, archivos, calendarios y sistemas de trabajo. La comodidad aumenta rápidamente cuando se combinan estas fuentes, pero también lo hace el radio potencial de impacto.

La inversión central sigue siendo sencilla. La inyección de prompts es el detonante, mientras que el framework aporta alcance, autoridad y persistencia. Tratar solo el detonante deja intacta la maquinaria peligrosa.

La próxima vez que un titular de Google News anuncie otro secuestro de agente, mire más allá de las palabras maliciosas. Pregunte qué herramienta las ejecutó, qué permiso lo permitió y por qué ningún control independiente intervino.

Esa es la prueba que los creadores de agentes deben superar ahora. ¿Puede el sistema seguir siendo seguro después de que su modelo sea persuadido, confundido o simplemente se equivoque? Si la respuesta depende únicamente de mejores prompts, el framework todavía arrastra el fallo.