Producto

Snowflake y NTT DATA avisan: la identidad no basta para frenar a los agentes de IA

·NeutralImpacto medio
Snowflake y NTT DATA avisan: la identidad no basta para frenar a los agentes de IA

Los agentes autónomos necesitan autorización por acción y registros a prueba de manipulaciones. Sin gobernanza desde el diseño, el riesgo regulatorio y de seguridad se dispara.

El 69% de las empresas todavía ejecuta agentes de IA que comparten credenciales, una práctica directamente relacionada con más incidentes de seguridad. Así lo revela una investigación de VentureBeat presentada en el VB Transform 2026, donde Mukesh Karki, CTO de NTT DATA AIVista, y Mayank Upadhyay, director de seguridad y confianza de Snowflake, dejaron claro que arreglar la identidad es solo el primer paso.

El problema de fondo es que muchos hábitos del software tradicional se han trasladado sin pensar al mundo de los agentes. Upadhyay lo explica con un ejemplo: antes, un humano hacía clic y el programa ejecutaba una acción muy concreta. Ahora, el agente tiene "cerebro propio" y explora constantemente. Si le das más permisos de los necesarios, acabarás con efectos secundarios imprevistos. Embeber una única clave API estática agrava la exposición, porque el agente actúa como si fuera cualquier usuario y, si algo sale mal, resulta imposible rastrear quién fue el responsable.

Karki, cuyos clientes son sobre todo aseguradoras, hospitales y entidades financieras, insiste en que las credenciales acotadas son el mínimo imprescindible. En entornos regulados, un agente con permisos genéricos simplemente no puede operar. Pero eso no basta: cada acción debe validarse según las reglas de la organización y la jurisdicción concreta. Un ajustador de siniestros en Washington se rige por normas distintas que uno en California, y cada reclamación es un mundo.

La analogía del empleado también cojea. Un trabajador estrella en una empresa puede rendir menos en otra porque le falta contexto; con los agentes pasa igual. Pero a diferencia de las personas, las compañías no pueden incorporar y "hacer un chequeo de antecedentes" a miles de agentes. Upadhyay propone tratarlos como becarios: tienen buena intención, pero no siempre saben lo que hacen, así que hay que vigilarlos mientras se gana confianza. En la plataforma de Snowflake, los administradores pueden imponer barreras de seguridad (como operaciones de solo lectura) y los desarrolladores limitan aún más los permisos en cada sesión.

Para Karki, la gobernanza debe aplicarse en cada acción del agente y desde fuera del propio agente, porque es la única manera de demostrar después que actuó dentro de lo permitido. Upadhyay desglosa tres capas: la del agente (identidad, permisos de herramientas), la del modelo (protección contra inyecciones indirectas, ejecución dentro de la nube privada del cliente) y la de los datos (acceso con privilegios mínimos, control de acceso basado en roles). Sin las tres, el sistema no es fiable. A la hora de auditar, recomienda empezar por los permisos de secretos estáticos —el principal vector de ataque corregible— y por el "shadow AI" mediante una pasarela MCP que dé visibilidad sobre quién habla con qué servidor. La gran advertencia de Karki es que todo esto no se puede parchear después: la auditabilidad debe construirse desde el primer día.

El análisis de Salseo

  • La noticia señala un vacío de seguridad que va más allá de la identidad: los agentes de IA necesitan autorización en tiempo real por cada acción y registros inmutables. Sin eso, las empresas reguladas no podrán demostrar a los auditores que el agente actuó correctamente, lo que frena la adopción a gran escala.
  • El verdadero riesgo no es solo técnico, sino de responsabilidad legal. Si un agente comete un error con credenciales compartidas, la empresa no puede atribuir la acción a un agente concreto, lo que complica cualquier investigación forense y puede acarrear sanciones en sectores como finanzas o salud.
  • Snowflake y NTT DATA están dibujando el estándar de facto para la gobernanza de agentes, con tres capas (agente, modelo, datos). Las empresas que no integren estos controles desde el diseño se exponen a tener que rediseñar sus sistemas más adelante, con costes mucho mayores y posibles brechas de cumplimiento.

Empresas mencionadas

Fuente: VentureBeat