Todas las guías

Cómo gestionar los permisos de agentes de IA

Por Nodrail · 6 min de lectura

Los permisos de un agente de IA definen qué acciones puede realizar, sobre qué recursos y bajo qué condiciones. Para gestionarlos, necesitas un control en el punto donde la llamada a una herramienta puede producir un efecto: identificar al solicitante, resolver el recurso, evaluar la solicitud y aplicar la decisión antes de ejecutar la operación.

Puedes empezar con una matriz pequeña. Enumera las operaciones que necesita el agente, concreta su alcance y decide cuáles pueden continuar automáticamente, cuáles requieren revisión humana y cuáles deben detenerse.

En esta guía desarrollamos ese modelo para un agente de soporte. La política y los ejemplos son ilustrativos; no representan un SDK de Nodrail disponible ni una integración ya desplegada.

Define cada permiso alrededor de una acción

«Puede usar la herramienta de tickets» es una autorización demasiado amplia para este ejemplo. Una misma herramienta puede leer un ticket, publicar una respuesta o eliminar un registro. Las consecuencias cambian aunque todas las operaciones utilicen la misma credencial de API.

Describe cada solicitud con cinco elementos:

No aceptes como prueba que el propio agente diga pertenecer a otra organización o que el ticket está en un proyecto permitido. Obtén esos datos de un contexto de aplicación confiable. Cuando el agente actúe por una persona, comprueba tanto la autoridad que esta delega como las restricciones propias del agente.

El marco de seguridad de Permit distingue varios límites donde comprobar permisos, entre ellos el acceso a herramientas externas. Aquí nos centramos en ese punto: el momento en que una operación propuesta se convierte en una llamada a una herramienta.

Empieza por una matriz de permisos

Imagina un agente que lee tickets y prepara respuestas. Para una primera implantación, podemos definir una política deliberadamente acotada:

La última fila no significa que cualquier acción desconocida deba poder aprobarse. Un recurso desconocido, un solicitante sin autenticar o una prohibición explícita pueden exigir una denegación. Define primero dentro de qué límites puede conceder acceso una persona autorizada.

La lectura también merece atención. Puede revelar datos personales o exportar muchos registros. La autorización de la tabla pertenece a este ejemplo concreto; no establece que todas las operaciones de lectura sean seguras.

Distingue permitir, denegar y pedir revisión

Permitir significa que una regla aplicable autoriza la solicitud actual. Deberías poder explicar qué agente, operación, recursos y condiciones han coincidido.

Denegar significa que la solicitud no puede continuar. En este modelo, una prohibición explícita prevalece sobre una regla de permiso o una aprobación humana. Pedir la decisión a otra persona no debe convertirse en una vía para evitar esa prohibición.

Pedir aprobación significa que la herramienta todavía no se ha ejecutado. La aplicación conserva una solicitud pendiente y espera a que la revise una persona autorizada. Si nadie aprueba antes de la caducidad, la operación sigue sin estar autorizada.

La interfaz debe distinguir estos estados. «Pendiente» no debería parecer «Permitido», y un fallo al enviar una notificación no cambia la decisión. La guía sobre cómo añadir aprobación humana a un agente desarrolla ese ciclo de vida.

Aplica la decisión antes de llamar a la herramienta

Un servicio puede devolver una decisión de política, pero el componente que invoca la herramienta debe respetarla. En el agente de soporte, coloca la comprobación inmediatamente antes de la operación de la API de tickets y mantén estables los argumentos durante el proceso.

Este es pseudocódigo de arquitectura, no código ejecutable de un SDK:

solicitud = resolver_y_normalizar(contexto_confiable, llamada_propuesta)
decision = evaluar_politica_actual(solicitud)

si la decision no esta disponible o no es valida:
    detener_sin_invocar_herramienta()
si decision es DENEGAR:
    registrar_denegacion_y_detener()
si decision es PEDIR_APROBACION:
    guardar_solicitud_pendiente_y_pausar_sin_invocar()
si decision es PERMITIR:
    invocar_herramienta_registrada_con_la_solicitud_comprobada()

La última rama debe utilizar la solicitud comprobada. Si el agente cambia el proyecto, el ticket o el cuerpo de la respuesta después de recibir autorización, trátalo como una solicitud distinta.

Un hook o SDK puede incorporar este punto de control a un entorno existente. Comprueba qué llamadas intercepta, cómo se comporta ante fallos y si el agente puede modificarlo o evitarlo. La instrucción «pregunta primero» en un prompt no establece por sí sola ese límite de ejecución.

Separa la aprobación única de las reglas permanentes

Para publicar una respuesta, una persona puede aprobar un mensaje exacto dirigido a un ticket concreto. Esa decisión no debería autorizar otro destinatario, un texto modificado o una respuesta posterior.

Una regla permanente es un cambio de política diferente. Por ejemplo, el equipo podría permitir a un agente determinado publicar una clase definida de actualizaciones internas dentro de Support. Revisa todo el alcance y permite revocarlo. Una opción «Permitir siempre» debe mostrar qué incluye ese «siempre».

Incluso con una regla permanente, cada llamada cubierta necesita una decisión válida según las condiciones vigentes. Documenta cuándo se aplica una revocación y qué ocurre con las operaciones autorizadas o ya iniciadas. Revocar un permiso no retira un mensaje que ya se ha enviado.

Prueba el control y las rutas que podrían evitarlo

Antes de confiar en la integración del ejemplo, comprueba su comportamiento previsto con una herramienta de tickets simulada:

Son criterios de aceptación, no resultados de pruebas que ya hayamos ejecutado. Cuenta las llamadas reales a la herramienta simulada: una denegación registrada no demuestra que la operación no haya continuado por otra vía.

Prueba también una llamada a la API de tickets fuera del hook o SDK. Si el entorno conserva credenciales amplias y otra ruta de red, esa llamada puede evitar el control. Las garantías más fuertes requieren controlar esas vías, por ejemplo mediante credenciales acotadas y límites de ejecución o red que se apliquen realmente. Explica esa cobertura con precisión.

Registra las decisiones y los resultados por separado

Conserva contexto suficiente para investigar una decisión: organización, identidad del agente, identificador de solicitud, acción normalizada, recurso, versión de política, decisión y referencia de aprobación cuando exista. Oculta los argumentos sensibles que no necesiten conocer revisores u operadores.

Registra el resultado de ejecución por separado. Un permiso indica que la acción fue autorizada; un resultado comunicado por el cliente indica lo que ese cliente observó. Ninguno equivale automáticamente a una comprobación independiente del estado en el proveedor.

Lleva la primera política a la práctica

Empieza con un agente, una herramienta y una lista corta de operaciones. Construye la matriz, identifica dónde se aplica el control y verifica los caminos de permiso, denegación, revisión y error antes de ampliar el acceso.

Nodrail está desarrollando una capa headless de permisos y aprobaciones humanas para agentes que tu equipo ya ejecuta. Publicaremos las integraciones compatibles y sus instrucciones cuando estén probadas. Conoce Nodrail y apúntate a la lista de espera, o continúa con la guía de aprobación humana.