Supabase User MCP

すべての人間とエージェントに、独自のデータベースID境界を与える。

Supabase User MCP は、Supabase 上に構築されたアプリケーション向けの、セキュリティ優先の独立したデータプレーン MCP サーバーです。AI クライアントが特定のユーザーまたはエージェントとしてアプリケーションデータを扱えるように設計されており、PostgreSQL の行レベルセキュリティ（RLS）が最終的な認可権限として機能し続けます。

[!WARNING] このリポジトリは活発な M0 開発中です。デプロイ可能なユーザーデータサーバーではなく、権限を持たないプロトコルプローブのみを含んでおり、本番データに接続してはなりません。

なぜこれが存在するのか

Supabase のホスト型 MCP サーバーは、開発者向けのコントロールプレーンツールです。プロジェクト、スキーマ、マイグレーション、関数、および運用リソースを開発者の権限で管理します。Supabase は、このサーバーを顧客や本番データに公開するのではなく、開発とテストに使用することを明示的に推奨しています。

Supabase User MCP は、補完的なデータプレーンの問題を探求します。

目標は、プロンプトインジェクションを不可能にすることではありません。目標は、侵害されたモデルが、与えられたIDとケイパビリティの権限を超えることができないようにすることです。

Related MCP server: MCP Warehouse Server

セキュリティテーゼ

MCP client
    │ authenticated request
    ▼
Supabase User MCP
    ├── validates identity and request context
    ├── exposes a small, allowlisted tool surface
    ├── enforces limits, approval states, and audit metadata
    ▼
Supabase Data API / PostgREST
    ▼
PostgreSQL + RLS
    ├── caller and OAuth-client policy
    ├── tenant and capability policy
    └── row and operation policy

このプロジェクトは、6つの譲れない原則に従います。

1. MCP リクエストパスにマスターキーは不要。 パブリックツールハンドラーは、ユーザーアクションを実行するために service_role やシークレットキーを決して使用してはなりません。

2. データベースが最終決定を行う。 アプリケーションチェックはユーザビリティを向上させます。RLS とデータベース制約が認可を強制します。

3. ツールはケイパビリティであり、汎用的な REST コンソールではない。 初期のサーバーは、任意の SQL、テーブル、スキーマ、RPC 名、URL、または HTTP メソッドを公開しません。

4. 読み取りと書き込みは異なる権限である。 正規の変更または不可逆的な変更は、データベースで強制される提案と承認のワークフローを使用します。

5. 信頼されていないコンテンツはデータとして扱う。 ツールの結果は制限され、信頼されていないものとしてマークされます。プロンプトインジェクションは封じ込め問題としてテストされます。

6. 主張には証拠が必要。 マイルストーンは、その肯定的、否定的、クロスID、および敵対的テストがすべて合格した場合にのみ完了とみなされます。

計画されているプロダクトサーフェス

最初の実用的なリリースは、意図的に範囲を狭めています。

• memory_search — 認可されたレコードに対する制限付き全文検索またはセマンティック検索

• memory_get — 不透明な識別子によって認可された1つのメモリレコードを取得

• memory_list_recent — ハードなページ制限付きで認可された最近のレコードを一覧表示

• memory_append_observation — 非正規の情報を冪等に追加

• memory_propose_change — 人間のレビューのために正規の変更をステージング

• memory_get_proposal — 変更を適用せずに承認ステータスを検査

これらの名前は、参照となる sovereign-memory 実装を説明しています。アダプターは、後で同じケイパビリティモデルを他の Supabase アプリケーションスキーマにマッピングする可能性があります。完全な機能カタログを参照してください。

現在のフェーズ

プロジェクトは M0: プロトコルとポリシーの基盤 にあります。サーバーコードが実行可能と見なされる前に、M0 は2つのIDに関する問題を解決する必要があります。

• リモート HTTP MCP サーバーが、MCP のオーディエンスバインディングとトークン転送要件に違反せずに、ダウンストリームの Supabase トークンを取得する方法。

• Supabase の OAuth サーバーが現在、client_credentials グラントではなく、認可コードとリフレッシュトークンのグラントを文書化していることを考慮して、永続的な非人間プリンシパルがどのようにプロビジョニングおよび失効されるか。

これらは実装の詳細ではなく、アーキテクチャゲートです。ローカルの stdio プルーフとリモート HTTP サービスは、リモート ID チェーンがエンドツーエンドで実証されるまで、個別のデプロイメントプロファイルとして追跡されます。

現在の実行可能な M0 スパイクは、厳格な TypeScript ワークスペース、MCP 2026-07-28 stdio ネゴシエーション、構造化された入出力検証、および意図的に非権限的なツールを証明します。Supabase クライアント、認証情報、ネットワークアクセス、またはデータ操作はありません。互換性の証拠を参照してください。

M0 互換性プローブを試す

前提条件: Node.js 22.20.0 および npm 11.19.0。

npm ci
npm run check
npm run build
npm start

npm start は、MCP 2026-07-28 クライアント用の JSON-RPC stdio サーバーを起動します。これは対話型ターミナルアプリケーションではありません。公開されている唯一のツールは system_compatibility_probe で、ネットワーク操作やデータ操作は実行しません。正確なバージョンと検証コマンドは、開発ガイドに文書化されています。

ロードマップ

各マイルストーンには、成果物、依存関係、除外事項、および測定可能な出口基準が開発ロードマップにあります。

ドキュメント

• プロダクト定義 — ユーザー、ジョブ、境界、成功の尺度

• アーキテクチャ — コンポーネント、信頼境界、デプロイメントプロファイル

• 機能カタログ — 提案されたツールとプラットフォーム機能

• セキュリティモデル — ID、ケイパビリティ、RLS、承認

• 脅威モデル — 資産、攻撃者、悪用ケース、緩和策

• ロードマップ — 実装順序とリリースゲート

• 開発ガイド — 固定スタック、レイアウト、エンジニアリング標準

• M0 互換性の証拠 — 固定バージョンとプロトコルプルーフ

• アーキテクチャ決定 — 重要な決定と未解決のゲート

コントリビューション

現在、最も価値の高いコントリビューションは、敵対的レビュー、先行技術、ポリシーテストケース、および小さなドキュメント修正です。プルリクエストを開く前に、CONTRIBUTING.md と GOVERNANCE.md をお読みください。セキュリティレポートは、SECURITY.md に記載されている非公開プロセスに属し、公開イシューには属しません。

プロジェクトステータスと独立性

Supabase User MCP は独立したオープンソースプロジェクトです。これは Supabase の公式製品ではなく、Supabase, Inc. によって推奨されるものでもありません。「Supabase」は、Supabase プラットフォームとの互換性を識別するために使用されています。

Apache License 2.0 の下でライセンスされています。