Inside the Harness: Turn-Scoped Permissions stanno diventando una primitive dell'Agent Runtime

C'è un issue nel repository OpenAI Codex, filed a metà luglio, che dice più sulla direzione degli agent runtime di molti launch post. Il reporter ha notato che se cambiate il permission mode di Codex mentre un turn è in esecuzione, il running turn vi ignora. Mantiene le permissions con cui è partito e la nuova setting vale solo per il next turn. Aumentate access mid-turn e agent resta blocked. Riducetelo mid-turn e, peggio, la UI dice restricted mentre agent mantiene i powers originali ancora per diversi minuti.

Questo behaviour non è un bug nel senso ovvio. È il bordo visibile di una design decision che sta diventando standard negli agent runtime: permissions sono scoped al turn, snapshotted quando turn parte e trattate come property di quella unit of work invece che di user, machine o session. Questo piece spiega la primitive, il threat model a cui risponde e come Codex, reference implementation attuale, la collega davvero.

Punti chiave - Turn-scoped permissions significa che runtime snapshot approval policy, sandbox policy e permission profile quando inizia un turn, e ogni tool call nel turn viene eseguita contro quel snapshot. - Threat model non è malicious user. È capable agent che segue hostile instructions, prompt injection, oppure drift off-task mentre gira con i vostri credentials sulla vostra machine. - Codex implementa boundary come tre dial indipendenti: approval policy, chiede o no; sandbox mode, cosa possono toccare commands; permission profiles, fine-grained filesystem/network rules, enforced dall'OS, non dal model. - Enforcement vive sotto il model: Seatbelt su macOS, bubblewrap plus seccomp su Linux, sandbox dedicata su Windows. Dove policy non può essere enforced, Codex rifiuta command. - Frontier non risolta è mid-turn mutation: oggi snapshot è immutable per vita del turn, safe e a volte maddening.

Cosa è successo

Tra fine luglio e inizio agosto, permission surface Codex è passata da due coarse settings a qualcosa più simile a policy engine, e docs hanno recuperato. Old model aveva due dial in config.toml: sandbox_mode (read-only, workspace-write, danger-full-access) e approval_policy (untrusted, on-request, never). New model aggiunge permission profiles, attualmente beta: named, composable policies che combinano filesystem rules (read, write, deny per path, con deny vincente) e network rules, domain allowlists enforced tramite local proxy. Tre built-ins ship con runtime: :read-only, :workspace, :danger-full-access, e li estendete invece di partire da zero.

Anche interaction model è diventato più turn-native. /permissions cambia modes dentro running session. Una granular approval policy permette di mantenere alcune prompt categories interactive, sandbox escalations, MCP elicitations, mentre auto-reject altre, inclusa distinct request_permissions category, cioè agent stesso che chiede più access mid-task. E approvals possono essere routed a automatic reviewer agent che screens requests per exfiltration, credential probing e destructive actions prima che un human le veda, secondo OpenAI approvals and security documentation.

Niente di questo è un singolo announcement. È runtime che costruisce permission layer come operating systems costruirono user accounts: riluttante e in risposta al contatto con realtà.

OpenAI Codex è evoluto da due coarse settings, sandbox mode e approval policy, a named permission profiles che combinano per-path filesystem rules e proxied network domain rules, con mid-session switching, granular approval categories e optional auto-reviewing agent, secondo official permissions docs e approvals docs.

Cosa significa davvero "turn-scoped"

Definizione più pulita: insieme delle cose che agent può fare è legato a lifetime di single turn, captured quando inizia e in principio releasable quando termina. Non legato a user, che potrebbe assentarsi un'ora mentre agent lavora; non a machine, che ospita many turns di risk molto diverso; nemmeno a session, che può review code la mattina e install dependencies dopo pranzo.

Issue Codex iniziale prova che snapshot è reale. Running turn "retains a permission or sandbox snapshot created when the turn starts", come dice reporter, e fix proposto è machinery per propagare nuova approval policy, sandbox policy e permission profile in active turn o, failing that, internal pause-and-resume per restart turn sotto fresh permissions senza re-prompt user. Acceptance criteria sono quasi spec di turn-scoped permissions first-class: ridurre permissions mid-turn deve block nuove violating operations, aumentarle deve unblock agent, resumed/delegated/compacted turns devono preservare updated context.

Perché snapshot? Alternativa peggiore. Se permissions sono mutable global state, qualsiasi cosa che influenzi state, incluso content che agent legge, ha lever su ciò che agent può fare dopo. Immutable-per-turn snapshot significa permission decision presa una volta da human/policy in momento di clear intent, e agent non può parlare oltre mid-flight. Turn diventa smallest unit of trust, che coincide con agent work: "review this diff" e "push to main" non dovrebbero condividere permission context anche se same session.

Codex lega permissions a turn-start snapshot: issue luglio 2026 documenta che cambiare access modes mid-turn non influenza running turn e propone di propagare updated approval policy, sandbox policy e permission profiles in active turn, con resumed/delegated turns che preservano new context.

Il threat model a cui risponde

Vale essere precisi, perché "agent security" copre molta vague worry. Threat model dietro turn-scoped permissions ha tre actors, nessuno hacker con hoodie.

Prompt injection è headline threat. Agent legge untrusted content tutto il giorno: repositories, web pages, issue tickets, tool output. Tutto può portare instructions verso agent. Docs OpenAI sono dirette: default web search mode cached invece di live per ridurre injection exposure, e guidance avverte che network access permette a injected agent di fetch/follow untrusted instructions. Turn-scoped sandbox network-off-by-default capisce fino a dove successful injection può arrivare in quel turn.

Drift e over-reach è quello silenzioso. Capable agent facendo legitimate work vagherà comunque: installare qualcosa, fetch dependency, "helpfully" pulire directory. Sandbox risponde senza richiedere malicious agent, quindi boundary enforced dall'OS, Seatbelt macOS, bubblewrap plus seccomp Linux, native sandbox Windows, non dal good judgement del model. Dove platform non può enforce requested policy, Codex rifiuta command invece di run unsandboxed. Fail closed, non fail hopeful.

Credential exposure è multiplier. Devcontainer guidance lo dice chiaramente: Codex full access dentro container e malicious project può exfiltrate tutto dentro, inclusi Codex credentials. Per questo nuove primitives sono specifiche sui secrets: "**/*.env" = "deny" globs tolgono credential files da writable workspaces, .git, .codex, .agents protected read-only in writable roots, network proxy blocca local/private destinations per default come DNS-rebinding defence. Stessa shape di agentic AI architecture: model proposes, harness disposes, harness should hold secrets.

Threat model documentato Codex centra prompt injection, network off by default e cached web search per ridurre hostile live content, agent drift, OS-enforced sandboxes che rifiutano commands se policy non enforceable, e credential exposure, deny globs .env, read-only .git/.codex, local-network blocking, secondo OpenAI security docs.

Come l'implementazione sta insieme

Tre implementation details da copiare.

Deny batte write, write batte read, a equal specificity. Permission profiles consentono broad access prima e carve out exceptions: workspace writable, **/*.env denied, .devcontainer read-only. More specific paths override broad rules, denied subpath resta denied in writable parent. Potete anche reopen narrow subtree dentro broad deny, ~/Documents denied, ~/Documents/codex writable. È right precedence model perché least-privilege diventa additive to write invece di subtractive from memory.

Network access e network filtering sono switch separati. network.enabled = true consente commands di raggiungere network; features.network_proxy = true è ciò che enforce davvero domain rules attraverso local proxy. Uno senza altro dà unrestricted outbound access con false sense governance. Domain rules allowlist-first, deny wins, localhost e friends blocked salvo explicit allow, perché sandboxed agent con access ai local daemons non è meaningfully sandboxed.

Old e new systems non compongono. Profiles e legacy sandbox_mode mutually exclusive; se any loaded config sets sandbox_mode, profiles ignored. Enterprise admins possono forzare new model con managed allowed_permission_profiles allowlist, che deny anche omitted built-ins. Operational lesson: due permission systems che "both apply" portano a credere di aver denied qualcosa che non avete. Pick one, verify con /permissions e /status, poi expand.

Per teams che run agents oltre CLI, pattern generalizza. Snapshot permission context per task, credentials in tool-execution layer invece che model context, enforce below model, expire task end. Vendor runtime o own harness è domanda build versus buy, e self-host implica self-hosted agent trade-offs.

Codex permission profiles usano deny-over-write-over-read precedence con specificity overrides, separano network enablement da proxied domain enforcement e rifiutano composition con legacy sandbox settings per evitare ambiguity; admins possono mandate profiles via managed allowlists, secondo permissions docs.

Cosa fare adesso

1. Oggi: eseguite /permissions e /status nella prossima Codex session e guardate cosa è davvero in effect. Se any config layer sets ancora sandbox_mode, avete silently opted out dai permission profiles. Scegliete system.

2. Questa settimana: scrivete custom profile che estende :workspace, deny **/*.env, consente solo API domains davvero usati, con network_proxy on. Test con codex debug, sandbox command, prima di trust. Se review third-party code, pin projects a profile derivato da :read-only.

3. Questo mese: se build/wrap agent runtime, adottate turn come permission unit: snapshot turn start, expire turn end, secrets fuori model context, enforcement fail closed. Poi scrivete risposta all'open question Codex: cosa succede se permissions cambiano mid-turn? "Nothing until the next turn" è safe, ma users si aspettano che UI significhi ciò che dice.

FAQ

Cosa sono turn-scoped permissions?

Permission model in cui runtime capture approval policy, sandbox boundary e filesystem/network rules quando agent turn inizia e applica snapshot a every tool call. Permissions sono property di unit of work, non user, machine o session. In principio released a turn end, quindi elevated access non persists by default.

In cosa differisce da eseguire agent come restricted OS user?

OS users machine-scoped e static: every task eredita same blanket. Turn scoping lascia "review this repo" read-only mentre "install dependencies and test" gira con workspace writes e domain allowlist nella same session, senza account change. Dà anche natural place per expire access.

Prompt injection può cambiare permissions Codex?

Non within turn, by design: running turn usa snapshot preso a turn start e mid-turn settings changes non propagano, behaviour issue #32612. Residual risks sono next turn e surfaces già allowed, per questo network default off e sensitive paths denied/read-only.

Permission profiles sono abbastanza stabili?

Esplicitamente beta e non compongono con older sandbox_mode, quindi direction of travel, non finished API. Older modes stable baseline. Team rollout: pick one model per client version, verify con /status, aspettate profile fields moving.

In sintesi

Agent permissions maturano come Unix permissions: da "root or nothing" a fine-grained, least-privilege, auditable boundaries, ma unit non è process/user, è turn. Codex è implementation più chiara da studiare, e roughest edge, immutable mid-turn snapshot, è anche più istruttivo: persino reference runtime sta negoziando quanto dynamic permission può essere prima di non significare nulla. Se build/operate agents, imparate shape di primitive ora. Ogni serious runtime ne avrà una entro un anno, e quelle che sbagliano snapshot semantics impareranno in pubblico.

Se state progettando permission layer per vostri agents e volete second pair of eyes, è lavoro che faccio con client teams. Contattatemi.

Fonti

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

• OpenAI Developers, "Agent approvals and security": https://developers.openai.com/codex/agent-approvals-security (consultato 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, consultato 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, consultato 2026-08-29)

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