por AgentPolicy (LX AI)

Herramientas permitidas vs agentes de fin abierto

El atractivo de un agente de fin abierto es real: dale una shell, un navegador y un buzón, y puede resolver problemas que no has programado. El costo es el radio de acción. Cada herramienta que agregues es un camino que una instrucción inyectada puede recorrer. La pregunta de diseño no es si otorgar capacidad, sino cómo otorgarla de manera lo suficientemente estrecha como para que un paso en falso se mantenga contenido.

Definiciones de herramientas de privilegios mínimos

Comienzo escribiendo un contrato de herramienta que establece exactamente lo que el agente puede hacer y lo que no puede hacer. Una herramienta de "lectura de ticket" solo debe exponer una operación GET en un identificador de ticket específico, sin capacidad para mutar el ticket, adjuntar archivos o llamar a otros endpoints. Una herramienta de "envío de correo electrónico" solo debe aceptar una lista de destinatarios predefinida, una plantilla de asunto fija y un cuerpo que esté sanitizado para la inyección de nuevas líneas. Al reducir el contrato, un solo error en la salida del modelo se convierte en un evento limitado en lugar de una cascada.

Definir el conjunto de verbos

Enumerar cada método HTTP, comando de base de datos o operación de archivo que la herramienta necesita. Si la herramienta solo necesita leer, omitir POST, PUT, DELETE y cualquier comando administrativo. Mantengo una hoja de cálculo que asigna cada nombre de herramienta a los verbos permitidos y la reviso cada vez que se agrega un nuevo endpoint.

Restringir argumentos

Para cada argumento, especifico un tipo, un límite de longitud y un conjunto de caracteres permitidos. Un ID de ticket podría ser un UUID, limitado a 36 caracteres. Una ruta de archivo podría estar restringida a un subdirectorio bajo /var/agent/data y no debe contener ".." o rutas absolutas. Utilizo una biblioteca de validación de esquemas que rechaza cualquier solicitud que no se ajuste antes de que se ejecute la herramienta.

Versionar el contrato

Almaceno la definición de la herramienta como un archivo JSON en control de versiones. Cualquier cambio desencadena una solicitud de extracción que requiere la firma de un revisor de seguridad. Esto crea un registro de auditoría que muestra cuándo se amplió la superficie de privilegios y por qué.

Para ver cómo la inyección de prompts puede abusar de herramientas excesivamente amplias, revise la guía OWASP LLM01: https://genai.owasp.org/llmrisk/llm01-prompt-injection. La hoja de trucos muestra ejemplos concretos donde un modelo fue engañado para invocar un comando de shell porque la herramienta aceptaba entrada sin restricciones.

Nombre de la herramienta | Verbo permitido | Restricciones de argumentos | Llamada segura de ejemplo read_ticket | GET | ticket_id: UUID, 36 caracteres | /tickets/123e4567-e89b-12d3-a456-426614174000 send_email | POST | para: lista desde dominios aprobados, asunto: máximo 78 caracteres, cuerpo: sanitizado | {"para":["usuario@example.com"],"asunto":"Actualización","cuerpo":"Por favor revise el informe adjunto."} list_files | GET | ruta: debe comenzar con /var/agent/data/, no ".." | /var/agent/data/logs/2024-09-01.txt

Confirmación de acciones irreversibles

Las acciones que cambian el estado fuera del sandbox del agente, como enviar un mensaje, eliminar un registro o implementar una compilación, deben estar limitadas por un paso de aprobación separado que el agente no puede invocar en sí mismo. Trato estas como puertas de un solo sentido y diseño la política para requerir un token humano o un servicio de aprobación de corta duración antes de que se ejecute la herramienta.

Punto final de aprobación separado

Expongo una API interna que acepta una solicitud firmada del agente, registra la solicitud y luego espera a que un humano haga clic en "aprobar" en una interfaz de usuario o responda a un comando de chat. El agente solo recibe un identificador pendiente; no puede sondear el punto final de aprobación para forzar una concesión.

Tokens limitados por tiempo

Cuando se otorga la aprobación, el sistema emite un token que es válido para un solo uso y caduca después de cinco minutos. El punto final de la herramienta verifica la firma y la caducidad del token antes de proceder. Si el token está ausente o está obsoleto, la herramienta devuelve un error y el intento se registra.

Registro de la puerta

Cada solicitud de aprobación y decisión se escribe en un registro inmutable con marcas de tiempo, el identificador del agente, el nombre de la herramienta y los argumentos que se presentaron. Este registro me permite reconstruir si una instrucción envenenada logró evadir la puerta o fue detenida en el paso de aprobación.

Para obtener orientación sobre la higiene de credenciales en pipelines automatizados, consulte la hoja de riesgos de seguridad de CI/CD de OWASP: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Refuerza el principio de que los secretos nunca deben almacenarse en un lugar donde un agente pueda leerlos sin un flujo de aprobación explícito.

Registros de auditoría como un control, no como un pensamiento posterior

Trato el registro de auditoría como la principal evidencia de que una política se está aplicando. Sin un registro confiable, las declaraciones sobre privilegios mínimos son afirmaciones no verificables. Diseño la capa de registro para que sea de solo escritura desde la perspectiva del agente y se almacena en un sistema que el agente no puede alterar o eliminar.

Qué registrar

- Marca de tiempo con precisión de milisegundos - Identificador del agente (versión del modelo, ID de implementación) - Nombre de la herramienta y el verbo exacto llamado - Todos los argumentos pasados a la herramienta, después de la validación - Código de estado de resultado y resumen de los datos devueltos (tamaño, no contenido completo) - Origen de la solicitud (iniciada por el usuario, activador programado o motor de políticas)

Garantías de almacenamiento

Escribo cada entrada de registro en un almacenamiento de solo agregar, como un registro de anticipación en un bucket de almacenamiento en la nube con versionado de objetos habilitado. La política del bucket deniega cualquier operación de eliminación o sobrescritura desde la cuenta de servicio del agente. Esto garantiza que incluso si el modelo se ve comprometido, la historia permanece intacta.

Consulta para investigaciones

Cuando se informa un incidente, ejecuto una consulta SQL simple en el índice de registro para encontrar todas las ejecuciones de una herramienta determinada dentro de una ventana de tiempo. Evito uniones complejas que podrían ser lentas; en su lugar, confío en tablas particionadas por fecha y nombre de herramienta. La consulta devuelve la lista de identificadores que luego extraigo para un análisis forense más profundo.

Para comprender cómo la validación de entrada puede prevenir que argumentos maliciosos lleguen a una herramienta, consulte la hoja de trucos de prevención de inyección SQL: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. La hoja muestra consultas parametrizadas y tipificación estricta, que reflejan el enfoque de validación de argumentos que uso para las herramientas del agente.

Cuándo se justifica el acceso de fin abierto

Hay casos legítimos en los que un agente necesita un alcance más amplio, como el análisis de datos exploratorio o la caza de amenazas en un entorno aislado. En esas situaciones, otorgo apertura solo después de haber colocado al agente en una caja de arena que bloquea cualquier ruta a los datos de producción o los sistemas de pago externos.

Límites de la caja de arena

La caja de arena proporciona una shell, un motor de navegador y un buzón que solo puede enviar mensajes a un dominio de prueba dedicado. La política de red bloquea el tráfico saliente a cualquier dirección IP que pertenezca a los rangos de CIDR internos de la empresa. Solo se permite el tráfico de salida a un conjunto de espejos públicos aprobados para la instalación de paquetes.

Aislamiento de credenciales

No se montan secretos de producción en el sistema de archivos de la caja de arena. En su lugar, el agente recibe un token temporal que puede leer desde un bucket de datos público. Si el agente intenta leer un archivo fuera del punto de montaje permitido, el kernel devuelve un error de permiso y el intento se registra.

Sesiones con tiempo límite

Cada sesión de la caja de arena dura como máximo dos horas. Después del tiempo de espera, el entorno se desmonta y se lanza una imagen fresca. Esto limita la ventana durante la cual un agente mal comportado podría explorar o exfiltrar datos.

Todavía aplico definiciones de herramientas de privilegios mínimos dentro de la caja de arena; la diferencia es que las consecuencias de un error se contienen en el entorno desechable en lugar de en los sistemas de producción.

Tratar las políticas generadas como borradores

Cuando un modelo o un ingeniero junior produce un archivo de política, lo reviso exactamente como revisaría código no confiable que está a punto de ser implementado en un servicio crítico. La lista de verificación de revisión incluye verificar cada regla contra las definiciones de herramientas reales, confirmar que existen rutas de denegación y asegurarme de que el archivo esté versionado.

Asignación de reglas a herramientas

Creo una hoja de cálculo que enumera cada herramienta en un eje y cada regla de política en el otro. Para cada celda, marco si la regla permite, deniega o es silenciosa sobre la operación de la herramienta. Cualquier celda silenciosa desencadena un comentario que pide al autor que aclare la intención.

Verificación de denegación por defecto

Ejecuto un script de análisis estático que intenta invocar cada herramienta con un conjunto de argumentos malformados. Si el script encuentra una combinación que la política permite pero que debería ser denegada (por ejemplo, una herramienta de "eliminar" que acepta un identificador de comodín), el script falla la compilación y la política debe ser revisada.

Control de versiones y revisión

El archivo de política vive en un repositorio de Git con protección de rama que requiere dos aprobaciones antes de fusionar. Etiqueto cada versión publicada con un número semántico (por ejemplo, v1.2.0) y adjunto la instantánea de definición de herramienta correspondiente. Esto hace posible revertir a un estado conocido bueno si una nueva versión introduce una regla sobrepermisiva.

Nunca considero que una política generada sea final hasta que haya pasado este ciclo de revisión. Una política que nunca se examina crea una falsa sensación de seguridad y puede ocultar brechas que solo aparecen bajo carga del mundo real.

Qué no es esto

Esta guía no promete que seguir los pasos eliminará todos los modos de fallo posibles. No afirmo una protección del 100 % contra la inyección de instrucciones, la fuga de credenciales o los errores lógicos. También no digo que un agente nunca perderá una instrucción maliciosa; la detección depende de la calidad de los registros, la oportunidad de la revisión humana y la corrección de los contratos de herramientas. Trate los patrones como medidas de reducción de riesgos, no como una garantía de seguridad absoluta.