Salta ai contenuti
Rebase LogoRebase

IA & Agenti

Rebase include quattro elementi distinti per gli assistenti IA, ciascuno pensato per risolvere un problema diverso. È utile sapere a quale fare riferimento in base alle proprie esigenze:

Cos’è Chi lo usa
Server MCP Un server Model Context Protocol stdio con 40 tool su schema, dati, utenti, storage, cron e dev server Un assistente, a runtime
Agent skill 20 file di skill in formato Markdown scritti nel tuo repository da rebase skills install Un assistente, come materiale di riferimento
File di istruzioni ai-instructions.md insieme ai file puntatore specifici per assistente, creati da rebase init Un assistente, come regole sempre attive
Chiavi API Credenziali macchina con permessi specifici (scoped), per collezione e per operazione Qualsiasi client che effettua chiamate alle API HTTP

I primi tre servono a fornire a un assistente conoscenza e strumenti. Il quarto è l’unico che decide cosa può effettivamente fare.

Il punto fondamentale: a cosa può accedere un agente

Sezione intitolata “Il punto fondamentale: a cosa può accedere un agente”

Un agente dotato di tool sul tuo database è un normale client API che si trova semplicemente a decidere autonomamente la sua richiesta successiva. Rebase non cerca di limitarlo tramite istruzioni di testo — un prompt non è un meccanismo di controllo degli accessi, e un agente che legge le tue righe sta leggendo testo che qualcun altro potrebbe aver scritto. Il vincolo deve risiedere a un livello inferiore rispetto all’agente, ovvero nelle credenziali che possiede.

Rebase applica a queste credenziali due livelli di controllo indipendenti:

  1. L’elenco dei permessi della chiave API. Dichiarato per collezione e per operazione, in cui delete è separabile da write — che di solito è il permesso che si desidera negare a un agente a cui è invece consentito modificare i dati.
  2. Row-Level Security (RLS). Le chiavi API non ignorano la RLS. Una chiave si connette con il ruolo Postgres rebase_user come qualsiasi altro chiamante, quindi le tue policy continuano a determinare quali righe vengono restituite.

Entrambi i controlli devono autorizzare la richiesta. Nessuno dei due sostituisce l’altro, ed è proprio il secondo il motivo per cui una chiave con permessi "*" può comunque restituire un set di risultati vuoto.

Un dettaglio che spesso trae in inganno: l’impostazione access: "public" di una collezione estende quali righe un chiamante può vedere, non chi può effettuare la chiamata. È una dichiarazione sulla visibilità delle righe, non sull’autenticazione. Concederla non aggiunge un chiamante all’elenco dei permessi, e revocarla non gli impedisce di effettuare chiamate.

I dettagli tecnici — creazione delle chiavi, JSON dei permessi, rotazione, scadenza, rate limit — sono trattati in REST API → API Key. Non tralasciare Security Rules (RLS); il secondo livello di controllo è efficace solo quanto le policy che hai definito.

Ricerca vettoriale

Sezione intitolata “Ricerca vettoriale”

Rebase offre un tipo di proprietà nativo vector su Postgres e un metodo di query .vectorSearch() con supporto per le distanze cosine, l2 e inner_product. La funzionalità è già documentata in due sezioni distinte:

Tre aspetti fondamentali da considerare prima della progettazione: Rebase archivia ed esegue ricerche sugli embedding, ma non li calcola — non è presente alcun provider di embedding, impostazione di modello o chiave API all’interno di Rebase, quindi la generazione dei vettori è a tuo carico. pgvector è un prerequisito. L’immagine del database dello scaffold lo include, quindi un progetto creato con rebase init non richiede nulla qui; puntando a un database predisposto da qualcun altro servono un’immagine che porti l’estensione e un ruolo autorizzato a eseguire CREATE EXTENSION vector; una volta — Rebase non installa estensioni al posto tuo. Inoltre, ogni colonna vettoriale riceve un indice HNSW per la distanza coseno, perché è con il coseno che vectorSearch misura se non passi distance: un indice serve esattamente un operatore. Puoi regolarlo, o disattivarlo, sulla proprietà: vedi L’indice.

Non è inoltre possibile sottoscrivere query vettoriali in tempo reale; .vectorSearch(...).listen() viene rifiutato con l’errore VECTOR_SEARCH_NOT_LIVE.

Per la ricerca lessicale — ricerca full-text con ranking sui campi specificati, inclusi contenuti JSONB e array — consulta Ricerca. Si tratta di un meccanismo differente e i due non interagiscono tra loro.

Dove proseguire

Sezione intitolata “Dove proseguire”