Durante décadas, la seguridad de API se pensó como defensa de perímetro: alguien de afuera intentando entrar. El insider risk, el riesgo de quien ya está adentro y tiene credenciales legítimas, siempre se trató como una categoría aparte, con sus propios procesos de revisión de acceso, monitoreo y offboarding.
Los agentes de IA no encajan en ninguna de las dos categorías. No están afuera intentando entrar: tienen claves de API, tokens de servicio y alcances de permisos, muchas veces definidos por conveniencia y nunca vueltos a revisar. Tampoco son empleados. Nadie les pregunta qué hicieron el viernes, no pasan por revisión trimestral de acceso y no se van de la empresa cuando termina el proyecto. Un agente con contexto, permisos y capacidad de actuar es, en la práctica, un insider digital, solo que sin los controles que aplicamos a las personas.
Qué cambia en la práctica
Tratar a un agente como insider digital exige repensar tres cosas que los equipos de seguridad ya saben hacer con personas, pero rara vez hacen con sistemas autónomos:
- Aprovisionamiento de acceso proporcional. Es común que un agente reciba un token con alcance amplio "para que no falle en producción", algo que jamás pasaría una revisión de acceso de un empleado nuevo. El principio de menor privilegio sigue aplicando aunque del otro lado haya un sistema.
- Comportamiento continuo, no puntual. Un insider humano actúa en horario laboral, con pausas naturales que dan tiempo de notar algo fuera de lo común. Un agente encadena llamadas las 24 horas, en secuencias que ningún humano ejecutaría manualmente. Eso hace más difícil distinguir un comportamiento anómalo de un uso legítimo.
- Auditoría del comportamiento real, no solo del acceso otorgado. Saber qué permisos tiene un agente es necesario, pero no suficiente. La pregunta que importa es qué hizo realmente con ese acceso: qué endpoints tocó, en qué orden y con qué datos.
Auditas el acceso de un pasante con más rigor que el del agente que corre en producción las 24 horas del día. Eso es un problema de prioridad, no de tecnología.
Por dónde empezar
Los agentes no necesitan un framework nuevo de insider risk. Necesitan que la disciplina que ya existe para personas se aplique, con la misma seriedad, a los sistemas autónomos. El punto de partida suele ser simple: mapear qué agentes tienen acceso a qué superficies críticas, entender el comportamiento real (no solo el declarado) y revisar los alcances de permisos con la misma frecuencia con la que revisarías el acceso de una persona.
Escalar autonomía sin antes entender y comprobar esa resiliencia es como darle a un nuevo empleado acceso total el primer día y no volver a revisar qué hizo con eso. Tus agentes van a actuar de formas que no anticipaste. La pregunta es si alguien en tu equipo lo va a saber antes de que se convierta en un incidente.