Las empresas no ven dos tercios de su superficie de ataque de IA, advierte Snyk
Snyk ha puesto una cifra contundente al riesgo de la IA empresarial: casi dos tercios de la superficie de ataque relevante pueden quedar fuera de la visión directa de los equipos de seguridad. La advertencia, difundida a través de Google News, se centra en agentes, plugins, conjuntos de datos y canalizaciones de datos conectados a lo largo del trabajo diario. Estos componentes se multiplican a medida que las empresas llevan los experimentos de IA a producción.
La cifra procede de Snyk, no de una auditoría independiente de todo el mercado empresarial. Su análisis de respaldo utiliza información anonimizada de más de 500 entornos empresariales asociados con Snyk Evo. Esta distinción importa. Los datos ofrecen una visión de los entornos participantes, mientras que la afirmación más amplia aún requiere validación en otras plataformas e industrias.
Incluso con esa salvedad, Snyk describe un problema que va más allá de la telemetría de un solo proveedor. Una investigación de Cloud Security Alliance concluyó que el 68% de las organizaciones encuestadas no podía distinguir claramente las acciones de los agentes de IA de la actividad humana. Por separado, OWASP ha documentado la inyección de prompts, los permisos excesivos y la autonomía no controlada como riesgos materiales para las aplicaciones.
Por tanto, el conflicto central no es la adopción de IA frente a la resistencia. Es el despliegue rápido y descentralizado frente a sistemas de seguridad construidos alrededor de aplicaciones conocidas, identidades humanas e inventarios estables. Las empresas están autorizando a más software a razonar y actuar, mientras pierden confianza sobre qué está conectado a sus datos.
Esta brecha presiona a los equipos de seguridad, pero también afecta a desarrolladores, ingenieros de plataforma, responsables de compras y propietarios de negocio. Cada grupo puede introducir una dependencia de IA. Pocas organizaciones cuentan con un sistema capaz de mapear la cadena resultante desde el modelo hasta el plugin, la identidad, el conjunto de datos, la API y la acción en producción.
Por qué la advertencia de Snyk llegó a Google News
La afirmación más importante de Snyk no es que la IA cree nuevas vulnerabilidades. Es que las empresas no pueden ver de forma fiable los sistemas que las crean.
Snyk presentó su AI Security Fabric en febrero de 2026 como una capa que abarca el desarrollo de software y los sistemas agénticos. La empresa afirmó que su enfoque combinaría visibilidad, prevención y gobernanza a lo largo del ciclo de vida de desarrollo de software.
Ese anuncio de producto incluyó hallazgos de la investigación 2026 State of Agentic AI Adoption de Snyk. Según la empresa, su análisis abarcó información anonimizada de más de 500 entornos empresariales Evo. Snyk indicó que cada modelo de IA desplegado estaba asociado con casi tres veces más componentes ocultos, incluidos conjuntos de datos y herramientas de terceros.
La afirmación principal lleva esa observación más allá. Snyk sostiene que aproximadamente dos tercios del riesgo de IA empresarial se encuentran por debajo de la capa de modelos más visible. La parte oculta incluye herramientas de agentes, plugins, repositorios conectados, servicios externos y canalizaciones de datos que los empleados conectan durante el desarrollo o el trabajo diario.
Estos componentes no son automáticamente maliciosos. Un plugin puede simplemente recuperar un documento, llamar a una API interna o enviar un mensaje aprobado. El problema de seguridad surge de la relación entre el componente, sus permisos, sus fuentes de entrada y su capacidad para activar acciones posteriores.
Un inventario de modelos por sí solo no puede capturar esas relaciones. Dos equipos podrían usar el mismo modelo a través de agentes diferentes con perfiles de riesgo completamente distintos. Un agente puede resumir documentos públicos. Otro puede leer código fuente, consultar registros de clientes y escribir cambios en sistemas de producción.
Por eso la historia merece más que una advertencia conocida sobre empleados que usan chatbots no aprobados. La IA en la sombra ahora incluye funciones integradas en software aprobado, modelos desplegados localmente, marcos de agentes, extensiones de navegador, servicios de automatización e identidades de máquina. Algunos llegan mediante procesos formales de compra. Otros aparecen cuando un empleado conecta una herramienta más para terminar una tarea.
Google News da a esta afirmación un canal de distribución amplio, pero la agregación no valida la cifra subyacente. Los lectores deberían tratar la estimación de dos tercios como un hallazgo de proveedor extraído de los datos de entornos relacionados con clientes de Snyk. La conclusión más sólida se apoya en evidencia corroborante: las empresas tienen dificultades para inventariar el comportamiento de los agentes, los permisos y las dependencias de componentes.
Esa distinción evita que el análisis se convierta en marketing de producto. La estimación precisa de Snyk para todo el mercado sigue abierta a comprobación. El problema de visibilidad ya cuenta con respaldo de múltiples fuentes independientes y orientadas a estándares.
La superficie de ataque de IA ya no es una lista de aplicaciones
La superficie de ataque práctica ahora se comporta como un grafo cambiante, donde los modelos, las identidades, las herramientas y los almacenes de datos generan riesgo a través de sus conexiones.
La seguridad tradicional de aplicaciones parte de un objeto relativamente estable. Un equipo es propietario de una aplicación, mantiene su repositorio, rastrea dependencias y la despliega mediante infraestructura conocida. Las herramientas de seguridad pueden analizar el código, los paquetes, las imágenes de contenedores, la configuración de la nube y los endpoints expuestos.
Los sistemas nativos de IA añaden más piezas móviles. El análisis de Snyk sobre aplicaciones nativas de IA describe una cadena de suministro que puede incluir modelos preentrenados, embeddings, agentes de terceros, conjuntos de datos y servicios externos. Cada componente puede cambiar independientemente del código fuente de la aplicación.
Un embedding es una representación numérica utilizada para comparar el significado del contenido. Una base de datos vectorial puede almacenar millones de estas representaciones para su recuperación. Si los permisos o las etiquetas de origen son incorrectos, un agente puede recuperar información a la que su usuario nunca debió tener acceso.
La generación aumentada por recuperación, a menudo abreviada como RAG, proporciona a un modelo documentos o registros seleccionados antes de que produzca una respuesta. RAG puede mejorar la precisión, pero también crea otro límite de confianza. La capa de recuperación debe decidir qué fuentes puede buscar el agente y qué contenido debería devolver.
Las herramientas crean un límite más trascendental. Un agente conectado al correo electrónico, al control de código fuente, a la infraestructura en la nube o a una base de datos de clientes puede ir más allá de producir texto. Puede leer, escribir, ejecutar, aprobar o transmitir información, según los permisos que le hayan otorgado los desarrolladores.
Esto crea un desajuste con los inventarios de seguridad organizados alrededor de aplicaciones adquiridas. Una empresa puede haber aprobado el proveedor de modelos y el marco de agentes. Aun así, puede carecer de un registro completo de cada endpoint de herramienta, cuenta de servicio, conjunto de datos, plantilla de prompt o plugin conectado después del despliegue.
La cadena también puede cambiar sin una versión tradicional. Un proveedor de modelos puede actualizar su comportamiento. Una herramienta de terceros puede añadir una función. Un conjunto de datos puede recibir documentos nuevos. Un usuario puede ampliar un alcance de OAuth, que determina a qué puede acceder una aplicación mediante autorización delegada.
Estos cambios importan porque el riesgo depende de combinaciones. Un agente de resumen con acceso de solo lectura tiene un radio de impacto limitado. Otorgue a ese mismo agente permiso para enviar correo electrónico, editar archivos y llamar a un endpoint web sin restricciones, y una entrada manipulada puede producir un resultado muy diferente.
Por tanto, la superficie de ataque incluye más que vulnerabilidades en el código. Incluye permisos excesivos, contexto envenenado, credenciales expuestas, manejo inseguro de salidas, reglas de aprobación débiles y registros de acciones incompletos. Varios de estos problemas siguen siendo invisibles para los escáneres que solo inspeccionan archivos fuente o paquetes de software conocidos.
Para los equipos de ingeniería, la documentación se convierte en parte del sistema de control. Un registro consultable de decisiones de arquitectura, herramientas aprobadas, alcances de permisos y hallazgos de incidentes ayuda a los equipos a identificar relaciones que los paneles individuales no detectan. Una base de conocimiento de ingeniería estructurada puede respaldar ese trabajo, aunque no sustituye la monitorización de seguridad.
La lección más amplia es sencilla. Un sistema de IA no puede gobernarse como un único endpoint de modelo. Debe tratarse como una aplicación conectada cuyos datos, herramientas, identidades y acciones permanezcan visibles durante toda su operación.
La IA agéntica somete a presión los controles de identidad
El punto ciego de crecimiento más rápido se encuentra donde el software autónomo hereda permisos diseñados para usuarios humanos.
Cloud Security Alliance publicó una investigación sobre identidad de agentes en marzo de 2026. Su encuesta concluyó que el 73% de las organizaciones esperaba que los agentes de IA se volvieran vitales durante el año siguiente. Sin embargo, el 68% no podía distinguir claramente las acciones realizadas por agentes de las realizadas por personas.
La similitud entre esa cifra del 68% y la advertencia de aproximadamente dos tercios de Snyk es llamativa, pero las cifras miden cosas diferentes. Snyk analiza componentes ocultos y riesgo en entornos de IA. La encuesta de Cloud Security Alliance examina la atribución de identidad y la gestión de acceso.
En conjunto, revelan la misma debilidad estructural. Las organizaciones están dando acceso a sistemas empresariales a identidades de software más rápido de lo que actualizan sus prácticas de autenticación, autorización y monitorización.
Una identidad de máquina es una credencial utilizada por software en lugar de una persona. Puede adoptar la forma de una clave de API, cuenta de servicio, certificado, identidad de carga de trabajo o token OAuth. Los agentes dependen de estas credenciales para acceder a datos y realizar acciones.
Los sistemas de identidad humana suelen asumir que una persona inicia sesión, recibe un rol definido y genera actividad vinculada a esa cuenta. Los agentes complican este modelo. Un agente puede actuar para varios usuarios, llamar a varias herramientas y crear una cadena de operaciones generadas por máquinas en cuestión de segundos.
La atribución se vuelve especialmente difícil cuando un agente utiliza una cuenta de servicio compartida. Los registros pueden mostrar que la cuenta modificó un registro o descargó un archivo. Es posible que no identifiquen la solicitud del empleado, la decisión del modelo, el documento recuperado o la llamada al plugin que provocó la acción.
No se trata simplemente de una incomodidad de auditoría. La atribución débil dificulta la contención de incidentes. Un equipo de seguridad no puede revocar con confianza la credencial correcta si no sabe qué agente, usuario o flujo de trabajo inició una actividad sospechosa.
El acceso con privilegios excesivos aumenta el daño. Una herramienta creada solo para resumir mensajes puede recibir permiso para enviarlos o eliminarlos. Un asistente de código puede obtener acceso de escritura a múltiples repositorios cuando solo necesita revisar un proyecto.
OWASP describe esta condición como autonomía excesiva. Su guía identifica la funcionalidad, los permisos y la autonomía excesivos como causas raíz. OWASP recomienda limitar las herramientas disponibles, restringir los permisos, ejecutar acciones en el contexto del usuario y exigir aprobación para operaciones de alto impacto.
Estos controles se asemejan a prácticas maduras de confianza cero. Cada solicitud debe evaluarse mediante una identidad específica, una autorización definida y el contexto actual. El modelo no debería decidir por sí solo si una operación está permitida.
El agente también necesita una identidad distinta de la de su operador humano. Los registros deben preservar la relación entre la solicitud del usuario, la instancia del agente, la herramienta seleccionada, la credencial utilizada y la acción resultante. Sin esa cadena, las empresas pueden recopilar enormes volúmenes de telemetría y aun así seguir sin visibilidad.
Aquí es donde la adopción de IA ejerce presión sobre la arquitectura de seguridad. Los equipos de negocio quieren asistentes que eliminen aprobaciones repetitivas y completen tareas de varios pasos. Los equipos de seguridad necesitan puntos de control, permisos acotados y decisiones reconstruibles. Eliminar todos los puntos de control aumenta la velocidad, pero también amplía el posible radio de impacto de una acción incorrecta o manipulada.
El conflicto no se resolverá eligiendo autonomía total o prohibiendo los agentes. Las empresas necesitan distintos niveles de autonomía según las consecuencias. La redacción de un resumen puede seguir siendo automática. Enviar fondos, eliminar registros, modificar infraestructura de producción o divulgar datos protegidos debe requerir controles más sólidos.
La verdadera disyuntiva es velocidad frente a control verificable
Las empresas obtienen valor cuando los agentes cruzan límites entre sistemas, pero cada conexión adicional dificulta verificar el comportamiento.
La IA agéntica resulta atractiva para las empresas porque puede conectar pasos separados en un único flujo de trabajo. Un agente de soporte podría leer un ticket, recuperar el historial de una cuenta, clasificar la urgencia, proponer una respuesta y actualizar el registro del cliente. Esa secuencia puede reducir la coordinación manual.
La misma secuencia contiene varios límites de seguridad. El ticket puede incluir texto no confiable. El historial de la cuenta puede contener datos protegidos. El modelo puede generar una instrucción de herramienta insegura. El sistema del cliente puede aceptar una actualización con consecuencias duraderas.
La inyección de prompts hace concreta esta disyuntiva. La inyección de prompts ocurre cuando contenido diseñado de forma maliciosa cambia la manera en que un modelo sigue instrucciones. El contenido puede provenir directamente de un usuario o indirectamente de una página web, documento, correo electrónico, repositorio o registro recuperado.
Una aplicación convencional separa los comandos de los datos mediante sintaxis estricta y controles de acceso. Los modelos de lenguaje procesan ambos como tokens dentro del contexto. Ese diseño dificulta garantizar que un modelo siempre trate el texto externo como datos no confiables en lugar de como una instrucción.
La guía actual de OWASP afirma que no se conoce ningún método infalible para prevenir la inyección de prompts. Recomienda restringir el comportamiento, validar los formatos de salida esperados, filtrar entradas y salidas, y limitar los permisos disponibles para el modelo.
Estas mitigaciones reducen el impacto, pero no crean certeza. Un agente que solo puede leer una colección limitada de documentos representa menos peligro que uno capaz de ejecutar comandos de shell. Un paso de aprobación humana puede detectar acciones sospechosas, pero solo si la persona revisora recibe suficiente contexto para tomar una decisión informada.
La velocidad presiona cada salvaguarda. Los equipos pueden conceder acceso amplio para evitar trabajo repetido de integración. Pueden usar credenciales compartidas porque la autorización por usuario tarda más en implementarse. Pueden suprimir avisos de aprobación después de que los usuarios se quejen de la fricción.
Eso convierte la cuestión central en una disyuntiva entre velocidad de despliegue y control verificable. Snyk sostiene que la seguridad debe volverse continua porque los sistemas de IA cambian demasiado rápido para revisiones ocasionales. El interés comercial de la empresa es evidente, ya que vende productos posicionados en torno a ese requisito.
Por ello, los compradores deben separar el diagnóstico de la plataforma propuesta. Una capa de seguridad unificada podría mejorar la visibilidad, pero ningún proveedor ha demostrado que un solo producto pueda observar todos los modelos, despliegues locales, herramientas de navegador, conjuntos de datos, identidades e integraciones externas de una gran empresa.
Las afirmaciones de cobertura dependen de las integraciones y la telemetría. Un modelo en la nube aprobado puede ser fácil de detectar. Un modelo alojado localmente en la estación de trabajo de un desarrollador puede no serlo. Una función de IA dentro de un paquete de software conocido puede generar actividad que parezca tráfico normal de aplicaciones.
Las conexiones cifradas y las normas de privacidad introducen límites adicionales. Supervisar prompts o documentos recuperados puede exponer datos sensibles de empleados y clientes. Los equipos de seguridad necesitan suficiente contexto para detectar usos indebidos sin crear un segundo repositorio de información confidencial.
Las normas regionales sobre datos añaden otra restricción. Una empresa multinacional puede no ser capaz de centralizar todos los registros de interacción con IA. Puede necesitar procesamiento local, metadatos selectivos, controles de retención y diferentes políticas de supervisión para distintas jurisdicciones.
Estas complicaciones no invalidan la advertencia de Snyk. Refuerzan su punto central al tiempo que cuestionan cualquier solución simple. La visibilidad es necesaria, pero la propia visibilidad genera costos de diseño, privacidad y operación.
Lo que la afirmación de dos tercios no demuestra
Los datos de Snyk señalan una grave brecha de gobernanza, pero no establecen que dos tercios de cada entorno empresarial estén comprometidos o sean explotables.
La limitación más importante es el muestreo. Snyk describe hallazgos anonimizados de más de 500 entornos empresariales Evo. Las organizaciones que utilizan ese entorno pueden diferir del mercado más amplio en tamaño, prácticas de software, madurez de IA o prioridades de seguridad.
La empresa no ha establecido públicamente que su muestra represente a todas las industrias o regiones geográficas. También tiene un motivo comercial para definir el problema en términos que favorezcan una cobertura de seguridad más amplia. Ninguna de las dos cuestiones hace que los datos sean falsos, pero ambas requieren una atribución cuidadosa.
El “riesgo” también es más amplio que la “vulnerabilidad”. Un componente oculto puede no estar gestionado o inventariado de forma insuficiente sin contener una falla explotable. Se vuelve peligroso cuando se combina con permisos débiles, datos sensibles, entradas inseguras o la capacidad de realizar acciones relevantes.
Del mismo modo, “dos tercios” no significa que los equipos de seguridad vean exactamente un tercio de cada entorno. La estimación resume patrones en los entornos observados. Las organizaciones individuales pueden tener una cobertura mucho mejor o peor.
La expresión “superficie de ataque” puede además difuminar problemas distintos. Puede incluir activos expuestos a internet, API internas, dependencias de software, herramientas de agentes, flujos de datos, identidades y comportamiento de modelos. Los distintos proveedores contabilizan estos elementos de forma diferente.
La medición independiente requerirá definiciones compartidas. Los investigadores deben distinguir los activos conocidos de los desconocidos, los componentes accesibles de los inactivos y la exposición teórica de las rutas de ataque demostradas. Sin esas distinciones, los grandes porcentajes atraen atención pero ofrecen una orientación operativa limitada.
NIST proporciona una base más neutral mediante su Marco de Riesgos de IA. El marco organiza el trabajo en torno a gobernar, mapear, medir y gestionar los riesgos de IA. También enfatiza que la gestión de riesgos debe continuar durante todo el ciclo de vida del sistema.
El mapeo es especialmente relevante para la afirmación de Snyk. Una organización debe identificar el modelo, la tarea prevista, los usuarios, los datos, las dependencias, el contexto de despliegue y las partes afectadas antes de poder medir el riesgo. Un escáner no puede recuperar cada política o decisión de propiedad ausente.
La medición también necesita pruebas. Una empresa puede documentar los permisos previstos de un agente, pero nunca verificar sus permisos efectivos en producción. Puede registrar herramientas aprobadas y pasar por alto funciones añadidas mediante una integración actualizada.
Por tanto, la postura escéptica no sostiene que el punto ciego sea imaginario. Sostiene que la telemetría de un proveedor todavía no puede definir su tamaño exacto en todo el mercado. El titular debe motivar el inventario y las pruebas, no convertirse en un sustituto de ambos.
Los responsables de seguridad deben preguntar a los proveedores cómo calculan la cobertura. Deben solicitar el denominador, los métodos de detección, los entornos excluidos, la frecuencia de actualización y el proceso para resolver activos duplicados u obsoletos. Un porcentaje preciso sin ese contexto puede generar una falsa confianza.
También deben medir los resultados. Encontrar más componentes solo es útil si la organización puede priorizar relaciones peligrosas, asignar responsables, reducir permisos y corregir rutas verificadas. Un inventario mayor que produce una cola de alertas inmanejable puede convertirse en otra forma de ceguera.
Tres señales mostrarán si el punto ciego se está cerrando
La próxima fase se medirá mediante atribución de identidad, inventarios de componentes y reducciones verificadas de permisos peligrosos de los agentes.
La primera señal es si las empresas pueden separar la actividad de los agentes de la actividad humana en sus registros. El hallazgo del 68% de Cloud Security Alliance proporciona una referencia clara, aunque proceda de una encuesta y no de telemetría directa.
La mejora significaría que cada acción relevante incluye una identidad de agente, delegación de usuario, nombre de herramienta, contexto de autorización y resultado rastreable. Si encuestas posteriores muestran menos organizaciones con dificultades de atribución, se fortalecerá el argumento a favor de una gobernanza de agentes manejable.
Si la cifra se mantiene cerca de dos tercios, la conclusión opuesta se impone. Las empresas habrán desplegado más flujos de trabajo autónomos sin resolver la rendición de cuentas básica. Ese resultado reforzaría la advertencia de Snyk de que la brecha de visibilidad crece con la adopción.
La segunda señal es la aparición de listas de materiales de IA consistentes. Una lista de materiales de IA registra los modelos, conjuntos de datos, prompts, marcos de trabajo, herramientas, servicios y dependencias utilizados por un sistema. Extiende el concepto de lista de materiales de software a componentes específicos de IA.
La versión útil debe permanecer sincronizada con el despliegue. Un documento estático creado durante la adquisición no incluirá las herramientas y conjuntos de datos conectados posteriormente. El descubrimiento automatizado, la asignación de responsables, el historial de versiones y la evidencia de permisos efectivos importan más que simplemente producir una lista.
La adopción amplia de formatos interoperables de inventario reforzaría el argumento de que las empresas pueden recuperar la visibilidad. La dependencia continua de paneles específicos de cada proveedor dejaría puntos ciegos entre productos de seguridad, plataformas en la nube y entornos locales.
La tercera señal es si las organizaciones reducen la agencia excesiva en producción. Los equipos de seguridad deben rastrear cuántos agentes pueden escribir datos, ejecutar código, enviar comunicaciones, modificar infraestructura o acceder a repositorios sensibles sin una aprobación independiente.
Una cifra decreciente demostraría que las empresas están traduciendo la gobernanza de IA en controles técnicos. Una cifra creciente indicaría que los objetivos de productividad siguen prevaleciendo sobre la contención. Los informes de incidentes que involucren agentes con privilegios excesivos harían que esta métrica fuera especialmente urgente.
Estas señales importan más que el volumen de políticas de IA publicadas por las empresas. Las políticas describen la intención. Las identidades, los inventarios, los permisos y los registros revelan la realidad operativa.
El titular de Snyk en Google News tiene éxito porque condensa esa realidad en una advertencia memorable. La cifra exacta de dos tercios sigue siendo una estimación derivada de un proveedor, pero la discrepancia subyacente es difícil de descartar. Los componentes de IA se multiplican más rápido de lo que muchas organizaciones pueden descubrir, clasificar y gobernar.
Para los desarrolladores, la pregunta inmediata es si cada conexión de agente tiene un responsable identificado y un permiso necesario. Para los equipos de seguridad, es si los registros pueden reconstruir una acción desde la solicitud del usuario, pasando por la decisión del modelo, hasta el resultado posterior. Los compradores empresariales deben exigir evidencia de ambos aspectos.
El próximo trimestre ofrece una prueba práctica. Elija un agente de producción, mapee cada modelo, herramienta, identidad, conjunto de datos y llamada externa, y luego compare ese mapa con los registros de seguridad existentes. Si ambas vistas difieren de forma marcada, el punto ciego ya está dentro de la organización. Si coinciden, pruebe si los permisos y controles de aprobación se comportan como se documenta. Google News proporcionó la advertencia; ahora la telemetría empresarial debe proporcionar la respuesta.
