Agentes IA sin trazabilidad: el agujero de identidad en tu pyme

La adopción de agentes de inteligencia artificial en entornos cloud avanza más rápido que los controles de identidad que deberían gobernarlos. Según una reciente publicación de The New Stack, más del 20% de las políticas de acceso relacionadas con MCP (Model Context Protocol) que el equipo de Shawn Petty revisó en entornos de clientes y prospectos estaban rotas o directamente ausentes. En la mayoría de los casos, el servidor MCP se ejecutaba con el token personal de alguien, no con una cuenta de servicio dedicada.

El dato es relevante porque MCP se está convirtiendo en el estándar de facto para que los agentes de IA se conecten a herramientas, bases de datos y servicios cloud. Si el agente actúa con las credenciales personales de un empleado, cualquier acción que ejecute queda registrada a nombre de esa persona, aunque no haya sido ella quien la autorizó. El resultado es un agujero de trazabilidad: el agente hizo el trabajo, pero el log de auditoría no puede decir quién lo pidió.

Por qué esto importa en una pyme

En una empresa pequeña o mediana, la tentación de conectar un agente a un servicio cloud con el token del administrador es enorme. Es rápido, funciona y no requiere montar una infraestructura de identidad compleja. Pero ese atajo tiene consecuencias:

• Auditoría imposible: si el agente modifica un recurso, no hay forma de saber si fue una acción programada, un error o una decisión humana.
• Revocación complicada: si el empleado deja la empresa o cambia de rol, hay que localizar todos los agentes que usaban su token antes de desactivarlo.
• Superficie de ataque ampliada: un token personal suele tener más permisos de los necesarios y no está sujeto a rotación automática.
• Incumplimiento normativo: según qué sector, no poder trazar quién autorizó una acción puede ser un problema directo con auditores o clientes.

No es un problema teórico. En ForgeNEX hemos visto cómo equipos de IT en pymes empiezan a probar agentes para tareas de operación —consultar métricas, reiniciar servicios, lanzar pipelines— y lo hacen con el token del ingeniero que montó la prueba. Cuando la prueba pasa a producción, nadie revisa ese detalle.

Identidad para agentes: qué debería cambiar

La solución pasa por tratar a los agentes como identidades de pleno derecho, no como extensiones de una persona. Esto implica:

1. Cuentas de servicio dedicadas: cada agente debe tener su propia identidad, con permisos mínimos y rotación de credenciales.
2. Trazabilidad de la cadena completa: no basta con registrar qué hizo el agente; hay que registrar qué humano o sistema lo invocó y con qué autorización.
3. Políticas de acceso explícitas: definir qué puede hacer cada agente, en qué entornos y bajo qué condiciones. Nada de permisos heredados por comodidad.
4. Revisión periódica: las políticas MCP que Petty encontró rotas o ausentes no se rompieron solas; simplemente nadie las revisó después de la configuración inicial.

CloudBolt, la empresa de Petty, organiza un webinar el 27 de octubre para demostrar cómo rastrear las acciones de un agente hasta la persona responsable. Más allá del evento, el mensaje es claro: si tu empresa está desplegando agentes de IA, la identidad y la auditoría no pueden ser una ocurrencia tardía.

Qué recomendamos desde ForgeNEX

Para una pyme que empieza con agentes de IA, el orden de prioridades debería ser:

• Inventario antes que despliegue: saber qué agentes existen, qué tokens usan y a qué tienen acceso. Sin este paso, cualquier control posterior es papel mojado.
• Separar entornos: los agentes en pruebas no deben tocar producción con credenciales reales. Si necesitan datos, que sean anonimizados o sintéticos.
• Empezar por lo aburrido: cuentas de servicio, permisos mínimos y logs centralizados. No es glamuroso, pero evita el 90% de los problemas.
• Definir quién responde: cuando un agente hace algo mal, ¿quién asume la responsabilidad? Si la respuesta no es clara, el diseño de identidad está incompleto.

El auge de los agentes de IA recuerda a los primeros años de la nube: mucha experimentación, poca gobernanza y la sensación de que «ya lo arreglaremos». Pero a diferencia de la nube, los agentes actúan solos. Un token personal olvidado en un servidor MCP puede ejecutar acciones en nombre de alguien que ni siquiera sabe que ese agente existe.

La buena noticia es que las prácticas para resolverlo no son nuevas: identidad dedicada, permisos mínimos y trazabilidad completa. Lo que cambia es el sujeto: ya no solo gestionamos personas y servicios, ahora también agentes que actúan por nosotros. Y si no podemos decir quién pidió qué, no tenemos control, tenemos suerte.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.