feat(dashboard): add the settings panel for flagged-file delivery consent

[chenmingwei23]

Problem / Motivation

Kiro Crew refuses to deliver a file whose contents the credential scanner flags,
with no consented way through -- so a VPN device key the owner legitimately needs
delivered is blocked, and the feature reads as broken rather than protective
(issue #7770). This PR adds an owner-consented delivery path, recorded as a
durable grant every delivery gate re-reads.

The hard part is that this grant authorizes a secret-bearing file past four
independent content gates, so the consent point IS a security boundary -- and the
issue's own acceptance is that consent must be "a human dashboard action", not
something a background agent can grant on the owner's behalf.

Why it matters

An owner dashboard session proves identity, not human presence: anyone running
computer use points an agent at an owner-authenticated browser, so an
owner-session check alone lets a prompt-injected, auto-approved click record a
grant and make every later flagged file deliverable -- the exact "agent can
self-approve" hole #7770 exists to close. And a consent prompt the owner cannot
understand is not informed consent. The security boundary and the copy are the
two things this feature is actually about.

What changed (motivation -> approach -> change)

Security -- a human-only step-up, mirroring the established update_stepup
pattern (RFC OQ7) the repo already uses for "a dashboard session is not enough
authority for a security-critical write":

• Recording a grant is split into ARM + APPROVE. The owner-gated POST only ARMS a
  request and writes a single-use nonce; kirocrew file-delivery approve on the
  host consumes it and records the grant via a new loopback-only endpoint.
• The nonce lives in its OWN top-level leaf file-delivery-consent-pending/,
  registered in both security._CREW_SECRET_LEAVES (file gate) AND
  sandbox._CREW_HIDDEN_LEAVES, so it is bind-masked out of the agent sandbox in
  every mode. It is deliberately NOT under trust/, which is sandbox-VISIBLE for
  SEL appends and would let a prompt-injected agent forge a nonce there with a
  runtime-constructed shell path. Because that directory is created lazily at arm
  time, it is also added to sandbox._CREW_PRECREATE_HIDDEN_DIR_LEAVES so the
  mask binds over it before any sandbox spawns on a fresh install
  (aws-control-staging is the precedent).
• The loopback-only approve endpoint is on _STRICT_INTERNAL_API_PATHS (not
  MIXED), exactly like its sibling /api/update/approve: loopback +
  X-Internal-Secret only, no cookie fall-through, so a dashboard/agent bearer
  cannot even reach the handler. The handler also re-asserts host-locality.
• A self-protection-file-delivery denied-command FLOOR rule blocks the agent
  from running the approve verb through its own shell at all, mirroring
  self-protection-update. Defence in depth alongside the mask.
• The approve handler refuses to record a grant while COMPUTER USE is enabled:
  desktop input synthesis would let a prompt-injected agent type the approve
  command into a host terminal and complete the owner's armed step-up itself, so
  that one tier is excluded rather than trusted (reads the fail-safe-to-disabled
  keystone computer_use.json).
• It likewise refuses unless the effective agent sandbox actually applies the
  pending-nonce mask: with agent.sandbox off (or no backend + unsandboxed exec
  opted in) the nonce is unmasked and an unsandboxed agent could read or forge it
  directly, so the presence proof is void. Uses the same security-reviewed
  credential_mask_applies predicate the ACP tool gate uses, which fails closed.
• Withdrawal keeps its single owner-gated door with no step-up: revoking is the
  fail-safe direction.
• The approve handler orders its side effects so the irreversible one is last:
  it validates the nonce, records the grant, and only then clears the single-use
  nonce. A grant-write failure therefore leaves the nonce valid and the owner can
  retry, instead of a 500 that also destroyed the armed request; single-use still
  holds because the nonce is cleared on the success path before the response.

UX -- plain language and a stated purpose at the point of consent:

• file_delivery_desc now names the use case ("Use this when a file of your own
  -- like a VPN key -- was blocked on its way to you"), the piece a blind reader
  said it needed before it would allow anything.
• The destination is "This computer and your dashboard Files view" plus a
  one-line helper naming the outbox folder and the Files view, and stating it
  never goes to Slack or a chat channel; never-grantable legs are described in
  words, not the raw ids.
• The primary control reads "Allow delivery"; states are "Allowed" / "Not
  allowed"; the armed expiry renders as a human duration ("about 10 minutes"),
  not raw seconds; em dashes match the catalogue.
• A failed arm-status read now surfaces its own ErrorNotice instead of silently
  dropping the command panel. While a request is armed the row shows a "Waiting
  for approval" badge and a disabled "Waiting on this machine" CTA (so a re-click
  is not an invisible re-arm); the host command has a Copy button; an expired
  armed request leaves a line rather than a silent unmount.
• The kirocrew file-delivery CLI verb requires its approve action (no
  nargs="?"): a bare invocation errors instead of silently approving.
• docs/feature-map/README.md corrected to state the real boundary (arm is
  owner-gated; recording is the host-only nonce step-up; the masked nonce leaf
  plus the floor rule are the agent fences) -- the prior line called the
  endpoints owner-gated, which this change made false.
• All 12 locale catalogs updated via the repo's own tooling (translations by the
  i18n path, en-XA regenerated by gen-pseudolocale.mjs), passing the
  per-language style gates (Italian accents, zh-CN particle stacking, Hindi
  informal register).

Default preserved: delivery is still refused until the owner allows it, so nothing
changes until a human opts in on the host.

Tests

• Backend test/test_file_delivery_consent.py, test/test_denied_commands_security.py,
  test/test_sandbox_governance_mask.py, test/test_sandbox_absent_ceiling_seal.py
  and test/test_mcp_call_site_auth_coverage.py (run -n0): arm->approve
  round-trip; TestGrantRequiresAHostStepUp pins arm-records-nothing,
  remote-approve-refused, wrong-nonce-refused, single-use, the nonce leaf is
  masked, the precreate materialises the leaf before spawn, the approve endpoint
  is STRICT-not-MIXED, and approve is refused while computer use is enabled but
  allowed when disabled. Mutation-verified: the floor rule, the mask leaf, the
  precreate entry, the STRICT entry and the computer-use fence each redden a test
  when removed.
• Frontend SecurityPanel.fileDelivery.test.tsx: clicking Allow ARMS (records
  nothing) and shows the host command with the disabled waiting CTA, and a Copy
  button; a failed arm-status read is surfaced. tsc clean.
• i18n gates pass: catalogParity, changedValueQa, keyReference, englishIdentity,
  renderScan, and the per-locale style specs; en-XA is generator-produced.

Manual verification

Rendered the panel through the capture harness against the built SPA and read the
frames: the resting state (use-case sentence + plain destination), the armed
step-up showing kirocrew file-delivery approve with "expires in about 10
minutes", the write-failure notice, and the arm-status-failure notice. The
capture harness asserts each failure notice actually rendered before shooting, so
it cannot emit a plausible frame of the wrong state.

Screenshots / video

Resting state -- plain destination, the use-case sentence, "Allow delivery":

Armed step-up -- the click did NOT record a grant; the host command finishes it,
with a human-readable expiry:

Write-failure state:

All capture states are committed under temp-screenshots/file-delivery-consent/;
see the Files changed tab as a fallback.

Related Issues

Closes #7770

Out of scope (tracked separately)

The UX review (Fable 5) raised one blocker that this PR deliberately does not
fix: the consent card does not name the specific file that was refused, so the
owner has no concrete event to anchor the decision to. It is a valid concern, but
its only faithful implementation is a new surface -- the refused-file event is
written to no owner-readable store today (audit_decision records only
granted / revoked / delivered, never the refusal, and there is no SEL read
path in the app surface), so surfacing it needs a new refusal-capture store, a new
read endpoint, and card rendering. That is filed as #9091 and is not folded here,
to keep this PR's security-critical surface reviewable. The reviewer's suggested
source ("from the SEL entry audit_decision already writes") does not exist for
refusals -- the concern is real, the proposed remedy is not, and #9091 carries the
correct one. This PR does fold the review's smaller, frontend-only items: an
armed-state badge and a disabled "Waiting on this machine" CTA while armed, a Copy
button on the host command, an expired-request line instead of a silent unmount,
the long-duration expiry form, and the missing arm-status-failed screenshot.

Pattern harvest

• A dashboard owner-session gate proves identity, not human presence. A
  security-critical write reachable by an agent-driven owner browser needs a
  host-only step-up, and the step-up is only as strong as the fences around its
  nonce: the nonce must live on a sandbox-MASKED leaf (a sandbox-visible one can
  be forged with a runtime-constructed shell path), the leaf must be pre-created
  so the mask binds before spawn, the approve endpoint must be STRICT-internal so
  no cookie bearer reaches it, the CLI verb must be on the self-protection floor,
  and the one tier that can synthesize host presence (computer use) must be
  excluded. update_stepup is agent-proof because these hold together; each was
  a distinct review finding on this PR where one was missing.
• A security fix that moves a boundary falsifies every comment that described the
  old one, and comments are what no test covers -- grep the tree for the old
  description, not just the line the reviewer named.
• Consent copy has two gates: how a value is added, and what the value says. The
  destination label and a stated purpose are where informed consent is won or
  lost.

[github-actions]

Design Review (Fable 5) — 🟡 CONCERNS

Design-level review of 71e68b2272b147268c3e0c8a0cafccf13f7d2d90 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: CONCERNS

Sound step-up design correctly mirroring update_stepup, but the PR description misstates the shipped security mechanism and omits two approve-time refusals.

Watch

• The description says the nonce "lives under the trust/ leaf" and that the floor rule is "what makes the step-up agent-proof" — but the shipped code puts it in a dedicated file-delivery-consent-pending/ leaf where the sandbox bind-mask is "the load-bearing half" and the floor rule is the "defence-in-depth partner" (sandbox.py, security.py comments; the feature-map doc states this correctly). For a PR whose whole point is a security boundary, the description is the audit record — it currently directs human reviewers to audit the wrong control. Update it to match the shipped design.
• The approve endpoint 403s when computer use is enabled or when the sandbox mask is not in effect ("agent.sandbox is 'off', or no sandbox backend is available") — both undisclosed in the description. Consequence: on a host with no working sandbox backend the owner can never complete consent, so the original file_send: no owner-consented way to deliver a file containing secret material #7770 harm (a legitimately needed file stays blocked) remains unsolved for that configuration. The fail-closed choice is defensible; the silent scope reduction should be stated.

Suggestions

• Surface the computer-use / unsandboxed eligibility in the panel (or arm-status response) before the owner arms, so they don't discover the dead-end only after running the host command inside the 10-minute window.

[DESIGN-REVIEWED] 71e68b2

[github-actions]

First Principles Review (Fable 5) — 🟡 CONCERNS

Premise-level review of 71e68b2272b147268c3e0c8a0cafccf13f7d2d90 — why this exists and whether the shipped surface is the smallest honest version. Updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

First-Principles-Verdict: CONCERNS

The step-up earns its place, but two approve-time refusals that can permanently disable the feature are undeclared, and the new floor rule's stated justification is contradicted by the diff's own sandbox mask.

What this change ships

Intent: let an owner get their own scanner-flagged file (e.g. a VPN key) delivered, with consent that an agent driving the owner's browser cannot grant. ADDITION. (Capped at 10 items; the capture script and committed PNGs follow the existing temp-screenshots/ convention.)

1. New "Flagged-file delivery" section in Settings > Security, Allow/Withdraw per destination — justified
2. Clicking Allow now only ARMS; the grant is recorded elsewhere — justified
3. New kirocrew file-delivery approve host command — justified
4. New self-protection-file-delivery agent-denied floor rule — framing contradicted by diff
5. Nonce dir hidden from the agent sandbox and pre-created before each spawn — justified
6. Approve refused while computer use is enabled — undeclared
7. Approve refused when the sandbox mask would not apply — undeclared
8. Armed-state badge, disabled "Waiting on this machine" CTA, Copy button, expiry and expired lines — justified
9. Destination/state relabelled to "This computer and your dashboard Files view" / "Allowed" — justified (no panel previously rendered the old label)
10. consume_grant plus the arm source field — zero consumers / never read back

Watch

• Item 4: the description says "The nonce lives under the trust/ leaf, which is sandbox-VISIBLE … so the leaf itself does NOT fence it from the agent. What makes the step-up agent-proof is a new … FLOOR rule". The diff does the opposite — sandbox.py adds file-delivery-consent-pending to _CREW_HIDDEN_LEAVES and the module says "deliberately NOT under trust/". With the mask applied the agent cannot read the nonce, and where the mask does not apply item 7 already 403s the approve, so the rule's premise no longer holds as written.
• Items 6 and 7 appear in no "What changed" bullet. credential_mask_applies returns False whenever detect_backend is "none" (fails closed by design), so on a host with no sandbox backend the delivery path this PR exists to open can never be completed, and the owner only learns that after arming and running the command.

Subtractions

• Delete file_delivery_consent.consume_grant — zero production consumers (grep consume_grant: 1 definition, 2 call sites, both in test/test_file_delivery_consent.py); its own docstring points callers at validate_grant + clear_pending_grant, which is what the handler uses. Have the single-use test call that pair.
• Drop the source parameter and the "source" key in arm_grant — one caller passing one value (handlers/file_delivery_consent.py:256), and read_pending_grant never parses the field back.

[FIRST-PRINCIPLES-REVIEWED] 71e68b2

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 71e68b2272b147268c3e0c8a0cafccf13f7d2d90 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 71e68b2

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 71e68b2272b147268c3e0c8a0cafccf13f7d2d90: <one-sentence reason>

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed 71e68b2272b147268c3e0c8a0cafccf13f7d2d90 — this comment is updated in place on each push.

Review details

Now I have what I need. The global QueryClient sets staleTime: Infinity (website/src/api/queryClient.ts:67), and the comment there confirms refetchOnWindowFocus "only fires on stale queries" — so it never fires for the consent query. There is also no WebSocket invalidation for ['file-delivery-consent'] anywhere in the SPA (grep found none outside this panel). That defeats candidate 1's own suggested mitigation and confirms the defect. Both candidates are real but purely display-level (grant is recorded correctly server-side; delivery gates re-read the store). Neither is a crash, data loss, or security hole.

Two advisory UI-state bugs in the file-delivery card; nothing blocks the merge.

FINDING — website/src/pages/settings/SecurityPanel.tsx:2712 — after a host kirocrew file-delivery approve lands, the armed poll flips armed:false but nothing refetches ['file-delivery-consent'] (staleTime: Infinity blocks focus-refetch, no WS invalidation), so view.grants stays cached null — the live grant renders as "Not confirmed" with an "Allow delivery" button and the false "expired" notice, telling the owner there is nothing to withdraw, contradicting the code's own comment that "the flip to confirmed … surface[s] without a manual refresh" → Fix: invalidate/refetch the ['file-delivery-consent'] query when the armed status transitions armed→not-armed (e.g. an effect keyed on anyArmed), or give it a refetchInterval while a request is armed.

FINDING — website/src/pages/settings/SecurityPanel.tsx:2905 — when the arm-status GET starts failing after a successful arm, armed.isError makes armedView undefined so anyArmed is false, and wasArmed && !anyArmed && every(no grant) renders file_delivery_armed_expired ("That request expired before it was approved") simultaneously with the file_delivery_arm_status_failed notice — a contradictory, unfounded "expired" claim when the request may still be armed and merely unreadable → Fix: gate the expired <p> on !armed.isError.

[OPUS-REVIEWED] 71e68b2

Verdict parsed from the review's SHA-scoped output markers for commit 71e68b2272b147268c3e0c8a0cafccf13f7d2d90.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 71e68b2272b147268c3e0c8a0cafccf13f7d2d90: <one-sentence reason>

[github-actions]

UX Review (Fable 5) — 🟡 CONCERNS

UX-level review of 71e68b2272b147268c3e0c8a0cafccf13f7d2d90 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

All evidence reviewed: the blind read reconciles cleanly against the diff (every state the reader saw was read correctly, including the arm step-up and the same-thing continuity across off → waiting → allowed), screenshots match the code, and the remaining issues are consistency drift and missing evidence rather than comprehension failures. Final review:

UX-Verdict: CONCERNS

Comprehension held across every captured state; what remains is "Withdraw" clashing with this panel's established "Revoke", plus unshown expiry/copy states.

Watch

• Synonym drift on one page: taking back a grant is "Revoke" in the sibling Third-party apps card (SecurityPanel revoke key) but "Withdraw" here (file_delivery_withdraw) — a user who learned the panel meets two words for one operation, every visit. Smallest fix: reuse "Revoke".
• The blind reader flagged the word overload: "'delivery/delivered' is used for two different-feeling things… Same word, very different levels of risk" — the title "Where flagged files may be delivered" implies Slack is a candidate "where" until the lock line corrects it. Low impact (the reader still read both correctly); consider a title that names the recipient, e.g. "Delivering flagged files to you".

Evidence gaps

• The expired-request state (file_delivery_armed_expired: "That request expired before it was approved…") appears in no committed screenshot; add an after-expired frame to capture-file-delivery-consent.mjs.
• Copy feedback states ("Copied" acknowledgment and file_delivery_copy_failed notice) appear in no screenshot.
• No committed or embedded recording shows the Allow delivery click becoming the armed row (button flips to "Waiting on this machine", command panel mounts); a short .webm of that flip would close it.

Suggestions

• Delete "It is never sent to Slack or a chat channel." from file_delivery_destination_help — the always-visible lock line (file_delivery_never_grantable) restates it on the same card.
• Render the "Allowed" badge in an attention tone rather than ok-green: on a security panel, green marks healthy, and an active loosening grant is the one state the owner should keep noticing.

[UX-REVIEWED] 71e68b2

[chenmingwei23]

Parked as a draft pending internal discussion. Not abandoned, and not waiting on CI -- the board
is green apart from one review lane.

What is settled on this head. The crash-safety ordering defect is fixed and verified: the
grant is validated, then recorded, then the pending nonce is cleared, so a write failure no longer
destroys the armed consent along with the token needed to retry it. Seven separate exposures are
closed, each checked by removing the guard and confirming a test fails. The description is
accurate and pinned to this head.

What is not settled, and why it needs a decision rather than another patch. The posture fences
this change adds check the current configuration at completion time. An actor who can pre-stage
a delayed host-side completion while the posture is permissive, then restore the posture before it
fires, passes those checks. Closing that requires a presence proof generated at completion time
that cannot have been captured earlier -- a new mechanism, not a tighter condition, which is why it
is filed separately as #9160 rather than added here.

The distinction worth preserving: this is a narrowed window described as narrowed, not a closed
door and not neutral work. The concurrent routes are shut; the one that crosses two instants
remains, and it is named.

#9160 is the place for the mechanism discussion, since the same arm-in-the-dashboard,
complete-on-the-host shape appears elsewhere in the codebase and the question is whether that shape
is an accepted trade-off or an unfixed class.

[bolichen97]

Tried to rebase this onto main 9c2b4b678 for the 2026-09-08 open-PR audit, then aborted: one conflict needs your call. The branch is untouched.

src/kiro_crew/security.py is gone (#9183/#9089 split it into src/kiro_crew/security/). Five of your six additions port mechanically. The sixth does not: main deleted the catalog rows for self-protection-restart|update|gateway-restart|cloud into _SELF_PROTECTION_UNGATED_FLOOR_IDS (no row, no opt-out), pinned disjoint from _SELF_PROTECTION_FLOOR_RULE_IDS. Your self-protection-file-delivery copies the old update shape main removed as over-broad.

Pick a tier: ungated floor (drop the row, golden entry and opt-out), or keep the row. The denied_commands_golden.json and test_denied_commands_security.py conflicts follow from that. client.ts conflicts only mechanically with main's new voiceSynthesize.

A maintainer push would also make the maintainer last pusher, so a second approver would be needed. Reply if this reads wrong.