Clase 6 • Junio 2026 • Basado en documentación oficial y herramientas de la comunidad
Los agentes de IA son el equivalente digital de entregarle las llaves de tu casa a un asistente: útiles, eficientes, pero potencialmente catastróficos si no hay barreras. A diferencia del software tradicional —donde los permisos se modelan estáticamente en torno a usuarios y roles—, un agente autónomo ejecuta código, escribe archivos, hace llamadas de red y consume APIs en nombre de un humano, sin supervisión línea por línea.
Esto crea una superficie de ataque radicalmente distinta:
Esta clase analiza cómo las tres plataformas principales —OpenCode, Claude Code y Codex CLI— abordan cada uno de estos vectores. Spoiler: ninguna lo hace perfectamente, y la mejor defensa hoy es capa múltiple.
bash. La verdadera seguridad requiere sandboxing a nivel OS + aislamiento de red + gestión de secretos cifrados.Cada plataforma implementa un modelo de permisos conceptualmente distinto. OpenCode usa whitelist con 3 estados; Claude Code usa 6 modos con reglas jerárquicas; Codex CLI usa 3 modos sandbox con Permission Profiles beta.
Sintaxis YAML en frontmatter del agente. Tres valores por tool: allow, ask, deny.
permission:
"*": deny # denegar todo por defecto
read: allow
write: ask
bash: deny
pattern: "npm *" # pattern matching sobre comandos
Características clave:
external_directory: subagentes pueden acceder a directorios fuera del workspace.doom_loop protection: detección de loops infinitos..env denegado por defecto en read.bash para escapar del sandbox lógico. La comunidad compensa con Docker/bwrap/Podman externo.| Modo | Qué ejecuta sin preguntar |
|---|---|
default | Solo lecturas |
acceptEdits | Lecturas + file edits + filesystem commands (mkdir, touch, rm, mv, cp, sed) en working directory |
plan | Solo lecturas (exploración) |
auto | Todo, con safety checks background por clasificador separado |
dontAsk | Solo herramientas pre-aprobadas vía permissions.allow |
bypassPermissions | Todo (excepto rm -rf / y rm -rf ~ — circuit breaker) |
Reglas jerárquicas: deny → ask → allow (primera que matchea gana). Sintaxis de patterns:
Bash — todos los comandos bashRead(./.env) — path específicoBash(npm run build) — comando exactoBash(git * main) — glob patternmcp__puppeteer__puppeteer_navigate — tool MCPJerarquía de settings: Managed > CLI > local project > shared project > user. Una tool denied en cualquier nivel no se puede permitir.
Read-only commands (sin prompt): ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, git read-only forms.
| Modo | Descripción |
|---|---|
read-only | Solo lectura del workspace |
workspace-write (default) | Escritura al workspace + directorios configurados |
danger-full-access | Todo el sistema de archivos |
Permission Profiles (beta): reglas read/write/deny jerárquicas. Network: default sin red (allowlist-first). Approval: Suggest (default), Auto Edit, Full Auto.
El sandboxing es la verdadera línea de defensa: restringir qué puede hacer un agente a nivel de sistema operativo, no solo a nivel lógico.
Ausente No tiene sandboxing nativo. Solo permisos lógicos a nivel de tool. El mantenedor reconoce en issue #2242: "we try to restrict to cwd but agent can use bash to get around it". La comunidad compensa con Docker/bwrap/Podman.
OS-level Sandboxing por plataforma:
Filesystem isolation: escritura solo al working directory; lectura a todo el computador excepto paths denegados.
~/.aws/credentials y ~/.ssh/ son LEGIBLES por defecto — hay que denegarlos explícitamente en la configuración.Network isolation: proxy SOCKS/HTTP, sin dominios pre-permitidos, los dominios preguntan al primer intento.
OS-level Sandboxing por plataforma:
Protegidos: .git/, .codex/, gitdir: symlinks siempre read-only. Docker sandbox opcional con iptables egress filtering.
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Sandboxing OS | No | Landlock/Seatbelt/AppContainer | Seatbelt/bubblewrap |
| Sandbox Docker | Comunidad | run_in_container.sh | No |
| Network sandbox | No | Default deny (allowlist) | Proxy domain allowlist |
Cómo cada plataforma almacena credenciales, tokens y secrets. La diferencia entre plaintext y keychain cifrado puede ser la línea entre un incidente y una vulnerabilidad crítica.
Plaintext ~/.local/share/opencode/auth.json. Soporta {env:VAR} y {file:path} en config. Sin keyring built-in. Alternativas de terceros: opencode-1password-auth, opencode-varlock.
Híbrido ~/.codex/auth.json (plaintext). cli_auth_credentials_store acepta: file / keyring / auto. codex-secrets Rust crate en desarrollo (age encryption + OS keyring).
Cifrado macOS Keychain (encrypted), Linux ~/.claude/.credentials.json (chmod 0600), Windows %USERPROFILE%\.claude\.credentials.json (user profile ACL). apiKeyHelper para tokens dinámicos. CLAUDE_CODE_OAUTH_TOKEN para CI/CD.
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Secret encryption | Plaintext | Keyring opt-in | Keychain/chmod 0600 |
| Env var integration | {env:VAR} | Limitado | CLAUDE_CODE_OAUTH_TOKEN |
| Third-party vaults | 1Password plugin | En desarrollo | No |
El protocolo MCP (Model Context Protocol) permite a los agentes conectarse con servidores externos que exponen herramientas y datos. Esto abre un vector de ataque significativo: un MCP server malicioso o comprometido puede ejecutar operaciones dañinas.
OAuth 2.1 + Dynamic Client Registration. Timeout default 5s configurable. Sin validación automática de servidores. La seguridad recae en el agente que configura la conexión.
OAuth 2.0 con DCR automático en 401/403. Managed MCP: managed-mcp.json (system path), allowedMcpServers / deniedMcpServers, allowManagedMcpServersOnly. headersHelper para tokens dinámicos. strictPluginOnlyCustomization.
N/A No implementa MCP — usa function calling nativo. Sin verificación de plugins.
Herramientas comunitarias que han surgido para llenar el vacío de seguridad en el ecosistema MCP:
| Herramienta | Foco |
|---|---|
| MCP Shield | 17 detectores AST-based, 359 tests. Detecta shell_injection, eval, SSRF, secrets, path_traversal, prompt injection, typosquat, tool shadowing. pip install mcp-shield-audit |
| MCPShield | Lockfile management (mcp.lock.json), artifact verification SHA-512/SHA-256, typosquat detection (Levenshtein) |
| Credence Registry | Cryptographic attestations, source code fingerprints, provenance analysis |
| MCP Trust Framework | W3C Verifiable Credentials, DID-based identity |
| Glama | Server-side behavioral sandboxing, TDQS scoring, prompt injection drift detection |
| mcp-zero-trust-proxy | OAuth 2.1 PKCE, tool-level RBAC, audit logging, rate limiting |
Para despliegues empresariales, el control centralizado de políticas no es opcional. Cada plataforma aborda la gestión de políticas de seguridad a escala de organización de forma muy distinta.
MDM Soporta macOS .mobileconfig, /etc/opencode/ (Linux), remote config via .well-known/opencode. Managed settings son inderrotables — ni siquiera el desarrollador local puede sobrescribirlas.
Más completo Sistema enterprise con múltiples mecanismos:
managed-settings.json en system pathsmanaged-mcp.json — control exclusivo de MCP serverscom.anthropic.claudecode)HKLM\SOFTWARE\Policies\ClaudeCodemanaged-settings.d/*.jsonforceRemoteSettingsRefresh: trueAusente Sin sistema enterprise comparable. No hay managed settings, ni MDM, ni políticas remoto.
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Enterprise MDM | MDM/.well-known | No | MDM/plist/Registry |
| Managed settings | Inderrotables | No | Multi-level + drop-in |
| Remote config | .well-known/opencode | No | forceRemoteSettingsRefresh |
Claude Code es la única plataforma que implementa aislamiento físico vía git worktrees — un mecanismo ingenioso que crea checkouts separados del repositorio para cada sesión.
--worktree <name> crea un checkout separado con rama propiaisolation: worktree).worktreeinclude copia archivos gitignored (.env) al worktreeisolation: worktree.| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Worktree isolation | No | No | Git worktrees |
El ecosistema de herramientas comunitarias para verificación y seguridad de MCP ha crecido significativamente. Estas herramientas intentan cerrar el gap que las plataformas dejan en la verificación de servidores MCP de terceros.
Framework de auditoría estática con 17 detectores basados en AST y 359 tests. Detecta:
eval() y exec() dinámicospip install mcp-shield-audit
Sistema de lockfile management para MCP. Genera mcp.lock.json con hashes de verificación SHA-512/SHA-256. Detecta typosquatting mediante distancia de Levenshtein contra un registro de servidores conocidos.
Registro de attestations criptográficas para servidores MCP. Proporciona source code fingerprints y análisis de procedencia (provenance). Permite verificar que un servidor MCP proviene de una fuente legítima.
Marco basado en W3C Verifiable Credentials con identidad DID-based. Permite establecer una jerarquía de confianza descentralizada para servidores MCP.
Plataforma de servidores MCP con sandboxing comportamental del lado del servidor, scoring TDQS (Trust, Data Quality, Security) y detección de prompt injection drift.
Proxy de seguridad que implementa OAuth 2.1 PKCE, RBAC a nivel de tool, audit logging y rate limiting. Actúa como gateway de seguridad entre el agente y los servidores MCP.
La capacidad de auditar qué hizo un agente —qué herramientas ejecutó, qué archivos leyó, qué comandos corrió— es esencial para cumplimiento, forense y depuración.
Plugin gaps La Plugin API tiene carencias significativas: NO existe hook command.execute.after. Esto significa que los plugins no pueden interceptar comandos post-ejecución para auditoría. Alternativas de terceros: opencode-warden (JSONL audit log), opencode-permission-audit, opencode-trace.
Ausente Sin audit logging built-in. Solo sandbox enforcement + approval prompts. No hay rastro persistente de operaciones.
OpenTelemetry Implementación completa con OTel para métricas, eventos y traces (beta). Variables de configuración:
OTEL_LOG_TOOL_DETAILS — log detallado de invocaciones de toolsOTEL_LOG_USER_PROMPTS — log de prompts del usuarioOTEL_LOG_RAW_API_BODIES — log de cuerpos de requests APISDK SessionStore adapter compatible con S3, Redis, Postgres. cc-audit-log para parsing de transcripciones.
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Audit logging | Plugin gaps | No | OpenTelemetry |
| Log storage | Terceros | N/A | S3/Redis/Postgres |
| Aspecto | OpenCode | Codex CLI | Claude Code |
|---|---|---|---|
| Permisos | Whitelist (allow/ask/deny) | Permission Profiles beta | 6 modos + reglas jerárquicas |
| Sandboxing OS | No | Landlock/Seatbelt/AppContainer | Seatbelt/bubblewrap |
| Sandbox Docker | Comunidad | run_in_container.sh | No |
| Network sandbox | No | Default deny (allowlist) | Proxy domain allowlist |
| Secret encryption | Plaintext | Keyring opt-in | Keychain/chmod 0600 |
| MCP auth | OAuth 2.1 | No MCP | OAuth 2.0 + Managed |
| MCP supply chain | Terceros | No MCP | TOFU |
| Enterprise MDM | MDM/.well-known | No | MDM/plist/Registry |
| Audit logging | Plugin gaps | No | OpenTelemetry |
| Worktree isolation | No | No | Git worktrees |
Fortalezas:
Modelo whitelist simple y efectivo. Managed settings inderrotables. OAuth 2.1 nativo. Protección .env built-in.
Debilidades:
Sin sandboxing OS. Secrets en plaintext. Sin audit logging completo. Dependencia de comunidad para aislamiento real.
Fortalezas:
Sandboxing OS multi-plataforma completo. Default-deny network. Docker sandbox. Permission Profiles en beta con buen diseño.
Debilidades:
Sin MCP. Sin enterprise security. Sin audit logging. Secret management híbrido. Ecosistema más joven.
Fortalezas:
Sistema de permisos más granular de los 3. OpenTelemetry. Enterprise más completo. Managed MCP. Secretos cifrados.
Debilidades:
Sin Docker sandbox. ~/.aws y ~/.ssh legibles por defecto. Proxy sin inspección TLS. Sin worktree isolation en Agent Teams.
Eres un desarrollador individual que prioriza simplicidad:
OpenCode + sandbox Docker manual. El whitelist de permisos es intuitivo y el modelo lógico cubre el 80% de los casos. Añade Docker para el 20% restante.
Trabajas en una empresa con cumplimiento regulatorio (SOC 2, ISO 27001):
Claude Code con managed settings + OpenTelemetry. El sistema enterprise y el audit logging cubren los requisitos de compliance. Necesitarás denegar ~/.aws y ~/.ssh explícitamente.
Priorizas aislamiento máximo sin importar la complejidad:
Codex CLI con danger-full-access denegado + Permission Profiles restrictivos + Docker sandbox. Es la combinación más segura, aunque carece de herramientas enterprise.
Quieres minimizar riesgos de supply chain MCP:
Claude Code con allowManagedMcpServersOnly: true + MCP Shield en el pipeline CI/CD para auditar servidores antes de desplegarlos.
Caso extremo: multiple agentes autónomos en paralelo:
Claude Code con worktree isolation + managed settings + OTel audit. Es la única plataforma que ofrece aislamiento físico entre sesiones concurrentes.
bash sin restricciones está realmente sandboxeado. Combina permisos lógicos + sandboxing OS + aislamiento de red + gestión de secretos. Una sola capa no es suficiente.Todos los datos verificados a Junio 2026 de documentación oficial y repositorios de herramientas comunitarias.