Seguridad del agente

La creación de agentes de inteligencia artificial segura es una responsabilidad compartida entre Agent Framework y los desarrolladores de aplicaciones. Agent Framework proporciona los bloques de creación (abstracciones, proveedores y orquestación), pero los desarrolladores son responsables de validar las entradas, proteger los flujos de datos y configurar las herramientas de forma adecuada para su escenario.

En este artículo se describen los procedimientos recomendados para crear agentes seguros y seguros con Agent Framework.

Descripción de los límites de confianza

Los datos fluyen a través de varios componentes cuando se ejecuta un agente: entrada del usuario, proveedores de historial de chat, proveedores de contexto, el servicio LLM y las herramientas de función. Cada límite en el que los datos entran o salen de la aplicación representan una posible superficie expuesta a ataques.

Límites de confianza clave que se deben tener en cuenta:

• Servicio de IA : recibe mensajes de chat (que pueden incluir PII e instrucciones del sistema) y devuelve la salida generada por LLM.
• Almacenamiento del historial de chat : los proveedores pueden cargar y conservar mensajes de conversación a través del almacenamiento externo.
• Servicios de contexto : los proveedores de contexto pueden recuperar o almacenar datos de servicios externos (memorias, perfiles de usuario, resultados rag).
• Servicios accedidos mediante herramientas: las herramientas de función ejecutan código proporcionado por el desarrollador que puede llamar a API externas o bases de datos.

Todos los SDK de cliente elegidos por el desarrollador controlan toda la comunicación de servicio externo. Agent Framework no administra los detalles de autenticación, cifrado ni conexión de estos servicios.

procedimientos recomendados

Validar entradas de funciones

La inteligencia artificial puede llamar a cualquier función que proporcione como herramienta y elegir los argumentos. Trate los argumentos proporcionados por LLM como entrada que no es de confianza, similar a la entrada del usuario en una API web.

• Uso de la lista de permitidos — validar las entradas con valores conocidos como correctos en lugar de intentar filtrar patrones conocidos como incorrectos. Por ejemplo, compruebe que una ruta de acceso de archivo está dentro de un directorio permitido en lugar de comprobar si .. hay secuencias transversales.
• Aplicar restricciones de tipo y intervalo : compruebe que los argumentos son del tipo esperado y dentro de intervalos aceptables (límites numéricos, límites de longitud de cadena, intervalos de fechas).
• Limitar las longitudes de cadena : aplique las longitudes máximas en argumentos de cadena para evitar ataques por inyección o agotamiento de recursos.
• Impedir el recorrido de ruta de acceso : cuando las funciones aceptan rutas de acceso de archivo, las resuelven en rutas de acceso absolutas y comprueban que se encuentran dentro de los directorios permitidos.
• Usar consultas con parámetros : si se usan argumentos en consultas SQL, comandos de shell u otros contextos interpretados, use consultas con parámetros o escape, nunca concatenación de cadenas.

Requerir aprobación para herramientas de alto riesgo

De forma predeterminada, todas las herramientas proporcionadas a un agente se invocan sin aprobación de usuario. Utilice el mecanismo de aprobación de herramientas para controlar las operaciones de alto riesgo requiriendo confirmación humana.

Al decidir qué herramientas requieren aprobación, tenga en cuenta lo siguiente:

• Efectos secundarios : las herramientas que modifican datos, envían comunicaciones, realizan compras o tienen otros efectos secundarios generalmente deben requerir aprobación.
• Confidencialidad de los datos : las herramientas que acceden o devuelven datos confidenciales (PII, datos financieros, credenciales) garantizan la aprobación.
• Reversibilidad : las operaciones irreversibles (eliminación, envío de correos electrónicos) tienen un mayor riesgo que las consultas de solo lectura.
• Ámbito de impacto : las herramientas con un amplio impacto (operaciones masivas) deben requerir un mayor examen que los de ámbito limitado.

Mantener los mensajes del sistema controlados por el desarrollador

Los mensajes de chat llevan un rol (system, user, assistant, tool) que determina cómo los interpreta el servicio de IA. Comprender estos roles es fundamental:

Función	Nivel de confianza
system	Confianza más alta — Moldea directamente el comportamiento de LLM. Nunca debe contener entrada no confiable.
user	No confiable : puede contener intentos de inyección de mensajes o contenido malintencionado.
assistant	No confiable : generado por el LLM, que es un sistema externo.
tool	No confiable : puede contener datos de sistemas externos o contenido influenciado por el usuario.

No coloque la entrada del usuario final en mensajes de tipo system-role. Agent Framework asigna por defecto el texto sin tipo al rol de user, pero tenga cuidado al construir mensajes mediante programación.

Proveedores de extensiones de vet

Los proveedores de contexto y los proveedores de historial pueden insertar mensajes con cualquier rol, incluido system. Solo adjunte proveedores de confianza.

Tenga en cuenta la inyección de comandos indirecta: si el almacén de datos subyacente está comprometido, el contenido adversarial podría influir en el comportamiento de LLM. Por ejemplo, un documento recuperado a través de RAG podría contener instrucciones ocultas que hacen que LLM se desvíe del comportamiento previsto o filtre los datos a través de llamadas a herramientas.

Validar y sanear la salida de LLM

Las respuestas LLM deben tratarse como salida no fiable. El servicio de IA es un punto de conexión externo que Agent Framework no controla. Tenga en cuenta lo siguiente:

• Alucinación — los LLM pueden generar información que suena plausible aunque sea incorrecta. No considere la salida de LLM como autoritativa sin verificación.
• Inyección indirecta de solicitudes: datos recuperados por herramientas, proveedores de contexto o de historial de chat pueden contener contenido adversarial diseñado para influir en el modelo de lenguaje extenso (LLM).
• Cargas malintencionadas : la salida LLM puede contener contenido que es perjudicial si se representa o ejecuta sin sanear (HTML/JavaScript para XSS, SQL para inyección, comandos de shell).

Valide y sane siempre la salida de LLM antes de representarla en HTML, ejecutarla como código, usarla en consultas de base de datos o pasarla a cualquier contexto sensible a la seguridad.

Protección de datos confidenciales en registros

Agent Framework admite el registro y la telemetría a través de OpenTelemetry. Los datos confidenciales solo se registran cuando se habilitan explícitamente:

• Registro — En el nivel de registro Trace, se registra la colección completa ChatMessages. Esto puede incluir PII. Trace nunca se debe habilitar el nivel en producción.
• Telemetría — Cuando EnableSensitiveData se establece, la telemetría incluye el texto completo de los mensajes de chat, incluidas las llamadas de función y los resultados. No habilite esto en producción.

Protección de los datos de sesión

Las sesiones (AgentSession) representan el contexto de conversación y se pueden serializar para la persistencia. Trate las sesiones serializadas como datos confidenciales:

• Las sesiones pueden hacer referencia a contenido de conversación o identificadores de sesión.
• Restaurar una sesión desde un origen que no es de confianza equivale a aceptar entradas que no son de confianza. Un back-end de almacenamiento comprometido podría modificar los roles para escalar privilegios.
• Almacene las sesiones en un almacenamiento seguro con controles de acceso y encriptación adecuados.

Implementación de límites de recursos

Agent Framework no impone restricciones en la longitud de entrada/salida ni en las tasas de solicitud, ya que no sabe lo que es razonable para su escenario. Usted es responsable de:

• Límites de longitud de entrada: restrinja la longitud de entrada para evitar ataques de desbordamiento de contexto o doS.
• Límites de longitud de salida : use límites proporcionados por el servicio (por ejemplo, MaxOutputTokens en opciones de chat).
• Limitación de velocidad: use las instalaciones de limitación de velocidad para evitar saturaciones de costos y abuso de solicitudes simultáneas.

Pasos siguientes

Introducción a las herramientas

Contenido relacionado

• Herramientas de funciones
• Observabilidad
• Proveedores de contexto