Tokens de solo lectura y limitados a un proyecto: cómo mantener a un agente de IA bajo control

“¿Debería darle a un agente de IA acceso a mi lista de tareas?” son en realidad tres preguntas distintas disfrazadas de una: cuánto puede ver, qué tan rápido puedo cortarle el acceso si algo sale mal y qué sigue necesitando mi aprobación incluso mientras está conectado. Ninguna depende del modelo que uses: son propiedades de cómo el servidor aplica el acceso, no del criterio del agente.

¿Por qué el alcance importa más que el modelo?

Un agente solo puede hacer lo que sus credenciales le permiten, sin importar qué tan capaz o cuidadoso sea el modelo que hay detrás. Es una garantía del lado del servidor, deliberadamente aburrida, y no una esperanza sobre el comportamiento del modelo; por la misma razón limitarías la clave de API de cualquier otro servicio a exactamente lo que necesita, no a todo lo que en teoría podría tocar.

Acceso completo, solo lectura o un solo proyecto

Cada cuenta tiene su propio endpoint MCP y sus propios tokens; nunca uno compartido o global. En Pro y Teams, un token se puede limitar aún más: solo lectura, para que un agente pueda ver la cola y el contexto de los comentarios pero nunca cambiar nada, o un solo proyecto, para que solo vea las tareas de ese proyecto y nada más de tu cuenta. Empieza con menos acceso del que crees necesitar; ampliarlo después es fácil, mientras que reducirlo a posteriori significa confiar en un agente que ya tuvo acceso más amplio.

Revocar el acceso al instante

Regenerar o revocar un token lo invalida de inmediato, sin esperar a que caduque una caché en algún lado. Y si te estás recuperando de algo que no tienes claro, cambiar o restablecer tu contraseña revoca a la vez todas las credenciales de API de la cuenta, incluidos los tokens MCP y las apps conectadas, así que una posible filtración no deja acceso de agentes vivo en silencio después de que ya cambiaste la contraseña.

La aprobación como segundo control

El alcance define lo que un agente puede ver y tocar; la aprobación define lo que puede terminar sin preguntar. Una tarea marcada como auto-OK se puede cerrar directamente, algo aceptable para trabajo reversible y de bajo riesgo. Todo lo demás pasa por propose_completion y queda pendiente de aprobación hasta que una persona lo apruebe, y solo una persona puede marcar una tarea como auto-OK. Los dos mecanismos cubren riesgos distintos: el alcance limita el radio de impacto; la aprobación limita que algo quede cerrado sin supervisión.

Ejecuciones auditables y presupuestos

Cada sesión de un agente corre como una ejecución registrada, con su propio presupuesto de llamadas a herramientas y de tiempo. check_budget te dice cuánto queda antes de agotar el presupuesto de una sesión, y cuando se agota el de una tarea con presupuesto, start_run se rechaza por completo en lugar de dejar que la sesión siga con tiempo prestado. Es una tercera palanca independiente: no trata del acceso ni de lo que queda cerrado, sino de cuánto puede hacer una sola sesión antes de tener que detenerse y volver a consultar.

Una configuración inicial sensata

Empieza con un agente de solo lectura o limitado a un proyecto, deja la mayoría de las tareas sin auto-OK y observa algunas ejecuciones antes de aflojar cualquier cosa. Amplía el alcance del token, o empieza a marcar tareas rutinarias como auto-OK, una vez que hayas visto qué hace el agente con el acceso que tiene, no antes. Nada de esto se trata de desconfianza: es la misma actitud que tendrías al incorporar a alguien nuevo a un sistema con consecuencias reales.