FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
（非適用）承認境界をpermission profileへ移す案を取り下げる
実セッションを監査して最小権限案を検証し、意図との不一致から採用しなかった
目的
割り当て済みのroleがworkspace内の可逆な編集や一時ファイル操作のたびに承認待ちにならず、secret、境界外の書き込み、破壊的操作など安全上重要な行為だけを承認対象へ残す方法を検討した。command ruleだけではfile edit、connector、GUIなど別の承認層へ作用しないため、実セッションの記録から原因を分ける必要があった。
そのため、既存の単一なworkspace-write設定をread / edit role別のpermission profileへ置き換え、command gate、監査script、運用文書を同期する案を作った。ただし最終的にCEOが依頼意図と異なる作業だと判断し、案全体を取り下げた。
実装
2026年7月12日から15日13:51までのread-onlyなsession記録を監査し、155件のapproval response、2件のhard stop、2,365件の通常waitを分離した。approval responseは実際のoperationと時刻窓内で一意に対応できる場合だけ相関し、候補がないか複数ある9件は推測せずunmatchedのまま残す設計にした。
- edit roleはworkspaceと一時領域へ書き込めるが、secretらしいfile pattern、境界外、local serverの待受を許可しない案とした。
- read roleはworkspaceをread-onlyとし、
/tmpと実行時の一時領域だけへ書き込める案とした。 - networkは必要なdomainへ限定し、managed policy、connector、GUIの外部承認はproject設定では解除できない境界として残した。
command ruleでは、安全なwrapperだけをallowし、直接のrmはforbidden、破壊的なGit操作はpromptとする案を作った。通常の呼び方だけでなく、作業directory指定、global option、command gitを使う呼び方でも同じgateへ到達するnegative matrixを用意し、reset、restore、clean、rebase、強制送信、discardを伴う切替など22形を検査した。
監査scriptには、authorization header、credential flag、URL、environment assignmentを構造的にredactする処理を加え、未知のsecretらしい長い値を見つけた場合は出力を止めるfail-closed判定を設計した。fake credential、既知のsecret marker、曖昧な時刻相関をfixtureにし、監査結果を二度生成して同じ結果になることも確認対象にした。
- 初回検査で、workspace writeを広げた後の破壊的Gitと呼び方の迂回がgateに一致しない問題を検出した。
- 監査結果へcredentialを出し得るsanitizer、直近operationへの誤相関、完了条件と証拠の対応不足も検出した。
- 候補案ではこれらを修正し、8件の監査回帰テスト、22形のnegative matrix、snapshotの再現性とsecret scanを通した。
permission profileは次に開始するsessionから読み込まれる想定であり、現在動いているsessionのmanaged permissionを遡って変えるものではなかった。また、workspace全体へ書けるedit roleは、command ruleと運用gateを組み合わせても危険がゼロにはならない。この作用と残存riskを説明した後、CEOは変更の方向自体が依頼意図と一致しないと判断した。
[permissions.project_edit.filesystem]
":minimal" = "read"
":tmpdir" = "write"
glob_scan_max_depth = 8
[permissions.project_edit.filesystem.":workspace_roots"]
"." = "write"
"<secret configuration>" = "deny"図を描画しています…
確認したこと
確認結果
候補案はread / edit roleのfile access、限定network、command gate、監査時のsecret非露出を三つの層として分けていた。
TOMLとstrict config load、9 roleのinventory、command rule、8件の監査回帰テスト、snapshot再現、secret scan、横断参照、差分形式の検査は成功していた。
一方、edit roleはworkspace全体へ書けるため、未知の実行形式、managed policy、connector、GUIを含むすべての危険をproject ruleだけで排除できるものではなかった。
最終候補は実sessionへ適用されず、承認待ちの減少、read / edit profileの実runtime behavior、remote clientや外部承認層への影響は確認していない。
CEOが依頼意図と異なると明示し、候補成果と関連作業を取り下げた。cutoff時点で採用先には元の状態だけが残っていることを確認した。
完了とした根拠
CEOによる不採用判断の後、候補の設定・rule・監査script・文書が採用先へ反映されておらず、元の状態だけが維持されていることを確認したため、not-appliedとしてこの検討を完了とした。