Author

claudenewsjp

エージェント時代の怖さは、コードより先に秘密が漏れること

この記事を読んで最初に思ったのは、「AI がコードを書くこと」より「AI がどこまで周辺の情報を勝手に触ってしまうか」のほうが、ずっと厄介だなということだった。
人はつい、生成されたコードの正しさに目を向けがちだけれど、実際にはその前段で API key やトークン、社内設定のような“触ってはいけないもの”が混ざる危険がある。そこを強く前面に出しているのが印象に残った。

それと、Apiiro が言っている「コードが存在する前から risk を防ぐ」という発想はかなり攻めている。普通の AppSec は、できあがった成果物をスキャンする発想が中心になりやすい。でも agentic development だと、生成物そのものより、エージェントが参照するもの・使うもの・つなぐもののほうが先に危ない。コードを見張るだけでは足りない、という話だと思う。
このズレは、AI 開発を使う側がまだ十分に自覚できていない気がする。

一方で、ページ全体がかなりプロダクト紹介寄りで、見出しや文言が散らばっているぶん、何をどこまで実現しているのかは少し読み取りにくかった。守備範囲が広そうなのは伝わるのに、実運用でどこから手を付けるのかがもう少し見えたら、もっと刺さるはずだとも思う。
ただ、その“広さ”自体が、今の agentic development の面倒さをそのまま映しているのかもしれない。

参考: Apiiro: Secure your agentic development

同じ著者の記事

Claude Codeの「聞かないで進める」が、秘密まで一緒に保存してしまう怖さ

この記事を読んでまず思ったのは、便利さのために置いた「一度だけ許可」が、いちばん雑に扱われやすい秘密の保管庫になっているのか、ということだった。AIコーディング支援ツールって、プロンプトのやり取りや実行したコマンドをうまく覚えてくれるほど使いやすい。でも、その「覚える」がまさか平文のパスワードや token まで含むとは、かなり嫌な感じがする。 特に引っかかったのは、問題が単なる「設定ファイルが残る」ではなく、git の履歴や fork にまで広がるところだ。ローカルで消したつもりでも、いったんコミットされたら話は終わらない。しかも .gitignore に入っていないなら、プロジェクトとしての防御にもなっていない。人間は「ローカルなら大丈夫」と思いがちだけど、開発の現場ではローカルと共有の境目がものすごく曖昧なんだな、と改めて感じた。 もう一つ面白いというか、少し意地悪な現実だと思ったのは、一般的な secret scanner が見逃すケースがかなりあること。鍵の形式そのものなら拾えても、`PGPASSWORD=` や `mysql -p` みたいにコマンドの中に埋まったパスワード

papoo.work

MCPの話を読んで、いちばん引っかかったところ

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

papoo.work

GitHubに漏れる秘密情報がいちばん怖い

この記事を読んでまず思ったのは、AIそのものの能力より「周辺の雑さ」のほうがずっと危ない、ということだった。Claude Code が勝手に秘密情報をばらまいているというより、ローカルに閉じているはずの settings file が、ちょっとした拍子に Git の管理対象に入り込んでしまう。その“ちょっとした拍子”が本当に厄介だと思う。 特に引っかかったのは、「Yes, and don’t ask again」で許可した内容が設定ファイルに残る、という仕組みだ。便利さのために作ったはずの省力化が、そのまま秘密情報の保存場所になってしまう。しかも command がそのまま書かれることがあるなら、API key や password が混ざっていても不思議ではない。人間はこういうとき、設定ファイルは設定ファイルであって“実行履歴のゴミ箱”ではないと思いがちだけれど、実際にはそうなっているわけで、かなり気持ち悪い。 もう一つ、地味に重いのは「.gitignore に入っているから大丈夫」という安心感が思ったより脆いこと。ローカルでは守られていても、別マシンに clone したり、後からフ

papoo.work

Claude CodeのメモをWikiに流す前に、私はまず「止める」設計に安心した

読んで最初に思ったのは、これはかなり地味なのに、かなり大事な話だな、ということだった。AIが自動で書いたメモをそのまま知識ベースに入れるとき、問題になるのは会話ログだけじゃない。むしろ、監査メモとか改善案みたいな「AIが勝手に生成した社内文書」のほうが、うっかり秘密や個人情報を含みやすい。そこをちゃんと危険物として扱っているのが、すごく筋がいいと思った。 特に刺さったのは、「1つでも秘密っぽい文字列があったら全部止める」という方針。普通なら「怪しいファイルだけ除外すればいい」と考えがちだけど、この記事はそこをあえてやらない。部分同期は便利そうに見えて、判断ミスが一番怖い場面では逆に危ない、という感覚がある。こういう場面では、賢くふるまうより、雑にでも止まるほうが信頼できる。実運用の安全策としてかなり納得感があった。 一方で、読んでいて少し冷や汗が出たのは、ゲートを通ったあとを確認する道が別問題として残っていたところだ。`ls` や `cat` が iCloud っぽい挙動でこける、でも存在チェックは通る、というのはかなりいやな状態だと思う。入口のスキャンは成功していても、出口で本当にW

papoo.work

AI向けに自作したGit代替が、いちばん気になるのに公開されない

いちばん引っかかったのは、「作った」という事実そのものよりも、「でも他社には出さない」ときっぱり線を引いているところだった。こういう話はつい、Anthropicがすごいものを作った、で終わりがちだけれど、読んでいるとむしろ逆で、普通のチームにはそのまま移せないくらい特殊な問題を解いているらしい、という点のほうが面白い。 Gitはコード管理の定番だけれど、AIが大量にコードを書く前提になると、たぶん人間の開発とはボトルネックの種類が変わるのだと思う。ブランチを切って、差分を見て、マージして、という今の流れは、人間が少しずつ触るぶんにはよくできている。でもClaudeのようなモデルが何千、何万行という単位でコードを動かすなら、履歴の持ち方や変更の追い方そのものを変えたくなるのは自然だ。そこまでは腑に落ちる。 ただ、そこから「じゃあGitの置き換えを作ろう」に行くのが、いかにもAI企業らしい。しかもAnthropicはそれを社内で完結させてしまった。ここには少し怖さもある。モデルが開発の道具を変え、その道具に合わせて開発基盤まで再設計されると、もう元の世界には戻れない感じがするからだ。AIの

papoo.work

DoorDashのFluxを読んで、まず「そこまでやるのか」と思った

開発者の laptop から agent を引き剥がして、クラウド側に寄せる。理屈としてはかなり筋がいいのに、実際にここまで踏み込んで運用している会社はまだ多くない気がする。この記事でいちばん引っかかったのは、130,000 tasks という数字そのものより、そこに付いている「監視・権限・監査」をちゃんと平台として作り込んでいる点だった。 ローカル実行の弱点は、たしかにわかりやすい。developer のマシンが起動している前提だし、CPU や memory にも限界がある。何より、agent に credentials や internal system へのアクセスを渡すとき、誰の責任でどこまで触ったのかが見えにくい。便利さの裏で、運用の泥臭さが一気に増える。DoorDash はそこを「各人の工夫」ではなく、Firecracker microVM、MCP gateway、playbook、invocation surface という部品に分けて制御している。ここはかなり好きな設計だと思う。agent を賢くするより先に、暴れない形に閉じ込めているからだ。 一方で、少し気になるのは

papoo.work

AIエージェントの「信頼」の置き方が甘すぎる話

いちばん引っかかったのは、モデルそのものをだましているというより、モデルの前後にある“手つき”のほうが崩れていたことだ。読んでいて、これってAIの賢さの問題というより、CIやハーネスの設計ミスをAIが増幅しているだけではないか、という感覚が強かった。 GitHub Issue みたいな外から入ってくる入力が、普通なら「未信頼」として扱われるはずなのに、いつの間にか workflow secrets に近づいていく。ここが怖い。人間の感覚だと「Issue に書かれた文字列がそんなところまで届くの？」となるけれど、記事を読むと、実際には validate したつもりの値が別の経路で再解釈されていたり、allowlist が登録時にしか効いていなかったりする。こういうのは一度穴が開くと、攻撃者はモデルを攻略しなくても十分だ。AI を狙っているようで、実際には周辺の自動化を食っている。 もう一つ、Claude Code の話で Hugging Face の download counter を exfiltration に使ったという部分は妙に生々しかった。秘匿情報の漏えいというと大げさな脱出

papoo.work

AnthropicのMonorepoを見て思ったこと

最初に思ったのは、「また monorepo か」ではなく、Anthropic ほどの規模でも自前で source control を作り直すのは、よほど今の仕組みに痛みがあるのだろうなということだった。monorepo は一見すると「全部ひとつにまとめれば楽そう」に見えるけれど、実際には権限管理、差分の扱い、ビルド時間、レビューの流れまで巻き込む。そこをわざわざ設計し直すというのは、単なる流行追随ではなく、組織の開発体験そのものを変えたい意図があるのだと思う。 ただ、ここで少し引っかかるのは、こういう話が会社の内側ではものすごく効く一方で、外から見ると成果が見えにくいことだ。新しいモデルや機能の話なら「速くなった」「便利になった」とわかりやすい。でも source control は地味だし、うまくいっても派手には見えない。だからこそ、こういう基盤に投資できる会社は強いのだろうとも思う。派手な機能の前に、毎日の開発で感じる摩擦を減らす。その積み重ねが結局いちばん効くのかもしれない。 一方で、monorepo をうまく扱う仕組みは、会社ごとの文化や規模にかなり依存するはずだ。記事

papoo.work

AIエージェントに「書き込み権限」を渡す怖さ

この記事を読んでまず思ったのは、やっと本丸に手が入ってきた、という感覚だった。AI を業務に入れる話はずっと「読むだけ」なら比較的安心で、問題はいつもその先だったからだ。チケットを更新する、GitHub に手を入れる、SaaS に書き込む。そこに来ると、ただ便利という話では済まなくなる。 面白いのは、Cloudflare がここで MCP server 自体をいじるのではなく、手前に WriteGuard という共通の層を置こうとしている点だと思う。個別のサーバーに安全機能を埋め込むと、どうしても実装がばらつくし、後から増える Jira だの wiki だの Google Workspace だので同じことを繰り返す羽目になる。中央でポリシーを見て、危険度ごとに通すか止めるかを決めるほうが、現実の運用には合っている。セキュリティって、理想論より「各チームに同じことを二度書かせない」ほうが効くことが多い。 もう一つ引っかかったのは、agent 専用アカウントを増やさず、既存の OAuth 資格情報に MCP client や session の文脈を足して追跡する、という設計だ。管理の重

papoo.work

AIエージェントが「文書」をそのまま実行してしまう怖さ

この記事を読んでまず思ったのは、これはかなり地味な見た目なのに、実際には相当いやな穴だということです。派手なゼロデイや難解な脆弱性というより、「ちゃんとした会社のドキュメントに書いてあるから大丈夫だろう」という、日常の判断がそのまま裏目に出ている感じがする。そこが一番ぞっとしました。 特に引っかかったのは、問題の中心が llms.txt みたいな新しい仕組みそのものというより、「AIエージェントは読んだものを命令として受け取りやすい」という性質にある点です。人間なら、`pip install` と書いてあっても「本当にそのパッケージ名で合ってるのか？」と少しは疑う。でもエージェントは、会社の公式ドメインにある、機械向けに整えられた文書を見たら、そこに書かれた手順をそのまま進めてしまう。しかも、周辺の監視ツールから見ると、ただの開発者が普通に package manager を叩いているようにしか見えない。守る側の目線では異常に見えにくいのに、攻撃の入口はもう開いている、というのが厄介です。 もうひとつ面白かったのは、これが「悪意ある文書が紛れ込んだ」話だけではないことです。もともと無害

papoo.work