{"id":32564,"date":"2026-11-06T13:54:22","date_gmt":"2026-11-06T11:54:22","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=32564"},"modified":"2026-11-06T14:09:54","modified_gmt":"2026-11-06T12:09:54","slug":"adopting-cyberimmunity-for-ai-agent-design-rollout","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/32564\/","title":{"rendered":"Lecciones de ciberinmunidad para agentes de IA"},"content":{"rendered":"

Los sistemas de IA son mucho m\u00e1s dif\u00edciles de proteger que los sistemas inform\u00e1ticos tradicionales, ya sea por errores de los operadores, interferencias maliciosas o simplemente por un comportamiento inestable. Esto se debe a dos motivos principales. En primer lugar, los resultados de la IA son probabil\u00edsticos<\/a>, por lo que una misma instrucci\u00f3n puede generar respuestas distintas cada vez que se ejecuta. En segundo lugar, los LLM actuales no pueden distinguir de forma fiable entre \u00f3rdenes y datos<\/a>. A pesar de los problemas de seguridad demostrados de los sistemas de IA<\/a> de los que hemos hablado tantas veces, resulta imposible ignorar los posibles beneficios econ\u00f3micos que supone su adopci\u00f3n. Por eso, muchas empresas est\u00e1n pasando de los simples asistentes de IA a los agentes de IA. Estos agentes realizan tareas por su cuenta y tienen acceso directo a las mismas herramientas que las personas, desde consultar bases de datos hasta modificar la configuraci\u00f3n de los procesos de producci\u00f3n. Nuestros expertos, en su nuevo estudio<\/a>, analizan c\u00f3mo definir claramente y minimizar los riesgos derivados para reducir al m\u00ednimo los posibles problemas. Este enfoque toma prestados y adapta los principios de \u201cciberinmunidad\u201d y \u201cseguridad desde el dise\u00f1o\u201d (Secure by Design).<\/p>\n

Los principios b\u00e1sicos de la seguridad desde el dise\u00f1o<\/h2>\n

Todos los principios de esta disciplina son de aplicaci\u00f3n universal al dise\u00f1o de cualquier sistema inform\u00e1tico, incluidos los agentes de IA. Lo que difiere es el grado de adaptaci\u00f3n y revisi\u00f3n que requiere cada principio para los escenarios de IA.<\/p>\n

    \n
  1. La seguridad es un factor independiente e importante desde la propia fase de dise\u00f1o. Los objetivos y supuestos de seguridad se establecen desde el primer d\u00eda y se respetan a lo largo de todas las fases del desarrollo. En el caso de los agentes de IA, estos supuestos deben incluir tres puntos clave: (i) el modelo de lenguaje se considera no fiable, (ii) los datos externos de cualquier tipo se consideran potencialmente maliciosos y (iii) no se pueden realizar acciones irreversibles de forma aut\u00f3noma sin la aprobaci\u00f3n obligatoria de un ser humano.<\/li>\n
  2. El sistema se dise\u00f1a partiendo del supuesto de que sufrir\u00e1 ataques.<\/li>\n
  3. La base inform\u00e1tica de confianza y la superficie de ataque se reducen al m\u00ednimo. Los agentes solo disponen de las herramientas que realmente necesitan, permisos limitados y la menor cantidad de contexto posible. La aplicaci\u00f3n de la pol\u00edtica de seguridad se gestiona \u00edntegramente mediante componentes determin\u00edsticos: el supervisor de pol\u00edticas, el arn\u00e9s del agente y los mecanismos de aislamiento (entornos aislados).<\/li>\n
  4. Se aplica el principio de privilegio m\u00ednimo. Cada agente tiene su propio conjunto de credenciales y privilegios de acceso (identidad), limitados al m\u00ednimo imprescindible para realizar su trabajo. Si un agente necesita temporalmente privilegios elevados, solo los obtiene tras recibir una autorizaci\u00f3n externa, y estos duran exactamente lo que dura la tarea que los requiere.<\/li>\n
  5. Los componentes est\u00e1n aislados. En los sistemas basados en agentes, este es uno de los problemas de arquitectura m\u00e1s complejos y con m\u00faltiples capas. El entorno de ejecuci\u00f3n del agente debe funcionar en un entorno con aislamiento (entorno aislado o m\u00e1quina virtual), y los agentes deben mantenerse lo m\u00e1s aislados posible entre s\u00ed. El procesamiento de datos en contextos de confianza y no fiables tambi\u00e9n se mantiene separado. Por ejemplo, un agente lee una solicitud de incorporaci\u00f3n de cambios y escribe un borrador del c\u00f3digo, mientras que otro revisa ese trabajo sin llegar a ver el texto potencialmente malicioso de la solicitud.<\/li>\n
  6. La regla predeterminada es la denegaci\u00f3n. Las pol\u00edticas de seguridad siguen la regla: todo lo que no est\u00e9 expl\u00edcitamente permitido est\u00e1 prohibido. Esto incluye las llamadas a herramientas, las interacciones entre agentes y el tr\u00e1fico de red.<\/li>\n
  7. Se aplica la defensa en profundidad. Las diferentes medidas deben funcionar al mismo tiempo y reforzarse entre s\u00ed. Las defensas probabil\u00edsticas, como los mecanismos de protecci\u00f3n de la IA (un \u201cfirewall\u201d para los modelos de lenguaje) o la alineaci\u00f3n (el criterio del propio modelo sobre lo que es aceptable y lo que no), no pueden ofrecer garant\u00edas formales de seguridad. No obstante, hacen que el sistema sea m\u00e1s seguro en su conjunto y constituyen una valiosa fuente de telemetr\u00eda.<\/li>\n
  8. La cadena de suministro est\u00e1 protegida. Algunos agentes pueden instalar habilidades, bibliotecas y otros componentes de software por su cuenta, por lo que estas capacidades deben regirse por normas estrictas. O bien se bloquean por completo, o bien se limitan a una lista cerrada y preaprobada de versiones espec\u00edficas de componentes concretos. Los sistemas basados en modelos de lenguaje grandes (LLM) en la nube se enfrentan a un riesgo adicional: las actualizaciones de los modelos. Un d\u00eda, la misma solicitud de API podr\u00eda ser respondida por un modelo de lenguaje diferente con propiedades de seguridad distintas.<\/li>\n<\/ol>\n

    Las trampas de la seguridad de la IA<\/h2>\n

    Los principios generales de la seguridad desde el dise\u00f1o son bien conocidos y parecen sencillos en teor\u00eda. Sin embargo, aplicarlos a los sistemas de IA es complicado porque los agentes son incre\u00edblemente flexibles. Por ejemplo, un equipo de seguridad podr\u00eda creer que un agente en el ordenador de un desarrollador se ejecuta en un entorno aislado y no puede modificar nada fuera de \u00e9l. Pero un atacante, o incluso el propio agente, puede idear decenas de formas de eludir esta protecci\u00f3n aparentemente s\u00f3lida: desde ejecutar comandos a trav\u00e9s de un servidor MCP local que no est\u00e1 sujeto a las restricciones del entorno aislado hasta reconfigurar otro agente de IA<\/a> instalado en el sistema. Para complicar a\u00fan m\u00e1s las cosas, la variedad de vectores de ataque es enorme: desde campos arbitrarios en la configuraci\u00f3n del agente<\/a> hasta cadenas de texto aparentemente inofensivas en un archivo de habilidades<\/a>.<\/p>\n

    Un problema grave que los dise\u00f1adores suelen subestimar es la fatiga del usuario. Un agente muy activo puede generar docenas de solicitudes cada minuto, pidiendo al usuario que confirme acciones potencialmente peligrosas. En menos de una hora, la persona est\u00e1 haciendo clic en Aprobar<\/em> de forma autom\u00e1tica<\/a> sin leer lo que est\u00e1 aprobando. Por eso es importante ajustar cuidadosamente tanto la frecuencia con la que aparecen estas solicitudes como la forma en que est\u00e1n redactadas. Nadie leer\u00e1 una descripci\u00f3n de la solicitud que sea demasiado larga. Y una demasiado corta puede ocultar los detalles clave<\/a> que el usuario necesita para tomar la decisi\u00f3n correcta.<\/p>\n

    Las vulnerabilidades en los agentes y las herramientas relacionadas son un problema preocupante, y se ve agravado por la rapidez con la que estas categor\u00edas de software evolucionan y reciben actualizaciones. En plataformas y aplicaciones de uso habitual en el sector, como LangGraph<\/a>, MS Semantic Kernel<\/a> y Claude Code<\/a>, se han corregido vulnerabilidades cr\u00edticas en m\u00e1s de una ocasi\u00f3n. Los arquitectos siempre deber\u00edan plantearse sustituir un marco de trabajo grande y polivalente por un sistema compacto y simplificado que cuente \u00fanicamente con las funciones que un agente espec\u00edfico realmente necesita.<\/p>\n

    Adem\u00e1s, la implementaci\u00f3n cuidadosa de medidas de seguridad est\u00e1ndar y consolidadas en las herramientas disponibles reduce en gran medida el da\u00f1o si un agente sufre un ataque o se comporta de forma inesperada. Un ejemplo es una lista de dominios permitidos estricta que la herramienta de recuperaci\u00f3n web puede abrir cuando el agente lo solicite. Sin embargo, los dise\u00f1adores rara vez tienen en cuenta los problemas ocultos y la sobrecarga asociados al mantenimiento de dicha lista. Como resultado, la lista queda obsoleta poco a poco y deja brechas para los atacantes. El ejemplo m\u00e1s llamativo es el ataque EchoLeak<\/a>. Microsoft 365 Copilot contaba con una lista de sitios permitidos correctamente implementada y bastante eficaz para acceder a sitios externos, pero los atacantes la eludieron a trav\u00e9s de una funci\u00f3n de una herramienta secundaria y del dominio de MS Teams.<\/p>\n

    Consejos pr\u00e1cticos para arquitectos y equipos de seguridad<\/h2>\n

    Los arquitectos de sistemas de IA y los responsables de los equipos de ingenier\u00eda y seguridad deben integrar la seguridad de los agentes desde la fase de dise\u00f1o. Deben basarse principalmente en mecanismos verificables y deterministas: aislar componentes, controlar las interacciones y reducir al m\u00ednimo la base inform\u00e1tica de confianza.<\/p>\n

    Entre las decisiones arquitect\u00f3nicas clave se incluyen definir el nivel de autonom\u00eda aceptable para los agentes, limitar el acceso a datos confidenciales y a combinaciones peligrosas de capacidades, y utilizar entornos aislados, roles separados para los distintos modelos y puertas de enlace de control de acceso. Las restricciones a\u00f1adidas posteriormente reducen los riesgos, pero no sustituyen a una arquitectura segura.<\/p>\n

    A nivel organizativo y operativo, las empresas deben llevar un inventario de sus agentes, coordinar los esfuerzos de los equipos de seguridad y de implementaci\u00f3n, proteger los entornos de contenedores, gestionar la cadena de suministro (AIBOM) e integrar una defensa multicapa.<\/p>\n

    La observabilidad requiere especial atenci\u00f3n. En el caso de los sistemas de IA, esto deber\u00eda incluir el registro de las solicitudes, respuestas y razonamientos del LLM, as\u00ed como telemetr\u00eda detallada de los hosts y los entornos en la nube donde se ejecuta el agente.<\/p>\n

    La parte m\u00e1s dif\u00edcil del dise\u00f1o de agentes es encontrar el equilibrio entre seguridad, rendimiento y utilidad. Para saber c\u00f3mo lograr ese equilibrio mediante el modelado de amenazas y unos objetivos de seguridad claramente definidos, lee la versi\u00f3n completa del estudio<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

    C\u00f3mo aplicar los principios de seguridad desde el dise\u00f1o al implementar agentes de IA.<\/p>\n","protected":false},"author":2706,"featured_media":32565,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754,2755],"tags":[2093,1307,3725,61],"class_list":["post-32564","post","type-post","status-publish","format-standard","has-post-thumbnail","category-business","category-enterprise","category-smb","tag-aprendizaje-automatico","tag-ia","tag-llm","tag-seguridad"],"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/32564\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/31180\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/26212\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/31022\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/42919\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/56619\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/adopting-cyberimmunity-for-ai-agent-design-rollout\/31176\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/36921\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/adopting-cyberimmunity-for-ai-agent-design-rollout\/36592\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/ia\/","name":"IA"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32564","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2706"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=32564"}],"version-history":[{"count":6,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32564\/revisions"}],"predecessor-version":[{"id":32572,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/32564\/revisions\/32572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/32565"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=32564"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=32564"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=32564"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}