Supabase User MCP

Dale a cada humano y agente su propio límite de identidad de base de datos.

Supabase User MCP es un servidor MCP de plano de datos independiente y centrado en la seguridad para aplicaciones construidas sobre Supabase. Está diseñado para permitir que los clientes de IA trabajen con datos de aplicación como un usuario o agente específico, mientras que la Seguridad a Nivel de Fila (RLS) de PostgreSQL sigue siendo la autoridad final de autorización.

[!WARNING] Este repositorio está en desarrollo activo M0. Contiene solo una sonda de protocolo sin autoridad, no un servidor de datos de usuario desplegable, y no debe conectarse a datos de producción.

Por qué existe esto

El servidor MCP alojado de Supabase es una herramienta de plano de control para desarrolladores. Gestiona proyectos, esquemas, migraciones, funciones y recursos operativos bajo la autoridad de un desarrollador. Supabase recomienda explícitamente usar ese servidor para desarrollo y pruebas, en lugar de exponerlo a clientes o datos de producción.

Supabase User MCP explora el problema complementario del plano de datos:

El objetivo no es hacer imposible la inyección de prompts. El objetivo es garantizar que un modelo comprometido no pueda exceder la autoridad de la identidad y la capacidad que se le otorgó.

Related MCP server: agent-sudo-mcp

Tesis de seguridad

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

El proyecto sigue seis principios innegociables:

1. Sin clave maestra en la ruta de solicitud MCP. Un manejador de herramienta público nunca debe usar una clave service_role o secreta para realizar acciones de usuario.

2. La base de datos toma la decisión final. Las comprobaciones de la aplicación mejoran la usabilidad; RLS y las restricciones de la base de datos hacen cumplir la autorización.

3. Las herramientas son capacidades, no una consola REST genérica. El servidor inicial no expondrá SQL arbitrario, tablas, esquemas, nombres de RPC, URLs o métodos HTTP.

4. Las lecturas y escrituras son autoridades diferentes. Los cambios canónicos o irreversibles utilizan un flujo de trabajo de propuesta y aprobación impuesto por la base de datos.

5. El contenido no confiable sigue siendo datos. Los resultados de las herramientas están limitados y marcados como no confiables; la inyección de prompts se prueba como un problema de contención.

6. Las afirmaciones requieren evidencia. Un hito está completo solo cuando pasan sus pruebas positivas, negativas, de identidad cruzada y adversariales.

Superficie de producto planificada

La primera versión útil es deliberadamente limitada:

• memory_search — búsqueda de texto completo o semántica limitada sobre registros autorizados

• memory_get — recuperar un registro de memoria autorizado por identificador opaco

• memory_list_recent — listar registros recientes autorizados con un límite de página estricto

• memory_append_observation — agregar información no canónica de forma idempotente

• memory_propose_change — preparar una mutación canónica para revisión humana

• memory_get_proposal — inspeccionar el estado de aprobación sin aplicar el cambio

Los nombres describen la implementación de referencia de memoria soberana. Los adaptadores pueden mapear más tarde el mismo modelo de capacidades a otros esquemas de aplicación de Supabase. Consulta el catálogo de características completo.

Fase actual

El proyecto está en M0: fundamento de protocolo y política. Antes de que el código del servidor se considere viable, M0 debe resolver dos cuestiones de identidad:

• Cómo un servidor MCP HTTP remoto obtiene un token de Supabase aguas abajo sin violar los requisitos de vinculación de audiencia y tránsito de tokens de MCP.

• Cómo se aprovisionan y revocan los principales no humanos duraderos, dado que el servidor OAuth de Supabase documenta actualmente concesiones de código de autorización y token de actualización en lugar de una concesión client_credentials.

Estas son puertas de arquitectura, no detalles de implementación. La prueba local de stdio y el servicio HTTP remoto se rastrean como perfiles de despliegue separados hasta que la cadena de identidad remota se demuestre de extremo a extremo.

El spike ejecutable de M0 ahora prueba un espacio de trabajo TypeScript estricto, negociación stdio MCP 2026-07-28, validación estructurada de entrada/salida y una herramienta deliberadamente no autoritativa. No tiene cliente de Supabase, credenciales, acceso a red ni operaciones de datos. Consulta la evidencia de compatibilidad.

Prueba la sonda de compatibilidad M0

Requisitos previos: Node.js 22.20.0 y npm 11.19.0.

npm ci
npm run check
npm run build
npm start

npm start lanza un servidor stdio JSON-RPC para un cliente MCP 2026-07-28; no es una aplicación de terminal interactiva. La única herramienta expuesta es system_compatibility_probe, que no realiza ninguna operación de red o datos. Las versiones exactas y los comandos de verificación están documentados en la guía de desarrollo.

Hoja de ruta

Cada hito tiene entregables, dependencias, exclusiones y criterios de salida medibles en la hoja de ruta de desarrollo.

Documentación

• Definición de producto — usuarios, trabajos, límites y medidas de éxito

• Arquitectura — componentes, límites de confianza y perfiles de despliegue

• Catálogo de características — herramientas propuestas y capacidades de plataforma

• Modelo de seguridad — identidades, capacidades, RLS y aprobaciones

• Modelo de amenazas — activos, atacantes, casos de abuso y mitigaciones

• Hoja de ruta — secuencia de implementación y puertas de lanzamiento

• Guía de desarrollo — pila fija, diseño y estándares de ingeniería

• Evidencia de compatibilidad M0 — versiones fijas y prueba de protocolo

• Decisiones de arquitectura — decisiones consecuentes y puertas abiertas

Contribuciones

Las contribuciones de mayor valor hoy son revisiones adversariales, trabajo previo, casos de prueba de políticas y pequeñas correcciones de documentación. Por favor, lee CONTRIBUTING.md y GOVERNANCE.md antes de abrir una solicitud de extracción. Los informes de seguridad pertenecen al proceso privado descrito en SECURITY.md, no en un problema público.

Estado del proyecto e independencia

Supabase User MCP es un proyecto de código abierto independiente. No es un producto oficial de Supabase y no está respaldado por Supabase, Inc. "Supabase" se utiliza para identificar la compatibilidad con la plataforma Supabase.

Licenciado bajo la Licencia Apache 2.0.