AI Agente Guardrails: Construye una Puerta de Acción de Cuatro Controles

Las barandillas del agente AI no deben tener un solo aviso, un solo clasificador o un solo botón de aprobación. Para un agente que puede cambiar el estado externo, el defecto práctico es una puerta de acción de cuatro controles: decidir si la acción está permitida, demostrar que el que llama tiene autoridad para esta acción exacta, vincular el intento, luego verificar el efecto externo. Cada control responde a una pregunta diferente. Combinándolas en una sola bandera safe: true esconde si un agente está bloqueado, esperando a una persona, fuera del presupuesto de retraso, o simplemente falta evidencia después de una llamada de herramienta. Mantenga esos estados separados y el sistema puede fallar cerrado sin tratar cada pausa como un incidente. Poner la política en el límite de la acción Comience reduciendo lo que el agente puede pedirle a una herramienta. Un portal de políticas debe recibir datos de acción estructurados, no sólo en prosa: El resultado de la política debe ser uno de allow , deny o unknown . Unknown es importante. Una clasificación faltante no es un permiso, y obligar a la ambigüedad en allow o deny hace que el modelo invente certeza en nombre del operador. Esta puerta también debe comprobar si la herramienta pertenece al conjunto de capacidades del agente. El Orientación de la OWASP sobre la agencia excesiva identifica la funcionalidad excesiva, los permisos y la autonomía como causas raíz separadas. Sus mitigaciones son, en consecuencia, concretas: exponer solo las extensiones necesarias, preferir funciones estrechas a los comandos abiertos, otorgar permisos mínimos en aguas posteriores y hacer cumplir las autorizaciones en el sistema en aguas posteriores. Ese último límite importa. Una instrucción como never delete production data es útil en el contexto, pero no es un control de autorización. Un punto final de eliminación debe rechazar una identidad no autorizada incluso cuando un agente produce una razón persuasiva. Del mismo modo, un flujo de trabajo solo para lectura no debe recibir a un cliente cuyas credenciales pueden escribir. Los modelos de barandillas todavía tienen un trabajo, pero conozcan su momento. El Documentación del SDK de OpenAI Agents distingue los barandillas de entrada/salida del agente de los barandillas de herramienta de función. También señala que un protector de entrada paralelo puede terminar después de que el agente ya haya consumido tokens o herramientas ejecutadas. Para un límite de efectos secundarios, utilice un cheque de bloqueo inmediatamente antes de la ejecución, respaldado por una autorización real a continuación. El defecto razonable es: rechazar herramientas fuera de una lista de permisos por agente; calcular los ámbitos requeridos a partir de la acción estructurada; hacer cumplir dichos ámbitos fuera del modelo; cuando las entradas de política no sean completas, devuelvan unknown ; Registrar la versión de la política y el documento de acción junto con la decisión. Los filtros de contenido no reemplazan esta puerta. Documentación de barandillas de seguridad Connect AI de AWS cubre temas rechazados, filtros de contenido, comprobaciones de tierra, filtros de palabras y controles de información sensible, al tiempo que documenta los límites de configuración y las compensaciones de latencia. Estas son garantías útiles para las entradas y salidas. No demuestran que una liberación, un pago, un mensaje o una mutación de archivo estén autorizados. Atópense la aprobación a una acción, no a una conversación. Approved es demasiado vago para ejecutarse. Una aprobación segura es un envase de corta duración de la autoridad vinculado a la acción exacta de la persona revisada. Por lo menos, persista: Recompite el proceso de acción inmediatamente antes de la ejecución. Si el recurso, los argumentos, el actor, la herramienta, el impacto o la expiración difieren, la aprobación no coincide. Pregunte de nuevo en lugar de extender una vieja decisión sobre un nuevo trabajo. Esto evita una clase silenciosa pero seria de fracasos. Una persona puede aprobar un candidato de liberación para un repositorio, luego el contexto del agente cambia, un intento de reconstrucción de diferentes argumentos, o otra ejecución reutiliza el mismo estado de conversación. Un booleano libre flotante sobrevive a los tres errores. Un recibo vinculado a la acción no lo hace. La aprobación también requiere un propietario y un estado reiniciable. awaiting approval no es stuck : tiene una decisión nombrada, una ruta a la persona adecuada y una caducidad. Después de una decisión, reanudar desde el paquete de acción congelada en lugar de volver a ejecutar la planificación y esperar que el modelo proponga la misma operación. No todas las acciones necesitan a un humano. Utilice el impacto para decidir: las acciones de escaso alcance, sólo de lectura, reversibles, podrán proceder en el marco de una política permanente; los cambios con retroceso limitado y bien probado podrán utilizar límites y auditorías explícitos; las acciones públicas, financieras, destructivas, de cambio de privilegios o de otro modo de alto impacto requieren una aprobación exacta; Ambigüedad sobre las rutas de impacto a una persona. Por lo tanto, la revisión humana es un control dentro de la pila, no la pila misma. Ejecución restringida incluso después de la autorización Una acción permitida y aprobada puede seguir funcionando mal. El ejecutor necesita límites severos que el agente no puede renegociar en silencio: un plazo absoluto, verificado antes de cada intento; un número máximo de intentos; una clave de impotencia para los efectos secundarios; un límite máximo de recursos y de impacto; una ruta de cancelación; una regla para lo que sucede cuando el resultado es ambigüo. La identidad de la operación debe mantenerse estable a lo largo de los retemplazos. Si se produce una suspensión de tiempo de transporte después de que el destino haya cometido un cambio, la emisión de una nueva identidad de operación puede duplicar el efecto. Si el destino admite la idempotencia, reutilice la misma llave. Si ofrece una búsqueda autorizada, reconciliarse antes de volver a intentarlo. Si ninguno de los dos existe, deja de usar unverified en lugar de adivinar que otro intento es seguro. Mantenga el ejecutor en estado mecánico. Un modelo puede recomendar una nueva prueba, pero el código debe decidir si attempt < maxAttempts , el plazo es nuevo, el recurso sigue coincidiendo, y la acción tiene una clave de idempotencia utilizable. Este es uno de los raros lugares donde los condicionantes aburridos son exactamente el diseño correcto. Los límites no son sólo para contener los daños. Ellos preservan el diagnóstico. Sin ellos, una llamada repetida puede parecer persistencia, una operación expirada puede parecer progreso lento, y un efecto duplicado puede parecer recuperación. Con límites explícitos, el operador puede distinguir los estados de trabajo, espera, bloqueo e incertidumbre. Verifique el efecto de forma independiente. Una respuesta de la herramienta demuestra lo que la herramienta informó, no necesariamente lo que el usuario necesitaba. La puerta final compara una postcondición observable con el resultado prometido. Prefiero pruebas deterministas: Recoger el objeto creado mediante ID estable; leer la sucursal de destino o el registro de liberación; comprobar que el archivo esperado existe y que coincide con el hash; ejecutar los ensayos pertinentes; confirmar que aparece un mensaje en el destino previsto; comparar los valores antes y después del recurso exacto. No utilice la misma señal débil dos veces. Si el punto final de escritura devuelve { "ok": true } , copiar ese campo en un registro de finalización no es una verificación independiente. Lea desde el destino autorizado o inspeccione el producto prometido. Algunos resultados no pueden ser verificados de inmediato. Se puede aceptar una notificación pero no entregarla, un proveedor externo puede carecer de una API de lectura o un canal de observación puede estar obsoleto. Representar que como unverified , incluya la evidencia que falta y la próxima verificación segura, y evite reportar el éxito. Aquí es donde la salud y la seguridad operativas se encuentran. La política y la autorización impiden las acciones prohibidas; la verificación de efectos evita la realización falsa. Un agente puede obedecer todas las reglas de acceso y aún así fracasar en su tarea. Por el contrario, un resultado exitoso no excusa un camino no autorizado. Repite nueve casos antes de confiar en el diseño El artefacto que acompaña convierte los cuatro controles en una pequeña prueba ejecutable. La guardrail cases.json contiene nueve acciones propuestas. El evaluate agent guardrails.mjs se aplicará una prioridad fija: 1. la política; 2. el alcance y la autoridad de homologación; 3. límites de ejecución; 4. pruebas de efecto. Ejecutar con: El resumen reproducido es el siguiente: Los casos interesantes no son el paso limpio o la negación obvia. Una aprobación ha expirado. Otro fue emitido para una huella digital de acción diferente. Una carta agotó su presupuesto para volver a intentarlo. Un comando se ejecutó sin efecto observable. Una política no puede clasificar la acción en absoluto. Estos casos muestran por qué la prioridad del Estado debe ser explícita. Compruebe primero la evidencia del efecto y una acción no autorizada podría ser etiquetada simplemente no verificada. Compruebe la aprobación antes de la póliza y puede pedirle a una persona que autorice una herramienta que nunca debería haber estado disponible. Collapso desconocido en negación y el operador pierde una señal de calidad de datos reparable; collapso en permitir y el sistema inventa autoridad. Adapte el accesorio a sus propias herramientas. Añadir casos de sustitución de recursos, pérdida de alcance, no uso de aprobaciones, versiones obsoletas de políticas, caducidad de plazo, efectos parciales, fallas de retroceso y un canal de verificación que no esté de acuerdo con la respuesta de la herramienta. La puerta está lista sólo cuando esos fracasos producen el estado y la próxima acción que pretendiste. Mantenga la frontera honesta Las barandillas de seguridad de los agentes AI funcionan cuando cada control puede vetar la acción por su propia razón y exponer pruebas de esa decisión. La regla es: La política decide si la acción pertenece. La autoridad obliga a quién puede hacer exactamente qué. Los límites limitan el intento. La verificación demuestra el efecto. Esto cuesta más que añadir un clasificador. Las aprobaciones exactas añaden tiempo de espera. Los cheques de lectura después de escritura añaden llamadas. Las herramientas estrechas requieren ingeniería. Los estados desconocidos necesitan el manejo del operador. El comercio vale la pena para los efectos secundarios porque la ambigüedad permanece visible en lugar de convertirse en autoridad silenciosa o falso éxito. Sidewisp se encuentra actualmente en versión preliminar privada. Está destinado a ser una capa de salud alrededor de los tiempos de funcionamiento de los agentes existentes, pero la recogida y recuperación de los agentes de producción salud no se envían en el repositorio actual del sitio web. La pila de control aquí es un patrón de implementación que puedes probar ahora, no una afirmación de que Sidewisp actualmente lo impone. Si está evaluando a Sidewisp para futuros flujos de trabajo en materia de salud para agentes, únase a la vista previa privada. Mientras tanto, mantenga el sobre de acción y sus pruebas en su propio tiempo de ejecución: el barranco de seguridad más seguro es el que aún se mantiene cuando el modelo está confidentemente equivocado.