Il motore di storage è l'unica autorità che conta
Il precedente articolo sosteneva che l'agente dovrebbe detenere gli strumenti. Dagli uno strumento SQL e la domanda diventa immediata: cosa gli impedisce di interrogare la tabella che non dovrebbe?
Gli approcci ingenui sono fin troppo battuti e tutti sbagliati.
Istruzione a livello di prompt: "Non sei autorizzato a leggere la tabella delle conversazioni." Funziona con un modello cooperativo. Fallisce con qualsiasi modello che interpreti male l'istruzione, decida che il divieto non si applica al suo compito attuale o stia operando sotto un jailbreak.
Filtro a livello di applicazione: lo strumento sql_query avvolge l'SQL del modello, lo analizza alla ricerca di riferimenti a tabelle vietate e rifiuta la query prima di passarla al database. Funziona con un modello ingenuo. Fallisce con qualsiasi modello che citi i nomi delle tabelle, usi ATTACH, sfrutti una discrepanza di parsing tra il wrapper e il database o instradi attraverso una vista definita altrove.
Accesso solo tramite ORM: l'agente non tocca mai SQL grezzo, chiama metodi tipizzati. Funziona finché il sistema non sviluppa uno strumento di debug, uno strumento di analisi, uno strumento di migrazione o una funzionalità "lascia che l'agente unisca due tabelle", momento in cui la regola si rompe e la rottura passa inosservata.
In parole povere: nessuna di queste è un'applicazione coercitiva. Sono suggerimenti. Un sistema che desidera un vero isolamento dei sotto-agenti deve chiedere al motore di storage stesso di rifiutare la lettura, non al livello superiore. Questa è la disciplina che la sicurezza basata sulle capacità impone alle risorse del sistema operativo: il kernel dice di no, non l'applicazione. È anche la disciplina che la sicurezza a livello di riga di PostgreSQL impone ai SaaS multi-tenant: la politica risiede nel database, non nell'ORM, perché "l'ingegnere che ha costruito il nuovo microservizio si è dimenticato di applicare il filtro del tenant" è una classe di bug che solo una politica del motore di storage può escludere.
second-brain è il primo esempio funzionante del corpus. Il suo database con ambito di applicazione ha tre livelli, ciascuno necessario, nessuno sufficiente da solo.
Una nuova connessione SQLite in memoria per agente con ambito di applicazione. Il costruttore apre :memory: e collega il database reale in modalità sola lettura. La connessione dell'agente non ha uno schema principale reale, non c'è niente da leggere tranne ciò che il livello successivo ci mette.
Viste TEMP nello schema principale che reindirizzano alle tabelle consentite nell'origine. Le definizioni delle viste provengono dal profilo dell'agente e possono codificare la redazione a livello di colonna o i filtri a livello di riga. Un validatore del nome della vista impedisce l'iniezione di nomi di tabella dannosi attraverso il profilo.
Un hook authorizer dell'API C di SQLite che nega qualsiasi lettura dello schema di origine che non passi attraverso una vista. L'hook si attiva per ogni lettura che SQLite sta per eseguire, prima che l'ottimizzatore risolva anche il nome della tabella. Una lettura all'interno del corpo di una vista è consentita, la vista è il filtro dell'ambito. Una lettura di primo livello viene controllata rispetto all'insieme di nomi di vista che l'ambito ha creato. Qualsiasi lettura diretta dello schema di origine viene negata senza eccezioni.
L'LLM può scrivere qualsiasi SQL voglia. Può citare nomi di tabella, usare UNION, usare ATTACH, usare la grammatica completa di SQLite. Non può riuscire a leggere una riga da una tabella che non è nella whitelist, perché l'authorizer intercetta la lettura a livello C prima che il nome della tabella venga risolto. Il filtro a livello di applicazione è aggirabile. L'autorizzazione del motore di storage no.
Circa 50 righe di Python stdlib. Nessuna dipendenza aggiuntiva, nessun processo aggiuntivo, nessuna migrazione dello schema. Il sovraccarico per query è un callback C per lettura, invisibile rispetto al costo della query stessa. Il pattern si compone in modo pulito con tutto il resto: il registro degli strumenti dell'agente può ancora essere controllato dalle funzionalità, le definizioni delle viste possono ancora codificare la redazione a livello di colonna, la cronologia delle conversazioni può ancora essere redatta al momento della scrittura. Nessuno di questi livelli è indebolito dall'applicazione a livello di storage. Sono rafforzati da essa.
L'inquadramento è importante. Ogni altro pattern di sicurezza nei 19 sistemi è un suggerimento. Il motore di storage è l'autorità.
Altri tre degni di nota
Protezione dalla race condition nella pulizia asincrona (llm-wiki)
La manutenzione della memoria in background è fondamentalmente in conflitto con le azioni dell'utente in primo piano. Una scansione iniziata contro il progetto A e che termina contro il progetto B ha corrotto entrambi. Ha spostato le decisioni di A nel repository di revisione di B, o ha segnato gli elementi di B come risolti con i dati di A. Questa è una classe di bug facile da introdurre, difficile da rilevare e impossibile da risolvere in modo pulito perché lo stato corrotto sembra legittimo.
llm-wiki esegue un ciclo di revisione in background a due stadi e, ad ogni punto di resa, ricontrolla due segnali di protezione dalla race condition: un segnale di interruzione attivato dal gestore del cambio progetto e un confronto del percorso con il progetto corrente nell'archivio dell'interfaccia utente. Se uno dei due controlli fallisce, la scansione ritorna a metà volo senza applicare le decisioni. La stretta di mano del cambio progetto sul lato della coda completa il quadro: scarica lo stato del progetto attivo su disco prima di cancellare la memoria, riporta gli elementi in elaborazione allo stato "in sospeso", interrompe sia la chiamata LLM in volo che il giudizio di scansione in volo, e solo allora scrive nel percorso del progetto in pausa.
Il meta-pattern è il punto chiave: deterministico dove puoi, LLM dove devi, interrompibile ovunque. La struttura a due stadi tiene l'LLM fuori dai casi che semplici controlli di esistenza possono gestire. La protezione dalla race condition mantiene entrambi gli stadi interrompibili. La combinazione è un modello per qualsiasi ciclo di manutenzione della memoria in background in qualsiasi sistema.
Il costruttore no-op con degradazione automatica (graymatter)
La progettazione dell'API di una libreria ha una tensione ricorrente. Il "hello world" più semplice vuole che la libreria funzioni e basta, una riga per costruire, una per chiamare. La postura di produzione più difendibile vuole che fallisca rumorosamente in fase di costruzione con un errore strutturato che il chiamante non può ignorare.
graymatter sceglie di fallire in silenzio, ma con una disciplina che trasforma il compromesso in produttivo. Il costruttore non restituisce mai un errore. Se l'inizializzazione fallisce, bbolt è bloccato, la directory dei dati non è scrivibile, il vector store non può essere aperto, registra su stderr e restituisce una Memory degradata i cui metodi sono tutti no-op. I chiamanti in produzione verificano tramite Healthy() prima di fidarsi dell'handle. La libreria è ottenibile con go get, importabile in tre righe e funziona nella demo. Healthy() è la tassa di disciplina della produzione.
Il pattern rende la libreria sicura da incorporare in harness per agenti che hanno la loro propria cerimonia di avvio. Un harness per agenti che chiama [graymatter.New](https://graymatter.new/)(...) durante l'avvio, ignora il percorso di errore perché non esiste un percorso di errore, e continua, ottiene un livello di memoria funzionante nel percorso felice e un fallback senza memoria quando la directory dei dati è in sola lettura. In entrambi i casi, l'harness si avvia. Questo è un tipo specifico di composizione difensiva che i costruttori che falliscono rumorosamente non possono offrire senza una gestione esplicita degli errori in ogni sito di incorporamento.
Rilevamento dei duplicati in modalità shadow (mem9)
Ogni sistema che implementa la soppressione dei duplicati deve scegliere una soglia di similarità coseno. Sopra 0.95 è quasi certamente un duplicato. Sotto 0.7 è quasi certamente non lo è. Lo spazio intermedio è contestato, e il taglio giusto dipende dal modello di embedding, dal dominio, dalla distribuzione delle query e dal costo dei falsi positivi rispetto ai falsi negativi in questo particolare sistema.
La tentazione è schiacciante di sceglierne uno basato sull'intuizione e pubblicarlo. mem9 non lo fa. Esegue la query di rilevamento dei duplicati per ogni fatto, registra il punteggio coseno in un istogramma Prometheus e non intraprende alcuna azione. La soglia viene rimandata fino a quando i dati di produzione non la giustificano. "Pubblica l'osservazione, non l'euristica."
La stessa logica si applica a ogni decisione basata su soglia in ogni sistema di memoria. Soglia di rerank. Soglia di confidenza per il recall. Soglia di calore per la promozione di livello. Soglia di similarità per la fusione degli insight. La maggior parte dei sistemi nei 19 spedisce questi valori indovinati. mem9 spedisce con il valore rimandato. La disciplina è rara e il risultato è migliore.
Altri quattro, più stretti
Isolamento del database fisico per tenant (mem9).
Invece di un filtro WHERE tenant_id = ? su un archivio condiviso, mem9 provisiona un cluster TiDB separato per tenant tramite TiDB Zero. L'isolamento è lato motore di storage. L'applicazione non può accidentalmente interrogare tenant diversi perché non esiste un archivio condiviso da interrogare. È una versione a grana più grossa dello stesso stato finale dell'autorizzazione a livello di storage: isolamento applicato dal motore, non dall'applicazione. Il costo infrastrutturale che storicamente rendeva questo impraticabile è scomparso. TiDB Zero auto-provisiona. Neon fa lo stesso per PostgreSQL. Cloudflare D1 fa lo stesso per SQLite.
Decorazione del turno di origine con budget di contesto esplicito (mem9).
Un ricordo recuperato è una stringa. "L'utente preferisce Postgres." Corretto, laconico, impossibile da ancorare senza contesto. mem9 allega i turni di conversazione di origine come decorazione, valutati rispetto alla query e limitati da un triplo budget: punteggio minimo, limite per ricordo, limite totale. L'agente che legge "L'utente preferisce Postgres" ottiene il turno in cui l'utente ha detto "abbiamo provato MongoDB ma i join ci hanno ucciso, quindi sono passato a Postgres il trimestre scorso." Nessuna seconda chiamata allo strumento richiesta. L'ancoraggio è nel risultato. I prerequisiti sono già universali: provenienza più recupero ibrido. La maggior parte dei sistemi nei 19 potrebbe implementare questo in due giorni.
purpose.md come quarto file (llm-wiki).
Il pattern LLM Wiki di Karpathy ha tre file canonici: fonti grezze, il wiki set di lavoro e schema.md per le regole strutturali. llm-wiki ne aggiunge un quarto: purpose.md, compilato dall'utente, in linea in ogni chiamata LLM che il sistema fa. Ogni prompt di ingestione, ogni prompt di generazione, ogni chat di recupero lo legge. L'effetto è un priorità direzionale stabile che condiziona ogni comportamento a valle. L'LLM leggerà comunque il prompt di sistema. Aggiungere l'intento dell'utente non costa nulla e migliora tutto. L'assenza dalla maggior parte degli altri sistemi è più difficile da spiegare della sua presenza in llm-wiki.
AGENTS.md come contratto autorevole per l'agente (Tolaria, OpenContext). La maggior parte dei repository con un AGENTS.md o CLAUDE.md lo tratta come un file di suggerimenti. Tolaria e OpenContext lo trattano come un contratto, sostenendo ogni clausola vincolante con un controllo meccanico che fa fallire la build se l'agente la viola. "Non saltare gli hook di pre-commit" non è una richiesta educata, è una regola che la CI applica. "La copertura dei test deve rimanere sopra la soglia" non è una linea guida, è una barra che l'esecutore dei test interrompe. Un suggerimento può essere ignorato. Un contratto supportato da un controllo no. Due sistemi lo fanno già. Ancora uno e si diploma.
Quali diventeranno universali per primi
L'autorizzazione a livello di storage diventerà universale per prima. Questa è la previsione più sicura nell'analisi delle fonti. Ogni sistema di memoria che dà a un sotto-agente accesso SQL è a un prompt injection di distanza da una violazione della riservatezza senza l'applicazione a livello di storage. L'infrastruttura è già in atto. SQLite ha set_authorizer dall'inizio degli anni 2000. PostgreSQL RLS è mainstream. LanceDB e ClickHouse hanno i propri hook di policy. La barriera non è tecnica, è la consapevolezza. second-brain ha fornito l'esempio funzionante. La prossima generazione di API gestite copierà la disciplina perché l'alternativa è indifendibile.
La decorazione del turno di origine diventerà universale per seconda. I prerequisiti sono già universali. L'implementazione è due query più un budget. Il guadagno informativo lato agente è abbastanza grande che chiunque lo spedisca per primo in un'API gestita sarà visibilmente migliore nell'ancorare le risposte nel dialogo di origine rispetto a chi lo spedisce per secondo. La pressione a copiare è alta. graymatter ha la fonte per fatto. supermemory ha la discendenza. Hindsight ha la piena provenienza conversazionale. Ognuno di questi è a una PR di distanza dal pattern.
Il costruttore no-op con degradazione automatica diventerà universale per terzo, e in un linguaggio diverso. Le condizioni culturali di Go rendono il pattern sicuro. È improbabile che il prossimo adottante sia Python, la cultura è troppo incline alle eccezioni, ma potrebbe essere Rust. È una scelta di progettazione dell'API della libreria, non una scelta di memoria, e si diffonderà ovunque "estetica demo più disciplina di produzione" sia il giusto compromesso.
La distribuzione in modalità shadow è la sorpresa. Tecnicamente banale, culturalmente difficile. Se un secondo sistema strumenta una soglia prima di bloccarla, il pattern si diploma immediatamente, e il terzo e il quarto seguono entro un ciclo di rilascio perché l'ergonomia ingegneristica è inconfutabile una volta dimostrata.
I restanti quattro sono ciascuno condizionati da una forma di distribuzione specifica che diventa più comune. La protezione dalle race condition diventa universale quando più sistemi sviluppano parallelismo multi-conversazione. L'isolamento fisico per tenant diventa universale quando i clienti aziendali regolamentati iniziano a richiederlo. purpose.md diventa universale quando il paradigma Karpathy LLM Wiki ottiene la sua terza o quarta implementazione. AGENTS.md come contratto diventa universale quando l'inquadramento "gli agenti sono colleghi" diventa la metafora dominante dell'harness. Nessuno è inverosimile. Nessuno è certo.
Una Conclusione
Il filo conduttore di tutti e otto è la stessa posizione: il livello applicativo non è un confine di isolamento affidabile. L'autorizzazione a livello di storage è l'espressione per agente. I database fisici per tenant sono l'espressione per tenant. AGENTS.md come contratto è l'espressione per comportamento dell'agente. La prossima iterazione di questo corpus conterrà, in questa previsione, un nuovo pattern universale con quel nome.
L'articolo precedente sosteneva che l'agente dovrebbe detenere gli strumenti e decidere cosa recuperare. Questo parla di cosa tiene quando l'agente punta quegli strumenti verso un luogo che non ti aspettavi. I sei pattern universali sono il consenso. Gli otto qui sono gli indicatori anticipatori di dove si muoverà il consenso successivamente. L'autorizzazione a livello di storage è il bordo avanzato del bordo avanzato, e il costo di perderla è il tipo di costo che finisce su Hacker News.
