Le das a un agente de programación una tarea pequeña: arreglar un test que falla. Veinte minutos después ha reescrito tres archivos que no tienen nada que ver, ha ejecutado una migración de base de datos contra el DATABASE_URL que encontró en tu shell y ha forzado el push a una rama que estaba usando otra persona. Nada en el prompt pedía nada de eso. El agente tenía rienda suelta sobre la máquina, así que usó esa rienda suelta.
Los permisos son la forma de decidir de antemano qué puede tocar un agente. Un permiso de agente de programación es una regla que indica a qué archivos, comandos, credenciales y repositorios puede llegar un agente concreto durante una ejecución, y en qué puntos tiene que intervenir una persona. Si lo haces bien, un agente que se sale del guion falla de forma segura dentro de la caja que le has dibujado. Si lo haces mal, una sola ejecución desastrosa llega a producción.
Este artículo recorre el modelo de permisos capa por capa, pone nombre al modo de fallo en cada paso y termina con una lista de verificación que puedes aplicar hoy mismo. Usa Sharkly para que cada capa sea concreta, porque el trabajo de Sharkly es situarse por encima de tus agentes de programación y mantener este alcance en un solo lugar. Ya tienes agentes de programación. Sharkly los convierte en un equipo, y un equipo necesita reglas sobre quién puede hacer qué.
Las tres capas donde viven los permisos de un agente
Los permisos de un agente de programación no son un único ajuste. Viven en tres sitios, y un hueco en cualquiera de ellos anula los otros dos.
- El runtime decide qué herramientas puede invocar el agente: leer un archivo, editar un archivo, ejecutar un comando de shell, acceder a la red. Este es Claude Code, Codex, Gemini CLI o el agente que sea que ejecute el trabajo.
- La máquina decide a qué pueden llegar esas herramientas: qué directorios, qué credenciales, qué variables de entorno, qué red. Un Computer de Sharkly «proporciona el sistema operativo, los archivos, las credenciales, el acceso a la red y las herramientas que necesita un Agente», así que la máquina es el radio de impacto real.
- La tarea decide el límite de la intención: a qué repositorio está acotada esta ejecución, qué estados puede fijar el agente y el punto en el que una persona acepta el resultado.
Un límite que conviene dejar claro: un permiso no es una puerta de aprobación. Un permiso es lo que el agente puede hacer. Una puerta de aprobación es donde una persona decide. Necesitas ambas. Permisos estrictos sin ninguna puerta significan que nadie revisa el resultado. Una puerta con permisos laxos significa que el daño ya está hecho cuando alguien se digna a mirar.
Paso 1: delimita las herramientas del runtime
Empieza por donde actúa el agente. La mayoría de los agentes de programación incluyen un sistema de permisos: una lista de herramientas permitidas y otra de denegadas, además de una confirmación antes de ejecutar cualquier cosa destructiva. Claude Code, por ejemplo, te permite autorizar o denegar herramientas concretas y pregunta antes de ejecutar comandos de shell; los nombres exactos de los ajustes varían según el runtime y cambian con frecuencia, así que consulta la documentación actual de tu agente en lugar del fragmento que encontraste el año pasado.
La configuración segura por defecto es generosa con las lecturas y tacaña con las escrituras. Deja que el agente lea el repositorio, ejecute los tests, pase el typecheck y compile sin preguntar. Pon las ediciones de archivos y los comandos de shell detrás de una confirmación o de una lista de permitidos explícita.
El modo de fallo tiene nombre, y es el que todos usamos cuando aprieta el plazo: el modo de omisión total. Todos los runtimes tienen un flag que desactiva todas las confirmaciones, y resulta cómodo para una sesión supervisada. El peligro es dejarlo activado en una ejecución sin supervisión. Un agente que nunca tiene que preguntar, trabajando a partir de un plan que resultó estar equivocado, borrará encantado eso que malinterpretó. Usa la aceptación automática cuando estés mirando. Desactívala cuando te alejes.
Paso 2: delimita la máquina y sus credenciales
La lista de herramientas del runtime no sirve de nada si la máquina le entrega todo al agente. Un agente al que se permite ejecutar comandos de shell en tu equipo de uso diario puede leer todas tus claves SSH, todos los .env y todas las credenciales a las que llega tu propio usuario. El modo de fallo es silencioso: nada parece ir mal hasta que un agente usa una clave de producción que nunca debería haber visto.
Dos movimientos reducen el radio de impacto. Primero, ejecuta los agentes en un entorno acotado en lugar del portátil donde guardas tus secretos de verdad. Sharkly registra un Computer con un token de instalación de un solo uso y vida corta, y la documentación es tajante: no pongas ese token en una imagen reutilizable, un script, una Tarea ni un comentario. Ya sea que el Computer sea un contenedor, un servidor o una máquina de repuesto, el alcance del agente es el alcance de ese entorno, no el tuyo. Si quieres que los agentes trabajen mientras estás desconectado, ejecútalos en un Computer remoto en lugar de en tu portátil abierto.
Segundo, entrega solo lo que necesita una ejecución. El entorno de una ejecución de Sharkly se arma a partir de configuración explícita: repositorios adjuntos, variables de entorno, vinculaciones de secretos y un directorio de trabajo. Adjunta repositorios a un Agente cuando necesite un alcance de código más estrecho que el predeterminado del Space, para que un Agente de frontend nunca haga checkout del servicio de facturación. Mantén cada ejecución en su propio worktree aislado, que es la diferencia entre que una edición mala se quede en un solo checkout y que dos agentes corrompan el mismo árbol de trabajo. La norma de la casa se aplica a todos los campos: introduce solo la configuración que pide el producto y nunca pegues contraseñas ni tokens en campos no relacionados ni en comandos de arranque.
Paso 3: delimita la tarea y deja el merge en manos de una persona
La última capa es la intención. Incluso un agente correctamente aislado y con credenciales acotadas puede hacer el trabajo equivocado: marcar su propia tarea como completada, subir un cambio a medias a una rama compartida o decidir que un PR ya está listo para fusionar.
Aquí es donde encaja el contrato entre humanos y agentes. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y aceptan el resultado. La automatización se detiene donde se requiere el criterio del equipo. Un agente debería poder abrir un PR en borrador y adjuntar la salida de sus tests; no debería aprobar ese PR ni fusionarlo con tu rama protegida. La protección de ramas en el host y la revisión humana en la tarea son los dos candados que mantienen esa línea intacta.
En Sharkly, la propia tarea lleva este límite. Un Workflow de tipo Tarea restringe qué estados puede seleccionar un Agente, así que un Agente no puede mover en silencio el trabajo a un estado «Hecho» o «Publicado» que pertenece a una persona. Cuando un Agente necesita una decisión, deja la Tarea esperando una revisión humana o una respuesta humana, y eso aparece en el Inbox para que la persona responsable lo acepte, solicite cambios o lo reasigne. La ejecución, los bloqueos, los resultados y la revisión vuelven todos a la misma Tarea en lugar de dispersarse por cinco terminales.
Aquí es también donde la configuración por tu cuenta deja de escalar. Un agente, un repositorio, un ingeniero cuidadoso: puedes sostener todo el modelo de permisos en la cabeza. Añade un segundo y un tercer agente, más repositorios y un compañero de equipo, y «qué puede hacer cada agente aquí» se convierte en una pregunta que nadie puede responder de memoria. Un tablero de tareas convierte esas reglas en configuración compartida e inspeccionable: quién asignó el trabajo, qué alcance tenía la ejecución, qué evidencia volvió y quién lo aceptó. Esa es la capa de gestión por encima de tus agentes de programación. Puedes construirla a mano con worktrees, credenciales acotadas y protección de ramas, o ejecutar tus agentes de programación actuales a través de Sharkly y gestionar los permisos, las tareas y la revisión en un solo lugar.
La lista de verificación de permisos que puedes aplicar hoy
Repasa esta lista para cada agente al que dejes tocar un repositorio real:
- Runtime: lecturas y tests permitidos sin confirmación; ediciones y comandos de shell con confirmación; modo de omisión total desactivado en ejecuciones sin supervisión.
- Máquina: el agente se ejecuta en un Computer acotado, no en tu equipo de uso diario; tokens de instalación y de acceso de un solo uso y nunca incluidos en el repositorio.
- Credenciales: solo las variables de entorno y vinculaciones de secretos que necesita esta ejecución, nada pegado en campos no relacionados.
- Alcance de repositorios: el agente está adjunto a los repositorios que requiere su trabajo, no a todos los del Space.
- Aislamiento: cada ejecución tiene su propio worktree para que un cambio malo no pueda corromper un checkout compartido.
- Alcance de la tarea: el agente puede fijar estados de trabajo, pero no puede mover una tarea a un estado aceptado o publicado que pertenece a una persona.
- El merge: la protección de ramas más la revisión humana con evidencia a nivel de tarea se interponen entre el PR del agente y main.
Si alguna línea está floja, apriétala antes de la siguiente ejecución, no después del incidente que te enseñe por qué importaba.
Preguntas frecuentes
¿Cuál es la diferencia entre los permisos de un agente de programación y las puertas de aprobación? Los permisos definen lo que un agente es técnicamente capaz de hacer: a qué archivos, comandos y credenciales puede llegar. Una puerta de aprobación es el punto en el que una persona decide si acepta lo que hizo el agente. Necesitas ambas, porque unos permisos estrictos siguen dejando trabajo que un humano debería aprobar, y las puertas de aprobación no sirven de nada si el agente ya tenía permiso para causar daño.
¿Debería permitirse alguna vez que un agente de programación fusione sus propios PR? No, no por defecto. Deja que el agente abra un PR en borrador y adjunte la salida de su verificación, y luego deja el merge en manos de una persona o de una revisión obligatoria. El razonamiento es el contrato entre humanos y agentes: los agentes ejecutan e informan, las personas aceptan y publican. Esto se cumple incluso en flujos de trabajo con el humano en el bucle donde el agente hace la mayor parte del trabajo.
¿Es seguro ejecutar un agente con todas las confirmaciones de permisos desactivadas? Solo mientras lo estés mirando. Los modos de aceptación automática son útiles en una sesión supervisada donde puedes detener un paso equivocado. Para ejecuciones sin supervisión o nocturnas, mantén las confirmaciones o una lista de permitidos activadas, y pon al agente en una máquina acotada para que un error quede contenido.
