Das Backend/KI & Agenten
Die Berechtigung eines Keys
ist keine Policy.
Gib einem Agenten echte Werkzeuge über deine Daten — lesen, schreiben, migrieren, deployen — über einen MCP-Server, mit dem er sich in einem Konfigurationsblock verbindet.
Und nimm dann das Vertrauen aus der Sicherheit heraus. Was der Agent anfassen darf, ist ein gescopter Key, und was die Datenbank zurückgibt, entscheidet Row-Level Security. Zwei Tore, keines davon ein Prompt.
Model Context Protocol
Dein Projekt, als Werkzeuge, die ein Assistent aufrufen kann
@rebasepro/mcp spricht das Model Context Protocol, also kann alles, was MCP spricht, dein Backend steuern: Daten abfragen und ändern, Schema-Änderungen pushen, einen Datenbank-Branch öffnen, einen Cron-Job auslösen, den Dev-Server verfolgen.
Deine Collection-Definitionen und das generierte Drizzle-Schema werden ebenfalls als MCP-Resources bereitgestellt, sodass der Assistent dein echtes Datenmodell liest, statt es aus dem gerade offenen Code zu erraten.
Es gibt nichts zu bauen und keinen Adapter zu schreiben. Es ist ein Block in einer Konfigurationsdatei.
// .cursor/mcp.json — or Claude Desktop, Windsurf, Copilot…
{
"mcpServers": {
"rebase": {
"command": "npx",
"args": ["@rebasepro/mcp"],
"env": {
"REBASE_BASE_URL": "https://api.example.com",
"REBASE_API_TOKEN": "rk_live_…"
}
}
}
}Die Werkzeugoberfläche
40 tools, and these are their real names
Kein Kategoriendiagramm — die tatsächliche Liste, die der Server registriert. Ein Agent, der sie aufrufen kann, kann eine Anwendung bauen und betreiben, ohne einen Menschen im Request-Pfad.
- list_documents
- get_document
- create_document
- update_document
- delete_document
- list_users
- create_user
- update_user
- delete_user
- list_roles
- rebase_auth_reset_password
- rebase_schema_generate
- rebase_schema_introspect
- rebase_db_push
- rebase_db_generate
- rebase_db_migrate
- rebase_generate_sdk
- rebase_doctor
- rebase_db_branch_create
- rebase_db_branch_list
- rebase_db_branch_info
- rebase_db_branch_delete
- storage_list_objects
- storage_get_metadata
- storage_delete_object
- cron_list_jobs
- cron_get_job
- cron_trigger_job
- cron_get_job_logs
- cron_toggle_job
- invoke_function
- rebase_dev_start
- rebase_dev_logs
- rebase_dev_stop
- rebase_project_list
- rebase_project_current
- rebase_project_switch
- rebase_project_add
- rebase_project_remove
- rebase_project_status
Agenten mit minimalen Rechten
Autorisierung, die der Agent nicht vergessen kann
Jeder in dieser Kategorie wird dir sagen, seine Agent-Integration sei sicher. Die Frage, die sich lohnt, ist, was sie durchsetzt — denn wenn die Antwort die Tool-Schicht ist, dann ist ein Bug in der Tool-Schicht ein Vorfall. Hier ist die Tool-Schicht das erste von zwei Toren, und das zweite ist die Datenbank.
Widerrufe unten einen Scope und sieh zu, wie dieselben vier Aufrufe abgelehnt zurückkommen.
The key you hand the agent. Revoke something and watch the session below.
scopes
RLS roles
Scopes decide which calls the key may make; roles decide which rows those calls see. As service alone, Postgres grants it nothing unless a policy names it.
200 20 rows · id, title, price, stock
200 1 row updated · orders/8f21
403 SCOPE_MISSING · data:delete:orders
Refused twice: the key has no such scope, and no delete policy on orders names "service", so 0 rows match.
404 NOT_FOUND · customers/c7
The key holds the scope. Postgres does not agree — customers lets each customer read their own row, and "service" is nobody's.
The two gates are independent, which is the part worth sitting with: grant data:delete:orders above and the call still deletes nothing, because a scope is not a policy — and it comes back 403 rather than reporting a delete that never happened. No prompt, jailbreak or bug in the tool layer widens what the database will return.
Ein Key, kein Allmacht-Zugang
Ein Key hält Scopes, einen pro Collection und Operation — data:read:orders, data:write:orders — und delete ist ein eigener Scope, getrennt von write: genau den will man einem Agenten vorenthalten.
Welche Zeilen er sieht, ist eine eigene Einstellung: seine Rollen. Ohne eine Rolle außer service gewährt Postgres dem Key überhaupt nichts, solange keine deiner Policies diese Rolle nennt.
Der Key selbst wird einmal angezeigt. Was der Server behält, ist ein SHA-256-Hash — ein Dump der Key-Tabelle händigt also niemandem einen funktionierenden Key aus, und ein geleakter Key wird durch Löschen der Zeile widerrufen, nicht durch Rotation eines geteilten Secrets. Jeder trägt sein eigenes Rate-Limit und seine eigene Gültigkeit.
Wie die Policies erzeugt werden// The key behind that token. Scopes say which calls it may make —
// delete is its own scope — and roles say which rows those calls see.
{
"name": "support-agent",
"scopes": [
"data:read:products",
"data:read:orders",
"data:write:orders"
],
"roles": [],
"expires_at": "2026-12-31"
}Agenten-Infrastruktur
Alles, was ein Agent zum Arbeiten braucht
Vektorsuche, gescopte Keys, Streaming-Functions, Realtime und geplante Aufgaben — die operative Oberfläche, auf der Agenten aufbauen, in einem Fenster statt einer Kartenwand.
A surface an agent can hold
No controllers, no serializers, no migrations to hand-write, and nothing for a model to invent between the schema and the route. The whole contract fits in one context window, and the compiler checks whatever it writes back.
MCP ist ein Standard, also liegt die Liste dessen, was dein Backend steuern kann, nicht bei uns — es ist alles, was ihn spricht.
Richte einen Agenten darauf
Scaffolde ein Projekt, füge den Konfigurationsblock hinzu und gib deinem Assistenten einen Key, der eine Collection lesen darf. Das ist ein schnellerer Weg herauszufinden, ob davon etwas stimmt, als den Rest dieser Seite zu lesen.