TL;DR（要点先出し）

なぜ多層で守るのか

私の環境では、AIエージェントに実際のファイル操作やコマンド実行を任せています。便利な反面、一つの防御をすり抜けられたら終わりでは怖すぎます。人間の会社でも、鍵・受付・監視カメラ・金庫、と何重にも守るのと同じ発想です。

私が組んでいる守りは、ざっくり4層です（考え方だけ書きます。具体的な検知ルールや設定の中身は、攻撃の手がかりになり得るので伏せます）。

層	やっていること
① 実行前の門番	AIが何か操作する前に、その内容を検査し、危険なものは止めて、すべてを記録する
② 秘密は読ませない	パスワードや鍵が入ったファイルは、そもそも読み込み自体を禁止する
③ 秘密を記録に残さない	秘密の情報や個人的なデータを、変更履歴（Git）に含めない
④ 子プロセスに秘密を渡さない	AIが呼び出す別のプログラムに、環境変数の秘密を引き継がせない

——と、ここまでは「よくある多層防御」です。問題は、このうちの①が、実は長い間、機能していなかったことでした。

一番大事な①の門番は、AIの全操作を実行前に検査する仕組みです。ここが動いていれば、危険な操作は止まる。私は「これがあるから安心」と思っていました。

ところがある日、記録を見て青ざめました。その門番が、しばらくの間まったく働いておらず、その間の相当な数の操作が、検査されないまま素通りしていたのです。

原因は単純でした。門番が動くのに必要な部品（あるプログラム）が、環境を作り直したときに入っておらず、部品が見つからないエラーで「門番が開いたまま」になっていたのです。しかも、エラーは静かにログに記録されるだけで、表向きは何事もなく動いているように見えていた。これが一番怖い点でした。

これは、セキュリティの世界で「開いたまま故障する（fail-open）」と呼ばれる状態です。異常が起きたときに、安全側（閉じる）ではなく危険側（開く）に倒れてしまう。**「壊れたことに気づけない壊れ方」**が、最悪の壊れ方でした。

[fail-openとfail-closeの違い（壊れていた頃と直した後の対比図）]

作り替えのポイントは2つです。

迷ったら閉じる（fail-close）に倒す：必要な部品が万一入っていなくても、最小限の門番が代わりに働き、判断に迷う操作はむしろ止めるようにしました。「部品が無い＝丸ごと素通り」という構造そのものを無くしました。
後から必ず気づける：全操作を監査ログに残し、門番が異常なら分かるようにしました。「動いているつもり」を、証拠で確認できる状態にしたのです。

もう一つ、正直に書きます。社内向けの操作画面（WebUI）で使う秘密の鍵を、気づかないうちに変更履歴（Git）の管理対象に入れていました。幸い外部に公開する前に気づきましたが、これも「守っているつもりで穴が空いていた」典型でした。

対応はシンプルです。

秘密は「暗号化する」より前に、まず「そもそも記録に残さない・外に出さない」が効きます。

2つの事件に共通するのは、**「設定した時点では正しく動いていた」**ことです。だから安心してしまった。でも、システムは時間とともに壊れます。環境を作り直したり、うっかりファイルを足したりするだけで、守りには穴が空きます。

そこで、私はセキュリティの見方をこう変えました。

派手な防御を足すより、「静かに壊れて、気づけない」状態を無くす方が、ずっと効きました。

自宅の非力なPCでも、ここまでは守れます。同じように「AIに仕事を任せたいが、安全が不安」という方の、考え方の参考になれば幸いです。質問・ツッコミ歓迎です。

注：この記事では、具体的な検知ルール・設定ファイルの中身・現在の環境の詳細は、攻撃の手がかりになり得るため意図的に伏せています。考え方と教訓の骨子だけを共有しています。