Inside the Harness: Turn-Scoped Permissions se están convirtiendo en una primitive de Agent Runtime

Hay un issue en el repository de OpenAI Codex, filed a mediados de julio, que dice más sobre hacia dónde van los agent runtimes que la mayoría de launch posts. El reporter observó que si cambias el permission mode de Codex mientras corre un turn, el running turn te ignora. Conserva las permissions con las que empezó y tu nueva setting solo aplica al siguiente turn. Sube access mid-turn y el agent sigue blocked. Bájalo mid-turn y, peor, la UI dice restricted mientras el agent conserva sus powers originales durante varios minutos más.

Ese behaviour no es un bug en el sentido obvio. Es el borde visible de una design decision que se está volviendo estándar en agent runtimes: permissions se scopean al turn, se snapshottean cuando empieza y se tratan como property de esa unit of work en lugar del user, machine o session. Este piece explica qué es esa primitive, el threat model que responde y cómo Codex, la reference implementation ahora mismo, realmente lo conecta.

Conclusiones clave - Turn-scoped permissions significa que runtime captura una approval policy, sandbox policy y permission profile cuando comienza un turn, y cada tool call en ese turn ejecuta contra el snapshot. - Threat model no es malicious user. Es un capable agent siguiendo hostile instructions, prompt injection, o desviándose off-task mientras corre con tus credentials en tu machine. - Codex implementa boundary con tres dials independientes: approval policy, pregunta o no; sandbox mode, qué pueden tocar commands; permission profiles, fine-grained filesystem/network rules, enforced por OS, no model. - Enforcement vive debajo del model: Seatbelt en macOS, bubblewrap plus seccomp en Linux, sandbox dedicada en Windows. Donde policy no puede enforce, Codex rechaza command. - Frontier sin resolver es mid-turn mutation: hoy snapshot es immutable durante vida del turn, safe y a veces maddening.

Qué ocurrió

Entre finales de julio y principios de agosto, permission surface de Codex engordó desde dos coarse settings hasta algo parecido a policy engine, y docs se pusieron al día. Modelo antiguo eran dos dials en config.toml: sandbox_mode (read-only, workspace-write, danger-full-access) y approval_policy (untrusted, on-request, never). Modelo nuevo añade permission profiles, beta: policies nombradas y composable que combinan filesystem rules (read, write, deny por path, deny gana) y network rules, domain allowlists enforced por local proxy. Tres built-ins vienen con runtime: :read-only, :workspace, :danger-full-access, y los extiendes en vez de empezar de cero.

A la vez, interaction model se volvió más turn-native. /permissions cambia modes dentro de running session. Granular approval policy permite mantener algunas prompt categories interactive, sandbox escalations, MCP elicitations, mientras auto-rejecta otras, incluida distinct request_permissions category, el propio agent pidiendo más access mid-task. Y approvals pueden routearse a automatic reviewer agent que screens requests por exfiltration, credential probing y destructive actions antes de que human las vea, según documentation de approvals y security de OpenAI.

Nada de esto es un solo announcement. Es runtime construyendo permission layer como operating systems construyeron user accounts: a regañadientes y tras tocar realidad.

OpenAI Codex evolucionó de dos coarse settings, sandbox mode y approval policy, a named permission profiles que combinan per-path filesystem rules y proxied network domain rules, con mid-session switching, granular approval categories y optional auto-reviewing agent, según official permissions docs y approvals docs.

Qué significa realmente "turn-scoped"

La definición más limpia: conjunto de cosas que agent puede hacer está vinculado a lifetime de single turn, capturado cuando comienza y, en principio, released al terminar. No ligado al user, que podría ausentarse una hora mientras agent trabaja; no a machine, que aloja muchos turns de riesgos muy distintos; ni a session, que puede review code por la mañana e instalar dependencies después de comer.

Issue Codex que abre este piece prueba que snapshot es real. Running turn "retains a permission or sandbox snapshot created when the turn starts", como dijo reporter, y fix propuesto es machinery para propagar nueva approval policy, sandbox policy y permission profile al active turn, o failing that, internal pause-and-resume para que turn reinicie con fresh permissions sin que user reprompte. Lee acceptance criteria y son spec para turn-scoped permissions como first-class runtime concept: reducir permissions mid-turn debe bloquear nuevas violating operations, aumentarlas debe unblock agent, resumed/delegated/compacted turns deben preservar updated context.

¿Por qué snapshot? Porque alternativa peor. Si permissions son mutable global state, cualquier cosa que pueda influir state, incluido content que agent lee, tiene lever sobre lo que puede hacer después. Immutable-per-turn snapshot significa permission decision hecha una vez por human/policy en momento de clear intent, y agent no puede hablarse más allá mid-flight. Turn se vuelve smallest unit of trust, alineado con agent work: "review this diff" y "push to main" nunca deberían compartir permission context aunque compartan session.

Codex vincula permissions a turn-start snapshot: issue de julio de 2026 documenta que cambiar access modes mid-turn no afecta running turn y propone propagar updated approval policy, sandbox policy y permission profiles al active turn, con resumed/delegated turns preservando nuevo context.

El threat model que responde

Vale ser preciso, porque "agent security" cubre mucha preocupación vaga. Threat model tras turn-scoped permissions tiene tres actors nombrados, ninguno hacker con hoodie.

Prompt injection es headline threat. Agent lee untrusted content todo el día: repositories, web pages, issue tickets, tool output. Cualquiera puede llevar instructions dirigidas al agent. Docs OpenAI son directas: default web search mode es cached en vez de live específicamente para reducir injection exposure, y guidance advierte que network access permite injected agent fetch/follow untrusted instructions. Turn-scoped sandbox con network-off-by-default limita alcance de successful injection en ese turn.

Drift y over-reach es el silencioso. Capable agent haciendo trabajo legítimo igual vagará: instalar algo, fetch dependency, "helpfully" limpiar directory. Sandbox responde sin requerir malicious agent, por eso boundary enforced por OS, Seatbelt macOS, bubblewrap plus seccomp Linux, native sandbox Windows, no por good judgement del model. Donde platform no puede enforce requested policy, Codex rechaza command en vez de running unsandboxed. Fail closed, not fail hopeful.

Credential exposure es multiplier. Devcontainer guidance lo explica: corre Codex full access dentro container y malicious project puede exfiltrate todo dentro, incluidos Codex credentials. Por eso newer primitives son específicas con secrets: "**/*.env" = "deny" globs sacan credential files de writable workspaces, .git, .codex, .agents protected read-only dentro writable roots, y network proxy bloquea local/private destinations por default como DNS-rebinding defence. Same shape que broader architecture question en agentic AI architecture: model proposes, harness disposes, harness should hold secrets.

Threat model documentado de Codex centra prompt injection, network off by default y cached web search para reducir hostile live content; agent drift, OS-enforced sandboxes que rechazan commands si policy no puede enforce; credential exposure, deny globs .env, read-only .git/.codex, local-network blocking, según security docs de OpenAI.

Cómo encaja realmente la implementación

Tres implementation details merece copiar.

Deny gana a write, write gana a read, con misma specificity. Permission profiles dejan grant broad access primero y carve out exceptions: workspace writable, **/*.env denied, .devcontainer read-only. More specific paths override broader, y denied subpath sigue denied dentro writable parent. Puedes incluso reopen narrow subtree dentro broad deny, ~/Documents denied, ~/Documents/codex writable. Es right precedence model porque least-privilege se vuelve additive to write en vez de subtractive from memory.

Network access y network filtering son switches separados. network.enabled = true deja commands alcanzar network; features.network_proxy = true es lo que realmente enforce domain rules mediante local proxy. Uno sin otro da unrestricted outbound access con false sense governance. Domain rules allowlist-first, deny wins, y localhost y friends blocked salvo explícitamente allowed, porque sandboxed agent con access a local daemons no está meaningfully sandboxed.

Old y new systems no componen. Profiles y legacy sandbox_mode mutually exclusive; si any loaded config sets sandbox_mode, profiles ignored. Enterprise admins pueden forzar new model con managed allowed_permission_profiles allowlist, que también denies omitted built-ins. Operational lesson: dos permission systems que "both apply" es cómo acabas pensando que denied algo que no. Elige uno, verify con /permissions y /status, luego expand.

Para teams que corren agents beyond CLI, pattern generaliza. Snapshot permission context per task, mantén credentials en tool-execution layer no model context, enforce below model y expire todo al task end. Obtenerlo de vendor runtime o own harness es pregunta build versus buy, y si self-host, aplican self-hosted agent trade-offs con más knobs.

Codex permission profiles usan deny-over-write-over-read precedence con specificity overrides, separan network enablement de proxied domain enforcement y rehúsan componer con legacy sandbox settings para evitar ambiguity; admins pueden mandate profiles via managed allowlists, según permissions docs.

Qué hacer ahora

1. Hoy: ejecuta /permissions y /status en próxima Codex session y mira qué está realmente in effect, no lo que crees. Si any config layer todavía sets sandbox_mode, has opted out silenciosamente de permission profiles. Decide system.

2. Esta semana: escribe custom profile que extienda :workspace, deny **/*.env y permita solo API domains realmente llamados, con network_proxy on. Test con codex debug, sandbox command, antes de confiar. Si review third-party code, pin esos projects a profile derivado de :read-only en project config.

3. Este mes: si build agent runtime o wrap una, adopta turn como permission unit: snapshot al turn start, expire al turn end, secrets fuera model context, enforcement fail closed. Luego escribe respuesta a open question Codex aún no termina: ¿qué debe ocurrir si permissions cambian mid-turn? "Nothing until the next turn" es safe, pero users esperan que UI signifique lo que dice.

FAQ

¿Qué son turn-scoped permissions?

Permission model donde runtime captura approval policy, sandbox boundary y filesystem/network rules cuando empieza agent turn y aplica snapshot a cada tool call. Permissions son property de unit of work, no user, machine o session. En principio released al finalizar turn, elevated access no persists by default.

¿Cómo difiere de ejecutar agent como restricted OS user?

OS users machine-scoped y static: every task hereda same blanket. Turn scoping deja "review this repo" read-only mientras "install dependencies and test" corre con workspace writes y domain allowlist, misma session, sin cambiar accounts. También da lugar natural para expire access, que OS users no tienen.

¿Puede prompt injection cambiar permissions de Codex?

No within a turn, by design: running turn ejecuta contra snapshot tomado al turn start, y mid-turn setting changes no propagan, behaviour de issue #32612. Residual risks son next turn y surfaces ya allowed, por eso network default off y sensitive paths denied/read-only.

¿Permission profiles son estables para construir encima?

Explícitamente beta y no componen con older sandbox_mode, así que trátalos como direction of travel no finished API. Older modes stable baseline hoy. Para team rollout, pick one model per client version, verify behaviour con /status y espera profile fields moviéndose un tiempo.

En resumen

Agent permissions maduran como Unix permissions: de "root or nothing" hacia fine-grained, least-privilege, auditable boundaries, excepto unit no es process/user, es turn. Codex es implementación más clara para estudiar ahora, y roughest edge, immutable mid-turn snapshot, también más instructivo: hasta reference runtime negocia cuánto dynamic puede ser permission antes de dejar de significar algo. Si build/operate agents, aprende shape de primitive ahora. Toda serious runtime tendrá una en un año, y las que fallen snapshot semantics aprenderán en público.

Si diseñas permission layer para tus agents y quieres second pair of eyes, trabajo así con client teams. Ponte en contacto.

Fuentes

• OpenAI Developers, "Codex permissions": https://developers.openai.com/codex/permissions (consultado 2026-08-29)

• OpenAI Developers, "Agent approvals and security": https://developers.openai.com/codex/agent-approvals-security (consultado 2026-08-29)

• GitHub, openai/codex issue #32612, "Apply access-control changes to the currently running turn": https://github.com/openai/codex/issues/32612 (filed 2026-07-12, consultado 2026-08-29)

• GitHub, openai/codex issue #23626, "Codex CLI /permissions omits Read-only in WSL2 but shows it in Windows PowerShell": https://github.com/openai/codex/issues/23626 (filed 2026-05-20, consultado 2026-08-29)

• OpenAI Codex repository: https://github.com/openai/codex (consultado 2026-08-29)