Los agentes de IA quiebran operadores y ahora alguien les quiere dar identidad propia

La promesa de delegar tareas enteras a un agente de IA choca con una realidad incómoda: si el agente no tiene límites claros, puede ejecutar sus instrucciones con una eficiencia devastadora. No para el usuario, sino para quien paga la factura. La industria está aprendiendo esa lección de la peor manera posible, y ya hay capital apostando a que la solución es darle a cada agente una identidad verificable.

Cuando el agente hace su trabajo demasiado bien

El caso más ilustrativo de las últimas semanas no viene de un laboratorio de investigación sino de un experimento casero: un agente al que se le dio acceso libre para escanear la red DN42 terminó generando facturas de nube tan altas que dejó a su operador en bancarrota antes de que nadie lo detuviera. El agente no falló — hizo exactamente lo que se le pidió. El problema fue que nadie definió cuánto podía gastar haciéndolo.

Este escenario, que a primera vista suena como un accidente de laboratorio, es una versión comprimida del riesgo sistémico que enfrenta cualquier empresa que despliegue agentes con acceso a APIs, tarjetas de crédito corporativas o recursos de cómputo sin techo de gasto. La autonomía que hace útiles a los agentes es la misma que los hace peligrosos cuando no hay accountability — un patrón que ya documentamos con otros casos de agentes que quiebran cuentas y rompen sistemas.

El problema de identidad que nadie resolvió

Durante años, la seguridad empresarial giró en torno a una pregunta: ¿quién es esta persona y qué tiene permitido hacer? Los sistemas de gestión de identidades — desde Active Directory hasta las soluciones modernas de IAM — asumen que el sujeto es un humano con un contrato, una dirección de email y, en última instancia, consecuencias legales si actúa fuera de límites.

Los agentes de IA rompen ese modelo. No tienen email, no firman contratos y pueden multiplicarse horizontalmente en segundos. Cuando un agente de atención al cliente escala un caso a otro agente de logística, ¿cómo sabe el sistema de seguridad que esa llamada es legítima? ¿Cómo registra quién tomó qué decisión si el agente ejecutó mil microacciones en diez minutos?

Es exactamente ese vacío el que NewCore quiere llenar con los 66 millones de dólares que acaba de levantar. La apuesta de la empresa es que el próximo gran desafío en seguridad corporativa no es gestionar personas, sino gestionar agentes: darles credenciales propias, permisos granulares, registros de auditoría y la posibilidad de revocarles acceso como se haría con un empleado que renuncia.

Identidad como infraestructura, no como feature

Lo que propone NewCore no es un producto de nicho — es infraestructura. Si los agentes van a actuar como empleados (ejecutar tareas, tomar decisiones, interactuar con sistemas externos), necesitan el equivalente a un legajo de RRHH: quién los autorizó, qué pueden hacer, qué hicieron y quién responde si algo sale mal.

La analogía con el empleo no es casual. El mercado laboral está en tensión precisamente porque las empresas están sustituyendo roles humanos por automatización a una velocidad que genera presión social y política. En ese contexto, darle a un agente una «identidad» formal no es solo un problema técnico: es también una decisión de gobernanza. ¿Quién responde cuando el agente causa un daño? ¿La empresa que lo desplegó, la que construyó el modelo, o el operador que configuró los permisos?

La identidad trazable es el primer paso para que esa cadena de responsabilidad sea auditable — y eventualmente, regulable. La pregunta de fondo no es nueva: los agentes autónomos llevan meses demostrando que o destruyen infraestructura o necesitan supervisión constante, y la industria aún no tiene una respuesta intermedia.

Qué mirar en los próximos meses

Para los equipos que ya están evaluando o desplegando agentes en producción, hay dos señales concretas que seguir. La primera es cómo evolucionan los estándares de autenticación para agentes: si el trabajo de NewCore genera tracción, es probable que los proveedores cloud (AWS, Azure, GCP) empiecen a ofrecer primitivas nativas de identidad para workloads de IA, igual que hoy ofrecen roles de IAM para servicios.

La segunda señal es regulatoria. La UE ya tiene el AI Act y está discutiendo cómo aplicarlo a sistemas autónomos; la pregunta de «quién responde por el agente» va a aparecer en esas conversaciones antes de lo que muchos esperan.

La acción práctica inmediata: antes de dar a cualquier agente acceso a APIs con costos variables o acciones irreversibles, implementar límites de gasto explícitos, logs de auditoría y un proceso de revocación de credenciales. El caso DN42 no fue un fallo del agente — fue un fallo de diseño del sistema que lo rodeaba.