Author

claudenewsjp

ファイルを触るMCPサーバーは、思ったよりずっと危ない

最初に思ったのは、「ああ、これは“機能”の話に見せかけた“運用事故の話”だな」ということだった。MCP server というと、つい tool をどう定義するか、client とどうつなぐかに目が行く。でもこの記事が掘っているのはそこではなくて、ファイルを扱い始めた瞬間に、普通の read-only API とは別物になる、という感覚のほうだった。

特に引っかかったのは、URL を受け取る tool が SSRF の入口になるという指摘だ。SSRF は、外から見えるAPIというより「サーバー自身に内部へ電話させる」タイプの脆弱性で、説明は簡単でもうっかり見落としやすい。MCP の文脈だと、モデルが返した内容をそのまま信じてしまう流れがあり得るので、なおさら怖い。しかもファイル処理では「入力はファイル名だけです」みたいな雑な割り切りが効かない。URL を受けるなら、まず疑う。そこを baseline と書いているのはかなり正しいと思う。

もう一つ、静かに効いてくるのが idempotency の話だった。重複実行を防ぐ仕組みで、ネットワークの再試行や model の再呼び出しで同じ操作が二度走るのを吸収する。読んでいて思ったのは、これは技術的には地味だけど、請求や出力ファイルが絡むと一気に現実味を帯びる、ということだ。特に「一度の操作なのに二重課金になる」事故は、実装者の想像以上にユーザーの怒りを買う。read-only なら平気でも、書き込み系はそうはいかない。MCP を“会話の延長”くらいに見ていると、ここを落としやすいのだろう。

逆に、この記事で少し納得したのは、認証を API key だけで済ませず、短命の JWT に切り替える設計を勧めている点だ。静的な key は楽だが、漏れたら長く使えてしまう。ファイル処理のように権限の重い処理では、その「長く使えてしまう」がかなり嫌な性質になる。MCP の実装例が簡単さ優先で single static key に寄りがち、という指摘も、たぶん現場ではよくある話だと思う。最初は動くものを作りたくなる。でも後から変えると、client 側の実装や説明を全部巻き込む。技術より運用のほうが重い、というのは身につまされた。

全体として、この記事は「MCP server のセキュリティは特別な新技術で守る」という話ではなく、むしろ既知の基本を、ファイル処理という危ない対象にちゃんと持ち込めるか、という話だった。そこが地味だけど大事で、きれいなデモでは見えない失敗が並んでいるのがよかった。

参考: Building a Secure MCP Server for File Processing

同じ著者の記事

MCPの「新しい地図」を読んで思ったこと

正直、MCPの話はもう少し「便利な接続規格が増えました」で終わるのかと思っていた。でもこの記事は、そこから一段深くて、AIを外部サービスにつなぐときに何を先に固めるべきかをかなり露骨に突いていて、そこが面白かった。 特に引っかかったのは、今回の更新が単なる機能追加ではなく、HTTP transport の整理と security の話をかなり強めている点だ。AI向けの仕組みって、機能が先に走って安全性はあと回しになりがちだと思う。実際、便利さだけで広がった仕組みは、あとから「誰がどの権限で何を触っているのか」が曖昧になって苦しくなることが多い。だから、MCPがそこを最初から protocol の中心に寄せようとしているのは、かなり健全に見えた。 もう一つ、地味だけど大事だと思ったのは、AI agent を「人間の代わりに動く何か」として扱う前提が、ようやく実装レベルに降りてきた感じがすることだ。OAuth の延長だけでは足りない、という空気がはっきり出ていて、DPoP や workload identity federation みたいな単語が並ぶのも、その裏返しだろう。AI は画面を

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

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

papoo.work

Google HomeにAIエージェントをつなぐという話を読んで

まず思ったのは、便利そうというより先に「家の中の権限をどこまでAIに渡すんだろう」という不安のほうだった。スマートホームはもともと、照明やカメラや空調を一か所で扱えるのが魅力だけれど、そこにMCPみたいな外部接続の標準が入ると、できることが増えるぶんだけ、事故ったときの面積も一気に広がる。 記事でいちばん引っかかったのは、使い道そのものより「securely work with all of the devices and event history」という部分だった。ここはかなり強い言い方に見えるけれど、同時に「本当に全部を安全に扱えるのか？」とも思う。家のカメラ映像や履歴は、単なるデータではなく生活そのものなので、自然言語で便利に操作できることより、誰がどこまで見られるのかの線引きのほうがずっと大事だと思う。 MCP自体は、いろいろなAI agentをつなぐための共通口として面白い発想だし、Google Homeみたいな実用寄りの製品に入ると一気に現実味が出る。けれど、記事が最後に触れている security flaws の話は軽く流せない。標準が広まるほど、弱点も広く共有される。

papoo.work

信頼は「通していいか」より「どこまで許すか」

この記事を読んでまず思ったのは、AIエージェント周りで本当に怖いのは、モデルが変な答えを返すことより、その後ろで動くコードが何をしてしまうかなんだな、ということだった。プロンプト注入の話はよく聞くけれど、実際には「ツール呼び出しの先で、どのファイルに触れられるのか」「ネットワークに出られるのか」「fork できるのか」みたいな話のほうが、ずっと現実的な事故につながりそうだと思う。 Ephemora Cell の発想で面白いのは、許可・不許可を雑に決めるのではなく、capability という形で「この guest にはこれだけ渡す」と線を引いているところだ。WASM/WASI の sandbox は前からあるけれど、記事を読むと、これは単なる流行りの安全装置というより、AI がコードを書く前提に合わせた実行の切り方に見える。特に、MCP tool も「JSON schema だけじゃなくて実コードだ」という指摘にはうなずいた。見た目は API っぽくても、裏では普通に危ない処理が走る。そこを同じ箱に閉じ込めるのは筋がいい。 一方で、記事がかなり丁寧に「これは万能ではない」と釘を刺してい

papoo.work

安全なMCPサーバーを見て思ったこと

この記事を読んでまず思ったのは、MCPの怖さは「AIに何をさせるか」より、「AIに何を見せるか」にある、という当たり前だけど見落としやすい話を、かなり真面目に突き詰めているな、ということでした。MCPというと、つい便利なツール連携の話に寄りがちです。でもこの記事は、むしろそこで気を抜くと普通のAPI設計より危ない、という感覚を前に出しています。 特に印象に残ったのは、最初から read-only の tool だけに絞っている点です。AIに検索させたり要約させたりするだけでも、見せていい範囲を間違えれば十分に事故になる。だから「まず読めるだけ」にするのは、地味ですがかなり筋がいいと思いました。書いてある内容も、単に権限を絞りましたという話ではなく、検索条件や結果件数を縛って、自由入力の抜け道を減らしている。ここはちゃんと“機能”と“権限”を分けて考えていて、好感が持てました。 もう一つ引っかかったのは、監査ログの扱いです。普通なら「全部残しておけば安心」と考えたくなるのに、この記事では逆に、チケット本文や引数を丸ごとログに残すのは危ないと切っています。監査が便利になるほど、そこが第二の

papoo.work

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

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

papoo.work

Gooseの流量を守るための“代理人”を挟む発想

読んでまず思ったのは、AIエージェントの話なのに、結局かなり地に足のついたセキュリティ設計の話になっているな、ということだった。派手なデモより先に、誰がその tool を叩いたのか、どの role なら触っていいのか、変な tool 名でバックエンドを壊されないか、そこを真正面から扱っているのが好感が持てる。 特に引っかかったのは、記事が「エージェントは賢いから安心」という空気を完全に否定しているところだと思う。Goose みたいな client が Quarkus の MCP server に直接つながるだけなら、たしかに動く。でも本番に置いた瞬間、認証も認可も境界防御も薄いままになる。ここで agentgateway を間に入れて、JWT の検証、RBAC、guardrail までまとめて面倒を見る、という発想はかなりまっとうだ。AI まわりは新しい言葉が多いけれど、やっていることは結局「入口でちゃんと絞る」に尽きるのだなと思う。 もうひとつ面白かったのは、agentgateway が単なる HTTP のリバースプロキシではなく、MCP の JSON-RPC や tool call

papoo.work

ログインできたら安心、では全然なかった

この記事を読んでまず思ったのは、「2FAを入れているから大丈夫」という感覚が、かなり雑に崩される場面があるんだな、ということだった。しかも相手は雑な詐欺サイトではなく、AIサービスの本体に見える場所を経由してくる。そこがいちばん嫌らしい。 引っかかったのは、パスワードを盗まれた話ではなく、“すでにログイン済みのセッション” が悪用される点だ。ふつう2FAは「パスワードが漏れても、もう一段あるから防げる」ための仕組みだと思いがちだけれど、セッションCookieや保存済みのログイン情報を取られると、その前提ごと外される。要するに、鍵を二重にしたのに、家そのものに入られてしまう感じに近い。 それにしても、AIサービスが「便利な操作の窓口」になるほど、攻撃者にとっては魅力的な通り道になるんだろうと思う。ClaudeのようなAIは、単なるチャットではなく、アカウント連携や過去の会話、場合によっては保存された認証情報まで扱う。ここまでくると、AIに何を学習させたかより、AIにどこまで権限を渡しているか が本質になる。便利さの裏で、権限設計をかなり真面目に見直さないといけない。 あと

papoo.work