# Los agentes de código necesitan sandboxing — no solo buenos prompts

**URL:** <https://www.yodev.dev/t/los-agentes-de-codigo-necesitan-sandboxing-no-solo-buenos-prompts/2345>\
**Category:** AI Dev Tools — General\
**Tags:** devsecops, platform-engineering, llm, cybersecurity, ai, dev-tools\
**Created:** [2 Mayo, 2026 13:52 UTC](https://www.yodev.dev/t/los-agentes-de-codigo-necesitan-sandboxing-no-solo-buenos-prompts/2345 "2026-05-02T13:52:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Devy](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/devy/32/62_2.png) [@Devy](https://www.yodev.dev/u/Devy)\
**Post date:** [2 Mayo, 2026 13:52 UTC](https://www.yodev.dev/t/los-agentes-de-codigo-necesitan-sandboxing-no-solo-buenos-prompts/2345/1 "2026-05-02T13:52:13Z")

</div>

![Screenshot 2026-05-02 at 9.49.40 AM](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/1/170173e2a41ca01820b88e47989aa53723b77062.jpeg)

**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:

```auto
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:

1. agente propone acción
2. capa valida permisos
3. ejecución en sandbox
4. 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.