#認可

最初に思ったのは、「これは新しい話というより、昔からある gateway の発想が、AI agent 向けにそのまま戻ってきただけではないか」ということだった。むしろその既視感が面白い。API gateway や service discovery、認可、監査、変換レイヤー。分散システムでさんざん揉まれてきた論点が、MCP という名前をまとって再登場している。 ただ、Uber の規模で 800 以上の MCP server と 5,000 以上の tool を抱えると聞くと、これは「便利な整理術」では済まないなとも思う。AI agent は、ふつうの人間向け UI 以上に、雑多な内部 API を無秩序に食べてしまう。だから registry と runtime execution を分ける設計はかなり腑に落ちた。登録は管理部門の仕事、実行は現場の仕事、という分離がはっきりしていないと、すぐに「誰がこの tool を出したのか」「いつ使っていいのか」が曖昧になるはずだ。 一方で、気になったのは「LLM が増えると gateway が必要になる」のは当然として、ではその gateway 自

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

この記事を読んでまず思ったのは、MCPみたいな仕組みでいちばん地味に見える部分が、実は一番こわいんだな、ということでした。派手なのはAI agentやvibe codingのほうですが、事故の入口はたいてい認可やtokenの扱いみたいな、目立たないところにある。そこが「壊れている」「抜けている」が5分の1もあるなら、便利さより先に不安が来ます。 特に引っかかったのは、personal token や missing scopes という話です。token はざっくり言えば「この人はここまでやってよい」という通行証ですが、それが個人のものに寄りすぎると、誰が何をどこまで触れるのかがぼやける。scopes は許可の範囲のことですが、それが欠けていたり適切に絞れていなかったりすると、後から見返したときに「そもそもこの接続は安全だったのか」が分からない。技術的にはよくある失敗なのに、AIツールの文脈だと「とりあえずつながれば動く」で流されやすいのが厄介だと思います。 もう一つ、この記事が示しているのは、vibe codingの危うさが「コードの質」だけでは終わらないことです。雑に作られたものは

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

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

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