La seguridad de un sistema agéntico descansa en lo mismo que la de cualquier sistema bien hecho: identidad propia para cada agente, mínimo privilegio, secretos fuera del código y de las instrucciones, aislamiento entre clientes y un registro de todo. Tus datos se quedan en tus sistemas; el agente consulta lo que su tarea necesita y no guarda copias que nadie haya autorizado.
¿Dónde viven los datos?
En los sistemas donde ya viven. La capa agéntica no se vuelve una segunda base de datos de la empresa: lee del sistema fuente cuando necesita un dato y escribe de vuelta ahí el resultado. Lo que la capa guarda por sí misma es lo necesario para operar y para auditar: el estado de cada caso, la bitácora y la memoria acotada que el proceso requiere.
El código del sistema que construimos vive en tu repositorio y en tu infraestructura, no en la nuestra. Eso significa que tú controlas dónde corre, quién accede y cuánto tiempo se conserva cada cosa. El detalle de despliegue y de conservación se define por proyecto, según tu política y tu sector.
¿Qué ve el modelo de lenguaje?
Sólo lo que el núcleo le entrega para la tarea en curso. Es la parte que más preguntas genera, y la respuesta correcta es un principio de diseño: minimizar. Si para clasificar un documento no hace falta el domicilio completo, el domicilio no viaja al modelo. Si un dato sensible puede reemplazarse por una referencia, se reemplaza.
Puntos que conviene fijar por escrito en cada proyecto:
- Qué modelos y qué proveedores intervienen, y con qué condiciones contractuales sobre uso y retención de datos.
- Qué categorías de datos nunca se envían a un modelo externo.
- Dónde se registran las entradas y las salidas del modelo, y quién puede verlas.
Esas condiciones las dicta el contrato con cada proveedor y la política de tu empresa; las revisas tú y las revisamos contigo antes de construir.
¿Cómo se protegen las credenciales?
- Una por agente y por sistema. Si una se compromete, se revoca sin afectar a las demás.
- Fuera del código y fuera de las instrucciones. Viven en un almacén de secretos; nunca se ponen en el texto que lee el modelo, porque lo que el modelo lee puede acabar en una respuesta.
- Con vigencia y rotación. Se renuevan con una periodicidad definida y al cambiar el personal que las administra.
- Sin que el modelo las vea. El conector las usa; el modelo sólo pide la acción.
Que el agente nunca vea la llave no es un detalle: es lo que evita que una conversación mal intencionada convenza al agente de entregarla.
¿Qué riesgos son propios de los agentes?
Además de los de cualquier software, hay uno característico: el agente lee texto de fuentes externas (un correo, un documento, la respuesta de un cliente), y ese texto puede traer instrucciones disfrazadas. Se le llama inyección de instrucciones. La defensa no es pedirle al modelo que «no se deje engañar», sino diseñar para que engañarlo no sirva de nada:
- El agente sólo puede ejecutar el catálogo cerrado del conector, así que una instrucción maliciosa no encuentra acciones peligrosas que disparar.
- Las acciones sensibles exigen aprobación humana, y la persona ve el origen de la propuesta.
- El contenido externo se trata como dato, no como orden, y se marca como no confiable dentro del núcleo.
- Los límites (montos, destinatarios, volúmenes) se validan en el código, fuera del alcance del modelo.
Es el mismo principio de gobierno: no depender de que el modelo se porte bien, sino de que el sistema no lo necesite.
¿Cómo se aísla un cliente de otro?
Cada empresa tiene su propio espacio: sus datos, sus credenciales, sus agentes y su bitácora, sin compartirlos con otra. Cuando un mismo componente atiende a varias organizaciones, el aislamiento se aplica en la base de datos y se prueba con las credenciales de la propia aplicación, no con las de un administrador que salta las reglas. Una prueba que usa el acceso del dueño puede pasar aun cuando el aislamiento esté roto.
¿Qué debería preguntarle TI a cualquier proveedor?
- ¿Qué datos salen de mis sistemas, hacia dónde y por cuánto tiempo?
- ¿Con qué credencial actúa el agente en cada sistema y cómo la revoco?
- ¿Dónde están los límites: en el código o sólo en las instrucciones?
- ¿Qué ocurre si el modelo recibe una instrucción maliciosa dentro de un documento?
- ¿Puedo ver la bitácora completa, y puedo frenar un agente yo mismo?
- ¿Dónde vive el código y qué pasa si dejamos de trabajar juntos?
Si un proveedor no puede responder esas seis con precisión, la conversación está incompleta. Para el panorama, vuelve a la guía; para las dudas generales, preguntas frecuentes.
Este texto describe nuestro enfoque de diseño; no sustituye una revisión de seguridad ni asesoría legal sobre las obligaciones de tu sector, que corresponden a tus especialistas.