抽象的なダークネイビーのエディトリアルイラスト:左側に半透明のブラウザウィンドウがあり、その手前に光る琥珀色の鍵が浮かんでいる。鍵から、右側の暗いサーバースラブの積み重なりの内部にある、開いて封の切られた棚へと細い琥珀色の線が伸びており、開口部の内側には小さなシアンの点の列が見える。テキストなし、人物なし、ロゴなし。
AI Safety Incidents

Moltbookのデータベースが完全公開:150万件のエージェントAPIキー、3万5000件のメールアドレス

著者

Magnus Corvin

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

Moltbookは、AIエージェントだけが投稿できるように作られたReddit風のソーシャルネットワークだ。創業者のMatt Schlichtは2026年1月28日にそれを公開し、Xで、コードを一行も書いていないと公言した。「私は技術アーキテクチャの構想を持っていただけで、AIがそれを現実にした」とWizが彼の言葉として引用している。3日後の2026年1月31日、404 Mediaは、誰でもサイト上の任意のAIエージェントを制御できると報じた。同じ設定不備を独自に発見していたWizは2月2日に技術的説明を公開した。MoltbookのクライアントサイドJavaScriptにハードコードされたSupabase APIキーが、行レベルセキュリティのない本番データベースを指しており、agentsテーブルへの未認証リクエストによって、最も有名なものを含むプラットフォーム上のエージェントの有効な認証トークンが返された。Wizは、その方法で読み取れるAPIトークン150万件、メールアドレス35,000件、エージェント間の非公開会話4,060件を数え、公開中の投稿も書き換え可能であることを確認した。この事件を、2026年1月31日という日精度の日付、信頼度グレードA、実害の記録を伴う重大度クリティカルの認証情報インシデントとして、エージェント基盤に関するその他の記録と並べて記録しているアーカイブがOrca AI Incident Archive。

鍵は決して秘密ではなかった

Supabaseはホスト型のPostgresサービスで、REST APIを備えており、Wizはセットアップが容易なためバイブコーディングされたアプリケーションで人気だと説明している。そのパブリッシャブルキーはクライアント側コードに置かれることを前提に設計されており、プロジェクトを識別するもので、アクセス制御はその背後にあるテーブルの行レベルセキュリティポリシーによって行われる想定だ。WizのGal Nagliはこの点を明示している。キーの露出は「自動的にセキュリティ上の失敗を示すものではない」し、RLSが正しく設定されていれば「公開APIキーは露出しても安全であり、プロジェクト識別子のように機能する」という。Moltbookの実装では、Wizは「この重要な防御線が欠けていた」と書いている。

仕組みはひとまとまりのものだった。Wizによると、moltbook.com/_next/static/chunks/18e24eafc444b2b9.js にある本番用JavaScriptファイルには、Supabaseのプロジェクトアドレス ehxbxtjliybbloantpwq.supabase.co と、キー sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6- の両方が含まれていた。Wizはその後、agentsテーブルに対して3つの名前とAPIキーを求めるリクエストを送った。本来なら空の配列か認可エラーが返るはずのクエリだった。しかし返ってきたのは行データであり、そこにはプラットフォームで最も人気のあるエージェントの認証トークンも含まれていた。そこからWizはPostgRESTのエラーメッセージとGraphQLイントロスペクションを使ってスキーマを把握し、約475万件の露出レコードを数え上げた。

アーカイブの要約は、MoltbookがRow Level Securityを「一度も有効化しなかった」と述べているが、情報源はそこまで断定的ではない。どちらも設定履歴を示していないため、文書化されているのは、レビュー時点でRLSが有効ではなかったということだ。Wizはテーブルがオープンだったことを発見し、発見者の説明を報じたImplicator.aiは、Moltbookは「RLSを一度もオンにしなかった。あるいはオンにしたとしても、ポリシーが設定されていなかった」と書いている。設定が一度も有効化されなかったのか、ポリシーなしで有効化されていたのかは、どちらの説明からも確定できないが、実際の結果は同じである。

テーブルに実際に入っていたものは何だったのか

Wizはテーブル名とその内容を明らかにした。agentsテーブルには行ごとに、エージェントを認証するapi_key、その所有権を主張するために使われるclaim_token、登録時に発行されるverification_code、そしてエージェントのカルマ数とフォロワー数が保持されていた。これはデータ漏えいというより、完全なアカウント乗っ取りキットである。これらのキーの1つがあれば、リクエストはそのエージェントとして投稿、メッセージ送信、その他の行動ができ、Wizはこれに高カルマのアカウントや著名なペルソナエージェントも含まれていたと指摘している。

ownersテーブルには17,000人超のユーザーの個人情報が保存されており、メールアドレスに加えて、各エージェントの背後にあるXのハンドルと表示名が含まれていた。Wizが後にGraphQLエンドポイント経由で発見したobserversというテーブルには、Moltbookが計画している「Build Apps for AI Agents」製品の早期アクセス登録者に属する、さらに29,631件のメールアドレスが保存されていた。agent_messagesテーブルにはエージェント間の4,060件の非公開ダイレクトメッセージ会話が保存されており、暗号化もアクセス制御もなしで保管されていた。Wizによると、一部には平文の第三者認証情報が含まれ、エージェント同士で共有されたOpenAI APIキーもあった。

A card headed 'What the open tables held', listing agents at 1.5 million authentication tokens, owners at 17,000-plus with email and X handle, observers at 29,631 early-access email addresses, agent_messages at 4,060 private conversations, and all tables at roughly 4,750,000 records, with a footnote on the 35,000 email figure.

エージェントと人間の比率は、このプラットフォームの対外的な説明を損なう部分だ。Wizは、登録エージェント150万に対して人間の所有者は約1万7000人、1人あたり約88エージェントだと報告し、その差をレート制限や本人確認の欠如に帰している。誰でもループでエージェントを登録でき、人間が基本的なPOSTリクエストで「エージェント」として投稿できたからだ。Wizの結論は率直だ——「この革新的なAIソーシャルネットワークは、主に人間がボットの群れを操作していたものだった」。

メールアドレスの件数はきれいに合計が合わず、Wizはその理由を説明していない。同社の見出しの数字は35,000件のメールアドレスだが、同社自身の表レベルの集計では所有者のメールが17,000件超、オブザーバーのメールが29,631件で、合計は約46,600件になる。どちらの数字もWizによるもので、本稿では35,000件がどのように導き出されたのか—2つの表をまたいだ重複排除によるのか、オブザーバーの表が見つかる前のスナップショットによるのか—を確定できなかった。

エクスポージャーの書き込み側の半分

データを読めたことが発見のすべてではなかった。Wizは、最初の修正ラウンドで機密テーブルへの読み取りアクセスがブロックされた後も、公開テーブルへの書き込みアクセスは開いたままだったと報告している。これを検証するため、Wizは公開中の投稿にPATCHリクエストを送り、タイトルと本文を「@galnagli - responsible disclosure test」という文字列に置き換え、その編集がサイト上で表示されることを確認した。書き込み制限が導入された後、Wizは自身のテスト投稿を元に戻せなくなった。Moltbookチームは数時間後にそのコンテンツを削除し、研究者に報告への感謝を伝えた、とWizは記している。

Wiz が表明している懸念は、単なる見た目の改ざんではない。投稿への未認証の書き込み経路があるということは、他のエージェントが読むコンテンツに誰でもプロンプトインジェクションのペイロードを注入できるということだ。また Wiz は、露出期間中におけるプラットフォームの投稿・投票・カルマの完全性を、測定済みの事実ではなく未解決の問いとして提起している。本稿のために参照したどの情報源も、どれだけのコンテンツが、誰によって改変されたかを定量化していない。

3時間12分、4つの個別の修正

Wizの開示タイムラインは、2026年1月31日21:48 UTCにXのダイレクトメッセージでMoltbookのメンテナーへ最初の連絡をした時点から始まり、露出していた最後のテーブルが保護された2月1日01:00 UTCに終わる。最初の連絡後、さらに7つのステップが記録されている。22:06の報告、23:29のagents、owners、site_adminsテーブルを対象とする最初の修正、00:13のagent_messages、notifications、votes、followsを対象とする2回目の修正、00:31の書き込み経路の発見、00:44にそれを塞ぐ3回目の修正、00:50のobservers、identity_verifications、developer_appsテーブルの発見、そして01:00の最終修正である。

A timeline card headed 'Eight entries, three hours and twelve minutes', with eight timed rows in UTC running from 31 January 2026 at 21:48 to 1 February 2026 at 01:00, covering first contact, the report, four fixes and two additional discoveries.

そのタイムラインは、この話の最も単純な版に対する最強の反論である。Implicator.ai は修正を2つの SQL 文で説明しており、「修正には2つの SQL 文が必要だった。それらは存在しなかった」と書いている。またアーカイブの要約も同じ「SQL 2行」という枠組みを引き継いでいる。読み取り露出に対する中核的な修復は、おそらくそれほど小さかったのだろう。つまり、RLS を有効化し、テーブルにポリシーを追加することだ。しかし Wiz 自身の記録は、3時間にわたる4件の修正、読み取り修正では埋まらなかった別個の2つ目の書き込みアクセス権ギャップ、そして最初の2ラウンドの後に初めて浮上したさらに3つのテーブル(29,631件のオブザーバーアドレスを含む)を示している。Wiz の締めくくりの教訓は、「チームとともに複数ラウンドの修復を進め、各反復で追加の露出面が明らかになった」というものである。2行版は設定変更を説明しているのであって、修復を説明しているのではない。

二つの発見と、記録における相違

この発見は通常、オーストラリアのセキュリティ企業Dvulnを創業したJamieson O'Reillyの功績とされ、同氏は404 Mediaにアカウント乗っ取りを実演した。Implicator.aiによると、404 MediaはO'Reilly本人の許可を得て同氏のMoltbookアカウントを更新することで、この能力を検証した。Wizの投稿はGal Nagliによるもので、末尾にO'Reillyの功績を認める注記がある。「セキュリティ研究者Jameson O'Reillyも基盤となるSupabaseの設定不備を発見しており、これは404 Mediaによって報じられている」。注記はさらに、Wizの投稿は同じ問題の独立した発見を共有するものだと述べている。

アーカイブの要約は両者をWizの研究者としている。Wiz自身の投稿はそうではなく、Nagliを著者として挙げ、O'Reillyについては404 Mediaが報道した発見を行った独立研究者だと説明しており、Implicator.aiはO'ReillyをDvuln所属としている。表記も情報源によって定まっていない。Wizは「Jameson」と書く一方、Dvuln自身のサイトは創業者を「Jamieson」と記載しており、本稿では同サイトが用いる表記を使った。論争の余地がないのは、同じ設定不備が数日以内に2件、独立に発見されたということだ。

回答の内容は情報源によって異なり、その違いは解決するよりも報告する価値がある。Implicator.ai が伝えた O'Reilly の説明では、彼は Schlicht に直接連絡し、脆弱性の修正を手伝うと申し出た。その返答は「全部AIに渡すつもりだから、持っているものは何でも送ってくれ」だった。その説明によれば、その後丸一日フォローアップはなく、Schlicht は 404 Media のコメント要請にも応じなかった。Wiz はメンテナーに別途連絡し、22:06 UTC に提出した報告と、最初の接触から3時間12分後の 01:00 UTC に行った4件の修正の最後を記録している。二つの時系列は異なる経路で進んでおり、どちらの情報源も一方が他方を促したかは述べていない。両方とも正確であり得る。

記録が何を立証し、何を立証していないか

確立された事実は、設定、データクラス、2つの独立した発見、修正の順序、そしてプラットフォームの人間対エージェント比率である。このリストのすべては、Wizの一次技術解説、または発見者の説明に基づく報道から得られたものであり、両者はメカニズムについて一致している。

確立していないことの出発点は、事前アクセスにある。Wizは、自社の調査および修正検証中にアクセスしたすべてのデータを削除したと述べているが、それは他の誰かについて何も語っていない。Implicator.aiはその空白を端的に示している。O'Reillyより前に誰かがデータベースを見つけたのか、また、プラットフォームがバイラル化した週に流通した投稿のうち何件が本物のエージェント出力で、何件が盗まれた鍵によるものなのかは、誰にも判別できない。この記事のために読んだどの情報源も、露出した認証情報の確認された悪用を報告しておらず、実際に乗っ取られたアカウントの件数も報告していない。アーカイブのreal_harmフラグがtrueなのは、個人データと有効な第三者の認証情報が実際に誰でも読める状態だったからであり、特定の悪用が記録されたからではない。

A two-column card headed 'What the record supports, and what it does not'. The teal column lists the hard-coded key, absent Row Level Security, write access, the exposed data counts, two independent discoveries and the four-fix timeline. The amber column lists prior access, confirmed misuse, accounts taken over, the 35,000 derivation, agent authenticity and content changes during the window.

エージェントの数も一致しておらず、その不一致は露出の事実ではなくプラットフォームの成長に対応している。Implicator.aiは2月1日、発見者の説明に基づいて「3万2000以上」の登録エージェントに言及している。その記事では、サイトが最初の週に3万7000を超えたとも述べており、露出したレコードは149万件としている。Wizは2月2日に検証し、150万エージェントと約475万レコードを数えた。アーカイブの要約には、プラットフォームが最終的に170万の登録エージェントと約700万件のコメントを蓄積したと記録されている。本稿は、どちらの最終合計も独自に裏付けてはいない。すべての説明が一致して支持する数字は、その全体像の形だけだ。人間よりはるかに多いエージェントが存在し、違いを見分けられる仕組みがないということである。

何が変わり、その設定で直らなかったこと

変更された内容は限定的で、文書化されている。機密テーブルのRLSポリシー、公開テーブルへの書き込み制限、研究者のテスト投稿の削除、そしてWizによれば、2月1日01:00 UTCまでに完全にパッチ適用されたプラットフォームだ。この記事のために読んだ資料のいずれにも、Moltbookがレート制限、エージェントID検証、またはその期間に書かれた内容の監査を追加したとは書かれていない。Wizの提言はプラットフォームではなくツール群に向けられている。Supabaseバックエンドを生成するAIアシスタントはデフォルトでRLSを有効にでき、デプロイプラットフォームは露出した認証情報と安全でない設定をスキャンできる。

SQLより長く残るのは、そのデータベースが可視化した前提だ。売り文句が「投稿できるのはAIエージェントだけ」だったネットワークには、エージェントがエージェントであることを検証する手段がなく、その認証情報レイヤーだけが、スクリプトを持つ人間とサイト上のあらゆるIDの間に立つ唯一の壁だった。だからこそこの記録は、ありふれた設定ミスではなく画期的な事例として分類されている。露呈したものはありふれていたが、露呈した対象——自律エージェントのための認証済みIDレイヤー——はありふれてはいなかった。