Tu agente de código puede leer tus claves SSH. Así se le pone una valla

Cuando un agente de código ejecuta ls, cat o npm install en tu portátil, lo hace como tú. No como invitado ni como una cuenta de servicio limitada: como tu usuario, con tu carpeta personal, tus claves SSH, cada archivo .env de cada proyecto que hayas clonado alguna vez y las credenciales de git y de la nube que haya en tu configuración. Esa es la parte que la gente se salta al conectar un agente a una terminal, y es la razón por la que la noticia de GitHub del 2026-10-07 importa más de lo que su tamaño sugiere: el sandboxing local para Copilot ya está disponible de forma general.

El riesgo es el texto que lee el agente, no el agente

Esta parte es general, no depende de ningún producto. Un agente decide qué ejecutar a partir de lo que lee, y lee mucho que tú no escribiste: el README de un repositorio que acabas de clonar, una issue que abrió alguien, una página web que descargó, un comentario dentro de una dependencia. Si alguno de esos textos le pide que muestre un archivo o que envíe algo a alguna parte, el agente puede hacerle caso, porque para él la instrucción parece parte del trabajo. Eso es inyección de prompts. No puedes revisar cada línea que lee un agente, así que la pregunta útil no es «¿lo van a engañar?» sino «¿a qué puede llegar cuando lo engañen?».

Qué restringe el sandbox de GitHub

Según GitHub, el sandbox está disponible en Copilot CLI, la app de Copilot y las sesiones de VS Code que usan Agent Host, sin coste adicional sobre Copilot. Las herramientas y comandos que lanza Copilot se ejecutan con acceso restringido al sistema de archivos, la red, las credenciales y otras capacidades del sistema, según políticas que fija el desarrollador o la organización. GitHub enumera lo que puedes controlar: qué archivos y carpetas pueden leer o cambiar esos comandos; el acceso a internet, a la red local, a las credenciales de Git y a las de GitHub CLI; y el sandboxing de herramientas locales como servidores MCP locales y servidores de lenguaje, donde esté soportado. Las empresas pueden exigir el sandbox y bloquear las políticas para que un desarrollador no pueda relajarlas.

Por debajo está lo que GitHub llama Microsoft eXecution Container (MXC), que convierte una sola política de sandbox en los controles nativos de Windows, macOS y Linux. GitHub también señala algo con lo que estoy de acuerdo: el modelo y el sandbox de herramientas son asuntos separados, así que la política se aplica a lo que se ejecuta, sea cual sea el modelo que lleva el volante.

Capas que puedes copiar para cualquier agente

Uses el agente que uses, estos son hábitos generales, no ajustes sacados del anuncio de GitHub, y cada uno cierra una puerta distinta:

• Solo la carpeta del proyecto. El agente lee y escribe dentro del repositorio en el que trabaja, nada por encima.
• Nada de credenciales a mano. No dejes que herede tus tokens personales. Si necesita acceso, dale un token de vida corta limitado a esa única tarea.
• Una lista de red permitida. Los registros de paquetes y las APIs que necesita la tarea, no internet entero.
• Una persona aprueba lo destructivo. Borrar, hacer force-push, eliminar una tabla.
• Los repositorios no fiables van a un contenedor o a una VM, nunca directamente a la máquina que guarda tus claves.
• Lee el diff antes de que salga de tu máquina, y nunca le des a un agente credenciales de producción.

El siguiente paso lleva diez minutos: abre una terminal igual que lo hace tu agente y haz una lista de lo que ese usuario puede leer, empezando por ~/.ssh, la carpeta de configuración de tu nube y los archivos .env de tus proyectos. Lo que aparezca en esa lista está hoy al alcance del agente. Si usas Copilot, activa el sandbox y empieza por las reglas de sistema de archivos y credenciales; si usas otro agente, levanta la misma valla con un dev container y un token de alcance limitado. Fuente: changelog de GitHub, sandboxing local para GitHub Copilot.