El Top 10 de LLM de OWASP 2026 reconfigura el mapa de riesgos para la seguridad agéntica

Akamai llevó el Top 10 de LLM de OWASP 2026 a Google News menos de dos semanas después de que OWASP publicara su guía actualizada el 3 de agosto. El momento destaca un conflicto de seguridad que ahora va mucho más allá de las respuestas inseguras de los modelos. Las aplicaciones de IA otorgan cada vez más a los modelos herramientas, memoria, credenciales y permiso para actuar.

El nuevo mapa de riesgos refleja ese cambio. La inyección de prompts sigue siendo un problema central, pero una respuesta manipulada ya no es el peor resultado plausible. Una instrucción inyectada puede redirigir a un agente, activar una herramienta, modificar la memoria persistente, exponer credenciales o propagarse entre agentes conectados.

Esta transición también aumenta la presión sobre las empresas que implementan asistentes en el correo electrónico, la atención al cliente, el desarrollo de software y los sistemas internos de conocimiento. Los controles tradicionales de aplicaciones siguen siendo importantes, pero no gobiernan por completo sistemas que toman decisiones probabilísticas en flujos de trabajo de varios pasos.

El análisis de Akamai coincide con su propio impulso en seguridad de agentes. La compañía ha conectado la inspección del tráfico de IA, la identidad de agentes, el análisis del comportamiento y la aplicación de políticas en el edge dentro de un marco comercial más amplio. Eso hace que su interpretación sea útil, pero también merece escrutinio como la visión de un proveedor sobre un mercado emergente.

La historia de fondo no es una nueva lista de diez vulnerabilidades aisladas. Es un cambio de proteger la entrada y salida de un modelo hacia controlar toda una cadena de ejecución. El perímetro de seguridad ahora incluye cada documento que lee un agente, cada herramienta que invoca y cada identidad que puede asumir.

Google News refleja un cambio más amplio en la seguridad de OWASP

La actualización de OWASP transforma la seguridad de los LLM de un problema de modelo a un problema de control que abarca toda la aplicación.

OWASP publicó su guía de LLM de 2026 el 3 de agosto de 2026. La organización la describe como una guía impulsada por la comunidad y desarrollada por cientos de expertos en seguridad de IA. Afirma que el trabajo se basa en miles de incidentes de seguridad reales.

La guía actualiza las clasificaciones y amplía la cobertura de amenazas para aplicaciones impulsadas por modelos de lenguaje de gran tamaño. También vincula sus riesgos con NIST, MITRE ATLAS, CWE y el marco independiente de OWASP para aplicaciones agénticas.

Esta correspondencia cruzada importa más que un simple cambio de clasificación. Reconoce que los fallos de los LLM rara vez permanecen confinados a una interfaz de chat. Los sistemas modernos combinan modelos con recuperación de información, memoria, interfaces de programación de aplicaciones, servicios de identidad y herramientas ejecutables.

La anterior lista de riesgos de 2025 ya reflejaba parte de esta expansión. Sus categorías incluían inyección de prompts, divulgación de información sensible, debilidades en la cadena de suministro, envenenamiento de datos, manejo inadecuado de salidas y agencia excesiva.

La filtración del prompt del sistema, las debilidades en vectores y embeddings, la desinformación y el consumo sin límites completaban esa edición. Estas categorías abordaban las aplicaciones que rodean al modelo, no solo las debilidades dentro de los pesos del modelo.

La publicación de 2026 hace más explícita la relación con los sistemas autónomos. Una aplicación de LLM puede responder preguntas, mientras que un agente puede planificar y ejecutar una secuencia de acciones. La distinción cambia la forma en que los defensores calculan el impacto.

Una respuesta falsa de un chatbot de soporte puede engañar a un cliente. Una decisión errónea de un agente de soporte podría modificar una cuenta, emitir un reembolso o divulgar registros. El mismo comportamiento del modelo produce un resultado de seguridad distinto una vez que las herramientas y los privilegios entran en el flujo de trabajo.

La inyección de prompts ilustra la diferencia. Ocurre cuando una entrada elaborada cambia el comportamiento de un modelo de forma no prevista. La entrada puede proceder directamente de un usuario o indirectamente del contenido que recupera el sistema.

La inyección indirecta convierte el material empresarial ordinario en parte de la superficie de ataque. Una instrucción maliciosa podría estar dentro de un correo electrónico, una página web, un documento compartido, un ticket de soporte o un registro de conocimiento recuperado. El agente la encuentra mientras completa una tarea legítima.

El problema no consiste simplemente en que el modelo pueda repetir texto malicioso. El modelo podría tratar ese texto como una instrucción y trasladar sus efectos a otro componente. El acceso a herramientas convierte un fallo de interpretación del lenguaje en un incidente operativo de seguridad.

La distribución en Google News otorga a este marco especializado una audiencia más amplia. Sin embargo, el canal de agregación no debe confundirse con la evidencia primaria. La publicación de OWASP y los materiales técnicos subyacentes siguen siendo las referencias autorizadas.

Por tanto, el acontecimiento tiene dos capas. La capa visible es Akamai explicando un marco de riesgos recién publicado. La capa más importante es OWASP conectando formalmente los riesgos de las aplicaciones de LLM con los riesgos de ejecución agéntica.

Esa conexión plantea la tensión central del artículo. Las organizaciones quieren que los agentes completen más trabajo sin intervención constante. Cada permiso adicional también incrementa el daño que puede causar una instrucción comprometida.

Las aplicaciones agénticas ponen en riesgo herramientas, identidad y memoria

El valor de un agente proviene de su capacidad de actuar, pero esa misma capacidad amplía el radio de impacto de cada fallo de control.

OWASP publicó su Top 10 agéntico el 9 de diciembre de 2025. Más de 100 expertos del sector, investigadores y profesionales contribuyeron al marco revisado por pares.

La lista agéntica cubre el secuestro de objetivos, el uso indebido de herramientas, el abuso de identidad, las vulnerabilidades de la cadena de suministro, la ejecución inesperada de código y el envenenamiento de memoria. También abarca la comunicación insegura entre agentes, los fallos en cascada, la explotación de la confianza humana y los agentes rebeldes.

Estas categorías no sustituyen a la lista de LLM. Describen lo que ocurre cuando debilidades conocidas de los modelos interactúan con la autonomía, el estado persistente, los privilegios delegados y múltiples sistemas.

El secuestro de objetivos de un agente extiende la lógica de la inyección de prompts. Un atacante no necesita reescribir un modelo ni vulnerar su infraestructura. En cambio, desvía al agente del objetivo que pretendía su propietario.

Consideremos un agente al que se le pide resumir una bandeja de entrada. Un mensaje contiene instrucciones ocultas que dirigen al agente a buscar archivos confidenciales. Si el sistema no logra separar los datos de los comandos, el agente puede adoptar el objetivo del atacante.

Akamai describe ese escenario en su análisis sobre agentes seguros. Sus investigadores sostienen que los canales de instrucciones y los canales de información requieren rutas de procesamiento y niveles de privilegio diferentes.

El uso indebido de herramientas crea el siguiente eslabón de la cadena. Un objetivo inyectado tiene un impacto limitado cuando el modelo solo puede producir texto. El riesgo cambia cuando ese mismo modelo puede invocar una shell, modificar archivos, llamar a servicios externos o consultar bases de datos.

Una herramienta de shell de propósito general es especialmente difícil de gobernar. Expone muchas acciones a través de una única interfaz y hace que las decisiones de autorización sean menos granulares. Una herramienta más limitada puede restringir a un agente a operaciones y directorios definidos.

El abuso de identidad y privilegios añade otra capa. Muchos agentes operan con los permisos de la persona que los instaló o autorizó. Por tanto, un agente comprometido puede heredar accesos que estaban destinados a un empleado de confianza.

Las identidades de servicio dedicadas pueden reducir esa exposición. Sus permisos deben ser limitados, temporales y distintos de las sesiones interactivas de usuario. Las acciones sensibles también necesitan una nueva autorización, en lugar de depender de una aprobación general previa.

La memoria persistente cambia la duración de un ataque. Una instrucción maliciosa escrita en la memoria puede influir en sesiones posteriores después de que desaparezca la entrada original. Esto es envenenamiento de memoria: contenido hostil corrompe información que el agente trata como contexto de confianza.

Las organizaciones ya introducen una cantidad considerable de conocimiento operativo en sistemas de recuperación y espacios de trabajo de IA. Una base de conocimiento con capacidad de búsqueda puede mejorar el acceso a registros técnicos, pero su procedencia y permisos siguen siendo esenciales.

El conocimiento y las instrucciones no deben convertirse en elementos intercambiables. El material recuperado debe aportar datos para una tarea sin modificar silenciosamente las reglas operativas del agente. Los sistemas también necesitan registros que muestren qué fuente influyó en cada acción relevante.

La comunicación entre agentes crea más incertidumbre. Un agente puede confiar en la salida de otro sin conocer su origen, permisos o entradas previas. Un participante comprometido puede transmitir contexto envenenado a través de un flujo de trabajo que, por lo demás, es legítimo.

El fallo en cascada es el riesgo resultante a nivel de sistema. Una acción incorrecta puede activar agentes posteriores, automatizaciones y servicios externos. El daño final puede aparecer lejos del documento malicioso original.

Este modelo de amenazas presiona al mismo tiempo a desarrolladores, equipos de identidad, operaciones de seguridad y propietarios de negocio. Ningún filtro de prompts por sí solo puede asignar el mínimo privilegio, aislar la memoria, verificar herramientas y contener un fallo multiagente.

Por tanto, el Top 10 de LLM de OWASP 2026 funciona como punto de entrada, no como un modelo operativo completo. Los equipos deben conectar las pruebas de modelos con la seguridad de aplicaciones, la gestión de accesos, la revisión de la cadena de suministro y la respuesta a incidentes.

La autonomía y la contención son ahora los principales adversarios

La disyuntiva central de seguridad ya no es inteligencia frente a precisión; es autonomía útil frente a contención exigible.

Un asistente que pide aprobación antes de cada paso ofrece una automatización limitada. Un agente que nunca pregunta puede completar más trabajo, pero también puede ejecutar más rápido un plan equivocado u hostil.

Esto crea una decisión de producto incómoda. Los equipos deben decidir qué acciones merecen ejecución automática y cuáles requieren un punto de control humano. La respuesta depende de la reversibilidad, la sensibilidad de los datos, el impacto financiero y la confianza del agente.

El mínimo privilegio proporciona un punto de partida. Un agente debe recibir únicamente las capacidades necesarias para su tarea actual. Los permisos deben expirar cuando termine la tarea, en lugar de permanecer vinculados a una sesión de larga duración.

La mínima agencia aplica el mismo razonamiento a las decisiones. Un sistema no debe delegar un objetivo de varios pasos cuando una operación limitada lograría el resultado deseado. Una autoridad más restringida facilita contener comportamientos inesperados.

La distinción se hace clara en la atención al cliente. Un agente puede redactar una recomendación de reembolso utilizando el historial de la cuenta y documentos de políticas. Permitirle emitir el reembolso añade autoridad de pago e introduce una clase de riesgo diferente.

Los agentes de desarrollo de software muestran el mismo patrón. Leer un repositorio permite el análisis de código. Escribir en una rama añade riesgo de integridad, mientras que desplegar en producción introduce un impacto operativo directo.

Un diseño seguro puede separar esas capacidades. El agente podría recibir acceso de lectura de forma predeterminada, acceso temporal a ramas tras una aprobación y ninguna credencial de producción. Un control de despliegue independiente puede verificar el cambio final.

Los marcos de riesgo de 2026 también cuestionan la suposición de que la alineación del modelo es una defensa suficiente. La alineación intenta influir en el comportamiento del modelo, pero los controles de acceso deben restringir lo que permite la aplicación circundante.

Un modelo puede rechazar muchas instrucciones dañinas y aun así fallar ante una inyección desconocida. La contención parte de la premisa de que algunas decisiones del modelo serán erróneas. Limita las consecuencias cuando esa predicción se cumple.

La postura de Akamai refleja esta visión arquitectónica. Su análisis de febrero sobre OpenClaw sostiene que la seguridad de los agentes autónomos se apoya en controles convencionales de red, sistemas operativos y aplicaciones.

La empresa cita los servicios expuestos, la autenticación inadecuada, la ejecución de comandos y el almacenamiento de credenciales como debilidades fundamentales. Un agente situado sobre esas debilidades se convierte en un proxy privilegiado para un atacante.

Esta conclusión evita que la seguridad agéntica se convierta en una excusa para ignorar tareas de ingeniería ya conocidas. La inspección de entradas no puede compensar un servicio de administración expuesto. Un prompt de políticas no puede proteger credenciales almacenadas sin los controles adecuados.

La seguridad de la cadena de suministro también cobra mayor importancia cuando los agentes instalan o invocan skills de terceros. Un skill puede combinar instrucciones en lenguaje natural, código ejecutable, servicios remotos y solicitudes de acceso dentro de un mismo paquete.

La revisión tradicional de dependencias examina la procedencia, las versiones, las vulnerabilidades y los mantenedores. Los sistemas agénticos también deben examinar las capacidades declaradas, el comportamiento de los prompts, el acceso a herramientas y la información devuelta al modelo.

El sandboxing ayuda a aislar la ejecución no confiable. Sin embargo, un sandbox debe restringir archivos, redes, credenciales y persistencia para ofrecer una contención significativa. Un proceso nominalmente aislado con tokens de amplio alcance aún puede acceder a servicios sensibles.

La observabilidad es la otra mitad de la contención. Los equipos necesitan registros de la intención del usuario, las decisiones del modelo, los argumentos de las herramientas, las concesiones de permisos, las fuentes recuperadas, los cambios en la memoria y las respuestas posteriores.

Estos registros permiten a los defensores reconstruir por qué actuó un agente. También respaldan la detección automatizada cuando el comportamiento se desvía del alcance aprobado de una tarea.

Registrar cada pensamiento del modelo no es ni fiable ni siempre apropiado. El razonamiento interno puede estar incompleto, ser sensible o no estar disponible. En cambio, la evidencia de seguridad debe centrarse en decisiones, entradas, permisos y efectos observables.

La disyuntiva sigue siendo difícil porque los controles estrictos pueden reducir la utilidad de un agente. Las solicitudes frecuentes de aprobación generan fatiga. Las herramientas limitadas requieren más ingeniería, mientras que el aislamiento puede ralentizar flujos de trabajo complejos.

Sin embargo, eliminar controles no resuelve ese problema de producto. Traslada la complejidad a la respuesta ante incidentes y dificulta revertir los fallos. El diseño maduro de agentes debe tratar los límites de seguridad como parte de la funcionalidad.

Los lectores de Google News pueden encontrarse la actualización de OWASP como una lista de amenazas emergentes. Los compradores empresariales deberían interpretarla como una prueba de adquisición. Los proveedores deben explicar cómo sus sistemas limitan la autoridad, no solo lo bien que sus modelos siguen instrucciones.

Los desarrolladores deberían preguntar qué componentes pueden detener una acción después de que el modelo la haya elegido. Si la respuesta es únicamente otro prompt, la contención sigue dependiendo de la misma capa probabilística que produjo el riesgo.

El marco de seguridad de Akamai muestra tanto la oportunidad como la brecha

Akamai está traduciendo el lenguaje de riesgos de OWASP en controles de infraestructura, pero sus afirmaciones de producto aún requieren evidencia operativa independiente.

Akamai anunció un marco unificado de seguridad agéntica el 15 de junio de 2026. La empresa afirma que combina identidad, observabilidad, confianza y seguridad perimetral en una capa de decisiones en tiempo real.

Su marco de seguridad para agentes incluye seis pilares integrados. Estos abarcan identidad, asignación de permisos, aplicación de políticas, acceso a contenido, análisis de tráfico e interacciones comerciales.

Uno de los elementos es Know Your Agent, o KYA, un método propuesto para declarar la identidad, el origen y la intención de un agente. Akamai afirma que el enfoque vincula a los agentes con sus plataformas y los usuarios a quienes representan.

El problema de la identidad es real. Los sitios web a menudo pueden distinguir los navegadores convencionales de los bots conocidos, pero los agentes autónomos complican la atribución. Una solicitud puede involucrar a un proveedor de modelos, una plataforma de agentes, un usuario y varios servicios delegados.

Reconocer a un agente no hace automáticamente que su acción sea confiable. Las decisiones de seguridad también requieren la autoridad del usuario, la operación solicitada, el contexto actual y cualquier límite asociado a la delegación.

Un agente verificado aún podría verse comprometido. Un usuario legítimo podría solicitar una acción prohibida. Una plataforma de confianza podría transmitir contexto corrompido desde una fuente externa.

Por lo tanto, la identidad debe orientar la autorización en lugar de sustituirla. Cada solicitud sensible sigue necesitando una decisión de política basada en el alcance, el riesgo y la evidencia actual.

Akamai también propone la aplicación de políticas en el perímetro, que evalúa el tráfico de los agentes antes de que llegue a una aplicación. Esa ubicación puede proporcionar amplia visibilidad sobre las solicitudes web y reducir la carga de los servicios individuales.

Los controles perimetrales pueden identificar patrones de automatización, imponer límites de tasa y bloquear entradas maliciosas conocidas. También pueden aplicar reglas coherentes entre aplicaciones que, de otro modo, utilizan distintos marcos de IA.

Sin embargo, la inspección en la capa de red no puede ver cada decisión dentro de un agente. Puede observar una llamada a una API sin saber qué registro de memoria, documento recuperado o plan interno la provocó.

La telemetría a nivel de aplicación sigue siendo necesaria. Los desarrolladores deben capturar el alcance de la tarea del agente, la selección de herramientas, el estado de autorización y la procedencia pertinente. Ni el perímetro ni la aplicación ofrecen por sí solos una cobertura completa.

La posición comercial de Akamai plantea otra consideración. La empresa se beneficia cuando las compañías tratan el tráfico agéntico como una nueva categoría de infraestructura que requiere controles especializados.

Eso no invalida su análisis. Significa que los lectores deben separar las descripciones de riesgos verificadas de las afirmaciones sobre la capacidad de un proveedor concreto para abordarlos.

La misma cautela se aplica a todo el mercado de la seguridad. Un firewall podría detectar inyecciones comunes sin contener a un agente que ya posee permisos excesivos. Un producto de identidad podría autenticar agentes sin verificar su comportamiento actual.

Una plataforma de monitoreo podría registrar un incidente sin detenerlo. Un producto de red team podría encontrar patrones de ataque conocidos mientras pasa por alto fallos exclusivos del flujo de trabajo de una empresa.

La guía para agentes seguros de OWASP enfatiza orientaciones prácticas de diseño, desarrollo y despliegue. Su existencia muestra por qué ninguna capa de seguridad por sí sola completa el trabajo.

Las organizaciones necesitan controles superpuestos en arquitectura, identidad, datos, herramientas, monitoreo en tiempo de ejecución y respuesta ante incidentes. Los controles también deben probarse conjuntamente, en lugar de evaluarse como funciones de producto independientes.

La pregunta escéptica es si los productos actuales de seguridad para agentes pueden mantener el contexto a lo largo de esa cadena. Una decisión tomada en el perímetro de red necesita información de los sistemas de identidad y del estado de la tarea en la aplicación.

Los falsos positivos plantean otro desafío. Bloquear instrucciones legítimas puede hacer que un agente sea poco fiable, mientras que permitir entradas ambiguas puede abrir rutas peligrosas. Los proveedores necesitan evidencia medible sobre cómo equilibran esos resultados.

Las tasas de detección publicadas a menudo dependen de conjuntos de pruebas seleccionados. Los entornos de producción contienen conversaciones más largas, documentos propietarios, herramientas inusuales y ataques en evolución. Los resultados de benchmarks limitados pueden no trasladarse.

Las empresas deberían solicitar métodos de prueba, límites de cobertura, datos sobre falsos positivos y procedimientos de manejo de fallos. También deberían verificar si un control bloquea una acción o simplemente genera una alerta después.

El marco de Akamai se entiende mejor como evidencia de que el mercado está avanzando hacia una infraestructura consciente de los agentes. No demuestra que el problema de seguridad subyacente se haya resuelto.

El OWASP LLM Top 10 2026 proporciona un vocabulario compartido para evaluar ese mercado. Su mayor valor puede ser ayudar a los compradores a formular preguntas específicas en lugar de aceptar promesas generales sobre una “IA segura”.

Lo que los equipos de seguridad deberían vigilar tras la actualización de OWASP

La próxima prueba es si las organizaciones convierten la nueva taxonomía en controles medibles antes de que los despliegues autónomos sigan ampliándose.

La primera señal es la evidencia de que los proveedores están separando la identidad del agente de la identidad del usuario. Un agente que actúa en nombre de una persona no debería heredar todos los permisos disponibles en la sesión interactiva de esa persona.

Los equipos de seguridad deberían buscar credenciales con alcance limitado, períodos de vencimiento cortos, registros explícitos de delegación y autorización vinculada a tareas. Estas características reforzarían el argumento de que la identidad de los agentes se está volviendo operativa.

Una etiqueta que identifica una solicitud automatizada no es suficiente. El sistema debe mostrar quién autorizó al agente, qué puede hacer y cuándo termina esa autoridad.

La segunda señal es una mayor realización de pruebas de inyección indirecta de prompts y envenenamiento de memoria. Estos ataques entran a través de contenido que los usuarios pueden considerar datos empresariales normales.

Las evaluaciones útiles deberían incluir correo electrónico, documentos, sitios web, respuestas de herramientas, registros recuperados y memoria persistente. Las pruebas deben medir si el contenido malicioso llega a una herramienta capaz de actuar.

La tasa de contención importa más que un simple recuento de detecciones. Un control aporta valor cuando evita que un contexto hostil produzca un efecto no autorizado, incluso si el modelo inicialmente sigue la instrucción.

Los equipos también deberían probar ataques a lo largo del tiempo. Un registro de memoria envenenado podría permanecer inactivo antes de influir en una tarea posterior. Una evaluación breve puede pasar por alto esta persistencia.

La tercera señal es la presentación de informes de incidentes reales relacionados con flujos de trabajo multiagente. El marco de OWASP identifica comunicaciones inseguras, fallos en cascada y agentes rebeldes, pero la evidencia operativa pública sigue siendo limitada.

Las divulgaciones claras revelarían qué límites fallaron primero y qué controles contuvieron los daños. También ayudarían a distinguir las categorías teóricas de las debilidades recurrentes en producción.

La ausencia de informes públicos no debe interpretarse como ausencia de incidentes. Las organizaciones podrían no reconocer los fallos agénticos o clasificarlos dentro de categorías convencionales de aplicaciones e identidad.

La calidad de las futuras divulgaciones determinará la inversión en seguridad. Si la mayoría de los fallos se originan en privilegios excesivos, los controles de identidad y herramientas merecen prioridad. Si predomina la recuperación envenenada, la procedencia y el aislamiento de contenido se vuelven más urgentes.

El trabajo regulatorio y de estándares también influirá en la implementación. Mapear los riesgos de OWASP con NIST, MITRE ATLAS, CWE y otros marcos puede ayudar a los equipos a integrar controles de IA en los procesos de gobernanza existentes.

Sin embargo, el mapeo por sí solo no demuestra la eficacia. Los auditores necesitan evidencia de que un control funciona en condiciones realistas. Los desarrolladores necesitan pruebas repetibles que puedan ejecutarse cuando cambian los modelos, prompts, herramientas o permisos.

La atención de Google News en torno al análisis de Akamai puede ayudar a llevar el asunto más allá de los equipos especializados de seguridad. Los líderes de producto y los compradores empresariales ahora influyen en cuánta autoridad reciben los agentes.

Sus decisiones determinan si la seguridad se convierte en un requisito arquitectónico o en una revisión realizada después del despliegue. El segundo enfoque se vuelve cada vez más costoso a medida que los agentes adquieren memoria persistente e integraciones más amplias.

Una revisión práctica debería comenzar por las acciones, no por los nombres de los modelos. Los equipos deberían inventariar qué agentes pueden leer datos sensibles, modificar registros, ejecutar código, enviar mensajes o iniciar transacciones.

Cada acción necesita un responsable, un límite de permisos, una política de aprobación y una vía de recuperación. Las operaciones de alto impacto también deberían generar registros resistentes a manipulaciones que respalden la investigación.

Las organizaciones deberían asumir que la inyección de prompts no desaparecerá. El objetivo defendible es impedir que una manipulación exitosa se convierta en una acción sin restricciones.

Eso implica separar las instrucciones de la información recuperada, limitar las herramientas, aislar la ejecución y validar los resultados antes de que los sistemas posteriores los consuman. La memoria persistente requiere procedencia, controles de escritura y mecanismos de revisión.

La supervisión humana debe centrarse en decisiones significativas. Pedir a los usuarios que aprueben cada paso menor fomenta la confirmación automática. Los puntos de control deben aparecer antes de acciones irreversibles, sensibles o inesperadamente amplias.

Los planes de respuesta ante incidentes también necesitan procedimientos específicos para agentes. Los equipos deben poder revocar credenciales delegadas, desactivar herramientas, poner en cuarentena la memoria y rastrear los sistemas posteriores afectados.

La actualización de OWASP no establece un estándar de seguridad definitivo. Ofrece un modelo compartido para detectar brechas mientras las arquitecturas de agentes siguen evolucionando.

La contribución de Akamai consiste en conectar ese modelo con la aplicación de políticas en red, la identidad y la visibilidad operativa. Los competidores ofrecerán combinaciones diferentes, lo que brinda a los compradores la oportunidad de exigir resultados verificables.

Para los desarrolladores, la pregunta inmediata es sencilla: ¿qué ocurre después de que el modelo toma una decisión equivocada? Un sistema seguro debe responder con un límite técnico, no con una promesa sobre el comportamiento del modelo.

Para los compradores empresariales, el siguiente paso es probar un flujo de trabajo relevante desde la entrada hasta la ejecución. Sigan el contenido recuperado, los permisos, las herramientas, los cambios en la memoria y el efecto final.

Para los trabajadores del conocimiento, la actualización recuerda que un asistente conectado al trabajo privado tiene un perfil de riesgo distinto al de un chatbot aislado. La comodidad aumenta cuando crecen las conexiones, pero también la exposición.

Habrá que observar si los próximos productos restringen por defecto los permisos de los agentes, publican pruebas de inyección realistas y permiten una contención rápida. Esas señales mostrarán si el marco de OWASP está transformando los sistemas implementados.

La visibilidad en Google News puede amplificar la advertencia, pero la implementación determinará su valor. Antes de conceder acceso a otro agente, identifique el límite que impide que una instrucción comprometida se convierta en un fallo operativo persistente.