Supabase: tokens acotados por defecto para agentes IA

¿Qué cambió en los Personal Access Tokens de Supabase?

Hasta hace poco, un Personal Access Token de Supabase podía hacer todo lo que puedes hacer tú en tu cuenta: entrar a cada organización y a cada proyecto al que perteneces. Le entregabas uno a tu pipeline de CI y ese pipeline tenía las mismas llaves que tu cuenta completa, aunque solo necesitara leer un esquema.

Eso cambió. Desde el 28 de septiembre los tokens se pueden acotar para que hagan solo lo que la herramienta necesita, y Supabase lo presentó en su evento Select el 2 de octubre. El dato que mejor mide la adopción: casi nueve de cada diez tokens creados en el Dashboard desde el lanzamiento ya tienen permisos acotados. El resto son tokens de acceso total, que siguen disponibles para quien los necesite.

La lógica aplica a cualquier equipo: tu pipeline de CI, tus scripts de despliegue y tus agentes de IA hacen trabajos distintos. Un agente de código que solo necesita inspeccionar tablas y generar tipos no debería poder escribir en tu base de datos ni tocar otro proyecto. Un script de deploy recibe su propio token, con los permisos de escritura que su flujo sí requiere.

Cómo crear un token acotado para un agente de IA

El Dashboard plantea el proceso en cuatro decisiones y la propia interfaz recomienda no tomar atajos:

1. Elige los recursos. Puedes dar acceso a varias organizaciones, pero la recomendación es el alcance a nivel de proyecto. Si el agente trabaja en una sola aplicación, selecciona ese proyecto.
2. Elige los permisos. Hay presets que activan todo de golpe (No access, Read-only y Full access). Ojo con Read-only: incluye secretos como las API keys. Por eso conviene arrancar en No access y activar solo Database en modo lectura.
3. Define una expiración. Puedes fijar una fecha hasta un año adelante. La regla es simple: una herramienta temporal no debería sostener una llave permanente. Si el trabajo del agente termina en una semana, su token debería terminar también.
4. Revisa el blast radius. Antes de crear el token, la pantalla de revisión muestra qué estás autorizando. Al desplegar cada permiso ves los endpoints de la Management API y las herramientas MCP que cubre. También aparece un banner que califica el riesgo según alcance y capacidad de escritura: Low, Medium o High.

Dos detalles operativos que suelen olvidarse: el valor del token se muestra una sola vez, así que cópialo antes de cerrar la página; y su alcance y permisos quedan fijos al crearlo. Para modificarlos hay que generar un token de reemplazo. Los tokens acotados usan el prefijo sbp_fc y funcionan con el esquema estándar de autenticación bearer.

Un token nunca tiene más acceso que tú

El principio que sostiene todo el modelo es que los permisos del token están limitados por tu propia cuenta. Cada request evalúa dos cosas a la vez: el alcance del token y tu rol de usuario actual.

La consecuencia práctica es directa. Si dejas una organización o pierdes permiso para leer la base de datos de un proyecto, el agente pierde ese acceso en el mismo instante. Si tu acceso se restituye, el token vuelve a funcionar. La vista de detalle marca los recursos que ya no puedes alcanzar.

Lo mismo ocurre al momento de crearlo: el Dashboard señala cualquier permiso que tu rol no tenga. Puedes agregarlo igual, pero el token no podrá usarlo hasta que tu rol lo incluya. Es una salvaguarda útil, aunque también una fuente de sorpresas en equipos donde los roles cambian seguido.

Qué pasa con los tokens que ya existen

Nada malo, y vale aclararlo porque en seguridad cualquier anuncio suele leerse como una fecha de corte. Supabase confirmó que tus integraciones actuales siguen funcionando y que no hay fecha de deprecación ni de apagado: cada token existente opera hasta que expire o lo borres.

Lo único que cambia es la etiqueta. En el Dashboard, los tokens con acceso total llevan la insignia Legacy y la opción de crear uno nuevo con ese mismo alcance sigue disponible para flujos que realmente la necesiten.

Por qué esto importa ahora: credenciales sin dueño y agentes sin gobierno

El contexto explica por qué un cambio de alcance parece menor y no lo es. Un análisis de UpGuard difundido por BleepingComputer encontró más de 16.000 bases de datos de Supabase mal configuradas que exponían tablas legibles con datos personales, contraseñas o tokens de autenticación; en más de la mitad de los casos había información personal identificable. Entre los hallazgos, un servicio de valet en Estados Unidos expuso más de 100.000 registros de clientes y un servicio migratorio canadiense dejó al descubierto cerca de 5.000 registros de usuarios, incluidos 884 passwords en texto plano.

Los investigadores atribuyen la exposición a configuraciones deficientes, a políticas de row-level security ausentes o ineficaces y al mal uso de claves públicas. Su conclusión incómoda es que estos sitios suelen ser creados por agentes de IA cuyos dueños no entienden la configuración de su base de datos.

El problema es de arquitectura, no de un proveedor. Según TechRepublic, citando el Okta Enterprise AI Index construido con datos anonimizados de más de 20.000 organizaciones entre junio de 2022 y junio de 2026, las identidades no humanas ya superan a los usuarios humanos en el 83% de las empresas, pero solo el 21% tiene controles dedicados para gobernar esas identidades. El mismo análisis señala que las organizaciones con ese gobierno implementado eran cinco veces más propensas a reportar cero barreras para escalar agentes.

El riesgo dejó de ser teórico. En octubre, atacantes accedieron a un sistema legado de OpenCode Console y expusieron claves de API del 1,4% de sus usuarios, con cargos no autorizados que en algunos casos superaron los US$1.000, según TechCrunch. Anthropic y Google bloquearon las claves comprometidas y OpenAI acordó reembolsar los créditos consumidos.

Y la escala del ecosistema amplifica cada error: Supabase levantó US$500 millones en una Serie F a una valoración pre-money de US$10.000 millones en junio de 2026, liderada por GIC (TechCrunch), y cuatro meses después sumó US$150 millones y adquirió a Turso, la empresa de bases de datos SQLite, según pulse2.com. Más proyectos, más tokens, más superficie.

Cómo se comportan los tokens acotados en la API, el MCP y la CLI

Saber qué esperar cuando algo falla te ahorra horas de depuración:

• Management API: si a un request le falta un permiso, la respuesta 403 lo nombra en un campo missing_permissions. Verifica que tu propio rol tenga ese permiso y agrégalo al token de reemplazo. Un request a un proyecto fuera del alcance del token devuelve un 403 simple, sin detalle.
• MCP Server: cada herramienta valida permisos antes de ejecutarse y devuelve un error si la deniegan. Con permiso de lectura de base de datos puedes usar execute_sql para consultas de solo lectura; una escritura SQL devuelve un error de permisos de Postgres en lugar de un 403. Para apply_migration necesitas el permiso Migrations con lectura y escritura.
• CLI: el flujo de navegador de supabase login todavía crea un token con acceso total, y está en camino el cambio para que respete el alcance que elijas. Mientras tanto, crea el token en el Dashboard y pásalo con supabase login --token. En CI define SUPABASE_ACCESS_TOKEN, que tiene prioridad sobre cualquier token guardado localmente. Ojo con dos excepciones: los comandos que dependen de SUPABASE_DB_PASSWORD se saltan por completo los permisos del token, y si tu workflow usa supabase link, el token necesita además lectura de Project Settings, API Keys y API Key Secrets.

¿Qué significa esto para tu startup?

El cambio de Supabase llega justo cuando la mayoría de los equipos ya perdió la cuenta de cuántas credenciales tiene circulando. Cuatro movimientos concretos:

• Inventaria antes de crear. Lista los tokens que tocan tu cuenta de Supabase y tus proveedores de IA, y anota qué herramienta usa cada uno. La clave que nadie puede atribuir a un dueño es la que después nadie sabe rotar.
• Reemplaza, no borres. Si una integración usa un token de acceso total, crea uno acotado a su proyecto y a los permisos de su trabajo, y haz el swap. La creación de un token de reemplazo es el mecanismo oficial para cambiar de alcance.
• Acorta vidas útiles por defecto. Define expiraciones que coincidan con la duración real de la tarea y aplica la misma disciplina a tus claves de proveedores de IA: una clave única por herramienta reduce el daño cuando una se filtra.
• Divide en lugar de ampliar. Si el banner de riesgo marca High, no lo justifiques: separa el trabajo en dos tokens, uno de lectura y otro de escritura, en lugar de darle a un agente permiso para todo el proyecto.

Hay un quinto punto que suele pasarse por alto: como el token hereda tu rol, cualquier cambio de permisos en tu equipo puede romper un agente en silencio. Vale la pena que el responsable de cada integración sepa que bajar de rol en la organización equivale a apagar esa llave.

Conclusión

Durante años, la seguridad de las credenciales se resolvió con buena voluntad: rotar cada tanto y confiar en que nadie las compartiera. La ola de agentes de IA rompió ese supuesto, porque multiplicó las credenciales y les dio la capacidad de actuar solas. Que Supabase haga que cada token nazca acotado por defecto convierte una buena práctica en el comportamiento automático de la plataforma, y eso es más valioso que cualquier recomendación publicada.

Para un founder, la lección es más amplia que un producto: cada vez que le entregas una llave a una herramienta, la pregunta ya no es si confías en ella, sino cuál es el daño máximo que podría causar si esa llave se filtra. Responderla cuesta unos minutos. No responderla ya tiene casos documentados con nombre, fecha y cifras.

Fuentes

• Scope your Personal Access Tokens (fuente original)
• Over 16,000 Supabase databases expose PII, passwords, auth tokens | BleepingComputer
• The Hidden Security Problem Holding Enterprise AI Back | TechRepublic
• Hackers hit AI coding tool OpenCode | TechCrunch
• Supabase doubles valuation to $10B in 8 months | TechCrunch
• Supabase Raises $150 Million And Acquires Turso | pulse2.com

Artículos relacionados:

Supabase Select 2026: backend desde código y MCP para tu app Supabase Select 2026: Multigres, OrioleDB y dbarena Supabase Select 2026: agentes de IA ya operan tu base Supabase lanza su SDK .NET 8.0 con inyección de dependencias Supabase $10B: lecciones de funding para founders 2026