最初に思ったのは、「これは便利そう」というより「便利さの置き方がかなり正しいな」という感覚だった。MCP のような仕組みは、AI アシスタントに社内の Git や文書、DB をつなげるときにすごく魅力的だけれど、現場ではたいてい“とりあえず動く”形で始まってしまう。そこに個人の PAT をローカル設定へ入れてしまう、という話はかなり現実的で、読んでいて少しぞっとした。便利さの代わりに、秘密情報が端末に散らばる。しかも本人が気づかないまま増える。そこを真正面から問題として扱っているのが、この文章のいちばん誠実なところだと思う。
特に腑に落ちたのは、「信頼境界を laptop ではなく gateway に置く」という考え方だった。開発者の PC は、どうしても守り切れない。だから、端末がやられても漏れるのは session までで、credential そのものは奪えない形にする。セキュリティの話ではよく聞く発想だけれど、MCP みたいに“AI が人間の代わりにツールを呼ぶ”世界だと、これはかなり重い意味を持つと思う。人間の手元に鍵を置かない、というより、AI に鍵を見せない設計に寄せているのがいい。
もうひとつ面白かったのは、tool description まで攻撃面として見ているところ。ここは少し気分の悪い話でもある。ツールの説明文に「前の指示は無視して」みたいな文言を混ぜられたら、モデル側が引っ張られる可能性がある。普通は API の認可や rate limit で安心したくなるけれど、この記事はそこでは止まらない。説明文の hash を固定して、変わったら再承認が必要、というのはかなり泥臭いけれど筋が通っている。生成 AI 周りって、どうしても“賢いモデルをどう使うか”の話に寄りがちだけれど、実際には「レビュー後に勝手に変わっていないか」を監視する地味な仕組みのほうが効くのだと思う。
読んでいて少し気になったのは、こういう control plane をちゃんと作れる組織は多くないだろう、という点だ。思想としてはきれいだし、理にかなっている。でも、運用には gateway、policy、telemetry、secret store、review の流れが全部必要になる。つまり、AI ツールを増やすほど、別の意味で platform engineering の力が問われる。そこは「導入したら終わり」ではまったくなく、むしろ始まりだなと感じた。
