Supabaseのデータ露出、バイブコーディングアプリのセキュリティ主張に圧力

Supabaseは、プラットフォームがプロジェクトをデフォルトで安全と説明しているにもかかわらず、研究者が誰でも読み取れるテーブルを持つデータベース16,326件を特定したことで、厳しい目が向けられている。Supabaseのデータ露出に関する調査結果は、よく知られたクラウドセキュリティの問題と、AIコーディングツールで迅速に組み立てられるアプリという新たなリスク源を結び付けるものだ。

UpGuardは、露出したデータベースの半数以上で個人情報の兆候を見つけた。影響を受けたレコードには、氏名、住所、電話番号、生年月日、パスワード、認証トークン、私的なメッセージ、ナンバープレート、移民関連情報が含まれていたとされる。

これはSupabaseの内部システムに対する単一の侵害ではない。むしろ証拠は、アクセス制御の欠落または不十分さによって露出した顧客データベースを示している。この違いは重要だが、事態の規模に対する懸念を和らげるものではない。

この報告は、技術的な設定ミスをバイブコーディングモデルの試金石へと変える。AIアシスタントは、動作するインターフェースを生成し、数分でホスト型データベースに接続できる。しかし、すべてのユーザー、テーブル、ロール、操作に正しい認可ポリシーが適用されることを、確実に保証するわけではない。

Supabaseのデータ露出調査で判明したこと

UpGuardの中心的な発見は、特にずさんな1つのアプリではなく、同様のセキュリティミスを繰り返す、独自に構築された何千ものプロジェクトにある。

2026年9月の調査において、UpGuardはSupabaseの利用を示す約30万のユニークドメインを収集した。研究者らはBuiltWithとChrome User Experience Reportのデータを用いて、関連サイトを特定した。

次に、各プロジェクトがusersという名前のテーブルを公開しているかを調べた。この一般的なテーブル名により、各アプリケーションのデータベース設計を事前に把握せずとも、一貫した出発点を得られた。

テストではいくつかの結果が考えられた。安全または非アクティブなデータベースは、アクセス可能なデータを返さない。一部のデータベースは、エラーヒントを通じて別のアクセス可能なテーブルを示した。別のものは、レコードのページを返した。

その候補群の中で、UpGuardは読み取り可能なテーブルを持つデータベース16,326件を特定した。同社の露出調査によると、その半数以上には、何らかの個人識別情報を示唆するスキーマフィールドが含まれていた。

研究者らは、利用可能なすべてのレコードをダウンロードするのではなく、主にテーブルスキーマを分析した。スキーマは列名とデータ型を明らかにするため、テーブルにメールアドレス、パスワード、電話番号、決済情報が含まれる可能性を示せる。

この手法は、個人レコードへの不要なアクセスを抑えた。同時に、16,326件という数値は、すべてのデータベースが機微情報を含んでいたことや、攻撃者が以前に利用可能なデータをコピーしていたことを立証するものではない。

UpGuardは、メタデータが重大な露出を示唆した一部の事例を調査した。その例は、設定ミスが技術的負債の範囲を超え、直接的な個人被害へ至り得ることを示している。

インドの成人向けストリーミングサービスの1つは、65,467人分の情報を含むテーブルを露出させていた。フィールドには、身分証明書、住所、生年月日、金融口座、一部の政府発行識別番号が含まれていたとされる。別のテーブルには、コンテンツクリエイターが関与する10万件超の私的メッセージが保管されていた。

フィリピンのバーチャルSIM事業者は、2,000人超のユーザー情報と10万件超のテキストメッセージを露出させていた。大半のメッセージにはワンタイムパスコードが含まれていたが、サンプルにはライドシェアのドライバーと乗客の通常のやり取りも数千件含まれていた。

米国のバレーサービスは、10万人超の顧客に関するレコードを露出させていた。そのデータベースには、およそ78,000件のナンバープレート番号、約43,000件のメールアドレス、来店履歴、チップ情報、自由記述のメモが含まれていた。

研究者らはまた、25,000件のレコードを含むアフリカの政府領事館のデータベースも発見した。一部のエントリーでは、潜在的に脆弱な集団に属する人々の緊急住居の所在地が特定可能だった。

カナダの移民サービスでは、5,000件近いレコードが露出していた。UpGuardによれば、そのうち884件には平文で保存されたパスワードが含まれており、このアプリケーションはアクセス制御とパスワード処理の両方で失敗していたことになる。

これらの事例は、より広い結論を裏付けるとともに、複数の失敗の層を明らかにしている。公開されたテーブルアクセスが入口を開いたが、脆弱なアプリケーション設計が内容をさらに危険なものにした。

元の報道によれば、影響を受けたデータセットの大半は米国に関連しているように見えた。それでもUpGuardは世界各地で露出したプロジェクトを発見し、この問題をグローバルなものと表現した。

地理的な広がりは重要だ。Supabaseは小規模アプリケーション、新興企業、既存組織に共通のインフラとして利用されている。そのため、同じ設定パターンの繰り返しが、複数の業界や法的管轄にまたがる無関係なユーザーへ影響を及ぼし得る。

なぜデータベースはWebから到達できたのか

Supabaseアプリケーション内の公開キーそのものが、必ずしも脆弱性ではない。決定的なのは、そのキーに何が許可されているかだ。

Supabaseは、認証、ストレージ、自動生成されるデータインターフェースとともに、ホスト型PostgreSQLデータベースを提供している。Webアプリケーションは、publishable keyを使ってData API経由でリクエストを送れる。

開発者は時として、ブラウザのコード内でこのキーを見つければ漏洩を証明するものだと考える。Supabaseは、Webサイトやモバイルアプリケーションを含む公開クライアント向けに、publishable keyを明示的に設計している。

実際の保護は、権限付与と、一般にRLSと略されるRow Level Securityによって実現される。RLSはPostgreSQLの機能であり、個々の行を返却または変更する前に、データベース内部で認可ルールを適用する。

サインインしたユーザーには、そのユーザーの識別子を持つレコードだけを読み取る権限が与えられる場合がある。サインアウトした訪問者には、まったくアクセスを許可しないこともできる。意図的に公開された製品カタログについては、全員に読み取りを許可する別のポリシーも設定できる。

Supabaseのセキュリティドキュメントは、開発者が公開されたテーブルでRLSを有効にし、最小権限の原則に従ってポリシーを設定しなければならないとしている。publishable keyが安全とみなされるのは、これらの制御によってアクセスが適切に制限されている場合に限られる。

同プラットフォームは、信頼されたバックエンドシステム向けにsecret keyやservice-role keyも提供している。これらのキーはRLSをバイパスするため、ブラウザ、配布済みアプリケーション、公開リポジトリに決して含めてはならない。

このアーキテクチャは微妙なセキュリティ境界を生み出す。publishable keyが見えることは想定内だが、同時に、認証されていない訪問者にも、データベースがanonロールにアクセスを許可しているあらゆるものへの経路を与える。

テーブルにRLSがない、過剰な権限が付与されている、あるいはすべての行を許可するポリシーが使われている場合、部外者は正規アプリと同じインターフェースを通じてクエリできる。高度な侵入手法は必要ない。

UpGuardの研究者らは、公開配信されているJavaScriptを調べてSupabaseの識別子を見つけ、対象プロジェクトを発見した。その後、各データベースに対し、一般的なテーブルが公開インターフェース経由で利用可能かを問い合わせられた。

この手法は通常のアプリケーション動作に似ている。違いは、誰がリクエストを送っているか、そしてデータベースが許可されたユーザーとインターネット上の他者を区別できるかにある。

Supabaseの詳細なRLSガイダンスは、公開スキーマ内のテーブルについて、RLSが存在せず、リクエストするロールに適切な権限があれば、読み取りまたは書き込みが可能になると警告している。匿名ロールと認証済みロールの両方について、許可される操作と拒否される操作をテストするよう推奨している。

このため、publishable keyをローテーションするだけでは根本的な問題は解決しない。新しいキーもクライアントから取得可能であり続ける一方、欠陥のあるデータベースポリシーはアクセスを許可し続ける。

開発者は代わりに、公開スキーマ、テーブル権限、RLSの状態、ポリシー条件、データベースビュー、サーバー認証情報を見直さなければならない。また、ユーザーが他者のレコードを読み取ったり変更したりできないことを確認するテストも必要だ。

ビューには特に注意が必要である。PostgreSQLのビューはデフォルトで所有者の権限を通じて権限評価を行うことがあり、基盤となるテーブルを保護する制限をバイパスする可能性がある。したがって、プロジェクトはどこでもRLSを有効にしていても、安全でないビュー経由でデータを開示する恐れがある。

同じ区別は認証にも当てはまる。サインインを要求することだけでは、テナント同士を自動的に分離できない。ポリシーが有効なセッションの存在だけを確認するものであれば、認証済みユーザー全員が広範なアクセスを得る可能性がある。

したがって、キーの観点から見たSupabaseのセキュリティは単純だ。公開クライアントには公開識別子が必要であり、データベースポリシーが実際の境界を強制する。難しいのは、アプリケーションが意図するルールを、完全でテスト済みのポリシーへ落とし込むことにある。

バイブコーディングが設定上の隔たりを繰り返されるパターンへ変える

AIアシスタントが目に見える成果を最適化する一方で、認可が指示を出す人から見えにくいままであるとき、バイブコーディングのセキュリティリスクは高まる。

従来型の開発チームでも、データベースを誤設定することはある。公開されたAmazon S3バケット、露出したElasticsearchクラスター、漏洩したクラウド認証情報は、生成AIがソフトウェア開発に登場するはるか以前から存在した。

バイブコーディングで変わるのは、速度、利用しやすさ、レビュー不足の組み合わせだ。人は自然言語でアプリを依頼し、生成されたコードを受け入れ、ホスト型バックエンドに接続し、信頼境界を理解しないままデプロイできる。

登録が機能し、レコードが正しく保存され、ページが読み込まれるため、アプリケーションは完成しているように見える。これらのテストが確認するのは機能性だ。あるアカウントが別のアカウントのレコードをクエリできないことまでは確認しない。

認可の失敗は、正常系だけを示すデモでは特に見逃しやすい。開発者はサインイン後に期待通りのプロフィールを確認し、システムが保護されていると考える。攻撃者は別の問いを投げかける。リクエストからセッションを省略した場合、あるいはレコード識別子を変えた場合、何が起こるのか。

AIコーディングエージェントは、プログラムからインフラともやり取りする。UpGuardは、Supabaseではダッシュボードの一部から作成されたテーブルではRLSがデフォルトで有効になる一方、プログラムから作成されたテーブルには追加の注意が必要だと指摘した。

エージェントがSQLやAPIを通じてデータベーススキーマを作成する場合、この違いは重大になり得る。ある作成ワークフローに付随する保護設定が、プラットフォームへ至るすべての経路を自動的にカバーするわけではない。

Supabaseは、このより広範な使いやすさの課題を2025年のセキュリティレビューで認めている。同社は、RLSは柔軟である一方、このパターンに不慣れな開発者にとっては複雑になり得ると述べた。

2025年中に、Supabaseはより安全なデフォルト設定を追加し、Security Advisorを拡充した。また、Data APIに対するプロジェクトの制御を強化し、無効化する選択肢や、デフォルトのpublicスキーマではなくカスタムスキーマを公開する選択肢を提供した。

これらの変更は役立つが、既存プロジェクトを消し去ったり、生成済みのすべてのマイグレーションを修正したりするものではない。セキュリティツールは一般的なエラーを検出できるが、基本的なチェックを通過していても、ポリシーが論理的に誤っている可能性は残る。

生成されたルールは、誤った識別子を比較したり、更新経路を見落としたり、読み取りを保護する一方で未認可の書き込みを許可したりする可能性がある。1つのテーブルでは機能しても、関連テーブルを公開したままにすることもある。

人間の監督者が、その欠けている挙動の存在を認識していなければならない。RLS、ロール権限付与、テナント分離を知らない初心者は、モデルにそれらのテストを求めることすらないかもしれない。

これは、構築と監査の間に非対称性を生む。機能の生成には1つのプロンプトで足りる。しかし、その機能があらゆるアイデンティティと操作を安全に処理することを証明するには、脅威モデル、ネガティブテスト、そして生成された成果物の慎重な検証が必要となる。

先行研究は、これが孤立した調査結果ではなく、繰り返し見られるパターンであることを示唆している。UpGuardは、Y Combinator企業、AI開発プラットフォームで作られたアプリ、独立系サイトを対象とする研究を引用した。

Modern Pentestは、調査したY Combinatorスタートアップ107社のうち28％が、Supabaseの設定を通じて個人情報を公開していたと報告した。別の研究では、バイブコーディングで作られたアプリ1,072件を調査し、39件で公開Supabaseキーを通じてテーブルを読み取れることが判明した。

サンプルと手法は異なるため、これらの割合を合算すべきではない。しかし、いずれの調査でも同じ種類の失敗が見つかった。すなわち、クライアントから見える接続情報と、アプリケーションの意図より広範なデータベース権限の組み合わせだ。

2026年2月のある事案は、その影響をとりわけ明確に示した。セキュリティ企業Wizは、AIエージェント向けプラットフォームとして紹介されていたソーシャルネットワークMoltbookで、Supabaseバックエンドの設定不備を発見した。

Moltbook investigationによると、このデータベースではプラットフォームデータへの読み取りおよび書き込みアクセスが許可されていた。露出した情報には、35,000件のメールアドレスと150万件のAPI認証トークンが含まれていた。

Wizは、非侵襲的な評価の際にクライアント側JavaScriptを確認して問題を見つけたと述べた。Moltbookチームは、報告を受けてから数時間以内にデータベースを保護した。

この事例は、現在のトレードオフを端的に示している。AI支援は注目を素早く集めるサービスの構築に役立った一方、アプリケーションの目に見える成功は、重大なデータベース制御の失敗を覆い隠していた。

AIで構築されたソフトウェアを評価する組織にとって、これは動作するプロトタイプの意味を変える。AIは、誰かがその下層にあるセキュリティモデルを検証する前に、目に見えるワークフローを完成させられるため、デモンストレーションが本番運用への準備度を示す度合いは以前より小さくなった。

社内のengineering knowledge baseは、チームがアーキテクチャ上の意思決定とレビューの証拠を保持する助けになる。データベーステストの代わりにはならないが、セキュリティ上の前提がプロンプトや引き継ぎの過程で失われるのを防げる。

「デフォルトで安全」と共有責任の衝突

主な対立点は、安全なプラットフォームのデフォルト設定と、経験の浅い顧客にも重大な設定を委ねる共有責任モデルの間にある。

Supabaseの最高情報セキュリティ責任者であるBil Harmer氏はTechCrunchに対し、同社はコメント前にUpGuardの調査を確認していなかったと語った。Supabaseプロジェクトはデフォルトで安全であり、セキュリティは共有責任だと説明した。

この立場は、標準的なクラウドモデルを反映している。プロバイダーはホストされたプラットフォームを保護し、アクセス制御を提供する。どのユーザーやアプリケーションがデータに到達できるかは、顧客が決定する。

この区別は妥当だ。UpGuardは、Supabaseの企業システムを侵害したり、正しく構成されたRLSポリシーを回避したりしたとは報告していない。公開されたデータベースは、より広いアクセスを許す設定を行った顧客のものだった。

ただし、デフォルト設定をプロジェクト作成時だけで評価することはできない。人やコーディングエージェントがテーブルを作成し、APIを公開し、サンプルをコピーし、アプリケーションをデプロイするために使う実際の経路も含まれる。

システムは安全に始まっても、エージェント生成のマイグレーションを通じて後から露出する可能性がある。また、安全なダッシュボード操作を提供していても、プログラム経由のワークフローが異なるセキュリティ状態を作り出すこともある。

したがって、「デフォルトで安全」という表現には明確な境界が必要だ。新規プロジェクトが何も公開しないことを意味するのか。サポートされるすべてのテーブル作成経路を対象とするのか。RLSなしのテーブルに本番データが入る前に、ユーザーへ警告するのか。

共有責任はまた、各当事者が自らの役割を理解していることを前提とする。経験豊富なクラウドエンジニアは、公開クライアント識別子をサーバー側の認可と組み合わせなければならないことを知っている。多くのバイブコーダーはそうではない。

この知識のギャップが、顧客のミスに対する責任をプラットフォームだけに負わせるものではない。しかし、SupabaseとAIコーディングプロバイダーに対し、安全でない状態を作りにくく、検出しやすくするよう求める圧力を高める。

プラットフォームはすでにその方向へ進んでいる。SupabaseのSecurity Advisorは一般的なデータベース問題をチェックし、本番運用チェックリストでは、関連するすべてのテーブルでRLSを有効化し、ポリシーを確認するようユーザーに指示している。

より厳格な設計では、保護されていないテーブルへの本番アクセスをブロックしたり、明示的なオーバーライドを求めたりすることが考えられる。こうした対策は偶発的な露出を減らす一方、正当な公開データセットや迅速な開発を妨げる可能性もある。

Supabaseは、すべての公開テーブルを脆弱性として扱うことなく、そうしたケースの均衡を取らなければならない。レストランのメニュー、公開リーダーボード、公開ディレクトリでは、匿名での読み取りを許可することに合理性がある。

プラットフォームは、テーブル名だけから意図を推測できない。usersテーブルはproductsテーブルより疑わしいが、アプリケーションがメールアドレスを非公開にしつつ、ユーザープロフィールを意図的に公開する場合もある。

自動化ツールも同じ曖昧さに直面する。匿名ロールがテーブルを読み取れることは検出できる。しかし、そのアクセスが製品の約束に反するかを判断するには、ビジネス上の文脈が必要となる。

これが本質的なトレードオフだ。柔軟なデータベースポリシーは開発者に多様なアプリケーションの構築を可能にするが、その柔軟性は見えないミスの余地も生む。意見の強い制限はミスを防ぐ一方で、正当な設計を制約する。

AIアシスタントは、さらにもう1つの責任主体を加える。開発者はエージェントの推奨を受けてSupabaseを選び、そのエージェントにスキーマやポリシーの生成を頼る可能性がある。

モデルプロバイダーはデータベースをホストせず、Supabaseも生成されるすべてのコマンドを制御しない。最終的な認可モデルを説明できない場合でも、アプリの所有者はユーザーに対して責任を負う。

この分断された連鎖により、セキュリティ障害は責任の所在を定めにくく、繰り返されやすくなる。各参加者はドキュメントや他者の設定を指摘できる一方、影響を受けた人には、私的情報が公開されたという結果しか見えない。

エンタープライズの購入担当者にとって、実践的な対応は開発システム全体を評価することだ。ベンダー認証は重要だが、デプロイ制御、コードレビュー、データベーステスト、ログ、インシデント対応、AIエージェントを監督する人々の経験も同様に重要である。

数字が示すことと、示さないこと

この調査は大きな露出面を示しているが、その手法は16,326件の確認済み侵害を立証するものでも、Supabaseの顧客基盤全体を測定するものでもない。

UpGuardは、プラットフォーム上のすべてのアプリケーションから無作為に抽出したのではなく、Supabaseの利用を示す指標があるドメインから調査を始めた。その情報源は、Webテクノロジーのデータセットを通じて可視化されるサイトに偏っていた。

研究者たちは続いて、usersという名前のテーブルを照会した。多くのアプリケーションがユーザーレコードを保持しているため、この選択は合理的だったが、個人情報を含む可能性が高いデータベースへ調査を偏らせる結果にもなった。

UpGuardはこの制約を開示している。同社は、人に関連する一般的なテーブルを意図的に選んだこともあり、結果がPIIに偏っていると述べた。

16,326件という合計は、読み取り可能なテーブルを公開しているデータベースを対象としている。すべてのテーブルに機密レコードが含まれていたことを意味するものではない。一部のプロジェクトは、意図的にデータを公開していたり、合成情報を使っていたり、放棄されていたりする可能性がある。

スキーマ分析は、行ごとのフォレンジック調査とは異なる形で潜在的な露出を測定する。passwordという列名は深刻な警告だが、それだけで有効な認証情報が保存されていたことを証明するわけではない。

研究者たちは一部の事例を手作業で検証し、それらのデータベースから具体的なレコード数を報告した。これらの例は、少なくとも一部の露出が、意味のある規模の実在する機微データを含んでいたことを示している。

この調査では、開示前にどれだけの第三者がデータベースへアクセスしたかも特定できない。公開状態はリスクを生むが、犯罪者が情報を発見またはダウンロードした証拠ではない。

この違いは、データ露出と確認済みデータ侵害を分ける。露出とは、権限のないアクセスが可能だったことを意味する。侵害には一般に、権限のない当事者が実際にデータへアクセスまたは取得したという証拠が必要だ。

組織はこの区別を使って事案を過小評価すべきではない。機微なレコードが適切な認可なしに到達可能になれば、調査担当者には誰がアクセスしたかを証明するための十分なログがない可能性がある。

この調査はまた、すべてのSupabaseプロジェクトにおける露出率を算出しているわけでもない。UpGuardは約30万の候補ドメインを分析したが、1つの組織が複数のドメインやプロジェクトを運用することもある。

非アクティブなサイトや誤った技術指標は、その分母を複雑にし得る。最終的な数字は、Supabase顧客の割合ではなく、発見された集団として理解するのが最適だ。

こうした留保を踏まえても、読み取り可能なデータベース16,326件は相当な攻撃対象領域を表す。悪意ある攻撃者は、同じような発見プロセスを自動化し、価値の高いフィールドを含むテーブルを優先できる。

詳細な事例は、これらが無害なデモプロジェクトだったという主張も弱めている。移民記録、緊急住宅の所在地、私的な成人間コミュニケーション、ナンバープレート、ワンタイムパスコードには、明確なプライバシーと安全性への影響がある。

Supabaseの対応も同じ精度で扱うべきだ。同社は、セキュリティ問題を把握した際には影響を受けた顧客に通知すると述べた。しかし、何件のプロジェクトに通知したのか、どれほど迅速に対応したのか、どれだけの露出が未解決のままだったのかは確認されていない。

UpGuardは、検証した重大な事例についてアプリケーション所有者に通知したと述べた。同社の公開レポートは、16,326件すべてのデータベースについて完全な修正率を示していない。

こうした空白は、調査結果の報道に反映されるべきだ。証拠は、広範な設定上の問題と複数の深刻な露出を裏付けている。しかし、Supabase自体がハッキングされた、あるいは特定されたすべてのデータベースが機微なレコードを漏えいしたと主張する根拠にはならない。

また、重要な比較上の疑問も未解決のままだ。同等のインターネット規模の手法を適用すれば、同様のホスト型データベースでも似た問題が確認される可能性がある。

Firebase、Appwrite、自己管理型PostgreSQLデプロイメント、その他のバックエンドサービスは、異なるインターフェースを公開し、異なる権限モデルを採用している。開発者はそれらのいずれも設定ミスを起こし得る。

Supabaseが注目を集めるのは、クライアントフレンドリーなアーキテクチャ、自動API、AIコーディングワークフローでの人気により、この問題が可視化されやすいためだ。人気の高まりは、安全なデプロイメントの数とミスの数の双方を増やす。

したがって、公平な評価では、Supabaseがデータを保護できない唯一の存在だという描き方を避けるべきだ。より強い結論は、経験の浅いビルダーの間で採用が広がっていることにより、アクセス制御の使いやすさがプラットフォームレベルの懸念になっている、というものだ。

リスクが縮小しているかを示す3つのシグナル

次の段階は、包括的なセキュリティの約束ではなく、測定可能な製品変更、修正の証拠、独立した再検証によって評価されるべきだ。

第1のシグナルは、Supabaseがプログラム経由で作成されたテーブルをどう扱うかだ。コーディングエージェントは、手動でのダッシュボード操作ではなく、SQL、管理インターフェース、自動化されたマイグレーションを通じて作業することが多い。

意味のある変更は、作成経路を問わずRLSと制限的な権限付与を一貫させるか、テーブルがData API経由で到達可能になる前に明示的な判断を求めるものとなる。エージェントのワークフロー内で明確な警告を表示すれば、その保護はさらに強化される。

Supabaseがダッシュボード経由の作成とプログラムによる作成の隔たりを埋められれば、より安全なデフォルト設定によってvibe codingに伴うセキュリティリスクを低減できるという見方が強まるだろう。ワークフローに差が残る場合、経験の浅い開発者は危険な状態にあることを認識しないまま、その状態に入り続けることになる。

2つ目のシグナルは、是正に関するデータだ。SupabaseとUpGuardは、特定されたプロジェクトのうち何件に通知が送られ、何人の所有者が対応し、何件のデータベースで意図しないレコード公開が停止されたかを明らかにできる。

是正率が高ければ、通知とセキュリティツールによって既存の対応残件を減らせることを示す。一方で低率なら、多くのプロジェクトが放棄されている、保守が不十分である、あるいは設定を修正できない人々によって運用されている可能性を示唆する。

影響を受けた組織は、公開されたレコードについてユーザーへの通知や規制当局への報告が必要かどうかも判断しなければならない。この判断は、所在地、データの種類、アクセスの証拠、適用される法律に左右される。

3つ目のシグナルは、今後数カ月にわたる独立した再テストだ。研究者は比較可能なスキャンを繰り返し、意図的に公開されたデータと機微な情報の露出を区別する透明性の高い手法を公表すべきである。

データベース数の減少は、Supabaseの安全なデフォルト設定戦略を裏付けるだろう。横ばいまたは増加であれば、プラットフォームの成長とAI支援開発が、既存の統制で修正できる速度を上回って安全でないプロジェクトを生み出していることを示す。

その再テストでは、AIコーディング提供者も精査に値する。各社のエージェントは、最小権限のポリシーを作成し、認可が拒否されるケースのテストを生成し、デプロイメントが個人情報を公開する場合に警告すべきだ。

開発者が責任ある対応をするために、SupabaseやAIコーディングを断念する必要はない。生成されたソフトウェアは、その認可動作がテストされるまで信頼できないものとして扱う必要がある。

具体的には、匿名アクセスと認証済みアクセスを分けて確認し、すべてのデータベース操作をテストし、ビューをレビューし、サーバーキーを保護し、アプリケーションに不要なインターフェースを無効化することを意味する。

チームは、こうした統制の背景にある決定も残しておくべきだ。検索可能なAIナレッジベースは、ドキュメントを後回しにすることなく、要件、生成されたマイグレーション、監査結果、是正作業を結び付けられる。

Supabaseのデータ露出をめぐる問題は、突き詰めれば説明責任のギャップに関するものだ。プラットフォームは設定可能な統制を提供し、AIエージェントはアプリケーションを組み立て、ユーザーは完成したインターフェースを信頼する。

実際の情報がシステムに入力される前に、目に見えない権限を誰が検証するのか。AI生成アプリをリリースする組織は、テスト結果、責任者の明示、アクセス拒否の証拠によって、この問いに答えられるべきである。