Le backend/IA & agents
La permission d'une clé
n'est pas une politique.
Donnez à un agent de vrais outils sur vos données — lire, écrire, migrer, déployer — via un serveur MCP auquel il se connecte en un bloc de configuration.
Puis retirez-en la sécurité fondée sur la confiance. Ce que l'agent peut toucher est une clé à portée limitée, et ce que la base renverra relève de la sécurité au niveau des lignes. Deux portes, dont aucune n'est un prompt.
Model Context Protocol
Votre projet, sous forme d'outils qu'un assistant peut appeler
@rebasepro/mcp parle le Model Context Protocol : tout ce qui parle MCP peut piloter votre backend — interroger et modifier les données, pousser des changements de schéma, ouvrir une branche de base, déclencher un cron, suivre le serveur de dev.
Vos définitions de collection et le schéma Drizzle généré sont aussi exposés comme ressources MCP : l'assistant lit votre vrai modèle de données au lieu de le deviner depuis le code qu'il a sous les yeux.
Il n'y a rien à construire et aucun adaptateur à écrire. C'est un bloc dans un fichier de configuration.
// .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_…"
}
}
}
}La surface d'outils
40 tools, and these are their real names
Pas un diagramme de catégories — la liste réelle que le serveur enregistre. Un agent capable de les appeler peut construire et exploiter une application sans humain dans le chemin de la requête.
- 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
Des agents à moindre privilège
Une autorisation que l'agent ne peut pas oublier
Tout le monde dans cette catégorie vous dira que son intégration agent est sûre. La question qui vaut la peine est : qu'est-ce qui l'applique ? Car si la réponse est la couche d'outils, alors un bug dans cette couche est une brèche. Ici la couche d'outils est la première de deux portes, et la seconde est la base de données.
Révoquez un scope ci-dessous et regardez les quatre mêmes appels revenir refusés.
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.
Une clé, pas un identifiant tout-puissant
Une clé détient des scopes, un par collection et par opération — data:read:orders, data:write:orders — et delete est un scope à part entière, séparé de write : c'est justement celui qu'on veut retirer à un agent.
Les lignes qu'elle voit relèvent d'un autre réglage : ses rôles. Sans autre rôle que service, Postgres n'accorde rien du tout à la clé tant qu'une de vos politiques ne nomme pas ce rôle.
La clé elle-même n'est montrée qu'une fois. Ce que le serveur garde est un hachage SHA-256 : un dump de la table des clés ne donne à personne une clé fonctionnelle — et une clé qui fuit se révoque en supprimant la ligne, pas en faisant tourner un secret partagé. Chacune porte sa propre limite de débit et sa propre expiration.
Comment les policies sont générées// 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"
}Infrastructure pour agents
Tout ce dont un agent a besoin pour opérer
Recherche vectorielle, clés à portée limitée, fonctions en streaming, temps réel et tâches planifiées — la surface opérationnelle sur laquelle les agents s'appuient, dans une fenêtre plutôt qu'un mur de cartes.
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.
1 collection file → 0 custom controllers to hallucinate · TypeScript + SQL migration verified before apply
MCP est un standard : la liste de ce qui peut piloter votre backend ne nous appartient pas — c'est tout ce qui le parle.
Pointez-y un agent
Échafaudez un projet, ajoutez le bloc de configuration, et donnez à votre assistant une clé capable de lire une collection. C'est un moyen plus rapide de vérifier tout ceci que de lire le reste de cette page.