Límites de agente asignados al marco de gestión de riesgos de inteligencia artificial de NIST

Por qué construí AgentGuard

Comencé AgentGuard después de ver a un equipo enviar un agente impulsado por que podía leer una base de datos, llamar a una API de pago y enviar un correo electrónico, todo con una sola solicitud. El agente funcionó en la demostración, pero un simple error de escritura en la consulta del usuario hizo que transfiriera dinero a la cuenta incorrecta. Nadie había verificado qué podía hacer el agente antes de la llamada, y no había forma de detenerlo una vez que ocurrió el error.

Me di cuenta de que el problema no era el modelo en sí, sino los límites que faltaban alrededor de sus acciones. Quería una forma repetible de enumerar cada herramienta a la que puede acceder un agente, decidir quién puede habilitar cada herramienta, probar al agente contra los permisos que creemos que tiene, y reaccionar cuando algo sale mal. El marco de gestión de riesgos de inteligencia artificial de NIST me dio las cuatro funciones que se alinean exactamente con esos pasos.

Conceptos básicos: filtros de entrada, permisos de herramientas, verificaciones de salida

Filtros de entrada

Estos son controles que se ejecutan en la solicitud del usuario o en la lógica interna del agente antes de invocar una herramienta. Ejemplos incluyen:

- Detección de patrones de inyección de solicitud que intentan ignorar instrucciones anteriores. - Verificación de palabras clave o frases no permitidas que indiquen una solicitud para acceder a un sistema restringido. - Validación de que la solicitud contiene un token de aprobación requerido cuando se hace referencia a una herramienta de alto riesgo.

Implementamos filtros de entrada como motores de regex ligeros combinados con una pequeña lista de permitidos de patrones seguros. Agregan menos de dos milisegundos de latencia por llamada.

Permisos de herramientas

Los permisos de herramientas definen qué datos puede leer, escribir o eliminar una herramienta y qué servicios externos puede contactar. Almacenamos cada permiso como una tupla:

- Identificador de herramienta - Fuentes de datos permitidas (por ejemplo, acceso de solo lectura a la tabla de clientes, acceso de escritura al registro de auditoría) - Destinos de red (por ejemplo, api.paymentprovider.com en el puerto 443) - Nivel de aprobación requerido (ninguno, revisión de pares, firma del gerente)

Cuando el agente solicita usar una herramienta, el servicio de permisos verifica la tupla contra el contexto actual y permite la llamada, modifica los parámetros o la bloquea.

Verificaciones de salida

Después de que una herramienta devuelve un resultado, las verificaciones de salida verifican que la respuesta se mantenga dentro de los límites esperados. Ejemplos:

- Asegurarse de que una consulta SQL devuelva no más de 100 filas. - Confirmar que la carga de correo electrónico no contiene URLs externas. - Escanear en busca de secretos filtrados, como claves de API o contraseñas, en la respuesta.

Si una verificación falla, el sistema puede truncar el resultado, ocultar bits sensibles o activar una alerta.

Asignación de guardrails a las funciones de NIST AI RMF

El marco de cuatro funciones proporciona una estructura clara para organizar el trabajo de guardrails. A continuación, se muestra una tabla que indica a qué función pertenece cada guardrail, el artefacto concreto que producimos y un ejemplo breve.

Función de NIST | Tipo de guardrail | Artefacto | Ejemplo Gobernar | Flujo de trabajo de aprobación | Registro de habilitación de herramientas | Un documento firmado que enumera quién aprobó la herramienta send_email, la fecha y el MFA requerido para el aprobador. Mapa | Inventario de herramientas | Matriz de permisos | Una hoja de cálculo que enumera cada herramienta, las tablas que puede leer/escritura, y los puntos finales externos que puede llamar. Medir | Conjunto de pruebas | Conjunto de solicitudes adversas | Una colección de solicitudes diseñadas para desencadenar una escalada de privilegios, exfiltración de datos o llamadas externas no autorizadas. Administrar | Respuesta en tiempo de ejecución | Registro de interruptor de seguridad | Una entrada con marca de tiempo que registra cuándo el agente intentó eliminar un registro de producción, la acción que se bloqueó y el operador que fue notificado.

Cada función se basa en la anterior. Gobernar decide quién puede agregar una nueva herramienta al inventario. Mapa crea el inventario que Medir probará. Medir produce evidencia que Administrar puede actuar. El ciclo se repite cada vez que cambia la lista de herramientas o la solicitud del agente.

Cómo evaluamos una herramienta de llamada

Paso 1: Identificar la herramienta y su clase de permiso

Comenzamos buscando la herramienta en la matriz de permisos. La matriz asigna un nivel de riesgo base:

- Búsqueda de solo lectura (por ejemplo, recuperación de un catálogo de productos) → bajo

- Escritura en un registro interno → medio

- Acción externa con efectos secundarios (por ejemplo, envío de dinero, eliminación de un registro) → alto

Si la herramienta requiere un token de aprobación, agregamos un nivel al riesgo base.

Paso 2: Analizar la solicitud para el riesgo de inyección

Ejecutamos la solicitud del usuario a través del motor de filtro de entrada.

Paso 3: Verificar la sensibilidad de los datos

Examinamos las fuentes de datos que la herramienta puede acceder. Si alguna fuente contiene información de identificación personal (PII) o datos financieros, agregamos otro nivel.

Paso 4: Producir la calificación final y los filtros sugeridos

La calificación final es la suma de los ajustes del nivel base, del nivel de solicitud y del nivel de datos. Según la calificación, recomendamos:

- Bajo → no se aplica ningún filtro adicional, solo se registra la llamada.

- Medio → agregar un filtro de entrada que elimine las palabras clave no permitidas y una comprobación de salida que limite el recuento de filas.

- Alto → requiere una aprobación humana en el bucle, aplicar una lista de permitidos estricta de parámetros y habilitar la redacción completa de la salida.

Qué es lo que esto NO es

Quiero dejar claro los límites de las barreras de seguridad para que no las confundas con una bala de plata.

- Las barreras de seguridad no garantizan que un agente nunca cause daño. Reducen el radio de acción de un error, pero un atacante determinado o una herramienta mal configurada aún pueden producir efectos no deseados dentro del límite permitido. - No reemplazan las prácticas de codificación seguras. Si la herramienta subyacente tiene una vulnerabilidad (por ejemplo, un error de inyección SQL descrito en la hoja de trucos de inyección SQL https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), la barrera de seguridad no puede corregir ese error. - No proporcionan una certificación de seguridad del 100 %. Piensa en ellas como ayudas para la toma de decisiones que te ayudan a tomar decisiones informadas sobre el uso de herramientas. - No son una configuración de establecer y olvidar. Cada vez que el prompt del agente, la lista de herramientas o los datos a los que una herramienta puede acceder cambian, debes volver a ejecutar el proceso de revisión.

Poniendo en práctica: un flujo de revisión paso a paso

1. Recopilar el sistema de inicio y la lista de herramientas del agente

Exportar el texto exacto que el agente recibe al inicio y el archivo JSON o YAML que declara cada herramienta que puede llamar.

2. Rellenar la matriz de permisos

Para cada herramienta, registrar:

- Objetivos de lectura permitidos - Objetivos de escritura permitidos - Puntos finales externos y autenticación requerida - Cualquier token de aprobación o rol necesario

3. Ejecutar la calificación de riesgo basal

Aplicar el proceso de calificación de cuatro pasos descrito anteriormente. Registrar el nivel de riesgo inicial para cada herramienta.

4. Generar sugerencias de filtros de entrada y salida

Basado en el nivel de riesgo, producir reglas de filtro concretas (patrones de regex, límites de recuento de filas, reglas de redacción). Almacenarlos junto con la definición de la herramienta.

5. Ejecutar la suite de pruebas adversarias

Ejecutar el agente contra el conjunto de prompts de la columna Medir de la tabla. Verificar que los filtros bloquean o mitiguen los modos de fallo esperados.

6. Documentar el resultado

Crear un informe breve que enumere:

- Nombre de la herramienta - Calificación de riesgo inicial - Filtros aplicados - Resultados de las pruebas (aprobado/reprobado) - Cualquier paso de aprobación manual requerido

7. Configurar el monitoreo y las alertas

Configurar el entorno de ejecución del agente para registrar cada llamada a la herramienta, los filtros aplicados y los resultados de la comprobación de salida. Enviar anomalías a su canal de respuesta a incidentes.

8. Programar un disparador de revisión

Marcar el flujo de trabajo para repetir cuando ocurra alguno de los siguientes eventos:

- Se agrega una nueva herramienta a la lista - Se edita el sistema de inicio - Cambian los permisos de una herramienta (por ejemplo, una base de datos gana una nueva columna con PII)

Errores comunes y cómo los evitamos

Error 1: Dependencia excesiva de un solo tipo de filtro

Los equipos a veces piensan que agregar un bloqueador de palabras clave es suficiente. Contrarrestamos esto requiriendo controles de entrada y salida para cualquier herramienta de riesgo medio o alto, y registramos cuando se active alguno de los controles.

Error 2: Olvidar actualizar la matriz de permisos

Cuando una herramienta adquiere una nueva capacidad (por ejemplo, una API de pago ahora admite reembolsos), la matriz debe editarse antes de que el agente pueda usarla. Lo aplicamos haciendo que la matriz sea un archivo de control de versiones que la tubería CI valida en cada push.

Error 3: Ignorar herramientas de bajo riesgo que se convierten en de alto riesgo en contexto

Una búsqueda de solo lectura que devuelve la dirección de correo electrónico de un usuario puede volverse peligrosa si el agente luego usa esa dirección en un flujo de restablecimiento de contraseña. Tratamos la sensibilidad de los datos como un factor de calificación separado, por lo que una herramienta de bajo nivel que toca la información de identificación personal (PII) se actualiza automáticamente.

Error 4: Saltarse el paso de intervención humana para herramientas de alto riesgo

Para herramientas que pueden mover dinero o eliminar registros, exigimos un paso de aprobación explícito que no puede ser omitido por la automatización. La aprobación se registra en un registro inmutable.

Error 5: Tratar la configuración de la barrera de seguridad como una tarea de una sola vez

Incorporamos el flujo de trabajo de revisión en la definición de terminado del equipo para cualquier función que cambie el comportamiento del agente. Esto hace que el proceso sea repetible en lugar de un elemento de lista olvidado.

Referencias

- https://genai.owasp.org/llmrisk/-prompt-injection - https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene - https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

Preguntas frecuentes

¿Hacen las barreras de seguridad que un agente sea seguro?

No. Restringen el radio de acción de un error. Un atacante determinado, una herramienta mal configurada o una mala solicitud aún pueden causar daño dentro del límite que se permitió.

¿Qué necesitamos para realizar una revisión?

La solicitud del sistema del agente y su lista de herramientas. Eso es suficiente para calificar las llamadas y sugerir filtros.

¿Es el mapeo de la Ley de Inteligencia Artificial de la UE un asesoramiento legal?

No. Es un mapeo para ayudarlo a encontrar las obligaciones adecuadas. Clasificar su sistema y cumplir con las obligaciones aún necesita un revisor calificado.

¿Con qué frecuencia debemos volver a ejecutarlo?

Cada vez que cambie la lista de herramientas, la solicitud del sistema o los datos a los que puede acceder una herramienta.

¿Prueba el agente en tiempo de ejecución?

Revisa la solicitud y la configuración de la herramienta. La supervisión en tiempo de ejecución es una capa separada que aún necesita.

¿Qué sucede si una herramienta es genuinamente de alto riesgo?

Requiere un paso de aprobación, limita sus parámetros y registra cada invocación. Las herramientas de alto riesgo generalmente necesitan un humano en el bucle en lugar de un filtro.

Referencias

- OWASP — Top 10 para Aplicaciones de Modelos de Lenguaje Grande - NIST — Marco de Gestión de Riesgos de IA

Prueba el producto: AgentGuard

2026-09-20 · solo fuentes primarias · no métricas de tráfico fabricadas · solo soporte de decisión

Artículos relacionados

- Las listas de permitidos de herramientas de agente de inteligencia artificial: por qué gana deny-by-default - Explora la matriz completa de temas de micro-SaaS de inteligencia artificial →