💻 computer science

Don't Show What They Can't See: Authorization-First Schema Context for Secure Text-to-SQL

Questo articolo propone un framework basato sull'autorizzazione preventiva che impone un controllo degli accessi granulare durante il recupero dello schema per prevenire l'esposizione non autorizzata dei metadati del database nei sistemi text-to-SQL basati su LLM, ottenendo lo zero di perdite di oggetti non autorizzati pur mantenendo l'utilità del recupero e riducendo significativamente i riferimenti SQL non autorizzati.

Autori originali: Jianan Jiang, Zhenxin Zhang, Yucheng Long, Zhihao Li, Yaqi Wu, Yu Wang

Pubblicato 2026-09-28

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jianan Jiang, Zhenxin Zhang, Yucheng Long, Zhihao Li, Yaqi Wu, Yu Wang

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un bibliotecario capace di tradurre istantaneamente le vostre domande verbali in precisi comandi per la biblioteca, trovando esattamente i libri di cui avete bisogno tra milioni di scaffali. Questa è la promessa dei moderni sistemi di intelligenza artificiale che trasformano il linguaggio naturale in query per database. Questi sistemi si affidano a una mappa dettagliata dei contenuti della biblioteca — un elenco di ogni tabella, colonna e connessione tra esse — per comprendere ciò che state chiedendo. In un ambiente sicuro, tuttavia, non ogni parte di quella mappa dovrebbe essere visibile a ogni persona. Proprio come un cassiere di banca non può vedere i codici di accesso alla cassaforte di ogni conto, un utente dovrebbe vedere solo le parti del database a cui è autorizzato ad accedere. Il pericolo sorge quando il sistema mostra accidentalmente l'intera mappa al traduttore prima ancora che inizi a lavorare. Se il traduttore viene ingannato o manipolato, potrebbe rivelare l'esistenza di tabelle segrete o colonne sensibili, fornendo a un attaccante una base per un attacco mirato, anche se non vede mai un singolo record reale.

Ricercatori dell'Università di Guangzhou e dell'Università di Xidian hanno sviluppato un nuovo modo per gestire questo problema, garantendo che il traduttore veda solo le parti della mappa che l'utente è autorizzato a vedere. Il loro approccio inverte l'ordine tradizionale delle operazioni. Invece di raccogliere tutte le informazioni, filtrare le parti proibite e poi chiedere all'intelligenza artificiale di scrivere la query, controllano prima i permessi dell'utente. Costruiscono una versione piccola e sicura della mappa del database che contiene solo le tabelle e le colonne che l'utente è autorizzato a toccare. Solo questa mappa sicura e limitata viene quindi mostrata al sistema di IA. Questo impedisce all'IA di conoscere anche solo le sezioni proibite, in modo che anche se un malintenzionato cercasse di ingannare il sistema per rivelare segreti, non ci siano segreti nel contesto da rivelare.

Il team ha testato questo metodo su una collezione di 20 database diversi contenenti 240 domande specifiche accoppiate con diversi ruoli utente. Nel metodo standard, in cui il sistema vede l'intera mappa del database prima del filtraggio, l'IA era esposta a una media di 35,5 oggetti non autorizzati — come tabelle segrete o colonne nascoste — ogni singola volta che elaborava una richiesta. Con il nuovo metodo "authorization-first", quel numero è sceso a zero. Il sistema ha mantenuto con successo tutte le informazioni non autorizzate fuori dalla vista dell'IA prima ancora che iniziasse a pensare. Fondamentalmente, questa sicurezza non è avvenuta a scapito delle prestazioni. Il sistema era altrettanto bravo a trovare le tabelle e le colonne corrette per le domande effettive dell'utente quanto lo era il vecchio metodo. I ricercatori hanno scoperto che l'unico motivo per cui il vecchio metodo a volte falliva nel produrre la risposta corretta era che doveva lavorare con un insieme di informazioni molto più grande e confuso, mentre il nuovo metodo lavorava con un sottoinsieme pulito e pertinente.

Una scoperta chiave nel loro lavoro è stata la comprensione di dove avvengono ancora gli errori. Anche con il nuovo sistema di sicurezza, l'IA occasionalmente scriveva query che menzionavano cose che non avrebbe dovuto, tuttavia i ricercatori hanno tracciato questi errori e scoperto che non erano causati dalla fuga di informazioni da parte del sistema. Invece, l'IA stava semplicemente indovinando o "allucinando" i nomi delle colonne proibite, inventandoli dal nulla. Questa distinzione è vitale: dimostra che nascondere le informazioni proibite all'IA ferma la fuga diretta di segreti, ma non impedisce all'IA di inventare nomi. Pertanto, il nuovo metodo funziona meglio se combinato con un controllo finale che valida la query prima che venga eseguita, creando due livelli di difesa. Un livello impedisce all'IA di vedere i segreti, e il secondo livello impedisce all'IA di usare accidentalmente un segreto inventato.

Lo studio ha anche esaminato come il sistema gestisce i nomi confusi o abbreviati spesso presenti nei database aziendali reali, dove "customer risk score" potrebbe essere scritto come "cust_rsk_scr". Quando i nomi del database erano chiari e descrittivi, il nuovo sistema si è comportato allo stesso modo del vecchio. Ma quando i nomi erano abbreviati e criptici, il sistema ha utilizzato una tecnica speciale per aggiungere descrizioni in linguaggio naturale alla mappa sicura. Questo ha aiutato l'IA a capire cosa significassero i codici brevi, migliorando la sua capacità di trovare i dati corretti dell'11,5 percento rispetto a un sistema senza quelle descrizioni. Questo miglioramento è avvenuto solo quando i nomi erano difficili da indovinare, dimostrando che l'aiuto extra è necessario solo quando la mappa è difficile da leggere.

Per garantire che il sistema fosse davvero sicuro, i ricercatori hanno simulato attacchi in cui un utente cercava di ingannare l'IA per elencare tutte le tabelle segrete. Nel vecchio sistema, questi attacchi avevano successo circa la metà delle volte, rivelando una parte significativa della struttura nascosta del database. Nel nuovo sistema, gli attacchi sono falliti completamente. L'IA, non avendo mai visto le tabelle segrete, non poteva elencarle. L'unica informazione che è trapelata è stata costituita da parole comuni che apparivano casualmente nelle istruzioni generali del sistema, non dai veri segreti del database. Ciò ha confermato che il nuovo metodo blocca efficacementamente il percorso che un attaccante userebbe per mappare un database.

I ricercatori riconoscono che la loro soluzione è un passo avanti potente ma non è una cura definitiva per ogni problema. Impedisce all'IA di vedere i segreti che non dovrebbe vedere, ma non può impedire a un attaccante di indovinare i segreti basandosi su conoscenze pubbliche o di inferire dati nascosti dai messaggi di errore. Per questo motivo, il nuovo metodo è progettato per lavorare insieme ai controlli di sicurezza esistenti, non per sostituirli. Assicurando che l'IA non veda affatto le parti proibite del database, il sistema rimuove una vulnerabilità importante. Crea un confine dove l'IA può lavorare solo con ciò che l'utente è autorizzato a vedere, rendendo l'intero processo di trasformazione delle domande in comandi per il database molto più sicuro per le organizzazioni che devono proteggere informazioni sensibili.

Riepilogo Tecnico: Non mostrare ciò che non possono vedere: Contesto di Schema con Autorizzazione Prioritaria per un Text-to-SQL Sicuro

1. Definizione del Problema

Gli agenti Text-to-SQL basati su Large Language Model (LLM) si affidano agli schemi dei database (tabelle, colonne e relazioni di join) per comprendere l'intento dell'utente e generare query. In ambienti aziendali con controllo degli accessi granulare, anche i metadati dello schema possono essere sensibili. Ad esempio, nomi di tabelle come employee_compensation o nomi di colonne come fraud_score rivelano processi aziendali interni e asset di dati anche senza esporre i record effettivi dei dati.

I sistemi Text-to-SQL attuali forniscono tipicamente lo schema completo o recuperano oggetti rilevanti dallo spazio dello schema completo prima di aggiungerli al contesto del modello. Questo design assume che i metadati dello schema siano universalmente visibili, il che è insicuro in ambienti multi-tenant o con accessi ristretti. Il problema centrale affrontato è l'esposizione dello schema a livello di processo:

La Minaccia: Se uno schema completo o parzialmente recuperato entra in un componente a minore fiducia (ad esempio, un servizio LLM esterno, un modulo di reranking o un componente vulnerabile al prompt injection), gli identificatori non autorizzati e le relazioni strutturali vengono divulgati.
Il Limite delle Difese Esistenti: La validazione SQL post-generazione e i controlli di accesso ai Database Management System (DBMS) possono bloccare l'esecuzione di query non autorizzate, ma non possono revocare le informazioni sullo schema che il modello ha già osservato. Una volta che un oggetto non autorizzato entra nel contesto, può essere sfruttato tramite prompt injection, role-playing o sondaggi multi-turn per ricostruire strutture di schema sensibili.
Il Gap: Manca un meccanismo che applichi l'autorizzazione prima del recupero della rilevanza, garantendo che oggetti non autorizzati non entrino mai nella pipeline a minore fiducia.

2. Metodologia: Framework con Autorizzazione Prioritaria

Gli autori propongono un framework Authorization-First (con autorizzazione prioritaria) che costruisce un contesto di schema compatto e sicuro, applicando il controllo degli accessi prima che avvenga qualsiasi computazione della rilevanza. Il sistema opera sotto un modello di minaccia in cui i componenti di recupero, reranking e generazione si trovano al di fuori del confine di fiducia.

2.1 Principi Fondamentali

Confidenzialità Pre-Generazione: L'autorizzazione è trattata come un prerequisito affinché un oggetto dello schema possa partecipare al recupero. Il sistema costruisce uno spazio sub-dimensionale autorizzato dall'utente ( $S_u$ ) prima di qualsiasi scoring di rilevanza dipendente dalla query.
Ereditarietà Consapevole della Provenienza: La sicurezza si estende oltre gli oggetti base (tabelle, colonne) agli artefatti derivati (descrizioni semantiche, suggerimenti di join, dimostrazioni SQL). Un artefatto è visibile solo se tutti gli oggetti base da cui dipende sono autorizzati. Ad esempio, una descrizione di una colonna autorizzata non può menzionare una tabella non autorizzata.
Astensione Non Rivelatrice: Se una richiesta non può essere soddisfatta all'interno dello spazio sub-dimensionale autorizzato, il sistema rifiuta la richiesta con un messaggio generico ("La richiesta non può essere completata nell'ambito di accesso corrente") che è byte-identico indipendentemente dalla causa. Ciò impedisce al comportamento di rifiuto di agire come un oracle di sondaggio dello schema.

2.2 Pipeline del Sistema

Il framework consiste in una governance offline e un'inferenza online:

Governance Offline: Lo schema viene atomizzato e le descrizioni semantiche vengono generate. Fondamentalmente, le descrizioni sono generate solo dal target dell'oggetto e dalla propria tabella, mai dallo schema globale, per evitare la fuga di identificatori nascosti. Le etichette di provenienza sono attaccate a tutti gli artefatti.
Inferenza Online:
- Costruzione dello Spazio Sub-dimensionale Autorizzato: Prima di elaborare la domanda dell'utente, il sistema filtra lo schema per creare $S_u = \text{Authorize}(S, P(u))$ , dove $P(u)$ è la policy dell'utente.
- Recupero Restrittivo: Il recupero delle tabelle, la selezione delle colonne e la selezione delle relazioni avvengono esclusivamente all'interno di $S_u$ . Gli oggetti non autorizzati sono assenti dallo spazio dei candidati, non solo con un punteggio basso.
- Arricchimento Semantico Sicuro per i Permessi: Per gestire identificatori abbreviati aziendali (es. cust_rsk_scr), il sistema utilizza le descrizioni semantiche come fallback per il recupero. Queste descrizioni sono fuse con il matching degli identificatori ma aderiscono rigorosamente alle regole di provenienza.
- Gate di Soddisfacibilità: Il sistema verifica se $S_u$ (non solo il top-K recuperato) copre le entità e le operazioni richieste. Se la copertura è insufficiente, viene emesso un rifiuto generico.
- Assemblaggio del Contesto: Il contesto finale è assemblato partendo da tabelle, colonne, relazioni e artefatti derivati autorizzati.

3. Contributi Chiave

Framework di Confidenzialità dello Schema Pre-Generazione: Gli autori isolano la confidenzialità dello schema pre-generazione come un obiettivo distinto dalla l'autorizzazione SQL post-generazione. Definiscono un modello di minaccia per l'elaborazione dello schema tra confini diversi e introducono una metrica di esposizione a livello di processo. Il meccanismo proposto assicura che gli oggetti non autorizzati e i loro artefatti derivati siano rimossi prima di qualsiasi computazione di recupero della rilevanza.
Evidenza Empirica per l'Ordinamento e la Difesa in Profondità: Attraverso esperimenti controllati in cui i prompt finali sono byte-identici tra il metodo proposto e un baseline "retrieve-then-mask", gli autori dimostrano che l'eliminazione della fuga a livello di processo è attribuibile esclusivamente all'ordine dell'autorizzazione (pre-recupero vs post-recupero). Inoltre, l'analisi della fuga-provenienza dimostra che la minimizzazione del contesto e la validazione post-generazione mitigano rischi ortogonali: i contesti a schema completo perdono informazioni tramite injection diretta, mentre le fughe residue sotto il framework proposto originano esclusivamente dall'allucinazione del modello.
Risultati Condizionali sull'Arricchimento Semantico: Il paper stabilisce che l'opacità dell'identificatore è una precondizione per il beneficio dell'arricchimento semantico. Mentre l'arricchimento non produce guadagni misurabili su dataset standard con identificatori in linguaggio naturale, esso migliora significativamente il recall dello schema e l'accuratezza downstream su schemi di tipo aziendale sistematicamente abbreviati.

4. Risultati Sperimentali

Il framework è stato valutato su un benchmark Spider aumentato con controllo degli accessi contenente 240 coppie domanda-ruolo su 20 database e quattro livelli di permessi.

Esposizione a Livello di Processo: Il framework ha ridotto l'esposizione dello schema a livello di processo da una media di 35,5 oggetti non autorizzati per richiesta (nei baseline a schema completo) a 0. Ciò è stato ottenuto a costo zero di utilità rispetto a un baseline "retrieve-then-mask" con budget equivalente.
Fuga SQL: I riferimenti SQL non autorizzati sono stati ridotti da 0,546 (Schema completo) a 0,115.
- La riduzione da 0,546 a ~0,15 è stata guidata dalla minimizzazione del contesto (dimensione del contesto ridotta).
- La riduzione ulteriore a 0,115 è stata guidata dal gate di soddisfacibilità.
Provenienza della Fuga: L'analisi ha mostrato che, sotto il framework proposto, il 100% dei riferimenti SQL non autorizzati che si sono verificati è originato dall'allucinazione del modello (indovinare gli identificatori) piuttosto che dal contesto fornito. Al contrario, sotto i baseline a schema completo, il 100% delle fughe è stato copiato direttamente dal contesto.
Resistenza al Prompt Injection: In un caso di studio riguardante attacchi di enumerazione diretta e role-play, il framework ha ridotto il recupero di tabelle non autorizzate dal 40–55% (Schema completo) allo 0,00% in configurazioni di schema offuscato.
Impatto dell'Arricchimento Semantico: Su schemi offuscati, l'arricchimento semantico ha migliorato il recall del recupero di +11,5 punti percentuali e lo SchemaF1 di +6,6 punti percentuali. Su schemi in linguaggio naturale, non ha mostrato guadagni misurabili.

5. Significato e Assertions

Il paper sostiene che l'autorizzazione deve precedere il recupero per ottenere la confidenzialità a livello di processo nei sistemi Text-to-SQL. Gli autori argomentano che le difese post-generazione sono insufficienti perché non possono revocare le informazioni già osservate dai componenti a minore fiducia.

Il significato del lavoro risiede in:

Cambio Architetturale: Spostare il confine di sicurezza dallo strato di esecuzione SQL allo strato di costruzione del contesto dello schema.
Difesa in Profondità: Dimostrare che la minimizzazione del contesto (impedire al modello di vedere dati sensibili) e la validazione SQL (impedire al modello di eseguire query non autorizzate) affrontano rischi ortogonali e dovrebbero essere usati insieme.
Costo di Utilità Zero: Dimostrare che l'autorizzazione rigorosa pre-recupero non degrada l'utilità del recupero o l'accuratezza della generazione rispetto a un baseline che recupera la stessa quantità di dati autorizzati ma lo fa dopo aver visto l'intero schema.

Gli autori rimangono modesti riguardo ai limiti, notando che il framework non previene l'inferenza da conoscenze pubbliche, messaggi di errore del database o disclosure statistica. Riconoscono inoltre che il gate di soddisfacibilità è un'euristica e che la valutazione si basa su policy sintetiche piuttosto che su ambienti aziendali dinamici. Il framework è presentato come uno strato di minimizzazione delle informazioni che completa, piuttosto che sostituire, i controlli di accesso DBMS e la validazione SQL esistenti.