Audiencia: Ingenieros senior / seguridad / platform teams
Formato: Opinión + patrones de arquitectura
Contexto: Gobernanza de AI en desarrollo
TL;DR
- Los agentes de código ya no son solo herramientas — son actores con permisos
- El problema principal no es qué generan, sino qué pueden ejecutar
- Sin aislamiento (sandboxing), el riesgo pasa de código incorrecto a ejecución peligrosa
El cambio silencioso
Durante el último año, el foco estuvo en:
- calidad de código generado
- velocidad
- productividad
Pero el cambio real es otro:
los agentes ahora interactúan con tu entorno
- ejecutan comandos
- leen/escriben archivos
- interactúan con Git
Esto cambia completamente el modelo de riesgo.
Caso reciente: ejecución vía Git hooks
Una vulnerabilidad reciente en tooling de AI coding permitió que:
- repositorios anidados incluyeran hooks maliciosos
- el agente ejecutara operaciones Git
- el código se ejecutara sin visibilidad clara
No es un bug aislado.
Es un síntoma.
El problema real: permisos implícitos
Muchos agentes operan bajo supuestos peligrosos:
- acceso completo al filesystem
- ejecución de shell sin restricciones
- confianza en repositorios externos
En otras palabras:
demasiado poder, muy poca fricción
El error conceptual
Estamos tratando agentes como si fueran:
- autocomplete avanzado
Cuando en realidad son más cercanos a:
- procesos automatizados con privilegios
Y eso requiere otro modelo mental.
Patrón correcto: sandbox primero
Antes de pensar en prompts, piensa en aislamiento.
1. Aislamiento de ejecución
- contenedores efímeros
- entornos sin acceso directo al host
2. Permisos explícitos
Nada implícito.
Ejemplo:
permissions:
filesystem: read-only
git: restricted
shell: disabled
3. Auditoría
Todo lo que el agente hace debe ser:
- logueado
- trazable
4. Confirmaciones humanas
Para acciones sensibles:
- ejecución de scripts
- cambios en infra
- operaciones destructivas
Arquitectura recomendada
En lugar de:
agente con acceso total
Usa:
agente → capa de control → entorno aislado
Flujo:
- agente propone acción
- capa valida permisos
- ejecución en sandbox
- resultado auditado
Trade-offs
Sí, hay fricción:
- menor velocidad
- más setup
Pero el beneficio:
- control
- seguridad
- previsibilidad
Qué deben hacer los equipos hoy
Paso 1
Mapear qué pueden hacer hoy los agentes:
- comandos
- accesos
- integraciones
Paso 2
Reducir permisos por defecto
Paso 3
Introducir sandboxing progresivo
Paso 4
Definir políticas claras
Perspectiva de ingeniería
Esto no es paranoia.
Es evolución natural.
Cada vez que una herramienta gana capacidad de ejecución:
necesita límites más claros
Veredicto
El problema no es que los agentes escriban código.
Es que ahora lo ejecutan.
Reflexión final
La próxima generación de herramientas de desarrollo no se va a diferenciar por:
- qué tan bien generan código
Sino por:
- qué tan bien controlan lo que ese código puede hacer
Porque en 2026, el riesgo no es el código incorrecto.
Es el código correcto ejecutándose en el contexto equivocado.