No le des las llaves del despacho: cómo limitar a un agente de IA

Un agente de IA no necesita acceso a todo para hacer bien una tarea. La pregunta útil no es si confiamos en el modelo, sino qué puede hacer aunque se equivoque.

Un asistente contesta. Un agente actúa. Puede abrir archivos, ejecutar comandos, consultar servicios, modificar documentos o enviar el resultado a otra persona. Esa capacidad ahorra trabajo, pero también cambia la pregunta de seguridad. Ya no basta con revisar lo que dice la IA. Hay que decidir qué le permitimos hacer antes de que empiece.

En un despacho, conceder acceso completo al ordenador para resumir un contrato sería como entregar las llaves, el código de la alarma y el archivo entero para buscar una carpeta. La tarea puede ser legítima. El permiso sigue siendo desproporcionado.

Dos novedades recientes muestran por qué importa. Claude Code corrigió casos en los que reglas de denegación o confirmación podían fallar ante comandos compuestos, archivos abiertos mediante enlaces simbólicos y comandos precedidos por variables de entorno.[1] Apple anunció, por su parte, controles adicionales para conceder acceso completo al disco. La empresa recordó que ese permiso evita buena parte de las protecciones ordinarias de macOS y puede exponer archivos, correo, mensajes e historial de navegación.[2]

No es una razón para rechazar los agentes. Es una razón para tratarlos como operadores con permisos, no como simples cajas de texto.

El permiso decisivo es el alcance

El principio de mínimo privilegio es anterior a la IA. NIST lo define como limitar a cada usuario —o proceso que actúa en su nombre— a los privilegios mínimos necesarios para cumplir la tarea asignada.[3] Aplicado a un agente, obliga a separar capacidades que con frecuencia se agrupan bajo una sola casilla de «acceso»:

• Leer: abrir los documentos de una carpeta concreta.
• Escribir: crear o modificar archivos dentro de un espacio de trabajo.
• Ejecutar: lanzar programas, scripts o comandos.
• Conectarse: consultar internet, una API o un sistema interno.
• Enviar o publicar: producir un efecto visible fuera del entorno de trabajo.
• Borrar o cambiar permisos: realizar acciones difíciles de revertir.

Estas facultades no tienen el mismo riesgo. Un agente puede necesitar leer tres contratos sin necesitar el correo completo del cliente. Puede preparar una respuesta sin poder enviarla. Puede generar una versión nueva sin sobrescribir el original. Puede comprobar una web sin disponer de credenciales para desplegarla.

La seguridad mejora cuando el permiso sigue a la tarea y caduca con ella. «Trabaja en este expediente durante una hora» es una autorización mejor definida que «puedes acceder al gestor documental». «Crea un borrador en esta carpeta» es más controlable que «edita mis archivos». El nombre del producto importa menos que ese perímetro efectivo.

Los límites técnicos también fallan

Una regla de denegación parece sencilla: si aparece un comando peligroso, se bloquea. En la práctica, el mismo efecto puede expresarse de muchas maneras. Un comando puede formar parte de una cadena, aparecer detrás de una asignación de variable o alcanzar un archivo a través de una ruta indirecta. Las correcciones de Claude Code v2.1.289 son valiosas precisamente porque hacen visible esa complejidad.[1]

La conclusión correcta no es que las reglas de permisos sean inútiles. Es que ninguna capa debe cargar sola con toda la seguridad. Una lista de comandos prohibidos ayuda, pero no sustituye el aislamiento del sistema de archivos. Una aprobación humana ayuda, pero no sustituye una cuenta sin acceso a producción. Un registro ayuda a investigar, pero no deshace un correo enviado al destinatario equivocado.

Tampoco hace falta atribuir mala intención al modelo. Bastan una instrucción ambigua, un archivo con contenido engañoso, un error de interpretación o un defecto en la aplicación que ejecuta la acción. Diseñar el perímetro sirve para que un fallo ordinario tenga consecuencias ordinarias.

Apple plantea el mismo problema desde otro ángulo. El acceso completo al disco se creó para usos excepcionales, como determinadas aplicaciones de copia de seguridad. Cuando se concede a una aplicación con funciones de agente, el permiso deja de cubrir una operación concreta y abre una parte muy amplia de la vida digital del usuario.[2] La pregunta no es solo «¿confío en esta aplicación?», sino «¿por qué necesita ver todo para resolver esta tarea?».

Un modelo práctico para el despacho

No hace falta construir una arquitectura sofisticada desde el primer día. Sí conviene fijar cinco límites antes de conectar un agente a trabajo real.

1. Una zona de trabajo separada

Copie o vincule únicamente los documentos necesarios a una carpeta del asunto. Evite iniciar el agente desde el directorio personal, el buzón completo o una unidad compartida con otros clientes. Si la tarea admite lectura, empiece sin permiso de escritura. Si necesita producir archivos, dele una carpeta de salida nueva, no el original.

2. Una identidad propia y limitada

No entregue las credenciales habituales del socio, administrador o responsable de sistemas. Utilice una cuenta específica, con acceso a los repositorios, buzones o servicios imprescindibles. Prefiera credenciales temporales y revocables. Una llave limitada permite cerrar una puerta sin cambiar todas las cerraduras del despacho.

3. Red y herramientas por necesidad

Un agente que revisa documentos locales quizá no necesite internet. Si debe consultar fuentes, limite los destinos cuando sea posible. Si usa conectores, habilite solo las operaciones requeridas. «Buscar expedientes» y «modificar expedientes» deberían ser permisos distintos.

4. Aprobación en los efectos externos

Las acciones de bajo riesgo y reversibles pueden ejecutarse dentro del perímetro sin interrumpir al profesional. Las que cruzan ese perímetro deben detenerse. En un despacho, los puntos de control suelen ser pocos y claros: enviar un correo, presentar un escrito, publicar contenido, desplegar un sistema, borrar información, cambiar accesos o compartir datos con un tercero.

La aprobación debe mostrar el objeto exacto: qué se enviará, a quién, desde qué cuenta y con qué archivos. Una autorización para publicar una versión concreta puede cubrir la secuencia técnica completa —guardar, desplegar y comprobar— siempre que no cambien el contenido, el destino ni los permisos. Si cambia alguno de esos elementos, cambia la decisión.

5. Registro, prueba y revocación

Conserve un rastro suficiente para responder tres preguntas: qué pidió la persona, qué intentó hacer el agente y qué ocurrió realmente. Registre también las denegaciones y las aprobaciones. Al terminar, retire las credenciales temporales y cierre el acceso. Un permiso que nadie recuerda revocar se convierte en infraestructura permanente por accidente.

Los controles funcionan mejor por capas. OpenAI describe, para Codex, dos mecanismos complementarios: el sandbox marca el límite técnico —dónde puede escribir o si puede usar la red— y la política de aprobación decide cuándo debe detenerse y pedir permiso.[4] El mismo patrón puede aplicarse sin adoptar una herramienta concreta: un límite que la máquina no puede cruzar y una decisión humana para las excepciones.

Probar antes de ampliar: un piloto real

En un piloto reciente utilicé Hermes para coordinar una tarea y Codex para ejecutarla dentro de un único repositorio. La primera prueba empezó en modo de solo lectura, sin red y sin permiso para modificar otros espacios de trabajo. La instrucción identificaba el repositorio, la rama y el punto de partida. Al terminar, comprobamos de forma independiente que el commit no había cambiado y que el árbol de trabajo seguía limpio.

Ese resultado no demostró que el modelo fuera infalible. Demostró algo más útil: que podía producir una respuesta válida sin recibir permisos de escritura ni acceso general al ordenador.

La segunda decisión fue organizativa. Hermes coordinaba y verificaba; Codex ejecutaba. No había dos agentes escribiendo a la vez en el mismo espacio. Preparar borradores y ejecutar pruebas podía hacerse dentro del perímetro. Publicar, desplegar o contactar con terceros quedaba reservado a una aprobación expresa.

El control no se añadió como una revisión burocrática al final. Formaba parte del encargo: alcance, permisos, resultado esperado y criterio de verificación. Solo después de observar una necesidad concreta tenía sentido ampliar capacidades.

El riesgo de preguntar demasiado

Un sistema que solicita permiso para cada lectura, búsqueda o comando rutinario acaba entrenando al usuario para pulsar «Aceptar». La fatiga de aprobación no es una objeción teórica. OpenAI ha descrito cómo las interrupciones frecuentes pueden llevar a usuarios a habilitar acceso completo, crear reglas demasiado amplias o aprobar sin comprender la consecuencia; sus datos internos sobre revisión automática muestran una reducción muy grande de las interrupciones, aunque la propia empresa advierte que este mecanismo no ofrece garantías deterministas.[5]

La solución no es eliminar las aprobaciones, sino colocarlas en los límites correctos:

• Dentro del perímetro: operaciones reversibles, registradas y necesarias para la tarea.
• Al cruzar el perímetro: revisión contextual o regla específica.
• Ante un efecto externo o difícil de revertir: aprobación humana con el contenido y destino visibles.

Así se concentra la atención donde vale más. El profesional no revisa cien pasos técnicos; decide sobre las pocas acciones que pueden comprometer confidencialidad, dinero, derechos, reputación o producción.

Nueve preguntas antes de pulsar «Permitir»

Antes de usar un agente con datos o herramientas del despacho, conviene responder por escrito:

1. ¿Cuál es la tarea exacta y cuándo termina?
2. ¿Qué archivos y sistemas necesita leer?
3. ¿Dónde puede escribir y qué originales quedan protegidos?
4. ¿Necesita red? ¿A qué destinos?
5. ¿Qué credenciales utilizará y cómo se revocan?
6. ¿Qué acciones externas o irreversibles requieren aprobación?
7. ¿Qué verá la persona que aprueba?
8. ¿Qué registro quedará de instrucciones, decisiones y resultados?
9. ¿Hemos probado tanto una acción permitida como una acción que debe bloquearse?

La confianza puede crecer después. Los permisos no deberían anticiparla.

Un agente útil no es el que recibe todas las llaves. Es el que puede completar su trabajo con una llave limitada, durante el tiempo necesario, mientras las puertas importantes siguen bajo control humano.