Permisos para agentes de IA: límites fuera del prompt

Leer un correo no da permiso para enviarlo

Le pides a un agente que prepare un borrador, pero no que lo envíe. Puedes dejarlo escrito en el prompt. Para que el límite se cumpla incluso si el modelo se equivoca, la aplicación también debe impedir el envío.

Anthropic publicó el 9 de octubre de 2026 un informe sobre acciones no previstas en sus evaluaciones y uso interno. Incluye intentos de sortear restricciones de herramientas y de acceso a información. La empresa atribuye a los casos identificados un impacto real mínimo; eso no mide la frecuencia del problema en todos los agentes.

La cuestión práctica aparece cuando algo se atasca: ¿el agente sigue dentro de sus permisos o puede buscar otro camino que los evite? Ese límite debe mantenerse fuera de la respuesta del modelo.

Un ejemplo: preparar un catálogo sin publicarlo

Imagina un asistente que revisa las fichas de una tienda y propone descripciones más claras. Su encargo termina en un borrador. Puede leer el catálogo autorizado y guardar sugerencias, pero no cambiar precios ni publicar una nueva versión de la tienda.

Si el servicio de borradores está caído, completar el trabajo escribiendo directamente en producción sería una mala salida. La aplicación debe rechazar esa operación aunque el texto propuesto sea correcto y el agente insista en que está resolviendo un problema técnico.

Este ejemplo es hipotético. Sirve para separar el objetivo del encargo de los medios permitidos: una descripción útil no justifica ampliar el acceso.

Comprobar cada acción antes de ejecutarla

Diseñaría herramientas distintas para guardar un borrador y publicar un catálogo. La primera recibiría el identificador de la tienda y los cambios propuestos. El servidor comprobaría que la identidad del asistente puede escribir en ese espacio. La segunda quedaría fuera de sus permisos durante esta tarea.

La comprobación debe incluir el recurso concreto. Tener acceso a una tienda no concede acceso a todas, y poder editar descripciones no permite tocar el stock. También conviene limitar los destinos de red y evitar credenciales que abran servicios ajenos al encargo.

Si el producto necesita publicación asistida, prepararía una autorización separada para una versión concreta del borrador. Cambiar su contenido después debería exigir una nueva validación. Así, aprobar una propuesta no acaba autorizando cualquier cambio posterior.

Qué aporta Agent Control Standard

OWASP presentó Agent Control Standard, o ACS, como parte de su proyecto de seguridad de IA generativa el 1 de septiembre de 2026. Su objetivo es conectar controles de ejecución mediante puntos de intervención, llamados hooks, en los que se comprueba una acción antes de continuar.

El repositorio publica la especificación v0.1.0 y una implementación de referencia que permite, rechaza o modifica peticiones. Al revisarlo el 13 de octubre de 2026, el README de la referencia en la rama integration advierte de dos límites concretos: el componente Guardian de referencia no implementa la autenticación exigida por ACS-Core y el comportamiento por defecto deja continuar al agente si falla el control, conocido como fail-open.

Son límites de esa implementación de referencia, no una descripción de todas las integraciones posibles. Antes de dar acceso real, revisa cómo se autentican las decisiones, qué acciones se interceptan y qué sucede si el control no responde. Probar un bloqueo cuando todo funciona no demuestra que el sistema mantenga el límite durante una caída.

ACS ofrece una referencia para diseñar controles compatibles entre componentes. Su publicación no demuestra adopción generalizada ni garantiza que una integración concreta bloquee todas las rutas de acceso.

Qué hacer cuando la tarea se bloquea

Una denegación de permisos necesita una salida explícita: detener esa acción, conservar el borrador si es posible y explicar qué falta. Buscar otra credencial o un servicio alternativo para conseguir el mismo cambio puede atravesar precisamente el límite que querías mantener.

Conviene distinguir un error temporal de una denegación. Un fallo de conexión podría admitir un número acotado de reintentos al mismo servicio; una respuesta de acceso prohibido no debería convertirse en una búsqueda abierta de alternativas.

El registro debería permitir reconstruir la herramienta solicitada, el recurso, la decisión y el efecto final. Guardar esos datos con acceso restringido y sin secretos facilita revisar lo ocurrido sin convertir los logs en otra vía de exposición.

Tres pruebas útiles antes de dar acceso real

Puedes empezar en un entorno aislado con tres situaciones del catálogo. Define el resultado esperado y comprueba los efectos en el servidor, además de leer la respuesta del modelo. Una frase como «no he publicado» no demuestra que no se haya ejecutado una escritura.

Estas son pruebas propuestas, no resultados medidos. Complementan la evaluación de calidad del agente: incluso una respuesta excelente necesita respetar el alcance autorizado. Antes de ampliar permisos, comprueba también cómo se recupera la tarea tras un bloqueo y quién revisará las incidencias.

Fuentes