Supabase User MCP

Geben Sie jedem Menschen und Agenten seine eigene Datenbankidentitätsgrenze.

Supabase User MCP ist ein unabhängiger, sicherheitsorientierter Datenebenen-MCP-Server für Anwendungen, die auf Supabase basieren. Er ist darauf ausgelegt, KI-Clients zu ermöglichen, mit Anwendungsdaten als bestimmter Benutzer oder Agent zu arbeiten, während PostgreSQL Row Level Security (RLS) die endgültige Autorisierungsinstanz bleibt.

[!WARNING] Dieses Repository befindet sich in aktiver M0-Entwicklung. Es enthält nur eine null-autoritäre Protokollsonde—keinen einsatzbereiten Benutzerdatenserver—und darf nicht mit Produktionsdaten verbunden werden.

Warum es das gibt

Supabases gehosteter MCP-Server ist ein Entwickler-Kontrollebenen-Tool. Es verwaltet Projekte, Schemas, Migrationen, Funktionen und Betriebsressourcen unter der Autorität eines Entwicklers. Supabase empfiehlt ausdrücklich, diesen Server für Entwicklung und Tests zu verwenden, anstatt ihn Kunden oder Produktionsdaten auszusetzen.

Supabase User MCP untersucht das komplementäre Datenebenen-Problem:

Das Ziel ist nicht, Prompt-Injection unmöglich zu machen. Das Ziel ist sicherzustellen, dass ein kompromittiertes Modell die Autorität der Identität und Fähigkeit, die ihm gegeben wurde, nicht überschreiten kann.

Related MCP server: MCP Warehouse Server

Sicherheitsthese

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

Das Projekt folgt sechs nicht verhandelbaren Prinzipien:

1. Kein Master-Schlüssel im MCP-Anforderungspfad. Ein öffentlicher Tool-Handler darf niemals einen service_role- oder geheimen Schlüssel verwenden, um Benutzeraktionen durchzuführen.

2. Die Datenbank trifft die endgültige Entscheidung. Anwendungsprüfungen verbessern die Benutzerfreundlichkeit; RLS und Datenbankbeschränkungen erzwingen die Autorisierung.

3. Tools sind Fähigkeiten, keine generische REST-Konsole. Der anfängliche Server wird keine beliebigen SQL, Tabellen, Schemas, RPC-Namen, URLs oder HTTP-Methoden offenlegen.

4. Lese- und Schreibvorgänge sind unterschiedliche Autoritäten. Kanonische oder irreversible Änderungen verwenden einen datenbankgestützten Vorschlags- und Genehmigungsworkflow.

5. Nicht vertrauenswürdiger Inhalt bleibt Daten. Tool-Ergebnisse sind begrenzt und als nicht vertrauenswürdig markiert; Prompt-Injection wird als Containment-Problem getestet.

6. Behauptungen erfordern Beweise. Ein Meilenstein ist erst abgeschlossen, wenn seine positiven, negativen, identitätsübergreifenden und adversariellen Tests bestanden sind.

Geplante Produktfläche

Die erste nützliche Veröffentlichung ist bewusst schmal:

• memory_search — begrenzte Volltext- oder semantische Suche über autorisierte Datensätze

• memory_get — einen autorisierten Speicherdatensatz anhand einer undurchsichtigen Kennung abrufen

• memory_list_recent — autorisierte aktuelle Datensätze mit einer harten Seitenbegrenzung auflisten

• memory_append_observation — nicht-kanonische Informationen idempotent anhängen

• memory_propose_change — eine kanonische Mutation zur menschlichen Überprüfung bereitstellen

• memory_get_proposal — Genehmigungsstatus überprüfen, ohne die Änderung anzuwenden

Die Namen beschreiben die Referenzimplementierung des souveränen Speichers. Adapter können später dasselbe Fähigkeitsmodell auf andere Supabase-Anwendungsschemata übertragen. Siehe den vollständigen Funktionskatalog.

Aktuelle Phase

Das Projekt befindet sich in M0: Protokoll- und Richtliniengrundlage. Bevor Servercode als tragfähig betrachtet wird, muss M0 zwei Identitätsfragen lösen:

• Wie ein entfernter HTTP-MCP-Server einen nachgelagerten Supabase-Token erhält, ohne die MCP-Audience-Binding- und Token-Transit-Anforderungen zu verletzen.

• Wie dauerhafte nicht-menschliche Prinzipale bereitgestellt und widerrufen werden, da Supabeses OAuth-Server derzeit Autorisierungscode- und Refresh-Token-Grants dokumentiert, anstatt eines client_credentials-Grants.

Dies sind Architekturtore, keine Implementierungsdetails. Der lokale stdio-Nachweis und der entfernte HTTP-Dienst werden als separate Bereitstellungsprofile verfolgt, bis die entfernte Identitätskette Ende-zu-Ende demonstriert ist.

Der ausführbare M0-Spike beweist nun einen strikten TypeScript-Workspace, MCP 2026-07-28 stdio-Negotiation, strukturierte Eingabe-/Ausgabevalidierung und ein bewusst nicht-autoritäres Tool. Es hat keinen Supabase-Client, keine Anmeldeinformationen, keinen Netzwerkzugriff und keine Datenoperationen. Siehe den Kompatibilitätsnachweis.

Versuchen Sie die M0-Kompatibilitätssonde

Voraussetzungen: Node.js 22.20.0 und npm 11.19.0.

npm ci
npm run check
npm run build
npm start

npm start startet einen JSON-RPC stdio-Server für einen MCP 2026-07-28-Client; es ist keine interaktive Terminalanwendung. Das einzige bereitgestellte Tool ist system_compatibility_probe, das keine Netzwerk- oder Datenoperation ausführt. Genaue Versionen und Überprüfungsbefehle sind im Entwicklungsleitfaden dokumentiert.

Fahrplan

Jeder Meilenstein hat Liefergegenstände, Abhängigkeiten, Ausschlüsse und messbare Austrittskriterien im Entwicklungsfahrplan.

Dokumentation

• Produktdefinition — Benutzer, Aufgaben, Grenzen und Erfolgsmaßstäbe

• Architektur — Komponenten, Vertrauensgrenzen und Bereitstellungsprofile

• Funktionskatalog — vorgeschlagene Tools und Plattformfähigkeiten

• Sicherheitsmodell — Identitäten, Fähigkeiten, RLS und Genehmigungen

• Bedrohungsmodell — Vermögenswerte, Angreifer, Missbrauchsfälle und Minderungen

• Fahrplan — Implementierungsreihenfolge und Freigabeschwellen

• Entwicklungsleitfaden — festgelegter Stack, Layout und technische Standards

• M0-Kompatibilitätsnachweis — festgelegte Versionen und Protokollnachweis

• Architekturentscheidungen — folgenreiche Entscheidungen und offene Tore

Mitwirken

Die wertvollsten Beiträge heute sind adversarielle Überprüfungen, Stand der Technik, Richtlinientestfälle und kleine Dokumentationskorrekturen. Bitte lesen Sie CONTRIBUTING.md und GOVERNANCE.md, bevor Sie einen Pull-Request öffnen. Sicherheitsmeldungen gehören in den privaten Prozess, der in SECURITY.md beschrieben ist, nicht in ein öffentliches Issue.

Projektstatus und Unabhängigkeit

Supabase User MCP ist ein unabhängiges Open-Source-Projekt. Es ist kein offizielles Supabase-Produkt und wird nicht von Supabase, Inc. unterstützt. „Supabase“ wird verwendet, um die Kompatibilität mit der Supabase-Plattform zu kennzeichnen.

Lizenziert unter der Apache License 2.0.