Presentado por NTT DATA AIVista
La investigación de junio de VentureBeat encontró que el 69% de las empresas todavía utilizan agentes de inteligencia artificial que comparten credenciales, una práctica asociada con tasas más altas de incidentes de seguridad y cuasiincidentes.
pero en Transformación VB 2026Mukesh Karki, CTO de NTT DATA AIVista, y Mayank Upadhyay, director de seguridad y confianza de Snowflake, argumentaron que arreglar la identidad es solo el primer paso. Las empresas también necesitan autorización a nivel de acción y pistas de auditoría a prueba de manipulaciones integradas en cada interacción de los agentes si quieren implementar sistemas autónomos de forma segura a escala.
«Estas organizaciones necesitan poder demostrar a sus auditores de una manera muy resistente a la manipulación que esos registros que muestran lo que hicieron en realidad prueban lo que están haciendo», dijo Karki. «Y la demostrabilidad es esencialmente su licencia para operar en un entorno regulatorio».
Por qué las credenciales compartidas provocan incidentes de seguridad de IA agente
El problema, dice Upadhyay, es que muchas suposiciones fueron heredadas de una generación anterior de software.
«En el mundo del software tradicional, un ser humano hace clic en algún lugar y el software hace algo muy determinista, y sabes a qué API va a llamar», dijo. «Pero en el mundo de los agentes, el software tiene un cerebro propio y se reconfigura constantemente. Si le das a este software más permiso del que necesita para un objetivo particular, los agentes son exploratorios por naturaleza, por lo que intentarán muchas cosas diferentes y tendrás efectos secundarios no deseados».
La incorporación de una única clave API estática agrava la exposición, añadió.
«Es un patrón realmente malo si tienes una clave API, la insertas en el agente y habla como cualquier persona con un servicio SaaS en particular, porque entonces le estás dando a este agente la unión de las necesidades de todos», dijo, señalando que el segundo modo de falla es forense, ya que «las cosas pueden salir mal y no serías capaz de atribuirlo al agente correcto».
Las credenciales con alcance son solo el punto de partida en industrias reguladas
Karki, cuyos clientes se encuentran principalmente en los sectores de seguros, atención médica y finanzas, trata las credenciales específicas como algo en juego.
«En un entorno regulatorio, un agente que no tiene un alcance amplio con credenciales de alcance compartido no se ejecutará, punto», dijo Karki. «Tener una credencial de alcance es sólo un punto de partida. En realidad, hay dos capas de restricciones. Una es la jurisdicción en la que opera el agente, y luego es la jurisdicción o las reglas de esa organización».
Por ejemplo, un agente de ajuste de reclamaciones en el estado de Washington opera con regulaciones diferentes a las de uno en California, añade, y cada reclamación es diferente.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
«Esas credenciales específicas no son suficientes, porque tienen que estar basadas en acciones y reglas en el momento en que se toman medidas», añadió.
Donde se rompe la analogía de los empleados con los agentes de IA
La analogía del empleado, argumentó Karki, sólo llega hasta cierto punto. Los agentes todavía necesitan conocer el contexto único de una organización, al igual que lo hace un nuevo empleado. Pero a diferencia de las personas, las empresas no pueden generar confianza de manera realista con miles de agentes a lo largo del tiempo.
«Un empleado estrella en una organización puede no ser el mejor empleado cuando se muda a otra organización, no porque haya empeorado, sino porque no tiene el contexto de este nuevo lugar, y lo mismo ocurre con los agentes», dijo Karki. «Si cada empleado tiene 100 agentes, no se puede decir que se van a incorporar a estos agentes y hacer una verificación de antecedentes sobre ellos».
Upadhyay dijo que la analogía de los empleados debería colocar a los agentes un peldaño más abajo en la jerarquía organizacional.
«Trátenlos como pasantes», sugirió. «Tienen buenas intenciones, pero no siempre saben lo que están haciendo, y hay que vigilarlos mientras se genera confianza gradualmente».
En la plataforma Snowflake, los administradores pueden imponer barreras de seguridad en toda la plataforma, como operaciones de solo lectura, mientras que los desarrolladores limitan aún más los permisos de un agente cuando inician cada sesión.
Un enfoque de tres niveles para la gobernanza de agentes de IA
No hay duda de adónde pertenece la gobernanza, dice Karki.
«La gobernanza tiene que ocurrir en cada acción del agente, y tiene que estar fuera del agente», explicó. «Esa es la única manera en la que podrás probar más adelante que el agente tomó una acción que se le permitió tomar».
Upadhyay dividió la gobernanza en tres capas:
La capa de agente cubre la identidad, los permisos de herramientas y la gobernanza de MCP.
La capa de modelo aborda la inyección de avisos indirectos y permite que los modelos se ejecuten dentro de la VPC del cliente para que los avisos permanezcan invisibles para el proveedor del modelo.
La capa de datos cubre el acceso con privilegios mínimos, la arquitectura sin copia y el control de acceso basado en roles.
Para que los agentes funcionen correctamente, se requiere gobernanza en los tres.
¿Qué empresas deberían auditar primero?
Para las empresas que auditan la gobernanza de los agentes de IA existentes, Upadhyay recomienda comenzar por dos lugares. El primero es la auditoría de permisos para secretos estáticos, el mayor vector de ataque reparable. Lo siguiente es abordar la IA en la sombra a través de una puerta de enlace MCP, de modo que los desarrolladores ya no tengan que ejecutar servidores MCP de código abierto pirateados debajo de sus escritorios y los administradores tengan visibilidad de quién está hablando con qué servidor MCP.
Existe un equilibrio entre restricción y capacidad, y eso se puede abordar a nivel de tarea, utilizando una puntuación de confianza para impedir la ejecución autónoma de acciones de alto riesgo y utilizando el sandboxing como un camino intermedio. Pero Karki advierte a las empresas que ya están ampliando sus sistemas agentes.
«Mucho de esto no se puede modernizar después de tener un sistema agente en ejecución, y es aún más difícil modernizarlo si hay que demostrar a los auditores por qué exactamente el agente se comportó como lo hizo», explicó. «La demostrabilidad debe construirse desde cero cuando se diseña el sistema».
Los artículos patrocinados son contenido producido por una empresa que paga por la publicación o tiene una relación comercial con VentureBeat, y siempre están claramente marcados. Para más información, póngase en contacto ventas@venturebeat.com.
