Seguridad de los agentes de IA: accesos, secretos y human-in-the-loop
Un agente de IA puede buscar en el CRM, escribir correos, ejecutar comandos, actualizar tareas y llamar APIs externas. Por eso la seguridad de los agentes de IA debe diseñarse antes del lanzamiento y no despues del primer incidente. Los problemas mas frecuentes son accesos demasiado amplios, secretos dentro de prompts y logs, y la falta de human-in-the-loop cuando el agente puede actuar sin confirmacion humana.
- Accesos - el agente solo debe ver los sistemas y campos que realmente necesita
- Secretos - claves API, tokens y contrasenas no deben vivir en prompts, git ni logs comunes
- Human-in-the-loop - las acciones criticas son mas seguras con aprobacion humana
- Principio central - no dar "todo por si acaso", sino solo los permisos minimos necesarios
- Resultado practico - menos riesgo de fugas de datos, acciones erroneas y retrocesos costosos
Por que los agentes de IA son mas peligrosos que un bot normal
Un chatbot normal muchas veces solo responde preguntas. Un agente de IA va mas lejos: lee documentos, usa herramientas, cambia registros de base de datos, crea facturas, envia mensajes a clientes y puede ejecutar codigo. Cuanta mas autonomia tenga, mas caro sale un error.
Riesgos tipicos:
- el agente recibe acceso a CRM, correo, base de conocimiento y pagos al mismo tiempo;
- datos personales, condiciones comerciales e instrucciones internas caen en un solo contexto;
- un empleado pega un token real en el prompt del sistema "solo para probar";
- el logging guarda la entrada completa del usuario junto con secretos;
- el agente envia un mensaje, borra un registro o lanza la operacion equivocada sin revision.
Conclusion: la seguridad del agente no consiste solo en "proteger el modelo". Tambien implica control de accesos, manejo de secretos, logging y aprobaciones.
Accesos: privilegio minimo en lugar de acceso total
El error mas comun es dar al agente una cuenta de administrador porque "asi la integracion es mas rapida". Comodo al principio, peligroso en produccion.
Como limitar accesos
- Separar roles - un agente de soporte no debe ver reportes financieros, y uno analitico no debe escribir a clientes.
- Limitar el alcance de datos - no todo el CRM, solo las entidades, campos y proyectos necesarios.
- Separar lectura y escritura - empezar en modo read-only y agregar escritura solo donde tenga sentido.
- Usar cuentas de servicio - no logins personales de empleados.
- Revisar periodicamente - los permisos se deben revisar y no dejar para siempre.
| Enfoque | Que pasa | Riesgo |
|---|---|---|
| Acceso admin para el agente | El agente ve y cambia todo | Danio maximo si falla |
| Read-only sobre los datos necesarios | El agente analiza sin romper el proceso | Menor riesgo, auditoria mas simple |
| Rol + scope + approve | El agente esta limitado y solo escribe tras aprobacion | Mejor equilibrio entre velocidad y control |
Donde el error cuesta mas
- CRM - contactos, oportunidades, notas, telefonos, email;
- correo y mensajeria - riesgo de envio externo;
- almacenamiento de archivos - contratos, informes, datos personales;
- servicios financieros - facturas, pagos, reembolsos;
- herramientas de terminal - comandos, deploys, migraciones, borrado de datos.
Si un solo agente necesita acceso a cinco sistemas, casi siempre conviene preguntar si no deberian ser varios agentes con responsabilidades estrechas.
Secretos: donde suelen ocurrir las fugas
Los secretos rara vez se filtran por un "super ataque". Mucho mas a menudo el equipo los pone donde no deben estar:
- en
.envque se sube por error a git; - en el prompt del sistema por comodidad;
- en capturas, tickets y documentos enviados a proveedores;
- en logs de peticiones y respuestas;
- en archivos JSON de prueba y notebooks de desarrollo.
Reglas basicas para manejar secretos
- Guardar secretos en un secret manager o en variables de entorno protegidas, no en el texto del prompt.
- Inyectar tokens en la capa de herramientas, no en la capa del modelo.
- Enmascarar campos sensibles en logs - claves, contrasenas, cookies, numeros de tarjeta, access tokens.
- Separar dev, stage y prod - diferentes claves, scopes y limites.
- Preparar revocacion y rotacion - si un secreto se filtra, debe reemplazarse rapido.
Buena practica: el modelo sabe que existe una herramienta como create_invoice() o search_crm(), pero nunca ve la clave API real que esta detras.
Human-in-the-loop: cuando una persona debe confirmar
No toda accion del agente necesita aprobacion manual. Pero hay una clase de operaciones donde human-in-the-loop ahorra mas dinero del que cuesta en tiempo.
Conviene activar aprobacion para:
- mensajes enviados a clientes en nombre de la empresa;
- cambios de precio, descuento, contrato o estado de oportunidad;
- borrado de datos, archivos y registros;
- comandos de servidor y despliegues;
- cualquier accion con consecuencias legales o financieras.
Modos practicos de control
| Modo | Como funciona | Cuando encaja |
|---|---|---|
| Autopiloto total | El agente decide y actua solo | Solo para tareas internas de bajo riesgo |
| Draft mode | El agente prepara la accion y una persona confirma | Soporte, ventas, documentos |
| Aprobacion en dos pasos | Las operaciones peligrosas requieren approve separado | Dinero, produccion, borrado, permisos |
Para la mayoria de las SMB, lo mejor es un agente que recoja datos y prepare borradores, mientras una persona confirma el paso externo o critico.
Logs, auditoria e investigacion de incidentes
Si el agente se equivoca, la empresa necesita saber:
- que entrada recibio;
- que herramienta llamo;
- que datos devolvio la herramienta;
- quien aprobo la accion o por que se ejecuto automaticamente;
- con que rapidez se puede revertir el resultado.
Por eso conviene guardar:
- logs de llamadas a herramientas;
- IDs de usuario y sesion;
- version del prompt o de la configuracion del agente;
- registro de aprobaciones manuales;
- logs de error enmascarados sin secretos expuestos.
Importante: registrar todo sin enmascarar puede convertirse en una nueva fuente de fuga. La auditoria importa, pero no al precio de guardar contrasenas y tokens en texto plano.
Arquitectura mas segura para un agente de IA
Un contorno practico minimo para muchos proyectos:
- Una cuenta de servicio separada por agente o por rol.
- Herramientas estrechas con permisos limitados en lugar de una herramienta universal de "hacer todo".
- Secret manager / env en vez de claves en prompts y repositorios.
- Paso de aprobacion para operaciones externas, financieras y destructivas.
- Logs y monitorizacion con enmascarado de datos sensibles.
- Rotacion de claves y revision de accesos de forma programada.
Que revisar antes del lanzamiento
- el agente no corre como admin salvo necesidad real;
- no hay tokens ni contrasenas reales en el repositorio;
- los datos de prueba no contienen datos personales reales;
- las acciones criticas no se ejecutan sin confirmacion;
- cada herramienta tiene claro que puede leer y que puede cambiar;
- existe un procedimiento claro para desactivar el agente ante un incidente.
Errores frecuentes de implementacion
- Un solo agente para todo - soporte, finanzas y admin juntos.
- Secretos en prompts - porque "asi es mas facil depurar".
- Sin etapa read-only - el agente puede escribir y borrar desde el primer dia.
- Sin human-in-the-loop - hasta que llega el primer error caro.
- Sin auditoria - despues del incidente nadie puede reconstruir lo ocurrido.
Cuanto mas autonomo sea el agente, mas hay que pensar como ingeniero de seguridad y no solo como integrador de LLM.
Conclusion
La seguridad de los agentes de IA se apoya en tres pilares: acceso minimo, manejo correcto de secretos y human-in-the-loop para acciones peligrosas. Si limitas el alcance desde el inicio, ocultas las claves al modelo, anades aprobaciones y mantienes auditoria, la IA acelera al equipo en lugar de crear una nueva superficie de incidentes.
Si planeas implementar un agente de IA en CRM, soporte o procesos internos - contactanos.
Preguntas frecuentes
En que se diferencia un agente de IA de un chatbot normal desde el punto de vista de seguridad?
Un agente de IA normalmente no solo responde, tambien actua. Puede llamar herramientas, leer bases de datos, cambiar registros, enviar correos y lanzar operaciones. Por eso el riesgo no es solo una mala respuesta, sino una mala accion en un sistema real.
Se le puede dar acceso admin a un agente interno?
Normalmente no conviene. Que sea interno no elimina el riesgo de errores, fugas o llamadas incorrectas de herramientas. Incluso para agentes internos es mejor usar una cuenta de servicio separada, read-only cuando sea posible y permisos de escritura estrechos.
Donde deben guardarse las claves API de las herramientas del agente?
En un secret manager o en variables de entorno protegidas. No en el prompt del sistema, documentos markdown, codigo fuente ni logs normales. El modelo debe llamar la herramienta y la clave debe inyectarse fuera de su contexto.
Hace falta human-in-the-loop para cada accion del agente?
No. Busqueda, borradores, clasificacion y analitica segura pueden ejecutarse automaticamente. Pero mensajes externos, dinero, borrado de datos, cambios de estado y comandos de servidor son mucho mas seguros con confirmacion humana.
Que hacer si un secreto ya aparecio en un log o en un prompt?
Tratarlo como comprometido. Hay que revocar o rotar la clave, eliminarla de logs y repositorios, revisar los sistemas conectados y corregir la causa raiz en el prompt, el logger, el archivo de prueba o el proceso de desarrollo.