Tu agente de IA necesita un proceso de onboarding. Acá te explico por qué.
No le darías acceso root a producción a un empleado nuevo en su primer día. Sin credenciales de administrador, sin acceso irrestricto a todos los sistemas internos, sin capacidad de mandar correos en nombre de la empresa sin que alguien los revise primero.
Sin embargo, eso es exactamente lo que la mayoría de los devs hacen cuando levantan un agente de IA.
Esta semana, tanto Microsoft como IBM publicaron análisis sobre los agentes de IA entrando al lugar de trabajo como “compañeros digitales”. Ambos llegaron a la misma conclusión incómoda: el modelo de seguridad para agentes de IA, en la mayoría de los equipos, básicamente no existe.
El framing de “coworker digital” no es metáfora — es política
Vasu Jakkal, VP de Seguridad de Microsoft, lo dijo sin rodeos: cada agente debería tener las mismas protecciones de seguridad que un empleado humano. Eso implica una identidad clara, acceso acotado (solo a lo que realmente necesita), un registro de todo lo que crea o toca, y protección contra atacantes externos que intenten manipularlo.
Ese último punto merece atención. Los agentes de IA que operan en codebases, leen archivos, ejecutan comandos en la terminal y llaman APIs externas son blancos cada vez más atractivos para ataques de prompt injection — donde contenido malicioso en archivos o páginas web intenta secuestrar el comportamiento del agente. Si tu agente puede leer un README y ejecutar código, un README cuidadosamente construido puede hacerlo hacer cosas que nunca autorizaste.
El análisis de IBM va aún más lejos. Shlomi Yanai, de AuthMind, lo enmarca como una crisis de gobernanza en cámara lenta: en pocos años, las identidades no humanas (agentes de IA, workflows automatizados, cuentas de servicio) van a superar en número a los usuarios humanos dentro de la mayoría de las organizaciones. La pregunta no es si tenés agentes de IA corriendo — probablemente ya los tenés. La pregunta es si alguien puede responder tres cosas sobre cada uno:
- ¿Sabés que existe? ¿Está catalogado en algún lado?
- ¿Sabés a qué está accediendo? ¿Archivos, APIs, bases de datos?
- ¿Confiás en lo que hace cuando llega ahí? ¿Qué puede leer, escribir, borrar o llamar?
Si no podés responder las tres, no estás corriendo un agente — estás corriendo un punto ciego.
Esto no es solo un problema enterprise
Es fácil leer “Microsoft e IBM hablando de gobernanza en IA” y mentalmente archivarlo bajo “preocupaciones de IT empresarial que no me aplican”. Eso sería un error.
Si usás Claude Code, Cursor, o cualquier herramienta de codeo agéntico, ya estás tomando decisiones de política implícitas:
- ¿Qué archivos puede leer el agente? (En general: todo en tu repo, incluyendo archivos
.env) - ¿Puede ejecutar comandos en la terminal? (En general: sí, con confirmación mínima)
- ¿Puede hacer requests externos o llamar APIs? (Depende de la configuración de servidores MCP)
- ¿Hay algún registro de lo que hizo durante la sesión? (Usualmente: solo en el historial de tu terminal)
La analogía del empleado nuevo funciona bien acá. Cuando hacés el onboarding de un dev humano, le das acceso a lo que necesita para el trabajo — no a todo el filesystem de la empresa. Configurás SSO para poder revocar acceso desde un solo lugar. Mantenés logs de auditoría para entender qué pasó si algo sale mal.
Tus agentes de IA merecen — y francamente requieren — la misma disciplina.
El checklist práctico
Esto es lo que aplicar este principio significa en la práctica dentro de un workflow de desarrollo:
Acotá el acceso de tu agente. No lo apuntes a todo tu directorio home o a un monorepo entero por defecto. Trabajá en contextos delimitados donde sea posible.
Auditá los permisos de tus servidores MCP. Cada servidor MCP que agregás es una nueva superficie de capacidades. Revisá lo que cada uno puede hacer realmente — no los instales a ciegas.
Leé lo que tu agente está haciendo. Los logs de sesión de Claude Code y el historial de commits son tu registro de auditoría. Usálos. Si un agente hizo un cambio que no esperabas, querés saberlo antes de que llegue a producción.
Tratá .env y credenciales como zonas prohibidas. Configurá explícitamente tus agentes para excluir patrones de archivos sensibles. No te apoyes en la suposición de que “no van a mirar ahí”.
Pensá en la confianza entre múltiples agentes. Si un agente puede llamar a otro agente (o disparar workflows vía webhooks), esa cadena de confianza se multiplica. Cada salto es una superficie de ataque potencial adicional.
El panorama más amplio: la orquestación es la nueva frontera
Gabe Goodhart de IBM hizo un punto que reencuadra toda la conversación: “Es un mercado de compradores para los modelos. El modelo en sí no va a ser el diferenciador principal. Lo que importa ahora es la orquestación — combinar modelos, herramientas y workflows.”
En 2026, todo el mundo tiene acceso a buenos modelos. La ventaja competitiva la tienen los equipos que construyen sistemas alrededor de esos modelos — y los sistemas requieren gobernanza, no solo capacidad.
Los devs que van a sacarle más partido a los agentes de IA no son los que les dan más acceso. Son los que les dan exactamente el acceso correcto, junto con la visibilidad para saber qué está pasando realmente.
Eso no es una limitación de lo que los agentes pueden hacer. Es lo que los hace lo suficientemente confiables como para hacer más.