Hasta dónde otorgar permisos a las herramientas de desarrollo de agentes en mi ordenador

La era en la que el editor simplemente escribía código por nosotros ha terminado. Ahora, agentes como Claude Code abren directamente la terminal, exploran el sistema de archivos y modifican el código. Es conveniente, pero a la vez inquietante. Un solo prompt injection podría filtrar archivos .env o claves SSH al exterior. Necesitamos métodos de control específicos que otorguen autonomía al agente, pero que le impidan cruzar la línea.

Redactar una "Constitución para el Agente" en la raíz del proyecto

Por defecto, los agentes intentan escanear todo el proyecto para ejecutar comandos. Si se deja sin supervisión, existe el riesgo de que lean valores de configuración sensibles. La defensa más segura es crear un archivo de reglas exclusivo para el agente en el directorio raíz del proyecto.

1. Cree un archivo CLAUDE.md o .agent-rules en la raíz.
2. Especifique las rutas de acceso prohibido dentro del archivo. Se deben establecer reglas de deny para rutas como .env, ~/.ssh o ~/.aws/credentials para que ni siquiera puedan ser consultadas.
3. Al ejecutar el agente, utilice la opción --allowedTools para permitir solo las funciones necesarias. Es una forma de activar únicamente las herramientas mínimas como Bash, Read o Write.

Al usar el modo Default de Claude Code, que requiere la aprobación del usuario para todas las operaciones de escritura, se puede bloquear físicamente el riesgo de filtración de código fuente. Un simple archivo de configuración basta para prevenir accidentes en los que el agente envíe variables de entorno al exterior sin permiso.

Cómo evitar que un agente en bucle vacíe su billetera

Las herramientas centradas en agentes planifican y ejecutan por sí mismas. El problema surge cuando caen en errores lógicos. Un agente que no encuentra una solución puede entrar en un bucle infinito repitiendo llamadas a la API, lo que resulta en cargos de decenas de dólares en un instante. Según datos de investigación de Anthropic, establecer condiciones de salida explícitas (Exit Criteria) en el prompt puede reducir el tiempo de ejecución hasta en un 62%.

Para evitar el descontrol de costes, debe diseñar directamente "disyuntores" dentro del prompt:

• Límite de intentos: Añada una restricción al final del comando: "Si no se resuelve tras un máximo de 5 intentos, detente inmediatamente e informa la causa del fallo".
• Criterios de éxito objetivos: Instrucciones subjetivas como "termina cuando el código se vea bien" son las peores. En su lugar, especifique el paso de npm test o de pruebas unitarias concretas como el criterio absoluto de finalización.
• Restricción de contexto: El uso de patrones glob en el archivo .cursorrules para limitar al agente a leer solo reglas de directorios específicos como src/api/**/* evita el desperdicio innecesario de tokens.

Establecer estas puertas de salida permite suprimir el consumo de tokens causado por instrucciones ambiguas, ahorrando más del 40% en los costes mensuales de la API.

Un flujo de trabajo aislado para no contaminar la rama principal

El método en el que el agente modifica directamente los archivos locales es rápido pero arriesgado, ya que código no verificado podría arruinar la rama principal. El equipo de ingeniería de Shopify introdujo un método de validación cruzada de resultados con un modelo separado al operar su propia herramienta de agentes, Sidekick. Nosotros también debemos separar el espacio de trabajo del agente.

La forma más limpia es usar git worktree. Cree un directorio y una rama independientes exclusivos para la sesión del agente y asígnele la tarea. Una vez finalizado el trabajo, pídale que ejecute git diff para informar un resumen de los cambios y que ejecute automáticamente pruebas unitarias con herramientas como Playwright o Vitest. Siguiendo este proceso, se puede reducir el tiempo de revisión manual en un 70% integrando solo código verificado en la rama principal.

Modificar la configuración del IDE que obstaculiza la velocidad del agente

La velocidad a la que un agente escribe código es mucho más rápida que la escritura humana. En este punto, si la función editor.formatOnSave de VS Code está activada, el formato del archivo cambia forzosamente mientras el agente escribe, provocando errores de coincidencia de texto. Es como si la herramienta tropezara con sus propios pies.

Además, las shells no interactivas que ejecutan los agentes a menudo no leen las variables de entorno configuradas en .zshrc, lo que provoca fallos en la ejecución de herramientas.

1. Desactive editor.formatOnSave estableciéndolo en false en el archivo .vscode/settings.json del proyecto colaborativo.
2. Las configuraciones de PATH o claves de API deben moverse de .zshrc al archivo .zshenv, que se carga independientemente del modo de ejecución de la shell.
3. En su lugar, use Husky para configurar hooks de pre-commit de modo que el linter y el formateador se ejecuten solo cuando el agente termine su trabajo y realice el commit.

Si no quiere ver a un agente parado torpemente por no encontrar las variables de entorno, debe revisar primero la configuración de su shell.

Categoría de configuración	Nombre de archivo	Contenido recomendado	Visibilidad del agente
Variables de entorno globales	.zshenv	PATH, API_KEY, rutas de SDK	Cargado en todas las sesiones
Configuración interactiva	.zshrc	alias, prompt, theme	Puede ser ignorado al ejecutar el agente
Configuración de inicio de sesión	.zprofile	Scripts de inicialización global del sistema	Válido solo en login shells