Listas de permitidos de herramientas de agentes de IA: por qué la denegación por defecto es la mejor opción

Por qué deny-by-default funciona mejor que tratar de bloquear cada llamada mala

Cuando comienzas con una postura de deny-by-default, solo tienes que pensar en lo que el agente realmente necesita. Cada otra llamada se detiene automáticamente, sin tener que predecir cada posible uso indebido. Esto reduce la carga mental del revisor y reduce la posibilidad de que se escape un peligroso error olvidado.

Considera un agente que escribe informes. Necesita leer un archivo de plantilla, extraer datos de una base de datos y enviar el PDF final a una casilla de correo interna. Si solo listas esas tres llamadas, cualquier intento de ejecutar un comando de shell, consultar una API externa o eliminar una tabla es denegado instantáneamente. Nunca tienes que escribir una regla que diga 'bloquear rm -rf', 'bloquear curl a evil.com' o 'bloquear DROP TABLE'. La regla deny-by-default cubre todos ellos.

En la práctica, he visto a equipos pasar semanas construyendo listas de bloqueo largas que aún así pierden un nuevo vector de ataque, mientras que una lista de permitidos corta de cinco elementos detuvo los mismos ataques el primer día. El esfuerzo ahorrado en mantenimiento es real: revisas la lista de permitidos cuando una herramienta cambia, no cuando aparece una nueva amenaza.

Cómo creo una lista de permitidos para un nuevo agente

Sigo una lista de verificación repetible que mantiene la lista ajustada y revisable.

- Escribo las tareas exactas que el agente debe realizar hoy. Ignoro las ideas de "podría ser útil más adelante".

- Para cada tarea, encuentro la herramienta única que realiza el trabajo con los parámetros más estrechos posibles. Si una herramienta ofrece una bandera que amplía el alcance, no la activo a menos que la tarea lo necesite explícitamente.

- Registo el nombre de la herramienta, el comando exacto o el punto de conexión de la API y los valores de parámetros permitidos en un archivo YAML simple. Este archivo vive junto con el código del agente para que los revisores puedan verlo de un vistazo.

- Ejecuto el agente en un entorno de sandbox y verifico que cada llamada enumerada tenga éxito y que cualquier llamada que no esté en el archivo devuelva un error.

- Pido a un colega que revise la lista. El trabajo del revisor es confirmar que cada entrada se asigna a una tarea real y que no hay capacidad extra oculta detrás de los valores predeterminados.

- Almaceno el archivo en control de versiones. Etiqueto cada confirmación con la versión del agente para que pueda rastrear qué lista de permitidos se envió con qué versión.

- Configuro un paso de CI que hace que la compilación falle si el archivo YAML está ausente o si contiene una herramienta no aprobada en el registro de herramientas del proyecto.

Este proceso me lleva alrededor de una hora para un agente simple y produce un documento que cualquier persona puede auditar.

Clasificando herramientas por lo que pueden cambiar

No todas las herramientas conllevan el mismo riesgo. Divido las herramientas permitidas en tres clases de impacto para saber dónde agregar controles adicionales.

Clase de impacto | Lo que significa | Ejemplo de herramienta | Salvaguardia típica Sólo lectura | Puede recuperar datos pero no alterar el estado | Lectura de archivo, SELECT de base de datos, API GET pública | Registrar la llamada, sin aprobación adicional necesaria Escritura o mutable | Puede crear, actualizar o eliminar datos | Escritura de archivo, INSERT/UPDATE/DELETE de base de datos, publicación de mensaje interno | Requerir un aprobador secundario para el primer uso, registrar con ID de usuario Efecto externo irreversible | Puede afectar sistemas fuera del límite de confianza | Enviar correo electrónico, publicar en redes sociales, iniciar pago, llamar a webhook externo | Aprobación manual obligatoria, registro de auditoría detallado, tiempo de espera en la llamada

Cuando reviso una nueva herramienta, pregunto: "Si se ejecuta esta llamada, ¿cuál es lo peor que podría suceder?" La respuesta me indica a qué fila de la tabla se aplica. Para herramientas de solo lectura, agrego solo una línea de registro. Para herramientas de escritura, agrego un flujo de trabajo de aprobación ligero. Para efectos irreversibles, aplico una puerta manual y mantengo la ventana de llamada corta.

Combinar listas de permitidos con filtros de entrada y salida

Una lista de permitidos elimina la capacidad innecesaria. Los filtros capturan los datos malos que se filtran a través de las llamadas permitidas. Los trato como capas complementarias, no como reemplazos.

En el lado de entrada, ejecuto un verificador de inyección de promtps que busca patrones de jailbreak conocidos. Utilizo la hoja de trucos de prevención de inyección de promtps LLM de OWASP (enlace) como referencia para las reglas que activo. Si el verificador marca una promtp, la rechazo o saneo el segmento ofensivo antes de que el agente la vea.

En el lado de salida, escaneo el texto generado por el agente en busca de secretos, intentos de inyección SQL o URLs no permitidas. La hoja de trucos de administración de secretos (enlace) me ayuda a crear patrones de regex para claves de API, contraseñas y tokens. La hoja de trucos de prevención de inyección SQL (enlace) guía los patrones que uso para capturar cadenas de consulta peligrosas que podrían ser devueltas en una respuesta.

Ambos conjuntos de filtros se ejecutan como middleware ligero. Agregan unos pocos milisegundos de latencia, pero detienen muchos ataques de bajo esfuerzo antes de que lleguen a la capa de herramientas. Dado que la lista de permitidos ya eliminó clases enteras de llamadas, los filtros tienen una superficie más pequeña para inspeccionar, lo que mantiene los falsos positivos bajos.

Qué no es esto

Quiero dejar claro los límites de una lista de permitidos para que no esperes que resuelva problemas que nunca estuvo destinado a abordar.

- No es una garantía de que el agente nunca se comportará mal. Un atacante determinado que encuentra una forma de invocar una herramienta permitida con parámetros maliciosos aún puede causar daño. - No reemplaza las prácticas de codificación seguras. Si el código del propio agente contiene una vulnerabilidad, la lista de permitidos no puede detener la explotación de ese error. - No es un sustituto de una gestión adecuada de secretos. Incluso si el agente no puede llamar a una herramienta de exfiltración de secretos, los secretos filtrados en registros o salida aún suponen un riesgo. - No detiene la inyección de instrucciones indirectas que manipula al agente para que utilice una herramienta permitida de una manera inesperada. Todavía necesitas validación de entrada y filtrado de salida. - No es una tarea de una sola vez. Cada vez que se agrega una herramienta, sus parámetros cambian o el propósito del agente cambia, debes revisar la lista. - No es una bala de plata para el cumplimiento. Regulaciones como el Reglamento de Inteligencia Artificial de la UE requieren documentación, evaluaciones de riesgos y supervisión humana que van más allá de una simple lista de permitidos.

Entender estos límites te ayuda a asignar esfuerzo donde agrega valor de seguridad real.

Errores comunes que he visto y cómo los evito

Incluso con un proceso claro, los equipos a veces caen en hábitos que debilitan la lista de permitidos. A continuación, se presentan los patrones que vigilo y los pasos concretos que tomo para mantener la lista honesta.

- Parámetros demasiado amplios – Alguien agrega una herramienta con una bandera como "--recursive" o "--all" porque parece conveniente. Contrarresto esto preguntando: "¿Cuál es el conjunto más pequeño de opciones que satisface la tarea?" Si la respuesta es un subconjunto, bloqueo la bandera en ese subconjunto en el YAML.

- Actualizaciones de herramientas olvidadas – Una biblioteca se actualiza y agrega un nuevo comando que se expone automáticamente. Mitigo esto bloqueando la versión exacta de la herramienta en el archivo de dependencias del agente y agregando un paso de CI que falla si una nueva versión introduce comandos no documentados.

- Mezclar política con prompt – Un desarrollador intenta hacer cumplir límites agregando instrucciones como "no llamar delete" dentro del prompt. Recuerdo al equipo que los controles a nivel de prompt pueden ser omitidos a través de una reexpresión astuta; el verdadero guardián debe estar en el registro de herramientas o la capa de ejecución, como AgentGuard.

- Registros de bloqueo faltantes – La lista de permitidos bloquea una llamada, pero nadie lo sabe. Aseguro que cada intento bloqueado escriba una entrada de registro estructurada con marca de tiempo, ID de agente y nombre de la herramienta rechazada.

Referencias

- OWASP LLM Prompt Injection Prevention Cheat Sheet - OWASP SQL Injection Prevention Cheat Sheet - OWASP Secrets Management Cheat Sheet - AgentGuard – Guía de archivos de configuración

Preguntas frecuentes

¿Es una instrucción de prompt suficiente para restringir herramientas?

No. Las restricciones a nivel de prompt se pueden sortear. Haga cumplir la lista de permitidos en el registro de herramientas o en la capa de ejecución.

¿Qué cuenta como un efecto externo irreversible?

Enviar correo electrónico o mensajes, mover dinero, eliminar registros, publicar contenido — cualquier cosa que no se pueda deshacer.

¿Cuántas herramientas son demasiadas?

No hay un número. La prueba es si puede explicar, para cada herramienta en la lista, qué tarea la requiere y qué puede destruir.

¿Reemplazan los filtros la lista de permitidos?

No. Los filtros capturan contenido malo; las listas de permitidos eliminan la capacidad innecesaria. Use ambos.

¿Cubre esto la inyección de prompt indirecta?

Limita el daño que se puede hacer. Detectar y bloquear la inyección en sí es un control de lado de entrada separado.

¿Es la revisión una auditoría de seguridad?

No. Es un soporte de decisión que califica las llamadas y sugiere filtros. Una evaluación completa de la implementación aún necesita una revisión de seguridad.

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

- Barreras de agente asignadas al marco de referencia de inteligencia artificial de NIST - Explora la matriz completa de temas de micro-SaaS de inteligencia artificial →