← Volver al listado de tecnologías ← Índice de Goose

12. Permisos y seguridad

9 de mayo de 2026 Por: Artiko

goosepermisosseguridadallowlistsandboxenterprise

12. Permisos y seguridad

Un agente con acceso total a tu sistema es un riesgo serio. Goose ofrece mecanismos en capas para restringir lo que el agente puede hacer.

flowchart TB
    A[Acción del agente] --> P{Permission granular}
    P -->|denegado| X[Error]
    P -->|permitido| AL{Extension allowlist}
    AL -->|no en lista| X
    AL -->|OK| GI{gooseignore}
    GI -->|matchea| X
    GI -->|OK| SB{sandbox Desktop}
    SB -->|fuera de scope| X
    SB -->|OK| Run[Ejecutar]

Cuatro capas: permisos granulares, allowlist, gooseignore, sandbox. Defensa en profundidad.

Permisos granulares

El primer control: qué puede hacer el agente, antes de chequear lo demás.

Niveles de permission mode

Modo	Comportamiento
`interactive`	Pregunta antes de cada operación destructiva (default)
`auto-approve`	Aprueba todo automáticamente
`auto-approve-tools <list>`	Pre-aprueba solo ciertas tools
`readonly`	El agente puede leer pero no modificar nada
`deny-all`	Deniega todo (útil para inspección)

# Sesión readonly para auditoría
goose session --readonly

# Auto-approve solo edit (no shell)
goose session --auto-approve-tools edit

Permisos por herramienta

Más granular que los modes globales:

# .goose/permissions.yaml
filesystem:
  read:
    allow: ["**/*.{ts,js,md,json}"]
    deny: [".env*", "secrets/**"]
  write:
    allow: ["src/**", "tests/**", "docs/**"]
    deny: ["src/sensitive/**"]
  execute: deny

shell:
  allow: ["git *", "npm *", "bun *"]
  deny: ["rm -rf *", "sudo *", "curl * | sh"]

network:
  fetch:
    allow:
      - "https://api.github.com/*"
      - "https://hooks.slack.com/*"
    deny: ["*"]  # default deny

Estas reglas las lee Goose antes de invocar cualquier herramienta. Si el modelo intenta correr sudo apt-get install hacker-tool, Goose lo rechaza sin involucrar al usuario.

Permission prompts

Cuando una operación no está pre-aprobada y no está en deny:

🪿 El agente quiere ejecutar:
   shell: rm -rf node_modules && npm install
   ¿Aprobar? [y/N/always]

y: solo esta vez.
N: rechazar.
always: agregar a permisos pre-aprobados de la sesión.

Para tareas peligrosas, leé bien antes de aprobar. La fatiga de prompts puede llevar a aprobar todo sin pensar — eso anula el propósito.

Extension allowlist

En entornos enterprise, querés que solo extensions aprobadas puedan correr.

# /etc/goose/allowlist.yaml (administrador)
allowlist:
  enabled: true
  enforcement: strict  # o lenient (warning pero deja correr)

  extensions:
    builtin:
      - developer
      - fetch
      - memory

    mcp:
      - github
      - postgres
      - jira

    custom:
      - empresa-internal-mcp

Con enforcement: strict:

Cualquier intento de habilitar extension fuera de la lista → error.
goose configure solo muestra extensions de la allowlist.
goose extension install solo permite instalar de fuentes confiables.

Distribución central

En empresas, la allowlist típicamente se distribuye con la custom distribution (capítulo 9):

distribution:
  base: goose-1.x.y
  enforce_allowlist: true
  allowlist:
    extensions: [...]
  config_locked:
    - provider     # users no pueden cambiar provider
    - default_model

Los developers reciben Goose pre-configurado con políticas que no pueden saltearse.

gooseignore (revisitado)

Ya lo vimos en el capítulo 8, pero acá enfatizamos su rol de seguridad:

# .goose/gooseignore — política de seguridad
.env*
.aws/credentials
.ssh/
secrets/
**/*.pem
**/*.key
**/private/**
~/.config/goose/sessions/  # no leer otras sesiones de goose

Importante:

gooseignore no es opcional para seguridad. Si tenés secrets en tu repo (lo cual ya es un problema), al menos protege que el agente los lea.
Funciona con patterns glob, soportada negación con !.
En entornos enterprise, distribuir un gooseignore global en /etc/goose/gooseignore que aplica a todos los users.

Sandbox del Desktop

En macOS, Goose Desktop puede correr dentro del App Sandbox de Apple. Limita:

Acceso a directorios fuera de los explícitamente permitidos.
Conexiones de red a hosts no aprobados.
Lanzamiento de procesos arbitrarios.

# Goose Desktop preferences
sandbox:
  enabled: true
  filesystem:
    accessible_paths:
      - ~/Documents/code/
      - ~/.config/goose/
  network:
    allowed_hosts:
      - api.openai.com
      - api.anthropic.com
      - github.com

Trade-off: con sandbox activo, algunas extensions que necesitan permisos amplios (computer-use, automation) van a fallar.

En CLI no hay sandbox equivalente. Si el agente puede correr shell arbitraria, tu único control es el set de permisos. Por eso allowlist + gooseignore son críticos en CLI.

Manejo de secretos

No metas API keys en config sin env vars

Mal:

openai:
  api_key: sk-real-key-here   # ❌ commiteado en git

Bien:

openai:
  api_key_env: OPENAI_API_KEY  # ✅ resuelto en runtime

Secret managers

secrets:
  provider: aws-secrets-manager
  region: us-east-1

openai:
  api_key_secret: prod/openai_key

Goose tira la query al secret manager solo cuando lo necesita, sin almacenar el valor en disco.

Pre-commit hooks

Si tenés Goose en un repo, sumá un hook que prevenga commits con API keys:

pre-commit install
# pre-commit-config.yaml con detect-secrets, gitleaks, etc.

Defensa en profundidad: la allowlist de gooseignore + el hook de pre-commit + secret scanner en CI.

Auditoría y logs de seguridad

Goose loguea (si configurás):

Cada tool call con timestamp, parámetros, resultado.
Cada extension habilitada/deshabilitada.
Cada cambio de permisos.
Cada secret accedido (sin loggear el valor).

logging:
  enabled: true
  level: info
  destinations:
    - type: file
      path: ~/.local/share/goose/logs/audit.jsonl
    - type: syslog
      address: tcp://siem.empresa.com:514

Útil para forensics: si pasó algo raro, podés reconstruir qué hizo el agente y cuándo.

Persistent instructions de seguridad

Lo que ponés en ~/.config/goose/persistent.md (o el del proyecto) también es una capa de defensa:

# Reglas no negociables

- NUNCA ejecutar `rm -rf` con paths absolutos
- NUNCA modificar archivos en `/etc/`, `/usr/`, `/Library/`
- NUNCA hacer commits o pushes sin que el usuario lo confirme explícitamente
- NUNCA leer archivos en `~/.ssh/` o `~/.aws/`
- Antes de borrar más de 10 archivos, pedir confirmación específica con la lista
- Si pedís "ejecutar X", primero mostrame el output de `which X` para confirmar binario correcto

Estas instrucciones no son binding (el agente puede ignorarlas si está mal alineado), pero reducen la probabilidad de errores. Combinados con permission gates duros, son suficientemente robustos.

Checklist enterprise

Setup mínimo seguro para deployment empresarial:

Es bastante work, pero comparable a lo que cualquier herramienta con acceso de developer requiere (CI runners, IDE plugins, etc.).

Anti-patterns de seguridad

1. Auto-approve everything

goose session --auto-approve-tools all con un modelo que tiene libertad shell + filesystem completo = receta para desastre. Solo úsalo en sandboxes verdaderos.

2. API key con scope amplio

Usar una API key con acceso a producción para experimentar con un agente. Siempre keys con scope mínimo: si el agente lee el .env, el blast radius es más chico.

3. Compartir sesiones con history

Las sesiones contienen toda la conversación. Si compartís una, podés leakear info que mostraste al agente. goose session --export ofrece redacción opcional: úsala.

4. MCP servers de fuentes no confiables

Un MCP server arbitrario puede leer todo lo que el agente lee. Solo instalá MCPs auditados o de tu propio equipo.

¿Qué viene?

Tu Goose está blindado. En el próximo capítulo volvemos a productividad: enhanced code editing, semantic codebase analysis y file management — los features que distinguen a Goose como agente de codebase real, no solo de scripts pequeños.