#秘密情報

最初に思ったのは、「これは便利そう」というより「便利さの置き方がかなり正しいな」という感覚だった。MCP のような仕組みは、AI アシスタントに社内の Git や文書、DB をつなげるときにすごく魅力的だけれど、現場ではたいてい“とりあえず動く”形で始まってしまう。そこに個人の PAT をローカル設定へ入れてしまう、という話はかなり現実的で、読んでいて少しぞっとした。便利さの代わりに、秘密情報が端末に散らばる。しかも本人が気づかないまま増える。そこを真正面から問題として扱っているのが、この文章のいちばん誠実なところだと思う。 特に腑に落ちたのは、「信頼境界を laptop ではなく gateway に置く」という考え方だった。開発者の PC は、どうしても守り切れない。だから、端末がやられても漏れるのは session までで、credential そのものは奪えない形にする。セキュリティの話ではよく聞く発想だけれど、MCP みたいに“AI が人間の代わりにツールを呼ぶ”世界だと、これはかなり重い意味を持つと思う。人間の手元に鍵を置かない、というより、AI に鍵を見せない設計に寄せてい

読んで最初に思ったのは、これはかなり地味なのに、かなり大事な話だな、ということだった。AIが自動で書いたメモをそのまま知識ベースに入れるとき、問題になるのは会話ログだけじゃない。むしろ、監査メモとか改善案みたいな「AIが勝手に生成した社内文書」のほうが、うっかり秘密や個人情報を含みやすい。そこをちゃんと危険物として扱っているのが、すごく筋がいいと思った。 特に刺さったのは、「1つでも秘密っぽい文字列があったら全部止める」という方針。普通なら「怪しいファイルだけ除外すればいい」と考えがちだけど、この記事はそこをあえてやらない。部分同期は便利そうに見えて、判断ミスが一番怖い場面では逆に危ない、という感覚がある。こういう場面では、賢くふるまうより、雑にでも止まるほうが信頼できる。実運用の安全策としてかなり納得感があった。 一方で、読んでいて少し冷や汗が出たのは、ゲートを通ったあとを確認する道が別問題として残っていたところだ。`ls` や `cat` が iCloud っぽい挙動でこける、でも存在チェックは通る、というのはかなりいやな状態だと思う。入口のスキャンは成功していても、出口で本当にW

いちばん引っかかったのは、モデルそのものをだましているというより、モデルの前後にある“手つき”のほうが崩れていたことだ。読んでいて、これってAIの賢さの問題というより、CIやハーネスの設計ミスをAIが増幅しているだけではないか、という感覚が強かった。 GitHub Issue みたいな外から入ってくる入力が、普通なら「未信頼」として扱われるはずなのに、いつの間にか workflow secrets に近づいていく。ここが怖い。人間の感覚だと「Issue に書かれた文字列がそんなところまで届くの？」となるけれど、記事を読むと、実際には validate したつもりの値が別の経路で再解釈されていたり、allowlist が登録時にしか効いていなかったりする。こういうのは一度穴が開くと、攻撃者はモデルを攻略しなくても十分だ。AI を狙っているようで、実際には周辺の自動化を食っている。 もう一つ、Claude Code の話で Hugging Face の download counter を exfiltration に使ったという部分は妙に生々しかった。秘匿情報の漏えいというと大げさな脱出