Decidir qué puede tocar un agente de IA: el límite de permisos que sobrevive a un mal día

La pregunta interesante sobre un agente de IA no es "¿podemos lograr que haga esa cosa?" Se trata de "¿cómo será la recuperación el día que se haga algo mal?"

La mayor parte de lo que se escribe sobre permisos de agentes de IA es contenido de proveedores de gestión de identidad (diagramas en forma de Okta, tablas de alcance, taxonomías OWASP) o marcos de cumplimiento de seguridad empresarial (evidencia SOC 2, referencias cruzadas de la Ley de IA de la UE). Ambos son útiles en el contexto correcto y ninguno es lo que un pequeño operador realmente necesita el día que le entrega a una máquina las claves de su repositorio git o de su sitio de producción en vivo. Lo que necesitan es un marco de decisión que responda honestamente a una pregunta por acción que el agente podría realizar: ¿cuál es el peor resultado posible en un mal día y cómo sería la recuperación después de eso?

Esta publicación es ese marco, escrito a partir de agentes que realmente entregaron acceso de escritura a este sitio web. Todo lo que aparece a continuación es algo que hago o algo que he decidido que el costo de recuperación es demasiado alto para justificar la conveniencia. No es un discurso de un proveedor de seguridad y no le vende un motor de políticas.

Por qué "menor privilegio" es la primera pregunta incorrecta

El marco estándar de la industria es least privilege: brinde a un agente solo lo que estrictamente necesita. Éste es un buen principio, pero llega muy tarde. Responde "¿cuánto acceso?" sin responder primero "¿a qué clase de acción es seguro otorgar cualquier nivel de acceso?"

El orden que realmente ayuda a un pequeño operador es:

1. Clasifique la acción por radio de explosión. No por si se puede hacer (cualquier cosa que admita una API se puede hacer), sino por lo que sucede si sale mal y no se puede deshacer. Aquí es donde deberían comenzar la mayoría de las decisiones sobre permisos y donde casi nunca lo hacen. 2. Decida si la acción pertenece a una clase que permitirá que los agentes realicen. Algunas clases simplemente no lo hacen, sin importar cuán estricto sea el alcance del token. 3. Solo entonces, para las acciones que pasan las dos primeras puertas, aplique el privilegio mínimo a los ámbitos y tokens específicos.

Saltarse los pasos 1 y 2 es la forma en que terminas con un agente que "sólo necesita permiso de eliminación para esa carpeta" y un mal día después elimina algo que no puedes recuperar.

La taxonomía del radio de explosión que decide todo lo demás

Básicamente, existen cuatro clases de acción, y la clase es la que determina si un agente debe alguna vez tocar la acción, no la lista de alcance de la API.

Clase 1: reversible por el propio agente, en cuestión de segundos. El agente edita un borrador. El agente ejecuta una consulta e inspecciona el resultado. El agente genera contenido en un archivo que también es de su propiedad. La recuperación de una mala acción de Clase 1 es que el agente vuelve a intentarlo. No hay un radio de explosión significativo porque la acción nunca abandonó la zona de pruebas del agente. Concédelos gratuitamente; no hacerlo es lo que hace que los agentes de IA se sientan inútiles.

Clase 2: reversible por un humano en minutos. El agente se compromete a git. El agente se dirige a una sucursal. El agente carga un borrador en un CMS. El agente pone un correo electrónico en una cola de "revisar antes de enviar". La recuperación es que un humano la nota, la revierte o la revisa. El radio de explosión es real pero limitado: una mala confirmación es una mala confirmación y git revert es una respuesta real que cuesta unos tres minutos. Otórgueles el registro de auditoría que permita al ser humano darse cuenta.

Clase 3: reversible en horas o días, a costo real. El agente publica públicamente. El agente envía un correo electrónico a una lista real. El agente modifica una base de datos de producción en vivo. La recuperación es que un humano se da cuenta Y realiza una acción que en sí misma tiene consecuencias (eliminar una publicación pública, enviar un correo electrónico de corrección, revertir una migración). Concédalos sólo si el radio de explosión de la acción específica es pequeño Y el registro de auditoría le permite detectar el caso grave en minutos, no en horas.

Clase 4: irreversible o reversible solo a un costo que cambia el negocio. El agente elimina el registro de un cliente. El agente mueve dinero. El agente cambia las credenciales de la cuenta. El agente publica algo que el cable recoge antes de que llegue la corrección. La recuperación es que pasas una semana disculpándote o pagando, y el coste de la confianza es permanente. No los concedas. Alguna vez. No importa cuán competente sea el agente, no importa cuán limitado sea el alcance del token. La conveniencia de automatizar una acción de Clase 4 nunca vale el costo de equivocarse una vez.

Las líneas entre las clases no son confusas en la práctica. Lo que les confunde es que la industria te vende herramientas que técnicamente pueden realizar cada acción y te permite decidir cuál. La taxonomía anterior es la decisión previa a la herramienta: antes de escribir una sola línea de código que pueda afectar a una acción de Clase 4, pregúntese si la acción pertenece al código.

Las cosas específicas que dejo hacer a mis agentes

Para ser más concretos, aquí está el alcance exacto que otorgo en este sitio, asignado a las clases anteriores. Esto no es una plantilla (su operación es diferente), pero es un ejemplo elaborado del marco.

Clase 1, concedida: cualquier cosa que se lea. Lea los archivos de repositorio, lea el mapa del sitio, lea los registros de implementación, lea el resumen, lea la lista de trabajo, lea el trabajo pendiente. El agente editorial lee todo lo que puede, todo el tiempo, y no hay coste de recuperación porque las lecturas no cambian nada.

Clase 1, concedida: cualquier cosa que escriba en archivos propiedad de la sesión del agente y que se inspeccionen antes de la confirmación. Borradores de publicaciones, portadas generadas, tarjetas OG generadas, metadatos actualizados del trabajo pendiente. El mal caso es un mal borrador; la recuperación es "eliminar el archivo, intentarlo de nuevo".

Clase 2, concedida: se compromete a main cuando pasa la puerta de construcción. Éste es el importante. Otorgo explícitamente al agente la capacidad de escribir en la sucursal que implementa Cloudflare Pages, sin un paso de revisión humana, con la condición específica de que npm run build devuelva cero. La puerta de construcción es lo que hace que esta sea una acción de Clase 2 en lugar de Clase 3: un despliegue roto es capturado por check-posts, check-links y check-search antes de que aterrice, y una mala confirmación que pasa las puertas aún es capaz de git revert en cuestión de minutos.

Clase 2, concedida: empuja a origin/main . El mismo razonamiento: el proceso de implementación tiene su propia puerta de compilación en el otro lado, y Cloudflare Pages conserva las implementaciones anteriores para su reversión. Un solo clic deshace cualquier implementación.

Clase 2, concedida: Llamadas a la API de GitHub para crear confirmaciones, abrir problemas y actualizar el estado del problema en la lista de trabajo. Todos estos son auditables en el historial del repositorio y se pueden deshacer manualmente.

Clase 3, considerada y NO otorgada: publicar en LinkedIn o cualquier plataforma social bajo mi nombre. El costo de recuperación de una publicación incorrecta en LinkedIn es una publicación eliminada que todos los que la vieron también compartieron en una captura de pantalla, más un impuesto a la reputación. La conveniencia de automatizar "publicar el artículo como una actualización de LinkedIn" no vale la pena. Esta es la razón específica por la que el documento AUTOMATION-PLAN del sitio dice explícitamente "No afecta a LinkedIn ni al correo electrónico": la clase fue considerada y rechazada, no simplemente dejada sin realizar.

Clase 3, considerada y NO concedida: envío de correo electrónico a la lista de newsletter. Mismo razonamiento. La recuperación de un correo electrónico incorrecto a una lista real es un correo electrónico de corrección que la gente también lee como "estas personas no pueden mantener sus sistemas en orden", además de cancelaciones de suscripción que son permanentes. Los boletines se envían cuando un humano hace clic en enviarlos.

Clase 4, bloqueado: eliminación de cualquier publicación publicada, eliminación de cualquier registro de suscriptor, cambios en las dependencias _headers, _redirects, functions/ o package.json sin una nueva revisión explícita. El agente puede PROPONER estos, en una entrada del registro de ejecución, pero la confirmación que los genera tiene que ser una que yo leí, no una que haya escrito el agente. Esta es una fricción real para el agente, y es una fricción que quiero.

Clase 4, bloqueado: cualquier cosa que tenga que ver con la configuración de la cuenta de Cloudflare, DNS o reglas de acceso. Las credenciales de la cuenta no se encuentran en absoluto en el entorno del agente. Si es necesario cambiarlos, los cambio.

Las dos preguntas que hay que hacerse antes de conceder cualquier acción a un agente

Antes de ampliar los permisos de un agente para incluir una nueva capacidad, oblíguese a responder ambas preguntas en un párrafo cada una. No es una lista de verificación: oraciones reales.

Pregunta 1: ¿Cuál es el peor resultado posible si esta acción sale mal y cuánto tiempo lleva la recuperación? No es el resultado promedio; el peor posible. Si, en teoría, el agente podría realizar la acción diez mil veces antes de que usted se dé cuenta, utilice ese número, no uno. "El agente podría enviar un correo electrónico incorrecto" es una acción de Clase 3; "el agente podría realizar un bucle y enviar el mismo correo electrónico incorrecto a mil destinatarios antes de que algo lo detecte" es una acción de Clase 4. La autonomía es lo que cambia la clase.

Pregunta 2: ¿Qué clase de persona requerirá la recuperación? ¿Estará disponible en un mal día? Una recuperación que requiere que usted esté disponible personalmente dentro de los 15 minutos para que la recuperación siga siendo una acción de Clase 2 no es realmente Clase 2; es Clase 3 con una suposición de tiempo afortunado. Sea honesto acerca de quién más tiene las credenciales para solucionar un caso grave y con qué confiabilidad se puede contactar con ellos.

Si no puede responder a ambas preguntas de forma satisfactoria en un párrafo cada una, la respuesta a "¿debería conceder la acción?" es no.

Los tres modos de falla que realmente he visto

Modo de error 1: "Esto es solo para la demostración". Un agente obtiene un permiso más amplio de lo necesario durante el desarrollo porque es más rápido conceder todo y limitarlo más adelante. Luego, la demostración funciona, la demostración se convierte en puesta en escena, la puesta en escena se convierte en producción, y nadie se acuerda de limitar los permisos hasta el día en que el agente llega a un caso que su yo restringido más tarde habría rechazado. Grant se limita desde la primera línea, incluso durante el desarrollo: al principio lleva diez minutos y es imposible después de la puesta en marcha porque ahora el trabajo real depende de ello.

Modo de falla 2: "El alcance no incluye acciones destructivas". El alcance repo de GitHub, por ejemplo, incluye eliminar ramas, forzar el envío y eliminar archivos. Parece un alcance de lectura y escritura y en realidad es un alcance de "hacer cualquier cosa en este repositorio". Lea los permisos reales del alcance antes de otorgarlos, no el nombre del alcance. La mayoría de los ámbitos de OAuth agrupan acciones que la persona que llama no pretende permitir; la agrupación es donde vive el radio de la explosión.

Modo de falla 3: "Agregaremos monitoreo más tarde". Cualquier permiso de Clase 2 o Clase 3 otorgado sin el registro de auditoría que le permite notar una mala acción es silenciosamente una acción de Clase 4, porque el reloj de recuperación no se inicia hasta que alguien se da cuenta, y si nadie se da cuenta entonces no hay recuperación; solo hay daño acumulado. La pista de auditoría es lo que define la clase tanto como la acción. Este es todo el argumento de what to log when an AI agent acts on your behalf: la tala no es documentación, es la medida de contención.

La pregunta "¿el humano pertenece aquí?" pregunta

Una vez que haya clasificado una acción, una decisión específica separa la automatización bien administrada del teatro: ¿pone a un humano al tanto?

El valor predeterminado de la industria es: sí, en cualquier cosa de Clase 3 o superior. Esa es la respuesta incorrecta, y es la respuesta incorrecta por la misma razón por la que "simplemente agregue un paso de revisión" falla en cualquier otro lugar: un ser humano que tiene que aprobar doscientas cosas por semana no es un control, es un sello de goma con una silla. La verificación humana solo es real si el humano realmente puede distinguir lo bueno de lo malo y si el volumen es lo suficientemente bajo como para que pueda prestar atención.

Dos reglas que funcionan en la práctica:

1. Un control humano es solo un control cuando el humano puede negarse. Si negarse es costoso (bloquea la liberación, retrasa al cliente, significa una conversación difícil), el humano no se negará de manera rutinaria, por lo que el control es un teatro. Si el trabajo del crítico es tener razón, no ser popular y negarse es realmente gratuito, el cheque funciona. 2. Un control humano de 20 artículos por semana es un control; un control humano de 200 artículos por semana no lo es. Por debajo de un umbral, los humanos prestan atención. Encima, dejan de leer. El umbral varía según la tarea, pero es mucho más bajo de lo que suponen la mayoría de los sistemas; yo uso "si abro cada uno de ellos individualmente, está por debajo del umbral; si lo hojeo, no está".

Cuando una verificación humana es un teatro, la respuesta honesta no es "agregar una lista de verificación mejor". Es: automatizar la decisión específica por completo (la verificación no agrega valor; eliminarla), o reducir el volumen hasta que un humano pueda realmente tomarla (la verificación es importante; el volumen es el problema, no la verificación). La automatización con un escalón estándar es peor que la automatización sin uno, porque la presencia del escalón desvía la culpa del diseño que hizo que el volumen fuera demasiado alto.

Los artefactos específicos que necesita una decisión de permisos

Por cada clase de acción que le otorgues a un agente, deben existir tres artefactos específicos. Si falta alguno de los tres, el permiso no se ha concedido de forma responsable, sino con optimismo.

Artefacto 1: el registro de auditoría externo al agente. No es el registro del propio agente de lo que hizo. Un registro externo (un historial de git, un registro de respuestas de API, una cola de correo electrónico con ID de mensajes) que sobrevive a la muerte del agente, a la finalización del proceso y a la pérdida de energía de la máquina. La evidencia real de la acción vive fuera del actor. Vea el argumento completo en what to log when an AI agent acts on your behalf; la versión muy breve es que el agente es el testigo menos confiable de sus propias acciones.

Artefacto 2: el procedimiento de recuperación, escrito. Un documento de un párrafo por clase de acción que dice: "Si la acción X se ejecuta mal, realice Y y Z en ese orden y espere que la recuperación se complete en W minutos". Si el procedimiento no existe, la acción no es realmente recuperable: no se ha recuperado pero aún no se ha detectado. Escriba el procedimiento antes de la primera vez que otorgue el permiso, no después de la primera vez que lo necesite.

Artefacto 3: el interruptor de apagado. Un lugar con un solo nombre donde puedes revocar la capacidad del agente para realizar esta acción en cuestión de segundos. Para mí, en este sitio, los interruptores de interrupción son: rotar el token GitHub OAuth (elimina todo acceso de escritura), rotar el token API de Cloudflare (elimina la verificación de implementación) y configurar el cron de ejecución diaria en deshabilitado (elimina el activador). Los tres están documentados, los tres son un comando cada uno y los tres son cosas que he usado al menos una vez.

Sin un interruptor de apagado real, el permiso no es un permiso, es un hecho consumado. No concedas nada que no puedas revocar en menos de un minuto.

El más difícil: permisos permanentes versus permisos justo a tiempo

El error más común en los permisos de los agentes es otorgar acceso permanente a una acción de Clase 3 para que el agente pueda "manejarla cuando sea necesario". Los permisos permanentes son la razón por la que las acciones de Clase 3 se convierten en problemas de Clase 4: un agente inactivo o comprometido con privilegios permanentes no está inactivo: está expuesto. Es por eso que Microsoft's own guidance y industry security research on AI agent identities convergen en la misma recomendación: otorgar permisos elevados sólo por el momento en que sean necesarios, con un TTL corto y revocación automática.

El modelo justo a tiempo es: el agente solicita permiso cuando lo necesita, obtiene un token con una vida útil medida en minutos, no en meses, y el token caduca independientemente de que el agente necesite usarlo o no. Si el agente no necesita el permiso durante la siguiente hora, no existe exposición. Si el agente se ve comprometido en esa hora, el atacante hereda un token que caduca antes de que pueda pivotar.

Esto requiere más trabajo de configuración. También es la diferencia entre un modelo de permisos que sobrevive a un mal día y uno que convierte un mal día en un mal trimestre. Si sólo va a construir una pieza de infraestructura no obvia para su agente, ésta es la solución.

Qué hacer el próximo martes

Si ya ejecuta agentes en sus propios sistemas, realice los dos ejercicios siguientes esta semana.

Ejercicio 1. Escriba todas las acciones que su agente puede realizar actualmente. No los nombres de las herramientas, las acciones. "Comprométete a git." "Enviar una POST HTTP a mi punto final de análisis". "Leer una fila de la base de datos". "Escribe una fila de la base de datos". Para cada uno, marque la clase de la taxonomía anterior.

Ejercicio 2. Para cada acción de Clase 3 o Clase 4 de la lista, responda la prueba de los tres artefactos: registro de auditoría desde el exterior, procedimiento de recuperación escrito, interruptor de apagado. Cualquier acción que falle en cualquiera de los tres, puede degradarse (revocar el permiso hasta que existan los artefactos) o tomarse el tiempo para construir el artefacto antes de la siguiente ejecución.

Si el ejercicio dura una hora, tienes una pequeña operación y esto vale una hora. Si tarda una semana, tienes una operación mayor y el retraso de realizarla ahora es menor que el coste del primer mal día para el que no te has preparado.

Dónde encaja esto con el resto del trabajo

El límite de permisos es el lado de contención de la ejecución de agentes desatendidos. La pista de auditoría es la parte de diagnóstico, en what to log when an AI agent acts on your behalf: el registro es lo que le dice por qué el agente hizo lo que hizo; los permisos son los que limitan lo que el agente podría haber hecho. Juntos son los que hacen operable un sistema autónomo.

Si su problema es anterior (aún no ha decidido qué tareas confiarle a un agente), el marco en how to automate your work with AI es la pregunta anterior. Y si su modo de falla específico es el flujo de trabajo que se ejecuta en verde y no hace nada (una acción silenciosa de Clase 2 que finge estar completada), el diagnóstico está en the automation failure nobody catches.

Preguntas frecuentes

¿Cuánto tiempo debe vivir un token de agente justo a tiempo?

El tiempo suficiente para la acción concreta, y no más. Para un ciclo de confirmación y envío que dura minutos; para un trabajo por lotes que se ejecuta en un bucle, es la longitud del bucle más un pequeño búfer. Si no puede indicar el número en minutos, la ficha está disponible para acceder con un disfraz.

¿Debería incluir un paso de revisión humana en cada acción de Clase 3 o automatizarla por completo?

Tampoco por defecto. Si el revisor puede realmente negarse sin castigo y el volumen es lo suficientemente bajo como para que lea cada elemento, conserve la reseña. De lo contrario, elija una: automatizar la decisión por completo o reducir el volumen hasta que la reseña sea real. Un paso aprobado es peor que ningún paso porque lava la responsabilidad.

¿Qué pasa si mi agente necesita un permiso de Clase 4 para un caso límite específico?

Entonces ese caso límite no está automatizado. El agente puede preparar la acción, registrar la solicitud y localizar a un humano, pero la confirmación, el envío o la eliminación los realiza el humano. La conveniencia de automatizar un caso de Clase 4 nunca vale la pena construir las tuberías que podrían ejecutarlos todos.

¿Cuántas acciones son demasiadas para un token de agente?

Cuente las clases, no las acciones. Una ficha que contenga cualquier combinación de acciones de Clase 1 y Clase 2 está bien; un solo token que abarca la Clase 2 y la Clase 3 es donde el radio de explosión se infiltra silenciosamente, porque las expectativas de auditoría para los dos son diferentes. Divida los tokens a lo largo de los límites de la clase, no a lo largo de los límites de las características.

¿Necesito un interruptor de apagado si el agente solo se ejecuta según un cronograma?

Sí. Un agente programado que ya se ha activado y está en mitad del ciclo es exactamente cuando necesita revocar el acceso, y "esperar a la siguiente ventana" no es un interruptor de apagado. Si rotar el token o desactivar el disparador no es un único comando documentado que haya ejecutado al menos una vez, no tiene uno.

¿Debería el agente escribir su propio registro de auditoría o debería confiar en sistemas externos?

Sistemas externos. El agente es el testigo menos confiable de sus propias acciones: un agente estrellado, muerto o comprometido no terminará de escribir su registro. El historial de Git, los registros de respuesta de API y las colas de mensajes sobreviven a la muerte del agente; El propio registro del agente es una conveniencia, no una prueba.

¿Cuál es la forma más rápida de auditar los permisos que ya he concedido?

Enumere todas las acciones que el agente puede realizar actualmente en inglés sencillo, márquelas con una clase de la taxonomía y, para cada línea de Clase 3 o Clase 4, verifique los tres artefactos: pista de auditoría externa, procedimiento de recuperación escrito, interruptor de apagado con un solo comando. Cualquier fila a la que le falte un artefacto se revoca hasta que el artefacto exista. Una hora de este trabajo es más barata que el primer mal día para el que no te has preparado.

La versión de una frase

Clasifique cada acción de los agentes por radio de explosión antes de clasificarla por alcance; rechazar por completo las acciones de Clase 4, sin importar cuán estricto sea el alcance del token; requerir tres artefactos (pista de auditoría externa, procedimiento de recuperación escrito, interruptor de apagado con un solo comando) para cada permiso de Clase 2 y Clase 3 que otorgue; y nunca conceda acceso permanente a una acción de Clase 3 cuando el justo a tiempo sea suficiente. El modelo de permisos que sobrevive a un mal día es el diseñado en torno al mal día, no al bueno.