Referencias oficiales: Trusted folders · Sandboxing · Checkpointing · Plan Mode
Ruta de aprendizaje
- Primeros pasos con Gemini CLI — instalación, autenticación y memoria
- La ventaja de 1M tokens — trabajar con codebases completos — análisis de repos sin derroche
- Gemini Extensions & MCP — crear flujos personalizados — empaquetar comandos, MCP y skills
- Trusted Folders, Sandboxing y Restore — confianza, aislamiento y rollback ← Estás aquí
- Headless Automation con Gemini CLI — scripts, CI y salida estructurada
- Sub-agentes y Orquestación de Skills — delegación y flujos especialistas
- Gemini Loop Seguro del Primer Día
- Playbook Gemini para Entregas de Escala Semanal
- Controles de Cambios de Alto Riesgo en Gemini
- Manual Operativo de Gemini — Ritmo Escalable de Entrega por CLI
- Gemini Playbook de Recuperación de Incidentes
- Gemini Bucle de Hardening Post-Incidente
- Gemini Simulacros de Resiliencia Caótica
- Gemini Métricas de Resiliencia y SLO
Documentación oficial usada en este artículo
- Qué cambia entre workspaces trusted y untrusted — Trusted folders
- Cómo y por qué se ejecuta el sandbox — Sandboxing
- Checkpointing y recuperación con restore — Checkpointing
La seguridad de Gemini CLI es una pila de capas
Cuando alguien pregunta si Gemini CLI es seguro, suele esperar una sola respuesta. En la práctica hay varias capas y cada una protege contra un riesgo distinto.
- Trusted folders — controlan cuánto puede influir el repo en la sesión.
- Plan Mode — evita actuar demasiado pronto.
- Sandboxing — aísla ejecuciones riesgosas.
- Checkpointing + restore — permite volver atrás si el diff sale mal.
Cuando combinas las cuatro, Gemini CLI deja de sentirse como automatización temeraria y pasa a parecer una herramienta de ingeniería controlada.
Trusted folders decide si el repo merece influir en la sesión
Esta es la primera puerta. Determina si el workspace puede cargar comportamiento local con confianza o si conviene tratarlo de forma más restringida.
Conviene empezar como untrusted cuando abres:
- código de clientes
- repos open source desconocidos
- samples con scripts que no has auditado
- ramas sensibles de incidentes o seguridad
El prompt de trust no es burocracia: es la decisión de si el repo puede cambiar el comportamiento del agente.
Mejor práctica: inspeccionar antes de confiar
Una rutina muy sana es:
- abrir como untrusted
- revisar árbol, lockfiles, scripts y configuración
- confiar solo cuando entiendes qué va a cargarse desde el repo
Ese hábito reduce mucho las sorpresas derivadas de commands o settings locales.
Plan Mode controla el momento de actuar
Trusted folders responde “¿debo dejar que este repo influya en la sesión?” Plan Mode responde “¿debo permitir cambios ahora mismo?”
Para tareas grandes, el patrón más seguro es:
- entrar primero en Plan Mode
- mapear arquitectura y riesgos
- decidir el borde del cambio
- volver al modo normal solo cuando la estrategia esté clara
En un repo multilenguaje como AI Native Notes esto importa mucho: slugs, frontmatter y paridad entre idiomas se rompen con facilidad si mutas demasiado pronto.
Sandboxing trata el riesgo de ejecución, no el juicio editorial
El sandbox entra cuando el agente necesita ejecutar shell, instalar dependencias o probar código que aún no terminas de confiar.
Úsalo especialmente cuando haya:
- package managers con postinstall dudoso
- builds o tests en repos desconocidos
- samples de terceros
- nuevas automatizaciones que todavía no conoces bien
Un modelo mental útil:
- Plan Mode decide si el agente puede actuar.
- Sandboxing decide dónde ocurren las acciones riesgosas.
Son controles distintos y muchas veces necesitas ambos.
Checkpointing es la red que agradeces cuando algo sale raro
Checkpointing crea puntos de recuperación antes de escribir archivos. Eso permite trabajar más rápido sin convertir cada sesión en una crisis de recuperación.
Es especialmente útil cuando:
- una tarea toca muchos archivos
- estás probando variantes de prompt
- el repo tiene formato estricto o artefactos generados
- haces cleanup o refactors de baja confianza
No reemplaza la disciplina de Git, pero sí resuelve muy bien el clásico “el agente hizo algo razonable, pero no quiero este diff”.
Ajusta el guardrail al tipo de repo
| Situación | Trust | Plan Mode | Sandbox | Checkpointing |
|---|---|---|---|---|
| Repo externo desconocido | Empezar untrusted | Sí | Normalmente sí | Opcional |
| Repo propio de producción | Trust selectivo | Sí para tareas amplias | Solo para comandos riesgosos | Sí en ediciones grandes |
| Cambios pequeños de copy | Trusted | Opcional | Casi nunca | Opcional |
| Experimentos de CI / automatización | Runner confiable | Diseñar antes | Sí | Git + artifacts |
La meta no es maximizar fricción, sino gastar seguridad solo donde el riesgo realmente existe.
Las restricciones también mejoran la calidad del pensamiento
Hay un efecto secundario valioso: las capas de seguridad obligan a diseñar mejor la tarea.
- “Investiga primero, no edites.”
- “Ejecuta esto solo dentro del sandbox.”
- “Crea un checkpoint antes de tocar el contenido.”
Ese tipo de límites no solo protege; también vuelve más claro el prompt.
Rutina recomendada para este repo
En AI Native Notes usaría este patrón:
- abrir como untrusted áreas que vengan de contribuciones externas
- usar Plan Mode antes de tocar navegación, slugs o estructura de locales
- activar checkpointing antes de cambios masivos en MDX
- reservar sandboxing para comandos, instalaciones o validaciones reales
Así se mantiene la velocidad editorial sin asumir ingenuamente que “como es un repo de docs, nada puede salir mal”.
Siguientes lecturas recomendadas
- Llevar exploración segura a automatización: Headless Automation con Gemini CLI
- Encajar delegación y especialistas sobre estas capas: Sub-agentes y Orquestación de Skills