[RFC] Strict delegation: host-enforced monotonic authority ceilings for subagents #36381

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jul 31, 2026
2. ayanamislover

   changed the title [-][RFC] Require a monotonic per-delegation permission preflight before spawning subagents[/-] [+][RFC] Strict delegation: host-enforced monotonic authority ceilings for subagents[/+] on Aug 1, 2026
3. sattyamjjain commented on Aug 4, 2026

   

   sattyamjjain

   on Aug 4, 2026

   More actions

   Read through the reviewer packet. The descriptor-lease work is more careful than most of what's shipping, so this is only about Q5, which is where I've spent most of my time.

   For MCP I think tool identity by name is the weak point in the invariant set. child_tools ⊆ parent's effective executable tools holds at prepare time, but an MCP server can change what sits behind a name after the receipt is sealed. notifications/tools/list_changed exists precisely so a server can announce a new or altered tool surface mid-session, and a server that simply stays quiet and swaps a tool's description doesn't even need that. So the sealed set stays a subset nominally while the actual authority behind it widens.

   The version that survives is binding the tool schema at prepare rather than the tool name. A digest over the normalized tool definition (name, input schema, description text), recorded in the receipt and re-checked at dispatch, with any mismatch failing closed instead of refreshing. Description text matters more than it looks here, since that's the injection surface, and a "harmless" description edit is exactly how the tool-poisoning class works.

   That also gives a concrete shape for Q5. An MCP server can meet a receipt-bindable contract if it pins tool definitions per session and either doesn't emit list_changed inside a sealed ceiling or is refused when it does. Servers that mutate their surface freely can't meet it, and I don't think that's fixable from the host side, which might be the honest answer to give rather than keeping the door open.

   On Q4, from operating unattended agents rather than from your codebase: most mid-run expansion pressure comes from under-specified tasks rather than genuine need. Permanently non-expandable children are workable when respawn is cheap, and painful when a long run dies near the end over one missing tool. A replacement receipt that re-proves against the original parent snapshot rather than the current one seems like the middle path, though that moves the drift problem rather than removing it.

   For context on where I'm standing: my own work here is in-process policy on the MCP call path, not an OS sandbox contract, so take this as a note on the source-isolation surface and not on the bubblewrap handoff.
4. jaebit commented on Aug 6, 2026

   

   jaebit

   on Aug 6, 2026

   More actions

   Downstream implementation evidence from a Codex policy-harness prototype

   I independently reached the same boundary while integrating Codex plugin hooks and custom agents on Windows. We implemented a deterministic local lifecycle contract in Pathmaru/Orchmaru, but deliberately kept its operational status at HOLD because a plugin/local ledger cannot provide the host-enforced property described by this RFC.

   Public prototype: jaebit/pathmaru@15ac74e

   The prototype models:

   • admission preregistration before launch;
   • launch, follow-up, terminal, and bounded-wait transitions;
   • immutable parent/task binding and single-use event IDs;
   • terminal-instance reuse rejection;
   • deterministic deny reasons and replay with zero declared model posts;
   • effective read-only capability checks for verifier roles.

   That work is useful as a contract and fixture, but it exposed three places where a downstream harness cannot close the boundary:

   1. A local receipt does not prove that admission ran before the host created a child thread or made a model request.
   2. A role TOML or prompt cannot prove the effective child sandbox when live parent/runtime authority can override or bypass it.
   3. A caller-supplied "observed" wait event is not evidence of an event-driven host wait; it can hide model-mediated polling.

   I suggest extending the RFC's receipt/provenance acceptance criteria to cover the complete collaboration lifecycle, not only birth-time authority. Field names below are illustrative rather than a request to freeze a particular API:

   lifecycle_decision = {
     task_id,
     parent_thread_id,
     child_thread_id?,
     instance_id?,
     transition,              // preregister | launch | followup | terminal | wait
     requested_role,
     effective_role,
     requested_model,
     effective_model,
     effective_sandbox,
     allowed,
     deny_reasons,
     created_instances_delta,
     actual_model_requests_delta,
     authority_receipt_id,
     transition_receipt_id
   }
   

   The host should be able to prove these invariants:

   • A denied or incomplete prerequisite path produces both zero created child instances and zero model requests.
   • A verifier admitted as read-only receives an effective platform sandbox that blocks mutation tools and filesystem writes; an attempted mutation produces an authoritative deny receipt.
   • Once an instance is terminal, every follow-up is rejected below all public continuation handlers and cannot cause another model request.
   • A bounded wait names one expected terminal/mailbox event and wakes from host activity or its single deadline, without periodic model re-entry.
   • The receipt records requested and effective role/model/sandbox values so fallback or inheritance cannot be mistaken for successful routing.

   A minimal regression gate would therefore assert:

   1. missing prerequisite -> no child and no model POST;
   2. terminal integrator -> reuse rejected;
   3. verifier write attempt -> platform denial;
   4. real heterogeneous worker launches -> authoritative effective-model receipts;
   5. quiet wait -> zero fixed-interval polling/model turns;
   6. target worktree unchanged for a read-only gate.

   This seems complementary to:

   • [Follow-up] Multi-Agent V2 needs verifiable full-profile application and lifecycle continuity for custom agents #33314 for full-profile application, follow-up continuity, and deterministic finalisation;
   • MultiAgentV2 canonical activity items omit effective subagent identity/model/effort metadata #32504 for authoritative effective child metadata;
   • Codex Desktop repeatedly re-enters the model during wait/status polling, consuming substantial credits #35259 and Background subprocesses/subagents do not wake the calling agent on completion #15723 for event-driven wait/wake behavior;
   • Windows PowerShell $home collision let a read-only subagent recursively delete %USERPROFILE% #32684 for the concrete risk of treating a read-only assignment as a prompt convention;
   • [Hooks] SubagentStart and SubagentStop are not dispatched for project-defined custom subagents on Windows #33097 for lifecycle-hook dispatch gaps.

   The local prototype is not proposed as an alternative security boundary. Its useful result is the negative one: contract fixtures can define these invariants, but only the Codex scheduler/control plane and sandbox backends can issue trustworthy lifecycle and no-side-effect receipts.
5. ayanamislover commented on Aug 8, 2026

   

   ayanamislover

   on Aug 8, 2026

   Author

   More actions

   Thank you @sattyamjjain and @jaebit — I treated both comments as concrete acceptance criteria and hardened the reference branch before publishing this update.

   Tool identity and mutable providers

   The receipt no longer binds only tool names. It now seals canonical SHA-256 digests over namespace/name, description, input schema, and execution-facing options. The host keeps the raw parent definition and the deterministic strict-child projection separate: the former is re-read at consume time, while the latter is what the child router and final dispatch must match. The fresh full-workspace sweep caught why this distinction matters: strict source policy removes the optional shell login field, so binding the raw parent schema directly caused the real strict child to fail closed. That regression is fixed and covered at receipt and real-child levels. The host now:

   • re-reads the parent's definition table at consume time;
   • rejects receipt creation when any delegatable tool lacks an exact strict-child projection;
   • filters model-visible and dispatchable tools against the sealed definitions;
   • gives the raw dispatchable runtime definition precedence over core-owned display projections; and
   • recomputes the digest immediately before telemetry, hooks, or the handler. A missing table or same-name drift fails closed with zero handler calls.

   MCP remains unsupported in strict children. The documented future contract requires a session-pinned normalized catalog and enforceable revision, treats notifications/tools/list_changed as ceiling invalidation, and rejects providers that can silently mutate behavior behind an unchanged advertised definition. I agree that this is the honest boundary rather than implying arbitrary MCP servers can be made safe from the host side.

   Host lifecycle evidence

   The strict V1 and V2 missing-receipt regressions now assert that the thread manager remains empty after denial, so no child thread or child model loop can start. The lifecycle notes also make the existing semantics explicit:

   • wait blocks on host status/mailbox watch channels plus one deadline, not model-mediated polling;
   • Completed is resumable and retains the same sealed ceiling;
   • close/removal is the terminal addressing boundary; and
   • receipt tombstones are grant-lifecycle state, not agent-terminal state.

   I did not claim a unified requested/effective role/model/sandbox audit stream that does not yet exist. That remains a separate observability follow-up; it must not become the authority source for the host-owned permission snapshot.

   Reverification

   • Windows full workspace: 13,010/13,010 passed, 102 skipped, 0 observed retries/failures. One legacy restricted-token delete test is explicitly excluded after reproducing the same failure on the unmodified pinned base; strict delegation rejects that backend. A preceding no-retry sweep had two unrelated full-load timing flakes, both of which then passed three isolated zero-retry rounds (6/6) before the clean final sweep.
   • Ubuntu 24.04.3 VMware full workspace: 13,667/13,667 passed, 23 skipped, 0 retries/failures. The trap restored kernel.apparmor_restrict_unprivileged_userns from 1 to 1, and /tmp/.git, /tmp/.agents, and /tmp/.codex were absent afterward.
   • Complete codex-core --lib: Windows 2,120/2,120 (3 skipped), Ubuntu 2,215/2,215 (0 skipped).
   • Scoped codex-core Clippy passed without diagnostics on both platforms before the final mechanical just fix / just fmt.

   Updated reference commit: ayanamislover@eab87d1

   The reviewer packet now includes the reply-driven threat-model delta, exact cross-platform evidence, and the deliberate unsupported-provider boundary: https://github.com/ayanamislover/codex/tree/eab87d1f0f035c4bc4f13878a0ab4d90ae8ee16c/research/agent-permission-preflight
6. Roppon-64 commented on Sep 30, 2026

   

   Roppon-64

   on Sep 30, 2026 – with ChatGPT Codex Connector

   More actions

   Could this RFC expose a required External Spawn Authorizer integration at its native delegation boundary?

   The RFC already addresses mandatory preflight, one-use receipts, and atomic enforcement before child creation. I would like to build on those guarantees rather than propose a parallel admission mechanism. The additional requirement is that an operator-configured external policy provider participates as a mandatory authorization authority.

   In an opt-in required mode, the contract would provide:

   • Mandatory pre-spawn invocation. Every admitted native delegation must involve a fresh call to the configured, authenticated authorizer before child creation. A model instruction to consult policy, or notification after creation, would not satisfy this requirement.
   • Typed decision and constraints. The authorizer can return decision: allow | deny, additional constraints, and an authorization receipt for an allow. Constraints may only narrow the host-validated authority. Unsupported or unenforceable constraints must cause refusal.
   • Receipt-gated creation. A valid external receipt is a prerequisite for the host’s existing strict-delegation admission/consume path. Missing receipts cannot fall back to ordinary spawning.
   • Exact binding. The receipt binds the canonicalized spawn request (or its cryptographic commitment), unique call identity, task identity or commitment, parent, resolved role, authority snapshot, and returned constraints, with a bounded expiry. Constraint application must produce a sealed effective authority covered by that binding; it must not silently change what was authorized.
   • Fail-closed validation. Replayed, expired, stale, or mismatched receipts—and unavailable authorizers, timeouts, malformed responses, unsupported versions, or identity/configuration drift—must prevent child creation.

   A possible integration with this RFC is:

   Existing strict preflight and authority snapshot
     -> required external authorization
     -> enforce and bind any narrowing constraints
     -> existing atomic receipt validation/consumption
     -> native child creation
   

   The host would retain responsibility for proving monotonicity, enforcing the compiled ceiling, and atomically validating the external receipt together with the strict-delegation grant. The external provider would not create children, expand permissions, or replace the native runtime. If required authorization fails, neither a child nor its initial model execution should start.

   This is machine authorization, with its own receipt type and audit semantics. An external allow must not be interpreted as human approval, workflow approval, or completion evidence. Conversely, those records cannot substitute for the required external receipt.

   Would this fit as an optional policy-provider extension to the RFC’s existing preparation and consume boundary? The transport and exact API names are open; the essential addition is a trusted external decision that is technically mandatory before native delegation can take effect.
7. virajchoudhary commented on Oct 13, 2026

   

   virajchoudhary

   on Oct 13, 2026 – with ChatGPT Codex Connector

   More actions

   Current-source confirmation from a Windows verifier-isolation investigation, 2026-10-13.

   At upstream 90f00bd89ed3263b4d5993849cccb795f4330449, both spawn versions route through prepare_agent_spawn_config in codex-rs/core/src/agent/child_config.rs. It applies the role and then calls apply_spawn_agent_runtime_overrides, which copies the live parent's permission-profile snapshot and approval policy. The typed AgentRoleOverrides in codex-rs/core/src/agent/role.rs also omits permission settings. Neither V1 nor V2 spawn arguments expose an independently enforced child permission profile.

   The current official Subagents documentation explicitly describes reapplying live parent permission overrides over role defaults. Accordingly, a role file containing sandbox_mode = "read-only" must not be treated as a hard write boundary under a Full Access parent. Our retained audit distinguishes a working read-only-parent delegation from the unresolved Full Access-parent case; those are different acceptance claims.

   This supports the RFC's sticky host-ceiling requirement. Changing role precedence or adding a birth-time sandbox field alone would not close permission expansion, nested delegation, tool-source authority, or reload paths. We did not apply such a partial patch or activate the research branch. Its published test totals were not independently rerun here.

   This is sanitized source analysis and workflow evidence, not a new exploit report, installed fix, or unsolicited code contribution. No credentials, conversation content, personal paths, or runtime configuration changes are included.
8. virajchoudhary commented on Oct 13, 2026

   

   virajchoudhary

   on Oct 13, 2026 – with ChatGPT Codex Connector

   More actions

   Independent reference admission checks and the remaining Windows OS gate

   I checked the published reference commit eab87d1f0f035c4bc4f13878a0ab4d90ae8ee16c on native Windows x64 with Rust 1.99.0 through just test. This was a separate local checkout, not an installed Codex or Desktop change.

   I added one focused local test for the Full Access-parent admission case: PermissionProfile::Disabled can prepare a managed read-only child snapshot, while an unsandboxed child request is rejected with UnsupportedPolicy. The final admission selection passed 22 tests. Five distinct session update, runtime-grant, and receipt-free/control-overlay tests also passed. Both selections used zero retries. No full workspace sweep was run.

   These are admission and in-memory enforcement checks. They do not prove child-side create, overwrite, delete, policy-file mutation, escalation, or nested-spawn denial through the Windows OS backend. The published real Windows filesystem tests construct a managed writable parent, rather than the exact Full Access-parent case. That case still needs a real-process canary.

   One practical test-isolation boundary matters when reproducing this on a working Codex host. The Elevated setup uses fixed CodexSandboxOffline and CodexSandboxOnline accounts and stable firewall rule names. Its provision_sandbox_users generates fresh passwords, and ensure_local_user falls back to NetUserSetInfo for an existing account. A separate CODEX_HOME changes the secrets-file location, not those machine-global identities or rules. It is therefore not proof that setup preserves an active host runtime.

   I did not run Elevated setup or a real restricted-child OS canary on the recovered host. The safe remaining gate is a disposable Windows test host, with effective child permissions, file/policy mutation attempts, escalation, nested delegation, and a parent write-control check. Known sandbox-account metadata and user PATH remained unchanged during the selected library tests.

   Independent source review accepts the narrow admission test but reports FAIL for the requested runtime-isolation acceptance. No installed repair or overall security PASS is claimed. This adds bounded reference evidence, not a proposal to productize the broad branch or submit an external PR. No credentials, private logs, account identifiers, personal paths, or conversations are included.