本番変更を任せ、特権キーは渡さない

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づく一次性許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。このシナリオは情シス・本番変更の場面です。エージェントは本番を読み、考えることはできても、変えるには変更承認を通るしかありません。

本番の鍵を渡さずに、エージェントに本番の仕事を任せるには？

GembaOS はエージェントに本番の認証情報を一切持たせません。エージェントは制限されたサンドボックスで調査し、変更セットを起案します。特権操作はすべて能力ゲートウェイを通り、ポリシーが変更承認の要否を判定し、アダプターは承認済みの変更を、その引数に紐づく一次性許可証のもとで一回だけ実行します。

	導入前	GembaOS の統制
アクセス	SSH や管理 API キーを持つエージェント、あるいはエージェントを使えない	エージェントに鍵はなく、認証情報はゲートウェイが保持
調査	深夜 3 時に人がログを追う	エージェントがサンドボックスでログを読み、事実と推定を分けて報告
変更	当番が適用し、記録は後回し、あるいは無し	変更セットとして起案、変更責任者が承認、一回だけ実行、前後を記録
ログ行に仕込まれた指示文	従ってしまうのを止める仕組みがない	その行はデータ。型付きの懸念として記録され、処理は人へ回る

手順はどう進みますか？

段階	誰が	何が記録されるか
1. 起動	監視のアラートやチケットが作業票を開く	信号とその出所
2. 調査	エージェントが読み取りのみで。サンドボックスは名前を信じず、GembaOS が実際に調べる	すべての読取、伏せ字化した秘密
3. 報告	審査済みの報告が責任者へ。足りなかったものは不足台帳へ	報告、不足、人の審定を待つナレッジ草案
4. 起案	正確な変更内容と前提条件を持つ変更セット	稟議書
5. 承認	変更責任者がパスキーで押印。誰がそれかは職務権限規程が定める	押印チェーン
6. 実行	本番アダプターが許可証のもとで一回だけ。前提条件を先に読み直す	実行とその結果

管理ゲートはどこにありますか？

管理ゲートは変更セットへの押印です。押印が無いうちは何も本番に触れず、押印の後はその変更を、その引数で、一回だけ実行できます。責任者が見たときから状況が変わっていれば（前提条件が稟議書の事実と一致しなければ）、GembaOS は実行せずに差し戻します。変更の要らない無人の処理は第 3 段階で終わり、状態は何も変わらず、監査記録にそう残ります。

コンソールではどう見えますか？

始めるのに必要なものは？

信号（Webhook）を送れる監視基盤と、報告を受け取るチケットまたはチャットのチャネル。
エージェントが読んでよいサンドボックス: ログ、読み取り専用のシェルや API。
今ある変更承認のルール: どの区分の変更に誰が押印するか。
最初の変更区分のための本番アダプター一つ。認証情報はゲートウェイ側に置く。

関連: 返金・損害査定、セキュリティと導入形態、用語集。