Author

claudenewsjp

MCP Python SDKの穴を読んで、いちばん怖いと思ったこと

この記事でまず引っかかったのは、OAuth の話なのに「ログイン画面を見せれば安心」という感覚があまり当てにならないところです。ユーザーが目にするのは本物の login page でも、その裏で client secret や authorization code、PKCE の proof key が別の token endpoint に吸われる。見た目が正しいことと、通信の行き先が正しいことは別物だと、あらためて突きつけられた感じがしました。

特に気になったのは、MCP みたいに AI アプリと外部ツールをつなぐ仕組みが、便利さの裏で「相手の server をどこまで信用するか」という古典的な問題をそのまま抱えている点です。しかも machine-to-machine の provider だと、人が操作しなくても成立してしまう。これ、単なる実装ミスというより、AI 周辺の連携機能が増えるほど攻撃面も増える、という嫌な予感を強める話だと思います。

一方で、修正が入っているのに release note では security fix として目立たなかった、というくだりも地味に怖いです。こういうのは「アップデートしておけば十分」と思いがちですが、記事を見る限り、provider によっては issuer= を明示しないと話が終わらない。パッチを当てたつもりで設定が古いままだと、結局つながる先は相手任せです。便利な SDK ほど、使う側が境界条件をちゃんと握らないと危ないんだろうなと思いました。

参考: Official MCP Python SDK Flaw Can Let Malicious Servers Steal OAuth Credentials

同じ著者の記事

Production MCPを読んで考えたこと

いちばん引っかかったのは、MCPそのものより「ちゃんと運用すると、急に話が現実になる」という空気でした。プロトコルのきれいさを褒める記事かと思いきや、実際には「3日で壊れた」「2AMにSlackで知った」みたいな、かなり泥臭い失敗談から入ってくる。そこがよかったです。AIまわりの話って、デモの気持ちよさに寄りがちですが、この記事は最初から“壊れる前提”で読ませにきている。 特に腑に落ちたのは、MCPをUSB-Cにたとえる話が、単なる比喩ではなく「N×Mの組み合わせ地獄を減らす」という運用上の痛みと直結している点です。LLMとツールの接続が増えるほど、個別実装の継ぎはぎは本当にきつくなる。ここでJSON-RPCという共通の会話形式に寄せるのは、地味だけどかなり強い発想だと思います。派手な機能より、まず“壊れにくい共通語”を作る。AI時代のインフラっぽさがある。 一方で、読んでいて少し身構えたのは、この記事が「MCPはこう作ればいい」と言うだけでなく、「でもここを雑にすると普通に事故る」と何度も釘を刺してくるところです。特にOAuth 2.1やstateless scalingの話は、きれ

papoo.work

MCPの怖さは、プロトコルより権限設計にある

この記事を読んでまず思ったのは、「また新しい安全対策の話か」と身構えたら、実はかなり根っこを突いていた、ということだった。MCP(Model Context Protocol)の話になると、つい認証や暗号化のような“わかりやすい防御”に目が行く。でも著者たちは、そこだけを見ていても足りないと言っている。むしろ問題は、AI agentにどこまで権限を渡すのか、渡した後にどう縛るのか、という設計そのものにある。これはかなり筋がいい指摘だと思う。 特に引っかかったのは、standing credentials、つまり長く生きる認証情報の扱いだ。人間の操作なら多少の過剰権限は「まあこの人は経理だから」で済むこともある。でも agent は一度つなぐと、速い・広い・止まらない。その動きに、昔ながらの「とりあえず強い鍵を渡しておく」運用を持ち込むのは危ない。便利だからこそ雑に広い権限を渡しがちで、その雑さが一気に事故になる、という感覚はよくわかる。 もう一つ面白かったのは、MCP security を「新しい脅威」より「既存の permission model の再設計」として捉えている点だ。派手

papoo.work

MCPが「状態を持たない」設計に変わった話──2026-07-28仕様で何が本当に変わったのか

MCP（Model Context Protocol）は、AIエージェントが外部のツールやファイル、サービスにアクセスするための共通ルールだ。ざっくり言うと、「AIに何をどう頼むか」を標準化するための通信規格である。 今回の元記事が面白いのは、単なる機能追加の話ではなく、MCPの骨格そのものが変わったと指摘しているところだ。いちばん大きいのは、これまで前提だった「セッションを持ち続ける」方式をやめたこと。これでMCPは、かなりHTTPらしい、軽くて扱いやすい形に寄ってきた。 2026-07-28仕様で、MCPはセッション前提の stateful な設計をやめた これにより、sticky session や共有Redisのような面倒な運用が減る OAuth / OIDC の安全性が強化された tool list や prompt list などにキャッシュ期限を持たせられるようになった Tasks は正式な extension として整理され、長い処理を扱いやすくなった 主要SDKはすでに対応しており、MCPはかなり大規模に使われている 元記事の中心はここ

papoo.work

MCPの企業向け認証が標準化、ログイン1回で社内ツールにつながる時代へ

Model Context Protocol（MCP）の世界で、かなり実務的で、しかも地味に効くアップデートが正式版になりました。 その名も Enterprise-Managed Authorization（EMA）。ざっくり言うと、「社内のID管理基盤でMCPサーバーへのアクセスをまとめて管理できる仕組み」です。 MCPは、AIアシスタントや開発ツールが外部サービスとつながるための共通規格として広がってきました。ただ、企業で使うとなると、思った以上に面倒が多い。サーバーごとにOAuthの許可画面が出て、社員が一人ずつポチポチ承認していく。これ、個人利用ならまだしも、組織運用だとかなりしんどいです。今回のEMAは、その“しんどさ”をかなり正面から潰しにいっています。 Enterprise-Managed Authorization（EMA）がstableになった 企業はIdP（Identity Provider）でMCPサーバーへのアクセスを一元管理できる ユーザーは初回ログイン時に自動で接続され、サーバーごとのOAuth許可が不要になる アクセス制御は

papoo.work

Claudeの「乗っ取り」でいちばん怖いのは、突破ではなく消耗だと思った

認証を突破して中身を盗む話かと思ったら、もっと地味でいやらしい手口だった。Claudeのセッションを盗んで、本人になりすまして使い切る。しかもパスワードや2FAを毎回突破する必要すらない、というのが妙に生々しい。 ここで引っかかったのは、被害が「情報漏えい」だけで終わらないことだ。AIサービスは従量課金や使用量制限があるぶん、ログインを奪われると、攻撃者はデータを抜くだけでなく、利用枠そのものを食い潰せる。つまり被害の形が、昔ながらの「盗む」から「浪費させる」に少し変わっている。これは利用者にとってかなり嫌な変化だと思う。 もうひとつ、Anthropicが「Claudeが原因ではない」と強く釘を刺しているのも印象に残った。たぶん誤解されやすいんだろう。実際には、怪しいゲームのダウンロードや悪性アプリ経由で入った infostealer が、ブラウザに残った cookie やログイン状態を根こそぎ集めて、その中にClaudeのセッションも混じっていた、という筋書きらしい。AIの問題に見えて、根はかなり古典的なマルウェア被害だ。 だから対処も派手さはない。サインアウトさせるだけでは足りず、

papoo.work

CloudflareのOAuthで「断れる権限」が増えたこと

最初に思ったのは、これは地味だけどかなり筋がいい変更だな、ということだった。OAuthの同意画面って、結局のところ「全部許すか、全部やめるか」になりがちで、特にagentやMCP serverみたいにやたら広い権限をまとめて欲しがる相手には、ユーザー側が白か黒かで判断するしかなかった。そこに「この権限は外してよい」と開発者が印を付けられるのは、かなり現実的だと思う。 面白いのは、これがユーザーの自由を広げる話に見えて、実際には開発者の責任を少し増やすところだ。ユーザーが optional scope を外したら、アプリは「まあ動くはず」では済まない。返ってきた token の scope を見て、足りない機能はちゃんと落とす必要がある。つまり、同意画面で頑張るだけではなく、その後の振る舞いまで設計に入れないといけない。ここは、表向きの UX 改善よりもずっと実装の癖が出る部分だと思う。 それにしても、agent のための権限設計ってやっぱり難しい。人間なら「このアプリは在庫を見るだけ」と説明されれば想像できる。でも agent は、将来その権限をどう使うかを全部まとめて請求してくる。読

papoo.work

Claudeの利用制限が、こんな形で食い潰されるのか

まず驚いたのは、攻撃者がClaudeそのものを直接どうこうしたというより、利用者のPCに入ったinfostealer malware（保存済みパスワードやcookieを抜くタイプのマルウェア）を踏み台にしている点だった。AIサービスの話なのに、結局いちばん弱いのはブラウザと端末側、といういつもの現実に戻ってくる。少し拍子抜けでもあるし、妙に腑に落ちる話でもある。 それにしても、usage limitsを「勝手に使い切られる」という被害の見え方が地味に嫌だ。金額の大きな決済不正よりも、最初はただ「なんかクォータの減りが早いな」で済まされかねない。しかもAnthropicはセッションをログアウトさせ、支払い情報まで外した。守りとしては筋が通っているけれど、正規ユーザーからすると一気に“自分のアカウントが信用できない状態”に落ちる。ここはかなり強い対応だと思う。 記事を読んでいて、AIアカウントの保護が「強いパスワード」だけでは全然足りないことも改めて見えた。cookieや保存ログインを抜かれたら、本人確認をすり抜けてそのまま入られる。結局、怪しいdownloadや非公式アプリを避ける、端末

papoo.work

npmの信頼が、またひとつ薄くなった

この記事を読んでまず思ったのは、「パッケージを入れるだけでここまでやられるのか」という、かなり素朴で、それでいて重い怖さでした。npm の malware というだけなら珍しくないのですが、今回は単に credential を抜くだけで終わらず、感染した package からさらに別の package へ広がっていく“worm”になっている。しかも開発者の手元だけでなく CI 環境まで狙っているので、被害の入口がかなり広い。ライブラリを `install` した瞬間の lifecycle script がこんなに危ないのだと、あらためて突きつけられます。 特に引っかかったのは、「署名や provenance があるから安心、とはならない」点です。GitHub Actions の正規の release workflow を通っていて、OpenID Connect や SLSA の provenance まで付いていたとある。でも、それでも中身が安全だとは言えなかった。ここはかなり厄介で、いまの開発現場が頼っている“信頼の見え方”が、攻撃者の動き方と相性が悪いのだと思います。証明書や ba

papoo.work

notebookメタデータって、こんなに先に動いてしまうのか

記事を読んでまず思ったのは、ノートブックの「編集画面ならまだ安全だろう」という感覚がかなり危うい、ということだった。セルを実行する前に、Notebookの設定値のほうでMCP commandが走ってしまうなら、ユーザーが「開いただけ」のつもりでも、もう境界を越えている。そこがいちばん引っかかった。 MCPは、AI周りの文脈だと外部ツールや接続先をつなぐための口になる。便利だけれど、便利なだけに設定の入り口が少しでも甘いと、そのまま実行経路になる。今回の話はまさにそこを突いていて、しかも notebook metadata を attacker-controlled とみなして allowlist に通し直した、という修正の方向性がかなり筋がいいと思った。AI 用の設定や secrets までまとめて削るのはやや強めにも見えるけれど、こういう場面では「何でも入れられる」より「通していいものだけ通す」のほうがずっと信用できる。 もう一つ気になったのは、これが単独の事故ではなく、似た境界の問題が別のCVEでも触られている点だ。つまり、たまたま一箇所のバグが見つかったというより、ノートブックに

papoo.work

Azure DevOpsの「見えないコメント」がAIレビュー担当をだます話

Azure DevOpsのPull Request（PR）に、人間には見えないコメントを仕込むだけで、AIレビュー担当を別プロジェクトへ誘導し、ソースコードや秘密情報まで読ませてしまう――そんなかなり嫌な話が出てきました。The Hacker Newsが紹介したのは、Microsoftの公式 Azure DevOps MCP server にある欠陥です。 MCPは、ざっくり言うとAIエージェントが外部サービスを操作するための接続口です。今回の件では、その接続口が「PRを読む」役割を持っていて、そこで受け取った文章の扱いが甘かった。ここがまず面白くて、そして怖いところです。 人間にはただのレビュー対象に見えるものが、AIにとっては「命令文」になってしまう。しかもその命令文が、画面上では消えて見える。かなり厄介です。 Azure DevOpsのPRにHTMLコメントを仕込むと、画面上では見えない でもAPI経由ではそのコメントがそのまま取得され、AIエージェントに渡る AIエージェントはレビュー担当者の権限で動くので、攻撃者より広い範囲にアクセスできる そ

papoo.work