Split first-party MCP spawns from hostile-input spawns in the unsandboxed-exec opt-in

[chenmingwei23]

What is the problem?

agent.sandbox_allow_unsandboxed_exec is a single boolean that conflates two very different decisions:

1. "let Kiro Crew's own managed MCP servers run" — kirocrew-core, kirocrew-cron, kirocrew-computer. First-party binaries, argv fully controlled by Kiro Crew, no agent- or repo-supplied input in the command line.
2. "unconfine the mode="strict" hostile-input paths" — dashboard/handlers/worktree.py (a repo-controlled include.path could make git read ~/.aws/credentials) and the Papyrus latex.py / gitops.py chokepoints (a crafted .tex could typeset a secret into a PDF).

On a host with no sandbox backend — every Windows host, and any Linux kernel that refuses user namespaces — detect_backend() returns "none", so wrap_argv() fail-closes for both classes. Getting (1) working therefore currently requires granting (2) as well.

Why this issue matters to the user

A Windows user who just wants working MCP tooling has to accept unconfined execution for the paths that actually take hostile input. #1527 made that choice informed and consented (a kirocrew setup prompt naming ~/.aws / ~/.ssh, default no, SEL-audited) rather than implicit, which is the right posture — but the granularity problem is unchanged: there is no way to say yes to (1) and no to (2).

Both blocking reviewers on that PR objected specifically on the (2) paths, which is the evidence that the distinction is real and worth encoding.

Proposed direction (not yet designed)

Add a caller-class axis to wrap_argv() distinguishing who chose the argv from what the sandbox hides (the existing mode). First-party fixed-argv spawns could proceed on a backend-less host while agent/repo-controlled callers keep fail-closing, making the current single opt-in unnecessary for case (1).

Constraints that make this its own change rather than a rider:

• wrap_argv() has ~30 call sites; every one needs classifying, and a mistake here is a security regression, not a bug.
• "First-party" has to be enforced structurally, not by trusting a keyword argument a future caller can copy-paste. A spawn-audit ratchet (test_every_spawn_is_routed_or_allowlisted already exists in this repo) is the natural enforcement point.
• Governance interaction: _clamp_sandbox_mode() lets a policy require a minimum tier. A carve-out must not become a way to duck that floor.
• The SEL audit story needs deciding: today a refusal is denied and a nested passthrough is allowed; a first-party unconfined spawn is a third case.

Blocking relationship

Per the Design Review on #1527, this granularity should land before the same consent pattern is replicated in the dashboard surface — otherwise the coarse boolean gets a second, more prominent front door.

Related

• PR fix(setup): ask for the unsandboxed-exec opt-in on a backend-less host #1527 — consent-at-setup (the interim fix)
• Issue fix: sandbox_allow_unsandboxed_exec should default to true on Windows #1525 — the original Windows report

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97] — claimed for the automated security-batch fix run (2026-08-09). A task spec is being generated; an implementation session will open a PR referencing this issue.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]

Implementation PR opened: #2428

Minimal boolean split per the fix strategy: keyword-only first_party_fixed_argv on wrap_argv/sandboxed_spawn_argv, a carve-out in the backend=="none" fail-close branch gated on no_backend class + no governance floor, SEL unconfined third outcome, spawn-audit ratchet (FIRST_PARTY_SPAWNS), and the managed MCP probe as the single classified site (equality-gated against _kirocrew_mcp_invocation, stronger than name matching). sandbox_allow_unsandboxed_exec semantics unchanged — still a strict superset. Driving the PR to green now.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97]

PR #2428 is review-ready: 49/49 checks green on 09f98db02fbac54db4e8d3f238dc66f0f4619f50, readiness:passed, both blocking AI reviewers clear (Opus: no findings; GPT: 4 legitimate findings fixed across 3 rounds — spec-env equality gate, single governance floor read, interpreter-fallback refusal, async SEL write — and 2 designed-residual findings rebutted with evidence + overridden). Awaiting human merge.