AI Riesgos de seguridad de los agentes: Construir un libro mayor de amenazas operativas

La forma práctica de manejar los riesgos de seguridad de los agentes de AI consiste en modelar las amenazas de cada operación de efecto secundario antes de la llamada a la herramienta. Registrar qué activo puede cambiar, qué autoridad de identidad proporciona, qué ámbitos se requieren, de dónde proviene la instrucción, cómo se limitará el efecto y qué evidencia hace que un retiro sea seguro. Si algún campo es desconocido, deténgase en ese límite en lugar de pedirle al modelo que deduzca el permiso. Esto produce una decisión útil, no otra lista de riesgos. El operador puede proceder, restringir una credencial, eliminar los permisos excedentes, revisar una instrucción no confiable, definir un límite de efecto o reconciliar un resultado ambigüo antes de volver a intentarlo. Una respuesta válida a la herramienta no es suficiente: la seguridad depende de la autoridad utilizada y del efecto externo producido. El modelo de amenaza de la operación, no sólo el modelo Un agente es más que un LLM. Se une un modelo, tiempo de ejecución, credenciales, herramientas, contenido externo y sistemas de destino en un solo camino de acción. El Seguridad del papel AI Agentes hace esta distinción explícita: los agentes utilizan acciones generadas por modelos para invocar herramientas que pueden afectar a los sistemas reales, creando preocupaciones de confidencialidad, integridad y disponibilidad más allá de la alineación del modelo. Comience con una operación propuesta y trace cuatro límites: 1. Limitación de instrucciones: Intención del usuario, contenido recuperado, salida de herramienta y memoria entran en el contexto del modelo. 2. A límite de autoridad: el tiempo de ejecución adjunta una identidad o credencial a la llamada de herramienta propuesta. 3. E límite de efecto: la herramienta puede leer o cambiar un recurso externo. 4. Retry boundary: resultados inciertos de transporte o de herramientas pueden hacer que el tiempo de ejecución repita un efecto. El Iniciativa de seguridad agencial de la OWASP describe su orientación como una referencia basada en el modelo de amenazas para los riesgos agenciales emergentes. Esa es la postura de inicio correcta: identificar activos, actores, cambios de confianza y posibles efectos antes de elegir controles. Utilice un libro mayor de amenazas a nivel de ejecución en lugar de notas de forma libre: No ponga valores secretos en el libro mayor. Las referencias de almacenamiento, los identificadores del emisor y del público, la expiración, el alcance, la identidad de la operación y las ubicaciones de la evidencia. El artefacto debe responder: ¿qué podría cambiar este funcionamiento, bajo cuya autoridad, y cómo sabremos? El defecto razonable es crear una fila de libro mayor por operación externa. Un modelo general de amenaza a nivel de agente todavía ayuda con la arquitectura, pero no puede decir si este pago en particular, mensaje, liberación o mutación de archivo es seguro ahora. Verificar la identidad de la credencial antes de comprobar la solicitud Una credencial no es segura sólo porque autentica. Para cada operación, registre: quién o qué representa la credencial; el lugar en que se haya emitido y el lugar en que pueda presentarse; si se comparte entre agentes o entornos; su trayectoria de vencimiento y revocación; el público exacto de los recursos; una referencia no secreta que permita a un operador girarla. El Especificación de la autorización del MCP de junio de 2025 es concreto sobre el límite HTTP. Los clientes incluyen un indicador de recursos, los servidores validan que se emitió un token para el público previsto, y una autorización inválida o insuficiente recibe un error. El relacionado Orientación sobre la seguridad de los PCM prohíbe el paso de tokens y explica por qué la confusión de la audiencia debilita los controles, las atribuciones y los límites de confianza. Dichas normas se aplican directamente a las autorizaciones HTTP de MCP. El principio de funcionamiento también funciona bien: nunca dejes que un solo token opaco permanezca en silencio para cada destino. Un token de administrador compartido sin propietario de tarea y sin audiencia estrecha puede funcionar perfectamente mientras destruye la atribución y aumenta el radio de explosión. Las credenciales de salud y la seguridad de las instrucciones son separadas. Una solicitud limpia no puede reparar un token expirado, y un token válido no hace que una instrucción no confiable sea legítima. Compruebe la evidencia de credenciales primero porque cada control posterior depende de saber qué identidad cruzará los límites de la herramienta. Cuando faltan pruebas, use stop credential , no probablemente autorizado. La reparación es mecánica: emita una credencial de corta duración, revocable para el agente exacto, la tarea, el público y el entorno. Mantenga el modelo fuera de esa decisión. Comparar el permiso requerido con el permiso otorgado El privilegio mínimo se vuelve verificable sólo cuando se comparan dos conjuntos para una operación: Si surplus no está vacío, detenga y reemplace la subvención. Una herramienta permitida no es suficiente. El mismo cliente de herramientas puede llevar ámbitos no relacionados con el trabajo actual, y esos permisos latente se vuelven disponibles cuando el contexto se envenena, un argumento de herramienta se sustituye, o el modelo simplemente elige la operación equivocada. También rechazará los escopes requeridos que faltan. Este caso suele ser menos peligroso que el de la autoridad excesiva, pero crea retos ruidosos y fomenta soluciones inseguras como el intercambio de credenciales más amplias. Una discrepancia de permisos debería producir un estado explícito y una reparación, no una invitación para que el agente cace secretos más fuertes. Las verificaciones de permisos requieren una descripción de los efectos. Usar la herramienta de repositorio es demasiado amplio; crear un candidato de liberación en el repositorio X proporciona un límite de recursos e impacto. Enlazar la aprobación, si es necesario, con la descripción congelada. La revisión humana es valiosa para operaciones de alto impacto o sin confianza, pero no se debe pedir a una persona que apruebe una acción que todavía tenga recursos sin nombre o efectos ilimitados. Aquí es donde un modelo de amenaza difiere de una implementación de barandillas. El libro mayor de amenazas identifica la autoridad y el efecto que requieren protección. La política, la aprobación, el sandboxing y la verificación son controles seleccionados posteriormente. Comenzando con los controles solos a menudo deja a los equipos protegiendo el instante mientras que una credencial sobresaliente permanece sin cambios. Tratar las instrucciones, los efectos y los retos como riesgos separados El contenido externo puede influir en un agente sin convertirse en autoridad. La dirección de origen de la instrucción se marcará como trusted , untrusted external content o mixed . Si el contenido no confiable contribuye a una acción con efectos secundarios, congelar el recurso y los argumentos propuestos, entonces requerir una decisión de política o revisión humana fuera de esa ruta de contenido. No resuelva esto eliminando todas las instrucciones externas. Un agente puede necesitar documentos recuperados o la salida de herramientas para trabajar. El límite de seguridad es si ese contenido puede silenciosamente elegir un efecto privilegiado. Un análisis de sólo lectura y un envío de mensaje público no deben compartir la misma regla de revisión. A continuación, define el efecto independientemente de la respuesta de la herramienta: el recurso de destino exacto; el número máximo o el tamaño de los cambios; la reversibilidad y el titular del retroceso; identidad de operación estable; una lectura de la información o otra prueba de resultados autorizada. Los retries merecen su propia fila porque un tiempo de espera no significa nada sucedió. El AWS Builders Guía de la biblioteca sobre las APIs idempotentes muestra cómo un identificador de solicitud de cliente estable puede hacer que las solicitudes repetidas sean semánticamente equivalentes. Ese contrato admite los intentos de seguridad por defecto. No autoriza la acción original, y no ayuda si el tiempo de ejecución genera un nuevo identificador para el segundo intento. Después de una pausa ambigua, utilice este orden: 1. mantener la identidad original de la operación; 2. hacer consultas sobre el destino autorizado; 3. clasificar el efecto como presente, ausente, parcial o desconocido; 4. reutilizarse únicamente cuando el contrato garantice la seguridad de otro intento; 5. verificar el resultado prometido después del intento final. Si el destino no ofrece ninguna idempotencia ni búsqueda de efectos, el estado correcto es reconcile before retry . Eso puede requerir a una persona. Aún es mejor que convertir la evidencia de transporte faltante en un pago duplicado, mensaje, liberación o eliminación. Reproduce el libro de amenazas de nueve casos El dispositivo de acompañamiento hace inspectable la regla de decisión. security risk cases.json contiene nueve operaciones propuestas. evaluate ai agent threat ledger.mjs comprueba los límites en orden fijo: 1. Presencia de credenciales, vencimiento, intercambio, revocabilidad y audiencia; 2. los ámbitos requeridos frente a los ámbitos concedidos; 3. procedencia no fiable de las instrucciones de escritura; 4. la definición del recurso y del efecto máximo; 5. la identidad de la operación, la idempotencia y la reconciliación antes de los retos; 6. pruebas de efecto independientes. Ejecutar con: El resumen reproducido es el siguiente: Sólo dos casos continúan. Uno es una lectura limitada. El otro es una escritura idempotente con una audiencia exacta, un conjunto exacto de alcance, un recurso nombrado, un impacto máximo y evidencia independiente. Los demás casos muestran una credencial compartida de administrador, un token de tarea expirado, un alcance de eliminación de excedentes, una instrucción externa no revisada, una exportación ilimitada, un nuevo intento con una nueva identidad de operación y una respuesta de éxito sin prueba de efecto. El orden es importante. Si se verifica el permiso antes de la audiencia de credenciales, un token de interconexión de servicios puede parecer seguro porque su alcance coincide. Si se comprueba la evidencia de efecto antes de volver a probar la identidad, el operador podrá etiquetar la carrera simplemente como incompleta mientras ya sea posible otro intento inseguro. El primer límite inseguro de confianza debe determinar la disposición. Adapte el dispositivo con sus escalones y efectos reales. Agregue una ruta de revocación faltante, entorno incorrecto, aprobación obsoleta, sustitución de recursos, escritura parcial, falla de retroceso y desacuerdo entre la salida de la herramienta y el estado de destino. El objetivo no es predecir cada ataque. Es hacer que la autoridad y la incertidumbre sean imposibles de ocultar dentro de un estado de agente verde. Mantenga operativo el modelo de amenaza Revisar el libro mayor cuando una herramienta, alcance, emisor de credenciales, API de destino, política de retoma o fuente de instrucciones cambie. No requiere un taller completo para cada ejecución; genera la mayoría de los campos a partir de esquemas de herramientas, metadatos de identidad, recibos de política y operación, luego pregunta a una persona solo sobre el impacto o la incertidumbre que el código no puede resolver. La regla de la decisión compacta es: Procede solo cuando la identidad está limitada a la audiencia, los permisos son iguales al conjunto requerido, las instrucciones no confiables no pueden autorizar silenciosamente los efectos, el impacto está limitado, los retemptos preservan la identidad de la operación, y el destino puede probar el resultado. Esta regla tiene límites. Los metadatos pueden mentir o quedarse obsoletos. Un alcance exacto puede permitir aún un argumento peligroso. La impotencia puede expirar. Un canal de lectura de nuevo puede ser comprometido con el escritor. Por lo tanto, el libro mayor reduce la ambigüedad; no demuestra que todo el sistema sea seguro. Combínalo con la autorización a continuación, aislamiento, registros de auditoría, pruebas y respuesta a incidentes apropiados para el impacto. 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. Este patrón de registro de amenazas es algo que los operadores pueden implementar en su propio tiempo de ejecución ahora, no una afirmación de que Sidewisp actualmente asegura o monitorea agentes en vivo. Si está evaluando a Sidewisp para futuros flujos de trabajo en materia de salud para agentes, únase a la vista previa privada. Hasta entonces, mantenga el libro de amenazas cerca del límite de la herramienta y deje que la evidencia desconocida detenga la acción antes de que se convierta en un incidente.