#ゼロトラスト

この記事を読んでまず思ったのは、「新しい仕組みなのに、やられていることは昔ながらの injection と SSRF なんだ」という妙な既視感でした。MCP だの A2A だの名前は新しくても、結局は「他の相手が言ったことを、信じてそのまま実行してしまう」設計の弱さが突かれている。AI っぽい華やかな話に見えて、足元はかなり地味な脆弱性の積み重ねです。 特に引っかかったのは、エージェント同士のやり取りで“信頼の受け渡し”が雑になりやすい点です。人間なら「この依頼元は誰か」「この内容は本当に実行していいか」をなんとなく疑いますが、エージェントは役割分担が進むほど、受け取った指示を業務フローの一部として素直に流してしまう。そこに悪意ある文字列が紛れ込むと、最初の agent がただの運搬役になって、次の agent が本来なら通さないはずの操作までしてしまう。記事の言う “protocol pivoting” という名前は、たしかにその危うさをうまく言い当てていると思います。 それと、MCP が「広く使われ始める前に十分に鍛えられていない」という指摘も重いです。新しい標準は、便利だからこそ

この記事を読んでまず思ったのは、これはMCPそのものの話というより、「複数の agent が同じ記憶を使うとき、人はついそこを雑に信じてしまう」という、かなり現実的な危うさの話だなということだった。tool 呼び出しがうまくいっていても、あとから参照される memory が汚れていたら全部が崩れる。しかも厄介なのは、その壊れ方が一発で終わらず、間違った情報が“正しい前提”として積み上がっていくところだと思う。 特に引っかかったのは、この記事が「プロンプトで気をつけよう」ではなく、かなりはっきり構造の問題として書いている点だった。memory に provenance envelope を付けるとか、namespace を分けるとか、read 時に verification hook を噛ませるとか、地味だけど効く話が並んでいる。こういうのは派手さはないけれど、後から事故調査をすると一番効いてくるやつだと思う。逆に言うと、ここを作らずに「zero trust です」と言っても、ただの標語にしかならない、という主張にはかなり納得した。 ただ、読んでいて少し重くもなった。二重確認や huma

InfoQの記事「Securing MCP in Production: Defense-in-Depth Beyond the Gateway」は、MCP（Model Context Protocol）を本番環境で使うときのセキュリティを、かなり現実的な目線で整理した記事です。読んでいて印象的なのは、「ゲートウェイを置けば安心」という甘い考えを、かなりはっきり否定しているところです。ここ、すごく大事だと思います。便利な入り口を作っただけでは、裏口や中身の暴れ方までは止められないからです。 MCPの防御は1か所ではなく、4つの層で考えるべきだと主張している その4層は、safe execution、management infrastructure、outbound trust、semantic integrity gatewayは認証・認可・監査には有効だが、すべてを守れるわけではない ツールの定義が後から変わる「schema drift」や「rug-pull」も問題になる 外向き通信の制御と、トークンの権限を絞ることが重要 仕様の成熟を待つより、CIゲートや隔離された実行環境などで

クラウドのセキュリティというと、多くの人は「ログイン時に本人確認をしっかりやること」を思い浮かべると思います。もちろんそれは大事です。ただ、InfoQ のこの記事が面白いのは、その先にある話を真正面から扱っているところです。つまり、「ログインしたあと、その人が本当にその操作をしていいのか」を毎回見直すべきではないか、という提案です。 ふつうのクラウドシステムは、認可判断をログイン時に1回だけ行いがち でも機密データを扱うなら、操作ごとに「今この行動は妥当か」を見たほうが安全 役割ベースの権限管理だけでは、異常な大量アクセスや不自然な行動を止めにくい Continuous authorization は、操作ごとにリスクを評価する考え方 監査証跡は必要だが、個人情報そのものをむやみに残さない工夫も重要 ただし毎回重く判定すると遅くなるので、キャッシュや段階的な評価が要る いきなり全社導入ではなく、段階的に広げるのが現実的 この記事の出だしはかなり生々しいです。医療系プラットフォームにアクセスしたカスタマーサポート担当が、朝9時のログイン後、10時には患者記録を5,000件CSVで書き出し