Los agentes actúan: llaman herramientas, tocan datos, ejecutan acciones. Eso exige controles que un chatbot pasivo nunca necesitó. Una guía práctica apoyada en el Secure AI Framework de Google.
Yohan Consani · Publicado el
Durante años, el riesgo de seguridad de un asistente de IA cabía en una pregunta simple: ¿qué puede decir? Un chatbot tradicional solo devuelve texto, y el peor caso solía ser una respuesta errónea, sesgada o filtrada. Con la llegada de los agentes, la pregunta cambia de naturaleza, porque el agente actúa. Llama APIs, escribe en bases de conocimiento, dispara flujos, lee datos sensibles y acciona otros sistemas. El riesgo deja de ser lo que dice y pasa a ser lo que ejecuta.
Es exactamente ese giro el que ayuda a ordenar el Secure AI Framework (SAIF) de Google. El SAIF es un framework conceptual abierto para proteger sistemas de IA de extremo a extremo: de los datos al modelo, de la infraestructura a la aplicación. Su versión más reciente, SAIF 2.0, da un paso explícito hacia el nuevo terreno: la seguridad de los agentes de IA. Este artículo es una síntesis práctica de ese material, traducida para quien necesita poner agentes en producción con responsabilidad.
Las acciones indebidas (Rogue Actions) son acciones no pretendidas ejecutadas por un agente basado en modelo, ya sean accidentales o maliciosas.Google · Secure AI Framework (SAIF)
Por qué un agente es distinto de un chatbot
La diferencia es simple de enunciar y profunda en sus consecuencias: un chatbot predice texto; un agente toma acciones en el mundo. Esa capacidad de actuar transforma la superficie de ataque. El SAIF nombra este riesgo específico de los agentes como Rogue Actions (RA), acciones indebidas ejecutadas por el agente, accidentales o maliciosas. Ahora está en juego una transacción enviada, un registro borrado, un correo disparado, un acceso concedido.
El efecto colateral es que riesgos clásicos de la IA, antes manejables, ganan un filo mucho más afilado cuando hay un agente capaz de ejecutar:
- Inyección de prompt (Prompt Injection, PIJ): antes podía, como mucho, forzar una respuesta no deseada. Con un agente, una instrucción escondida en un documento o página puede secuestrar acciones reales: hacer que el agente llame la herramienta equivocada con los argumentos del atacante.
- Salida de modelo insegura (Insecure Model Output): la salida del modelo deja de ser solo texto en pantalla y pasa a alimentar sistemas que la ejecutan (una consulta, un comando, una llamada de función). El contenido sin validar se convierte en acción.
- Divulgación de datos sensibles (Sensitive Data Disclosure): ahora incluye datos filtrados mediante la consulta al propio modelo o agente, extraídos con preguntas hábiles, no solo por una falla de acceso convencional.
El mapa del SAIF: cuatro áreas
El SAIF organiza el sistema de IA en cuatro áreas que deben protegerse en conjunto. Una cadena es tan fuerte como su eslabón más débil. Pensar en cada una evita el error común de blindar el modelo y olvidar todo lo que lo rodea.
- Datos (Data): las fuentes que alimentan y entrenan el sistema, su procedencia y su tratamiento.
- Infraestructura (Infrastructure): la plataforma de entrenamiento, servicio y almacenamiento sobre la que corre el sistema.
- Modelo (Model): el propio modelo, su uso, sus entradas y salidas.
- Aplicación (Application): la capa que expone el sistema, incluyendo, en SAIF 2.0, el agente en sí.
La espina dorsal: los tres controles de agente
Si hay una idea para llevarse de este artículo, es esta: la autonomía segura es autonomía limitada. El SAIF 2.0 lo condensa en tres controles que, juntos, cercan cada acción consecuente de un agente. Son complementarios: ninguno basta por sí solo.
1. Control del usuario sobre el agente (Agent User Control)
El principio es el humano en el bucle (human-in-the-loop): garantizar la aprobación del usuario para cualquier acción ejecutada por agentes o plugins que altere datos del usuario o actúe en su nombre. En lugar de que el agente escriba directamente, propone, y la persona confirma. Las acciones de bajo riesgo pueden fluir; las acciones consecuentes pasan por una puerta explícita de aprobación.
2. Permisos del agente (Agent Permissions)
Aquí aplica el principio del menor privilegio, pero con un matiz agéntico: el acceso a las herramientas debe ser contextual y dinámico. El agente solo debe ver las herramientas y los datos estrictamente necesarios para la tarea del momento, y no un conjunto fijo y amplio de poderes «por si acaso». Cuanto menor sea el radio de acción concedido, menor será el daño posible de una acción indebida.
3. Observabilidad del agente (Agent Observability)
De nada sirve limitar si nadie puede ver lo que pasó. Las acciones del agente, su uso de herramientas y su razonamiento deben ser transparentes y auditables mediante registro (logging). La observabilidad es lo que convierte un incidente en una investigación posible, y lo que permite distinguir un error honesto de un ataque.
Gobernanza: lo que sostiene los controles
Los controles técnicos solo se sostienen dentro de la gobernanza. El SAIF señala la Gobernanza de Riesgo (inventariar, medir y monitorear el riesgo residual, lo que queda tras las mitigaciones) y la Gobernanza de Producto, que inserta las decisiones de seguridad en el ciclo de vida. En los bordes, la validación y sanitización de entradas y salidas siguen siendo la higiene básica: nada que entre o salga del agente debe tratarse como confiable por defecto.
Dónde encaja Charla
Charla no reivindica ninguna certificación aquí: lo que describimos es alineación de ingeniería con un framework del sector. Aun así, vale mapear mecanismos reales de la plataforma a los tres controles de agente del SAIF, porque la arquitectura fue pensada en la misma dirección: autonomía con frenos.
- Control del usuario → Charla adopta una postura de proponer-y-aprobar: los cambios en conocimiento, wiki o identidad visual entran como propuestas revisables, nunca como escrituras silenciosas; la aprobación humana funciona como puerta de la recuperación de información.
- Permisos → Aislamiento por asistente (cada Charla tiene su propia base de conocimiento y lista de acceso, con la recuperación filtrada por asistente antes de la ordenación), RBAC jerárquico con permisos acotados, allowlists de herramientas con denegación por defecto, credenciales MCP selladas (AES-256-GCM bajo una clave del Secret Manager) y protección de egreso que bloquea peticiones a redes internas (protección contra SSRF).
- Observabilidad → Un log de auditoría solo-de-anexado (el rol de base de datos no puede hacer UPDATE ni DELETE sobre él) que registra cada acción privilegiada y cada llamada de herramienta, sumado a logs, trazas y métricas estructurados y correlacionados por id de petición. El streaming nunca expone la cadena de razonamiento en bruto.
Este diseño no es exhaustivo ni un sello de conformidad: es una elección consciente de arquitectura. Cada una de estas piezas existe para que una acción consecuente del agente solo ocurra dentro de límites: con permiso, con el debido visto bueno humano y dejando un rastro auditable.
Proteger una IA agéntica, al final, consiste en darle una autonomía limitada. Toda acción que importa pasa por tres preguntas: ¿tiene permiso? ¿La aprobó quien debe aprobarla? ¿Quedó registrada? El SAIF aporta el vocabulario; la ingeniería aporta los frenos. Y es en ese encuentro entre framework y práctica donde un agente deja de ser un riesgo y pasa a ser una herramienta confiable.