path: root/doc/AuditReport.md

# v1再監査報告とSandbox Usability Revision状況

> 2026-08-13オンデマンド昇格改定: 以下の管理者環境証跡は常時管理者方式の過去commitに対する履歴である。`asInvoker` main、Task単位helper、Named Pipe、dynamic WFP、persistent loopback Recoveryは最新commitで再検証するまでPASS根拠としない。

2026-08-13 working treeでmainを`asInvoker`、昇格hostを`requireAdministrator/uiAccess=false`とし、WFP/loopback mutationを固定`admin/` hostへ分離した。通常tokenのHTTP/stdio MCPから実Taskを実行し、初回`process_run`時のUAC、logon SID DACL Named Pipe、LPAC Process Tree、dynamic WFP、ACL/WFP cleanupを確認した。Windows suiteは昇格子Processだけで79件PASS、Core 105件、Planner 10件、administrative boundary 4件がfail/skip 0。

残っていた異常系も同日のactual-Process受入で再検証した。Task時UACを実際に拒否するとHTTP MCP Taskだけが`failed/sandbox.elevation_cancelled`となり、同一Server PIDで後続`tools/list`が成功した。固定Pipeではlocal peer PID取得、remote-form接続拒否、別Task ID、別protocol version、二重apply、過大message拒否を実helperで確認した。network適用後のhelper強制終了ではApplied Journalを保持し、startup RecoveryのUAC拒否でbind前exit 2、次回承認で`recovery.end=clean`となった。Windows標準`CheckNetIsolation`と昇格`netsh wfp show state`でloopback exemption、WFP filter/sublayer、Journal、helper Processの残留0を確認した。

> 2026-08-13 schema version 2追補: YAMLを唯一のSandbox desired stateとし、個別のExecutable Approval／Sandbox Resolution操作を廃止した。CLIはcommand省略のServer起動、`apply`、`show`に限定し、確認結果はconfig別Applied Configuration Storeへ一括保存する。本追補より前の管理者・publish証跡は旧schemaの履歴であり、schema version 2のPASS根拠ではない。最終検証はRelease build warning/error 0、Core 104件、Planner 10件、Windows Security/Recovery 56件、README operational 19件がfail/skip 0。publish HTTP MCPも`deepseek-v4-flash:cloud`でcompleted 3/3となり、cmd→cmd/curl/venv Python、Network none、終了後残留0を確認した。

## 基準

commit `37386b8`に対する2026-08-11の再監査結果は履歴として以下に保持する。2026-08-12に開始したSandbox Usability RevisionはUser Sandbox Configuration、Resolution、Executable Approval、Effective Sandbox Policy、LPAC Process Treeへ安全境界を改定する破壊的変更であり、旧commitのPASSを現行実装へ流用しない。

## Sandbox Usability Revision

- 仕様書から先に用語、安全不変条件、semantic schema、CLI、Store、LPAC/ACL/Job/WFP強制条件を改定した。
- 設計書へUser Configuration → Environment Resolution → Approval Resolution → Effective Policy → Broker → LPAC/ACL/Job/WFPを定義した。
- 旧`filesystem`／`process.approvals` schemaは移行診断付きで拒否する。
- Entry ProcessだけをApproval対象とし、Descendant Processは個別Approvalなしで同じLPAC identity、ACL、WFP、Job confinementを継承する。
- 2026-08-12の最終working-tree検証でRelease buildはwarning 0/error 0、Core 103件、Planner 10件、Windows Security/Recovery 53件がすべてPASS、skip 0。`deepseek-v4-flash:cloud` + `think:true` + Python 3.14.3によるstdio、HTTP IPv4、HTTP IPv6 Operational E2EもすべてPASSし、各経路で複雑なPython実装、子Python、独立unittestを完走した。Task終了後のJournal、backup、published process残留は0。証跡は`artifacts/evidence/sandbox-usability-final-working-tree-2/`に保存した。

## 2026-08-13 LPAC Descendant互換性再監査

`cmd.exe`から`curl.exe`を起動できない事象をEntry×Descendantで再調査した。最初のmatrixは`%ComSpec%`や`%SystemRoot%\System32\curl.exe`などドライブ修飾絶対pathを使用しており、その失敗をcmdのDescendant生成拒否と誤認していた。追加調査では、LPAC上のcmdから`cmd.exe /d /c exit 0`と`curl.exe --version`が成功した。絶対pathの場合はcmdが子Process生成前に`GetVolumeInformationW("C:\")`を呼び、そのアクセスが拒否されていた。したがって、cmdおよびLPAC/no-breakaway Process Tree一般の非互換性ではない。

MicrosoftのAppContainer資料は、unpackaged Win32 processをAppContainerで起動する方法と子のtoken継承を説明するが、任意のWin32 Executable組合せの動作互換性までは保証していない。LPACは`ALL APPLICATION PACKAGES`由来accessをopt-outするため、必要capabilityを明示選定する必要がある（[Launch an AppContainer](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer)、[AppContainer for legacy applications](https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-for-legacy-applications-)）。またJob Objectではbreakawayを許可しない構成がProcess Tree監視を維持する方式であり、breakawayを許可すると子がJob外になる（[Job Objects](https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects)、[Process Creation Flags](https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags)）。

`lpacAppExperience`はMicrosoft Learn/Windows SDKで権限範囲を確認できないため採用しない。限定実験の変更も撤回した。Job breakaway、通常AppContainer fallback、System32 protected DACL解除はいずれもSecurity Boundaryを弱めるため採用していない。

是正として、誤ったcmd専用エラー分類と失敗を期待するtestを撤回し、protected DACLとの両立規則、capability採用基準、Entry×Descendant×System32 utilityの組合せmatrixをDesignへ追加した。cmdのtestはPATH解決名またはWorkspace相対pathで実際のDescendant起動とNetwork通信を検証する。また、HTTP MCP実動作でSystem32 rootを除外しても配下のApproved `cmd.exe` fileへ個別ACLを適用していた実装漏れを検出したため、OS Runtime Root配下全体をDACL変更対象外とした。Network capabilityなし／ありの両条件ではRegistry read、Registry write拒否、COM拒否、Broker secret非継承も組合せ検証した。

是正後はREADME/CLI/Windows operational suite 19件とAgent.Windows全75件が管理者・skip 0でPASSした。最新publish BundleのHTTP MCP `agent_run`もcompleted 3/3となり、cmdから非修飾`cmd.exe`、非修飾`curl.exe`、Workspace相対`C:\tmp\.venv` Pythonを起動し、Network `none`の遮断と`CMD_HTTP_MCP_OK`を確認した。全9組の子Process自身によるLPAC SID/Job個別記録は未実施のため、対応するTraceability項目だけはPARTIALとして残す。

## 確認した矛盾と是正

| 観点 | 監査時の状態 | 是正 |
|---|---|---|
| Internal Tool | 仕様・設計・計画で5群/6群が混在 | 仕様から数とcatalogを除去。外部性質だけを残し、名前/schemaをDesignのTool catalogへ移管 |
| policy deny | 初回failedと最大3回replanが混在 | 同一呼出しへ再投入しない条件付きreplanへ統一。同一deny、計画未変更、実行不能、replan失敗でfailed |
| Skill形式 | READMEにlegacy互換記述 | `<skill-name>/SKILL.md`だけに統一 |
| Task完了 | 実行Taskなしでもcompletedになり得た | TaskGraph全件completedだけを完了条件とし、実行不能は理由付きfailedへ変更 |
| Planner fallback | 空/不正planから曖昧なfallback graphを生成 | 設定された`think`を維持して訂正instruction付きで1回だけ再試行し、再失敗はplanning failureへ変更。planning中のTool callを禁止する明示promptを追加 |
| Tool証跡 | 読取Taskや別Taskの副作用で完了できた | Taskごとの`required_tools`を設計し、必要Tool成功まで完了不可、範囲外副作用はdispatchもsession投入もしない |
| task_update | LLMが状態遷移可能 | Tool catalogには維持し、Task追加/dependency追加/estimate変更だけに限定 |
| cancel | CancellationToken通知時点でterminal | Task Resource cleanup完了後だけcancelled。cleanup失敗はfailed |
| progress/token | progress固定値、phase別token欠落 | TaskGraph同期、critical path実値、全Ollama phase集計へ変更 |
| context | 閾値超過時に単純削除 | structured要約成功後だけcompactし、失敗時は原文保持 |
| Configuration | validationのみでruntime未接続、local overrideなし | max_tasks/num_ctx/ratio/timeoutを接続し、`agent.local.yaml` mergeを追加 |
| CLI/運用 | `serve`必須、publish後の環境値復旧が必要 | 引数なし/先頭optionをserve化。local prompt/Skill/configをBundle対象外に分離 |
| Logging/Audit | 相関field・iteration・event名が不一致 | LLM相関/rotationとAudit必須eventへ統一。read-only JSONL viewerを追加 |
| Credential環境 | Brokerのenvironment blockをSandbox Processへ継承 | Windows/runtimeに必要な明示的Unicode environmentだけを渡し、任意token/password/SSH/API credentialを除外。実Processでsecret非継承を検証 |
| Descendant実行 | 旧child process全面禁止がprompt/Skill/testに残存 | EntryだけをApproval対象とし、同一LPAC SID/Job内のPowerShell、Python、.NET build/test Process Treeを許容する設計へ統一 |

## 旧commit `37386b8`の判定（履歴）

Release buildはwarning 0/error 0。管理者suiteでCore 82件、Planner 10件、Windows Security/Recovery 42件がすべてPASSし、skipは0だった。self-contained Bundleのruntime check、stdio、HTTP IPv4/IPv6 Operational E2Eも`deepseek-v4-flash:cloud`でPASSした。各E2Eでは実file read/edit、in-process build、独立self-test、Task進捗、ACL/WFP/temp cleanupを確認した。

MCP conformance runnerはapplication failure 0だった。runner専用fixtureを本番MCP Toolとして公開しないため実施不能なcheckと、Windows runner終了時のlibuv assertionはrunner limitationとして分離し、PASSには数えていない。Requirementの受入根拠は製品のCore/MCP integration、Windows suite、Operational E2Eで満たしている。詳細と現行証跡は`plans/RequirementTraceability.md`を正本とする。

この節の結果はSandbox Usability Revision後の現行実装のPASS根拠ではない。