{"id":28936,"date":"2026-02-16T22:54:34","date_gmt":"2026-02-17T04:54:34","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=28936"},"modified":"2026-02-17T06:47:50","modified_gmt":"2026-02-17T12:47:50","slug":"top-agentic-ai-risks-2026","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/28936\/","title":{"rendered":"Agentes de IA en tu organizaci\u00f3n: c\u00f3mo gestionar los riesgos"},"content":{"rendered":"

\u00bfC\u00f3mo se protege a una organizaci\u00f3n de las acciones peligrosas que realizan los agentes de IA que dicha organizaci\u00f3n utiliza? Esto ya no es solo una hip\u00f3tesis te\u00f3rica, ya que se debe considerar que el da\u00f1o real que puede causar la IA aut\u00f3noma var\u00eda desde proporcionar un servicio al cliente deficiente<\/a> hasta destruir las principales bases de datos corporativas<\/a>.\u00a0 Es una pregunta que los l\u00edderes empresariales se est\u00e1n planteando con insistencia actualmente, y las agencias gubernamentales junto con los expertos en seguridad se est\u00e1n apresurando en encontrar alguna respuesta.<\/p>\n

Para los directores de TI y los directores de seguridad de la informaci\u00f3n, los agentes de IA son un enorme dolor de cabeza en la gerencia. Estos agentes toman decisiones, usan herramientas y procesan datos confidenciales sin un ser humano que est\u00e9 al tanto. En consecuencia, resulta que muchas de nuestras herramientas est\u00e1ndar de TI y de seguridad son incapaces de controlar la IA.<\/p>\n

La Fundaci\u00f3n OWASP, una organizaci\u00f3n sin fines de lucro, ha publicado un pr\u00e1ctico manual sobre este tema. Su lista integral de los 10 principales riesgos en las aplicaciones de la IA ag\u00e9ntica<\/a> abarca desde amenazas de seguridad tradicionales, como el escalamiento de privilegios, hasta problemas espec\u00edficos de la IA, como el envenenamiento de la memoria de los agentes. Cada riesgo incluye ejemplos reales, un an\u00e1lisis de sus diferencias con otras amenazas similares y estrategias para su mitigaci\u00f3n. En esta publicaci\u00f3n, hemos resumido las descripciones y combinado las recomendaciones de defensa.<\/p>\n

\"Los<\/a>

Los 10 principales riesgos que conllevan la implementaci\u00f3n de agentes de IA aut\u00f3nomos. Fuente<\/a><\/p><\/div>\n

Secuestro de objetivos del agente (ASI01)<\/h2>\n

Este riesgo consiste en manipular las tareas o la l\u00f3gica de toma de decisiones de un agente aprovechando la incapacidad del modelo subyacente para distinguir entre instrucciones leg\u00edtimas y datos externos. Los atacantes utilizan la inyecci\u00f3n de mensajes o datos falsificados para reprogramar al agente y lograr que lleve a cabo acciones maliciosas. La diferencia clave con respecto a una inyecci\u00f3n de mensajes est\u00e1ndar es que este ataque rompe el proceso de planificaci\u00f3n de varios pasos del agente, en lugar de limitarse a enga\u00f1ar al modelo para que d\u00e9 una \u00fanica respuesta err\u00f3nea.<\/p>\n

Ejemplo: un atacante incrusta una instrucci\u00f3n oculta en una p\u00e1gina web que, una vez analizada por el agente de IA, activa la exportaci\u00f3n del historial del navegador del usuario. En un estudio de EchoLeak<\/a>, se mostr\u00f3 una vulnerabilidad de esta misma naturaleza.<\/p>\n

Uso indebido y aprovechamiento de herramientas (ASI02)<\/h2>\n

Este riesgo surge cuando un agente, impulsado por \u00f3rdenes ambiguas o influencias maliciosas, utiliza las herramientas leg\u00edtimas a las que tiene acceso de forma insegura o indebida. Algunos ejemplos incluyen la eliminaci\u00f3n masiva de datos o el env\u00edo de llamadas API facturables redundantes. Estos ataques suelen llevarse a cabo a trav\u00e9s de complejas cadenas de llamadas, lo que les permite pasar desapercibidos por los sistemas tradicionales de supervisi\u00f3n de hosts.<\/p>\n

Ejemplo: un chatbot de servicio de atenci\u00f3n al cliente con acceso a una API financiera es manipulado para procesar reembolsos no autorizados porque su acceso no estaba restringido a solo lectura. Otro ejemplo es la exfiltraci\u00f3n de datos a trav\u00e9s de consultas DNS, similar al ataque a Amazon Q<\/a>.<\/p>\n

Abuso de identidad y privilegios (ASI03)<\/h2>\n

Esta vulnerabilidad tiene que ver con la forma en que se conceden y heredan los permisos dentro de los flujos de trabajo ag\u00e9nticos<\/a>. Los atacantes aprovechan los permisos existentes o las credenciales almacenadas en cach\u00e9 para escalar privilegios o realizar acciones para las que el usuario original no estaba autorizado. El riesgo aumenta cuando los agentes utilizan identidades compartidas o reutilizan tokens de autenticaci\u00f3n en diferentes contextos de seguridad.<\/p>\n

Ejemplo: un empleado crea un agente que utiliza sus credenciales personales para acceder a los sistemas internos. Si ese agente se comparte con otros compa\u00f1eros de trabajo, cualquier solicitud que estos realicen al agente tambi\u00e9n se ejecutar\u00e1 con los permisos elevados del creador.<\/p>\n

Vulnerabilidades en la cadena de suministro ag\u00e9ntica (ASI04)<\/h2>\n

Los riesgos surgen cuando se utilizan modelos, herramientas o perfiles de agentes preconfigurados de terceros que pueden estar vulnerados o ser maliciosos desde el principio. Lo que hace que esto sea m\u00e1s complicado que el software tradicional es que los componentes ag\u00e9nticos se suelen cargar de forma din\u00e1mica y no se conocen de antemano. Esto aumenta significativamente el riesgo, especialmente si se le permite al agente buscar por s\u00ed mismo un paquete adecuado. Estamos siendo testigos de un aumento tanto del typosquatting, en el que las herramientas maliciosas en los registros imitan los nombres de bibliotecas populares, como del slopsquatting<\/a>, en el que un agente intenta nombrar herramientas que ni siquiera existen.<\/p>\n

Ejemplo: un agente asistente de codificaci\u00f3n instala autom\u00e1ticamente un paquete vulnerado que contiene una puerta trasera, lo que le permite al atacante extraer tokens CI\/CD y claves SSH directamente del entorno del agente. Ya hemos visto intentos documentados de ataques destructivos dirigidos a agentes de desarrollo de IA<\/a> en el mundo real.<\/p>\n

Ejecuci\u00f3n inesperada de c\u00f3digo\/RCE (ASI05)<\/h2>\n

Los sistemas ag\u00e9nticos suelen generar y ejecutar c\u00f3digo en tiempo real para realizar tareas, lo que les abre la puerta a los scripts o binarios maliciosos. Mediante la inyecci\u00f3n de mensajes y otras t\u00e9cnicas, se puede enga\u00f1ar a un agente para que ejecute sus herramientas disponibles con par\u00e1metros peligrosos o para que ejecute el c\u00f3digo proporcionado directamente por el atacante.\u00a0 Esto puede escalar hasta poner en riesgo todo el contenedor o el host, o escapar del entorno aislado, momento en el que el ataque se vuelve invisible para las herramientas de supervisi\u00f3n de IA est\u00e1ndar.<\/p>\n

Ejemplo: un atacante env\u00eda un mensaje<\/a> que, bajo la apariencia de una prueba de c\u00f3digo, enga\u00f1a a un agente de vibecoding<\/a> para que descargue un comando a trav\u00e9s de cURL<\/a> y lo canalice directamente a bash<\/a>.<\/p>\n

Envenenamiento de la memoria y el contexto (ASI06)<\/h2>\n

Los atacantes modifican la informaci\u00f3n en la que se basa un agente para mantener la continuidad, como el historial de di\u00e1logos, una base de conocimientos RAG o los res\u00famenes de las etapas de tareas anteriores. Este contexto envenenado distorsiona el razonamiento futuro del agente y la selecci\u00f3n de herramientas. Como resultado, pueden surgir puertas traseras persistentes en su l\u00f3gica que sobreviven entre sesiones. A diferencia de una inyecci\u00f3n puntual, este riesgo causa un impacto a largo plazo en el conocimiento y la l\u00f3gica de comportamiento del sistema.<\/p>\n

Ejemplo: un atacante introduce datos falsos en la memoria de un asistente sobre las cotizaciones de los precios de vuelos que recibi\u00f3 de parte de un proveedor. En consecuencia, el agente aprueba futuras transacciones a una tarifa fraudulenta. Se mostr\u00f3 un ejemplo de implantaci\u00f3n de memoria falsa en un ataque de demostraci\u00f3n contra Gemini<\/a>.<\/p>\n

Comunicaci\u00f3n insegura entre agentes (ASI07)<\/h2>\n

En los sistemas de m\u00faltiples agentes, la coordinaci\u00f3n se produce a trav\u00e9s de API o buses de mensajes que a menudo carecen de cifrado b\u00e1sico, autenticaci\u00f3n o comprobaciones de integridad. Los atacantes pueden interceptar, falsificar o modificar estos mensajes en tiempo real, de manera que se provocan problemas t\u00e9cnicos en todo el sistema distribuido. Esta vulnerabilidad abre la puerta a ataques de tipo \u201cagente intermedio\u201d, as\u00ed como a otros exploits de comunicaci\u00f3n cl\u00e1sicos que son populares en el mundo de la seguridad de la informaci\u00f3n aplicada: repetici\u00f3n de mensajes, suplantaci\u00f3n del remitente y degradaciones forzadas del protocolo.<\/p>\n

Ejemplo: cuando se obliga a los agentes a cambiar a un protocolo que no est\u00e1 cifrado para inyectar comandos ocultos, y, de este modo, secuestrar de forma efectiva el proceso colectivo de la toma de decisiones de todo el grupo de agentes.<\/p>\n

Fallos en cascada (ASI08)<\/h2>\n

Este riesgo describe c\u00f3mo un solo error, causado por una alucinaci\u00f3n, una inyecci\u00f3n de mensajes o cualquier otro problema t\u00e9cnico, puede propagarse y amplificarse a lo largo de una cadena de agentes aut\u00f3nomos. Debido a que estos agentes se transfieren tareas entre s\u00ed sin intervenci\u00f3n humana, un fallo en un eslab\u00f3n puede desencadenar un efecto domin\u00f3 que provocar\u00eda un colapso masivo de toda la red. El problema central aqu\u00ed es la gran velocidad del error: se propaga mucho m\u00e1s r\u00e1pido de lo que cualquier operador humano puede rastrear o detener.<\/p>\n

Ejemplo: un agente programador vulnerado env\u00eda una serie de comandos inseguros que son ejecutados autom\u00e1ticamente por los agentes descendentes, lo que provoca un bucle de acciones peligrosas que se replican en toda la organizaci\u00f3n.<\/p>\n

Aprovechamiento de la confianza entre humano y agente (ASI09)<\/h2>\n

Los atacantes se aprovechan de la naturaleza conversacional y la aparente experiencia de los agentes para manipular a los usuarios. El antropomorfismo lleva a las personas a depositar una confianza excesiva en las recomendaciones de la IA y a aprobar acciones cr\u00edticas sin considerarlo dos veces. El agente se comporta como un mal consejero, de modo que convierte al humano en el ejecutor final del ataque, lo que luego complica la investigaci\u00f3n forense posterior.<\/p>\n

Ejemplo: un agente de soporte t\u00e9cnico vulnerado hace referencia a n\u00fameros de reclamos reales para establecer una buena relaci\u00f3n con un nuevo empleado y, finalmente, le endulza el o\u00eddo para que le entregue sus credenciales corporativas.<\/p>\n

Agentes corruptos (ASI10)<\/h2>\n

Son agentes maliciosos, vulnerados o con alucinaciones que se desv\u00edan de sus funciones asignadas, operan de forma sigilosa o act\u00faan como par\u00e1sitos dentro del sistema. Una vez que se pierde el control, un agente de este tipo puede empezar a autorreplicarse, perseguir sus propios objetivos ocultos o incluso confabularse con otros agentes para eludir las medidas de seguridad. La principal amenaza descrita en ASI10 es la erosi\u00f3n a largo plazo de la integridad del comportamiento de un sistema tras una filtraci\u00f3n o anomal\u00eda inicial.<\/p>\n

Ejemplo: el caso m\u00e1s infame es el de un agente de desarrollo aut\u00f3nomo de Replit<\/a> que se volvi\u00f3 corrupto, elimin\u00f3 la base de datos principal de los clientes de la empresa y, luego, falsific\u00f3 completamente su contenido para que pareciera que el problema se hab\u00eda solucionado.<\/p>\n

C\u00f3mo mitigar los riesgos en los sistemas de IA ag\u00e9ntica<\/h2>\n

Si bien la naturaleza probabil\u00edstica de la generaci\u00f3n de LLM y la falta de separaci\u00f3n entre las instrucciones y los canales de datos hacen imposible una seguridad infalible, la aplicaci\u00f3n de un conjunto riguroso de controles (similar a una estrategia de confianza cero) puede limitar considerablemente el da\u00f1o cuando surgen los problemas. A continuaci\u00f3n, encontrar\u00e1s las medidas m\u00e1s importantes.<\/p>\n

Haz cumplir los principios de m\u00ednima autonom\u00eda y m\u00ednimo privilegio.<\/strong> Limita la autonom\u00eda de los agentes de IA asign\u00e1ndoles tareas con restricciones estrictamente definidas. Aseg\u00farate de que solo tengan acceso a las herramientas, API y datos corporativos espec\u00edficos que sean necesarios para su misi\u00f3n. Reduce los permisos al m\u00ednimo absoluto cuando sea apropiado, por ejemplo, manteniendo el modo de solo lectura.<\/p>\n

Utiliza credenciales de corta duraci\u00f3n.<\/strong> Emite tokens temporales y claves API con un alcance limitado para cada tarea espec\u00edfica. Esto evita que un atacante reutilice las credenciales si logra poner en riesgo a un agente.<\/p>\n

Intervenci\u00f3n humana obligatoria<\/strong> en las operaciones cr\u00edticas. Exige la confirmaci\u00f3n expl\u00edcita de una persona para cualquier acci\u00f3n irreversible o de alto riesgo, como la autorizaci\u00f3n de transferencias financieras o la eliminaci\u00f3n de datos de forma masiva.<\/p>\n

Aislamiento de la ejecuci\u00f3n y control del tr\u00e1fico.<\/strong> Ejecuta el c\u00f3digo y las herramientas en entornos segregados (contenedores o entornos aislados) con listas estrictas de herramientas y conexiones de red permitidas para evitar llamadas salientes no autorizadas.<\/p>\n

Cumplimiento de las directivas.<\/strong> Implementa puertas de intenci\u00f3n para examinar los planes y argumentos de un agente frente a reglas de seguridad r\u00edgidas antes de que se pongan en marcha.<\/p>\n

Validaci\u00f3n y desinfecci\u00f3n de entradas y salidas.<\/strong> Utiliza filtros especializados y esquemas de validaci\u00f3n para comprobar todos los mensajes y respuestas del modelo en busca de inyecciones y contenido malicioso. Esto se debe hacer en cada etapa del procesamiento de datos y siempre que se transfieran datos entre agentes.<\/p>\n

Registro seguro continuo.<\/strong> Registra todas las acciones de los agentes y los mensajes entre ellos en registros inmutables. Estos registros ser\u00e1n necesarios para cualquier auditor\u00eda e investigaci\u00f3n forense en el futuro.<\/p>\n

Agentes de vigilancia y supervisi\u00f3n del comportamiento.<\/strong> Implementa sistemas automatizados para detectar anomal\u00edas, como un aumento repentino de las llamadas a la API, intentos de autorreplicaci\u00f3n o un agente que se desv\u00eda repentinamente de sus objetivos principales. Este enfoque se superpone en gran medida con la supervisi\u00f3n necesaria para detectar ataques de red sofisticados que se aprovechan de los recursos locales. En consecuencia, las organizaciones que han introducido XDR<\/a> y est\u00e1n procesando telemetr\u00eda en un SIEM<\/a> tendr\u00e1n una ventaja inicial en este sentido, ya que les resultar\u00e1 mucho m\u00e1s f\u00e1cil mantener a raya a sus agentes de IA.<\/p>\n

Control de la cadena de suministro y SBOM (listas de materiales de software).<\/strong> Utiliza \u00fanicamente herramientas y modelos verificados de registros de confianza. Al momento de desarrollar software, firma cada componente, fija las versiones de las dependencias y vuelve a comprobar cada actualizaci\u00f3n.<\/p>\n

An\u00e1lisis est\u00e1tico y din\u00e1mico del c\u00f3digo generado.<\/strong> Analiza cada l\u00ednea de c\u00f3digo que escriba un agente en busca de vulnerabilidades antes de ejecutarlo. Proh\u00edbe por completo el uso de funciones peligrosas, como eval(). Estos dos \u00faltimos consejos ya deber\u00edan formar parte de un flujo de trabajo DevSecOps est\u00e1ndar, y deben ampliarse a todo el c\u00f3digo escrito por los agentes de IA. Hacerlo manualmente es casi imposible, por lo que se recomienda utilizar herramientas de automatizaci\u00f3n, como las que se encuentran en Kaspersky Cloud Workload Security.<\/p>\n

Protecci\u00f3n de las comunicaciones entre agentes.<\/strong> Garantiza la autenticaci\u00f3n mutua y el cifrado en todos los canales de comunicaci\u00f3n entre agentes. Utiliza firmas digitales para verificar la integridad de los mensajes.<\/p>\n

\u00a0Interruptores de emergencia.<\/strong> Encuentra formas de bloquear instant\u00e1neamente los agentes o las herramientas espec\u00edficas en el momento en que se detecte un comportamiento an\u00f3malo.<\/p>\n

Uso de la interfaz de usuario para calibrar la confianza.<\/strong> Utiliza indicadores visuales de riesgo y alertas de nivel de confianza para reducir el riesgo de que los humanos conf\u00eden ciegamente en la IA.<\/p>\n

Formaci\u00f3n de usuarios.<\/strong> Forma sistem\u00e1ticamente a los empleados sobre las realidades operativas de los sistemas basados en IA. Utiliza ejemplos adaptados a sus funciones laborales reales para analizar los riesgos espec\u00edficos de la IA. Debido a la rapidez con la que avanza este campo, un v\u00eddeo de cumplimiento normativo una vez al a\u00f1o no es suficiente: la formaci\u00f3n debe actualizarse varias veces al a\u00f1o.<\/p>\n

Para los analistas del SOC, tambi\u00e9n recomendamos el curso Kaspersky Expert Training: Seguridad frente a los modelos de lenguaje grandes,<\/a> que abarca las principales amenazas para los LLM y las estrategias de defensa para contrarrestarlas. El curso tambi\u00e9n puede ser \u00fatil para desarrolladores y arquitectos de IA que trabajan en implementaciones de LLM.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Los 10 principales riesgos que conllevan la implementaci\u00f3n de agentes de IA aut\u00f3nomos y nuestras recomendaciones para su mitigaci\u00f3n.<\/p>\n","protected":false},"author":2722,"featured_media":28937,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2795,3539],"tags":[2797,2018,1861,6051],"class_list":{"0":"post-28936","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-aprendizaje-automatico","10":"tag-ia","11":"tag-inteligencia-artificial","12":"tag-llm"},"hreflang":[{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/28936\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/top-agentic-ai-risks-2026\/30110\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/25171\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/13142\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/top-agentic-ai-risks-2026\/29988\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/top-agentic-ai-risks-2026\/31801\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/top-agentic-ai-risks-2026\/30419\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/top-agentic-ai-risks-2026\/41213\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/top-agentic-ai-risks-2026\/14222\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/55184\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/top-agentic-ai-risks-2026\/23537\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/top-agentic-ai-risks-2026\/24687\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/top-agentic-ai-risks-2026\/33133\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/top-agentic-ai-risks-2026\/30201\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/top-agentic-ai-risks-2026\/35872\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/top-agentic-ai-risks-2026\/35527\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/latam.kaspersky.com\/blog\/tag\/inteligencia-artificial\/","name":"inteligencia artificial"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=28936"}],"version-history":[{"count":2,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28936\/revisions"}],"predecessor-version":[{"id":28941,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/28936\/revisions\/28941"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/28937"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=28936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=28936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=28936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}