🤖 AI

Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

Questo documento affronta la lacuna di sicurezza critica nei sistemi aziendali AI multitenant, in cui la pertinenza del recupero prevale sull'autorizzazione, proponendo e validando un'architettura di isolamento a livelli lato server all'interno del framework open-source OGX che impone un'ingestione e un gating del recupero consapevoli delle policy per prevenire la fuoriuscita di dati tra tenant con un sovraccarico di prestazioni trascurabile.

Autori originali: Francisco Javier Arceo, Varsha Prasad Narsing

Pubblicato 2026-05-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Francisco Javier Arceo, Varsha Prasad Narsing

Articolo originale sotto licenza CC BY 4.0 (http://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

Immagina una biblioteca enorme e ad alta tecnologia dove migliaia di aziende diverse (inquilini) hanno affittato scaffali per conservare i loro documenti segreti. In questa biblioteca, ci sono anche robot potenti (agenti AI) assunti per trovare informazioni specifiche ed eseguire compiti in base a ciò che le aziende chiedono.

Il documento di Arceo e Narsing identifica un difetto pericoloso nel funzionamento attuale di queste biblioteche e propone un nuovo sistema di sicurezza per risolverlo.

Il Problema: La Trappola della "Rilevanza"

In una biblioteca normale, se chiedi "ricette", il bibliotecario ti consegna i libri più rilevanti per quella parola. Non gli importa chi possiede i libri; prende semplicemente le migliori corrispondenze.

Gli autori sottolineano che nel mondo dell'AI, questo è un disastro per la sicurezza.

Lo Scenario: L'Azienda A chiede al robot: "Come ripariamo il nostro server?"
L'Errore: Il robot cerca in tutta la biblioteca. Trova un documento dell'Azienda B che è molto simile alla domanda (magari riguarda anch'esso la riparazione di un server).
La Perdita di Dati: Poiché il documento è una "corrispondenza perfetta" per la domanda, il robot lo consegna. L'Azienda A ha appena letto il manuale segreto del server dell'Azienda B.

Il documento definisce questo fenomeno come il "Divario Rilevanza-Autorizzazione". Il sistema è eccellente nel trovare ciò che è rilevante, ma terribile nel verificare chi è autorizzato a vederlo.

La Soluzione: L'Edificio della "Isolazione a Strati"

Per risolvere il problema, gli autori propongono un nuovo progetto edilizio con tre specifici livelli di sicurezza e una regola rigorosa su chi detiene le chiavi.

1. I Tre Livelli di Sicurezza

Immagina il viaggio dei dati come un pacco che attraversa una struttura sicura:

Livello 1: La Stazione di Etichettatura (Ingestione Consapevole delle Policy)
Quando un'azienda consegna una scatola di documenti, il sistema timbra immediatamente ogni singola pagina con un'etichetta "Azienda A" o "Azienda B". Non è possibile dimenticarsi di etichettarle in seguito; ciò avviene nel momento stesso in cui arrivano. Questo assicura che ogni foglio di carta sappia a chi appartiene.
Livello 2: Il Cancello di Sicurezza (Controllo dell'Accesso alla Recupero)
Prima che al robot sia permesso di cercare libri, deve passare attraverso un cancello di sicurezza. Il cancello controlla il badge d'identità dell'utente.
- Se l'utente proviene dall'Azienda A, il cancello blocca fisicamente il corridoio contenente i libri dell'Azienda B.
- Il robot non vede mai i libri proibiti, quindi non può consegnarli per errore. Questo è chiamato controllo ABAC (Controllo di Accesso Basato sugli Attributi).
Livello 3: Il Cervello Condiviso (Inferenza Condivisa)
La parte effettiva di "pensiero" del robot (il modello AI) è condivisa da tutti per risparmiare denaro. Di solito, potresti pensare di aver bisogno di un robot separato per ogni azienda per mantenere segreti al sicuro. Ma poiché i Livelli 1 e 2 assicurano che solo i documenti corretti ed etichettati vengano mai forniti al robot, il robot può essere condiviso in sicurezza. È come uno chef che cucina per tutti, ma gli ingredienti sono pre-ordinati in modo che lo chef non usi mai per errore la ricetta segreta di un cliente nel piatto di un altro cliente.

2. La Regola "Lato Server"

Il documento sostiene che i controlli di sicurezza devono avvenire all'interno dell'edificio (il server), non all'esterno nell'ufficio del cliente (il client).

Il Vecchio Modo (Lato Client): Il computer del cliente esegue la ricerca e i controlli. Un cliente astuto potrebbe semplicemente disattivare il proprio software di sicurezza, ignorare le regole e chiedere al robot di guardare tutto.
Il Nuovo Modo (Lato Server): Il cliente invia una richiesta, ma il team di sicurezza interno dell'edificio esegue tutte le ricerche, l'uso degli strumenti e i controlli. Il cliente può chiedere una "macchina rossa", ma non può dire al team di sicurezza di ignorare le regole e mostrargli una "macchina blu" che appartiene a qualcun altro. L'edificio controlla come avviene la ricerca, assicurando che le regole non vengano mai violate.

I Risultati: Cosa Hanno Testato

Gli autori hanno costruito un sistema prototipale chiamato OGX (Open GenAI Stack) per testare questa idea. Hanno condotto esperimenti con aziende fittizie e domande insidiose per vedere cosa accadeva.

Sicurezza: Senza il nuovo cancello di sicurezza, nel 98–100% dei casi, il robot ha rivelato documenti segreti di altre aziende. Con il nuovo cancello, lo 0% dei segreti è stato rivelato. Il cancello di sicurezza ha fermato completamente le perdite di dati.
Velocità: Aggiungere il cancello di sicurezza ha rallentato le cose di una quantità minima (circa 19 millisecondi). È come aggiungere una pausa di un istante a una conversazione: impercettibile per gli umani ma cruciale per la sicurezza.
Qualità: Poiché il robot non era confuso da documenti irrilevanti di altre aziende, ha effettivamente trovato le risposte corrette più velocemente e con maggiore precisione.

La Conclusione

Il documento conclude che è possibile avere un sistema AI condiviso ed economico per molte aziende diverse senza che queste si rubino i segreti reciproci. Bisogna solo smettere di fidarsi della "rilevanza" di un risultato di ricerca e iniziare a imporre controlli rigorosi di "permesso" alla porta, gestiti tutti da un team di sicurezza centrale all'interno del server.

Sottolineano che questa è una soluzione vendor-neutral, il che significa che non ti vincola a una specifica azienda di AI (come OpenAI o Google); funziona con qualsiasi strumento AI open-source o commerciale tu scelga.

Riepilogo Tecnico: Sicurezza dell'Agente in Ambienti Aziendali Multitenant

1. Enunciato del Problema

Il documento affronta una lacuna fondamentale di sicurezza nella distribuzione di sistemi di Generazione Aumentata dal Recupero (RAG) e sistemi di IA agenti negli ambienti aziendali. Mentre i trattamenti accademici e le API rivolte ai consumatori spesso presuppongono l'accesso ai dati in modalità single-tenant e omogenea, le distribuzioni aziendali reali coinvolgono più tenant che condividono infrastrutture con dati eterogenei, rigorosa conformità normativa e requisiti di controllo degli accessi granulare.

Il problema centrale identificato è il divario tra rilevanza e autorizzazione. I sistemi di recupero esistenti (vettoriale, per parole chiave o ibrido) sono ottimizzati per la rilevanza semantica o la corrispondenza di parole chiave, ma mancano di meccanismi nativi per far rispettare le politiche di autorizzazione. Di conseguenza, una query proveniente da un tenant può recuperare e rendere visibile dati confidenziali appartenenti a un altro tenant se tali dati ottengono il punteggio più alto nelle metriche di rilevanza. Questo divario è esacerbato nei sistemi agenti dove:

La divulgazione mediata da strumenti si verifica quando gli agenti invocano strumenti con credenziali ampie anziché con l'autorizzazione dell'utente finale.
L'accumulo di contesto permette alle conversazioni multi-turno di filtrare dati tra tenant diversi senza una rivalutazione della politica per ogni turno.
L'orchestrazione lato client distribuisce la logica critica per la sicurezza a potenziali client non attendibili, consentendo di aggirare i controlli di autorizzazione.

Gli approcci standard per l'isolamento, come la replicazione dell'intera pila agente (archivi vettoriali, endpoint di inferenza) per ogni tenant, sono considerati proibitivi in termini di costi e operativamente frammentati.

2. Metodologia e Architettura

Gli autori propongono un'architettura di isolamento stratificato imposta attraverso l'orchestrazione lato server per proteggere i percorsi dei dati e di controllo dell'IA agente. Questo approccio è implementato in OGX (Open GenAI Stack), un framework open-source e vendor-neutral che fornisce API compatibili con OpenAI.

2.1 Isolamento Stratificato (Percorso Dati)

L'architettura protegge il flusso dei dati attraverso tre livelli distinti all'interno del confine di fiducia del server:

Ingestione Consapevole delle Politiche: I metadati del tenant (proprietà, attributi) sono allegati ai documenti al momento dell'ingestione. Ciò garantisce che ogni frammento di documento erediti attributi del tenant coerenti, prevenendo un'accoppiata accidentale tra tenant diversi.
Controllo del Recupero: Viene applicato un meccanismo di enforcement a due livelli:
- Pre-ricerca: L'autorizzazione basata su attributi (ABAC) viene valutata prima dell'inizio della ricerca.
- Post-recupero: Viene applicato un filtraggio a livello di frammento dopo il recupero.
- Il sistema supporta il pushdown dei predicati (dove il backend vettoriale applica i filtri nativamente durante la ricerca) per mantenere un richiamo perfetto su larga scala. Se il pushdown non è disponibile, il filtraggio post-recupero garantisce la sicurezza (nessuna perdita di dati) ma può degradare il richiamo su grandi corpora.
Inferenza Condivisa: Il livello di inferenza del Modello Linguistico (LLM) è condiviso tra i tenant. Poiché i livelli 1 e 2 assicurano che solo documenti autorizzati entrino nel contesto del prompt, il modello stesso non richiede isolamento per tenant, riducendo i costi infrastrutturali da $O(N \cdot M)$ a $O(M)$ .

2.2 Orchestrazione Lato Server (Percorso di Controllo)

Per affrontare i rischi di bypass lato client, gli autori sostengono l'orchestrazione lato server del ciclo inferenza $\to$ strumento $\to$ inferenza.

Confine di Fiducia: Tutte le operazioni critiche per la sicurezza (autorizzazione dell'esecuzione degli strumenti, isolamento dello stato, enforcement delle politiche) sono centralizzate all'interno del processo server.
Compromessi: Sebbene ciò introduca latenza per le chiamate agli strumenti rispetto all'esecuzione locale, impedisce a client compromessi di saltare i filtri o manipolare le invocazioni degli strumenti.
Approccio Ibrido: L'architettura permette ai framework lato client di mantenere il controllo sulla composizione dell'agente e sulle operazioni sensibili alla latenza, mentre il server impone gli invarianti di sicurezza.

3. Contributi Chiave

Il documento apporta quattro contributi principali:

Formalizzazione del Divario tra Rilevanza e Autorizzazione: Gli autori definiscono matematicamente perché il ranking basato sulla rilevanza da solo è insufficiente per l'isolamento e forniscono prove empiriche che un recupero non controllato filtra dati tra tenant diversi nel 98–100% delle sonde.
Architettura di Isolamento Stratificato: Un progetto proposto che combina ingestione consapevole delle politiche, controllo al momento del recupero e inferenza condivisa, con l'orchestrazione lato server come livello di enforcement.
Validazione Empirica: Una valutazione con sei esperimenti che misura la sicurezza (perdita di dati, resilienza all'iniezione di prompt), le prestazioni dei sistemi (latenza, throughput) e la qualità del recupero attraverso una matrice $2 \times 2$ di modalità di orchestrazione (client vs server) e controllo del recupero (non controllato vs controllato con ABAC).
Implementazione Open-Source: L'architettura è implementata in OGX, un framework vendor-neutral che offre API compatibili con OpenAI (inclusa un'API Responses per l'orchestrazione multi-turno) e un Operatore Kubernetes per la distribuzione.

4. Risultati Sperimentali

La valutazione ha utilizzato un banco di prova sintetico con tre tenant (finanza, ingegneria, legale) e 300 documenti.

Sicurezza (Perdita di Dati tra Tenant):
- Configurazioni Non Controllate: Indipendentemente dalla modalità di orchestrazione, il recupero non controllato ha portato a una perdita del 98–100% di dati tra tenant diversi.
- Configurazioni Controllate: Il controllo ABAC ha eliminato completamente la perdita di dati tra tenant (0% di perdita), raggiungendo l'obiettivo di sicurezza (G1).
- Iniezione di Prompt: Sotto configurazioni controllate, tutte le 90 sonde di iniezione di prompt sono state bloccate (0% di perdita). Nelle configurazioni non controllate, il 62–80% delle sonde ha recuperato con successo dati non autorizzati.
- Enforcement: Lo studio evidenzia che, sebbene il controllo lato client (Configurazione B) possa raggiungere lo 0% di perdita, dipende dall'integrità del client. L'orchestrazione lato server (Configurazione D) fornisce la garanzia di enforcement necessaria (G2) spostando la logica all'interno del confine di fiducia.
Prestazioni:
- Latenza: Il controllo del recupero ha aggiunto circa 19ms al percorso di ricerca (andata e ritorno di autenticazione + valutazione della politica + ricerca), che è trascurabile rispetto ai tempi di inferenza (secondi). L'orchestrazione lato server ha aggiunto circa 3s di latenza totale a causa delle andate e ritorni, ma supporta lo streaming per ridurre il tempo fino al primo token.
- Throughput: Il controllo non ha degradato il throughput. Il throughput è cresciuto linearmente con la concorrenza. L'orchestrazione lato client ha raggiunto circa il doppio delle QPS (Query Per Second) rispetto all'orchestrazione lato server ad alta concorrenza a causa di percorsi di richiesta più brevi.
Qualità del Recupero:
- Il controllo a livello di frammento ha migliorato la Precision@5 di 2,2 volte (da 0,200 a 0,433) filtrando il rumore tra tenant diversi.
- Pushdown dei Predicati: I backend che supportano il pushdown dei predicati hanno mantenuto Recall@5 = 1,0 attraverso tutte le dimensioni del corpus. I backend senza pushdown (utilizzando il filtraggio post-recupero) hanno visto il richiamo degradare significativamente (da 1,0 a 0,002) mentre la dimensione del corpus aumentava fino a 50k frammenti, sebbene le garanzie di sicurezza rimanessero intatte.

5. Significato e Ambito

Il documento afferma che questo lavoro è il primo ad affrontare l'intersezione tra progettazione standardizzata di API agenti, orchestrazione lato server e isolamento multitenant su infrastrutture condivise.

Significato: L'architettura dimostra che è possibile raggiungere simultaneamente multitenancy sicura, API vendor-neutral compatibili con OpenAI e capacità di agenti autonomi senza duplicazione dell'infrastruttura per tenant. Sposta il paradigma di sicurezza dal recupero "basato sulla rilevanza" al recupero "basato sulle politiche".
Ambito e Limitazioni:
- La soluzione è progettata per ambienti aziendali multitenant; è inutile per distribuzioni single-tenant o dati pubblici.
- L'architettura protegge la costruzione del contesto ma non la memoria parametrica; i modelli potrebbero ancora generare informazioni assorbite durante il pretraining.
- Il confine di fiducia è il processo server; l'architettura non protegge contro processi server compromessi, operatori interni o attacchi side-channel.
- Gli strumenti di funzione lato client rimangono al di fuori del confine di fiducia del server, sebbene OGX mitighi questo aspetto tramite una classificazione esplicita degli strumenti.

Gli autori concludono che, sebbene l'orchestrazione lato client offra una latenza inferiore per ambienti attendibili, l'orchestrazione lato server con controllo ABAC è essenziale per scenari aziendali che richiedono un isolamento rigoroso e conformità.