Los equipos de seguridad vigilan la IA que eligieron, pero los proveedores lanzan agentes que no eligieron

Artículo de opinión sostiene que la seguridad de IA omite agentes de proveedores y propone revisar identidad, permisos, conectividad y actividad.

Los equipos de seguridad vigilan la IA que eligieron, pero los proveedores lanzan agentes que no eligieron
IA

Imagen ilustrativa generada con IA

Un análisis publicado por The Hacker News sostiene que la mayor parte de la seguridad de la IA en las empresas apunta al objetivo equivocado. El artículo, contribuido por un socio y con material promocional, afirma que los controles diseñados para la IA que una empresa adoptó deliberadamente no alcanzan a los agentes que llegan dentro del software que ya utiliza. Es un artículo de opinión. No describe una brecha de seguridad, una vulnerabilidad ni una acción de cumplimiento normativo.

Tres formas en que un agente entra en la empresa

El autor clasifica los agentes según cómo llegan:

  • Heredados: incluidos en una plataforma existente mediante una actualización rutinaria del producto.
  • Configurados: creados a partir de los propios indicaciones y lógica de la empresa, pero ejecutándose sobre el entorno de ejecución, el modelo y los conectores de un proveedor.
  • Desarrollados: ensamblados con marcos de código abierto sobre una infraestructura que la empresa posee.

Según el autor, los dos primeros constituyen la «abrumadora mayoría» de la adopción y crecen «exponencialmente». Los agentes desarrollados se describen como el grupo más pequeño y de crecimiento más lento. El artículo no ofrece ninguna medición que respalde estas caracterizaciones.

La consecuencia, según el relato del autor, es que nadie decide adoptar un agente heredado. Aparece con una actualización, así que la revisión que normalmente precede a un nuevo despliegue de IA nunca tiene lugar.

Una cifra de un informe sin nombre

El artículo cita el «2026 State of Agent Security Report», que no vincula a ninguna editorial ni describe en términos de método o de muestra. Según ese informe, unos 1.280 productos de terceros en los entornos estudiados incorporan IA. Unos 282 de ellos están detrás de un inicio de sesión único (SSO).

El autor interpreta la brecha como si dejara «los otros mil» invisibles por defecto para la infraestructura de identidad. Son recuentos de productos, no de agentes ni de personas. Los demás ejemplos de escala del artículo, como cincuenta, quinientos y cinco mil agentes, son ilustraciones, no datos.

El ejemplo de Slack Code

El principal caso de estudio del autor es Slack Code, que según el artículo Salesforce lanzó en agosto de 2026. Un usuario etiqueta al agente de programación en una conversación. Este lee el contexto compartido, escribe código y abre pull requests, con alcance sobre GitHub y la infraestructura de producción, según el artículo.

El anuncio de Salesforce, citado en el texto, afirma que los agentes «heredan desde el primer día el modelo de seguridad integrado de Slack, sus permisos y sus controles de administración, sin ningún trabajo adicional para TI». El artículo contrapone esa promesa al alcance más amplio del agente, que va más allá de Slack.

Dónde ubica el autor el riesgo

El texto sostiene que el riesgo se encuentra sobre todo en la estructura de soporte del agente y en su ecosistema circundante, no en el modelo subyacente. Propone cuatro áreas de revisión:

  1. Identidad: qué agente actúa y en nombre de quién.
  2. Permisos: qué está autorizado a hacer.
  3. Conectividad: el radio de impacto, incluido lo que puede alcanzar de forma indirecta a través de otros sistemas.
  4. Actividad: un juicio basado en el comportamiento observado, no en la intención declarada.

Opet y la Ley de IA de la UE

El autor invoca a Patrick Opet, CISO global de JPMorgan Chase. Según el artículo, en 2025 Opet describió la cadena de suministro de terceros como un riesgo sistémico. Añade que los incidentes fueron lo bastante graves como para que el banco aislara a proveedores comprometidos, algo que se planteó en una carta abierta. El artículo no ofrece detalles de esos incidentes.

El autor también atribuye a Opet la postura de que un agente debería recibir una identidad, pero ningún permiso por defecto. Antes de tocar cualquier cosa fuera de su perímetro, TI debería confirmar en nombre de quién actúa.

En materia regulatoria, el autor afirma que la Ley de IA de la UE, cuyas obligaciones se aplican por fases hasta 2026, presupone que las empresas pueden inventariar sus sistemas de IA, nombrar responsables y acreditar la supervisión. Eso resulta difícil, sostiene el texto, cuando los agentes llegan sin previo aviso dentro de productos de proveedores.

El ángulo de los proveedores

El artículo nombra a Reco, y su plataforma Reco Graph, como un «ejemplo destacado» de herramienta que vincula identidades humanas y no humanas, aplicaciones, permisos y acciones de agentes en una vista en tiempo real. El texto procede de un socio, así que ese respaldo es la defensa de la postura del contribuyente. El descubrimiento de agentes de Reco se menciona en reco.ai/platform.

Para los equipos de seguridad, la conclusión práctica es más acotada que el discurso comercial. El argumento es que el inventario de agentes debería partir de las aplicaciones SaaS que ya se usan, y no de una lista de proyectos de IA aprobados.

Lee también

Fuentes

Este artículo es una reelaboración original basada en las siguientes fuentes.

Volver al inicio

Últimas noticias de ciberseguridad

Todas las noticias de ciberseguridad →