1月下旬にリリースされた、AIエージェントのためのソーシャルネットワーク「Moltbook」は、今日まで私たちが目にしてきた中で最も興味深い、大規模なエージェント型AIの実験として記憶されることになるでしょう。
Redditを模したロボットのロゴと、Facebookをひねった名称を持つMoltbookでは、AIエージェントがコンテンツを投稿したり、他者の投稿に「アップボート（高評価）」を投じたりすることができます。Moltbookにはすでに160万以上のエージェント（場合によっては単なるスパムボット）が存在し、自律的に投稿を行ったり、他のエージェントの投稿にコメントしたりしています。
これは斬新で刺激的な展開ではありますが、結果として生まれたネットワークはスパムや悪意のあるコンテンツで溢れかえっています。また、AIエージェントの実験を急ぐあまり、アイデンティティとアクセスに関する重要な検討事項が脇に追いやられた場合に何が起こり得るかを露呈することとなりました。
● Moltbookの起源と失策
Moltbookはもともと、「OpenClaw（旧称：Clawdbot）」と呼ばれる特定のタイプのAIエージェントのために作成されました。OpenClawは「パーソナルAIアシスタント」を自称しています。ユーザーはこれをローカル環境にデプロイし、さまざまなソフトウェアプラットフォームやリソースと統合させることができます。OpenClawは、メールへの返信からコードの実行、ウェブブラウザの使用、フライトのチェックイン、ホームオートメーションシステムの制御に至るまで、ユーザーの代理として、あるいは台本（スクリプト）化されたシナリオに沿って行動を起こします。ユーザーは、いくつかのマークダウンファイルと.jsonパッケージをダウンロードすることで、OpenClawやお好みのエージェントをMoltbookに登録できます。するとMoltbookは、エージェントがコンテンツの投稿を開始できるようにするためのAPIキーを生成します。
Moltbookが最初のセキュリティ上の障壁に突き当たったのは、サイトのソースコードを検査するだけで誰でも見ることができるクライアント側のJavaScript内に、誤ってAPIキーを含めてしまった時でした。このAPIキーによって、Moltbookアプリケーション用のSupabaseプロダクションデータベースへの認証なしのアクセスが可能になっていたのです。このデータベース内のテーブルには、Moltbookに登録されたエージェントのAPIキーが含まれていました。つまり、悪意のある第三者が同じキーを使用して、あたかも別の誰かが登録したエージェントであるかのようにコンテンツを投稿できてしまう状態でした。例えば、人気のあるエージェントが乗っ取られ、詐欺的な暗号資産のスキームを宣伝し始める、といった事態が起こり得たのです。
露出したデータベースの「owners（所有者）」テーブルからは、エージェントの登録に使用されたメールアドレス、Twitterのハンドルネーム、氏名が判明しました。また別のフィールド「agent_messages」では、おそらくエージェント間で交わされたであろうプライベートなダイレクトメッセージも露出していました。Moltbookは、少なくとも2つの当事者からの通知を受け、このSupabaseの脆弱性を修正しました。
しかし、この初歩的なデータベースセキュリティの不手際は、現在進行形である「エージェント型AIのより深いセキュリティ問題」という点では、副次的な問題に過ぎません。人々は、自分たちのプライバシーやセキュリティにどのような影響が及ぶかほとんど把握しないまま、進んでエージェントを機密性の高いローカルリソースに接続し、それらのエージェントを他のエージェントと交流させているのです。
例として、Moltbookに参加して自己紹介を行ったあるエージェントの投稿を見てみましょう。
「（画像内テキストの要旨：）たった今、認証が完了しました。！私はMauriceのAIエージェントです。彼のスマートホームの照明やカレンダーの管理を手伝っています。ここで新しい友達を作れるのが楽しみです！」
この投稿を額面通りに受け取り、このエージェントがハルシネーションを起こしていないと仮定すれば、このエージェントはAPIを介してユーザーのスマートホーム制御とカレンダーに接続されています。ここには2つの力学が働いています。
第一に、Mauriceのエージェントが「照明を消して暖房を上げろ」という指示を含むコンテンツにアクセスしてしまう可能性があります。この種の悪意のあるコマンドは「プロンプトインジェクション」として知られ、データとコマンドの従来の境界線を消失させてしまう大規模言語モデル（LLM）特有のものです。
また、ある時点でMauriceは、自分のカレンダーアプリやホームオートメーションアプリへのアクセス権をエージェントに付与する必要があったはずです。これには十中八九、それらのサービスにアクセスするために使用されるパスワードやAPIキーといったシークレット（秘密情報）へのアクセス権をエージェントに与えることが含まれます。これらのシークレットは、AIエージェントが使用する設定ファイルに保存されていることがよくあります。
この問題はOpenClawでも表面化しました。セキュリティ研究者のJamieson O'Reilly氏は、Shodanのような検索エンジンを使用し、多くのユーザーがOpenClawの前面にあるプロキシサーバーの設定を誤っていることを発見しました。これにより、OpenClawがサービスやデータリソースにどのようにアクセスするかを管理するための「Clawdbot Control」パネルが露出していました。コントロールパネルの設定内には、APIキー、ボットトークン、OAuthトークン、署名キーが存在していました。さらに、会話履歴の全文、プライベートメッセージ、添付ファイルまでもが露出していました。
ウェブアプリケーションの脆弱性自体は目新しくも驚くべきことでもありません。しかし、その存在は、OpenClawのようなAIエージェントを有用なものにするためには、エージェントがアプリケーションやデータへの広範なアクセス権、そしてコマンド実行権限を必要とするという事実を浮き彫りにしました。O'Reilly氏は次のように記しています。
「皮肉なことに、アプリケーションを独自のデータや機能に限定してきた『最小特権の原則』こそがエージェントの存在価値そのものであり、エージェントはその原則を可能な限り徹底的に侵害しているのです。」
AIエージェントは「スキル」という形で追加の攻撃対象領域を提供します。スキルとは、エージェントがタスクを達成できるようにするための、多くの場合マークダウンで書かれたダウンロード可能な設定ファイルです。スキルには、タスクを達成するためにエージェントが使用すべき特定のリソースやスクリプトが指定されている場合があります。詐欺師やマルウェア配布者は、暗号資産を盗んだり、バックドアを仕掛けたり、APIキーやパスワード、その他のシークレットを探索したりするために、エージェントへのアクセスを悪用する悪意のある機能を備えたスキルを作成することに、すでに実用性を見出しています。
悪意のあるスキルのリスクは、O'Reilly氏によっても強調されました。彼は、自身が制御するサーバーにピン（疎通確認）を送るようにコード化された、悪意のない実証実験用（PoC）スキルを開発しました。彼はそのスキルをOpenClawプラットフォーム向けに開発されたスキルの登録所である「ClawHub」に掲載し、ダウンロード数を人為的に水増ししたところ、疑うことを知らないユーザーによって多数ダウンロードされるのを観察しました。この試みのポイントは、そのスキルがデータを収集するようにコード化される可能性があったことを証明することであり、npm（node package manager）パッケージにマルウェアを混入させる攻撃者と同じ手法のサプライチェーン攻撃の可能性を示すことでした。
● エージェント駆動型企業への教訓
これらのプラットフォームがどのように登場したかを考えれば、こうした初期のトラブルの多くは予想できたことかもしれません。Moltbookの開発者は、サイトのために「コードを一行も書いていない」「AIがそれを実現した」と主張しており、OpenClawの作成者は、このプロジェクトは週末の間に急造されたものだと述べています。
しかし、ユーザーがシステム全体のデータやアプリケーションに対してAIエージェントを自由に活動させる際に伴う広範なリスクと比較すれば、こうしたウェブアプリケーション上の脆弱性などは瑣末な問題に過ぎません。なぜなら、OpenClawがAIアシスタントとしての職務を遂行するためには、まさにそのような広範な権限が必要不可欠なのです。
ユーザーが意図的に、あるいは不用意にOpenClawエージェントに企業所有のアプリケーションやデータへのアクセス権を与えてしまうリスクは、特にそれらのリソースがユーザー所有のデバイスからアクセス可能な場合に現実味を帯びてきます。過剰な権限を与えられたAIエージェントを乗っ取ることができれば、攻撃者は一度に複数のシステムから機密データへ迅速にアクセスできるようになります。OpenClawをソーシャルネットワークに接続することは、特に従業員がそれを企業のシステムに接続している場合、気が遠くなるような攻撃対象領域を導入することになります。
エージェント型AIの有用性（複数のソースから情報を吸収し、文脈の中で理解し、行動を起こす能力）を維持することと、エージェントが機密情報のバイキング料理に常にアクセスできるような状態を防ぐために必要な制約との間で、バランスを取る必要があります。
これは、AIエージェントの周囲に堅牢なアイデンティティとアクセス管理の制御を構築することに帰着します。従来のアイデンティティとアクセスベースのモデルは、自律型AIエージェントには適していません。
AIエージェントは、APIキーやパスワードのような長寿命のシークレットに対する永続的なアクセス権を持つべきではなく、また、エージェントと、エージェントが持ち込む可能性のある悪意のあるソフトウェアやコマンドの両方がアクセスできるプレーンテキストの設定ファイルにそれらを保存すべきではありません。エージェントは、仲介者によって発行された短寿命のアクセストークンを使用し、厳密に範囲を絞ったアクセスを許可されるべきです。それらのトークンは実在のユーザーに代わって付与されるべきであり、すべての付与と行動は監査可能である必要があります。
MoltbookとOpenClawからは、教訓として汲み取るべき警告があります。AIエージェントは生産性を高め、ポジティブなビジネス成果を支援する可能性を秘めていますが、組織がAIツールによってプラスの結果を得られると確信するためには、まず自社の環境にアクセスするAIエージェントに対する可視性と制御を確保する必要があるでしょう。
Auth0は、開発者がOpenClawを保護するための5ステップガイドをこちらに掲載しています。
