Egiziago Cioffi, az IT és Enterprise Architect, valamint a SynSphere Italia vezérigazgatója — egy milánói Microsoft-partner — saját maga épített egy Azure OpenAI-alapú e-mail asszisztenst. Cioffi írta az indexelő munkát, konfigurálta az Azure OpenAI lekérdezéses (retrieval) csővezetékét, és csatlakoztatta azt SharePointhoz. A csapat által végzett értékelések és egységtesztek mind sikeresnek mutatták az asszisztenst; a rendszer automatikusan megoldotta a beérkező ügyféllevelek nagyjából 60%-át, Cioffi szerint.
A valós hiba csak akkor derült ki, amikor Cioffi egy alacsony jogosultságú fiókkal lefuttatta ugyanazokat a kérdéseket, amelyeket korábban egy magasabb jogosultságú fiókkal teszteltek. Az asszisztens olyan SharePoint-tartalmat adott vissza, amelyet a lekérdező felhasználó a saját SharePoint-jogosultságai alapján nem tudott volna megnyitni. A lekérdezési naplók ezt a termelési hibát bizonyították, noha az értékelési pontszámok tisztának mutatták a rendszert.
Miért történt a hiba
Azure AI Search jelenleg támogatja a lekérdezéskor végzett dokumentumszintű ACL-szűrést (query-time ACL trimming) Entra-alapú tokenekkel; ez a képesség előnézetben elérhető volt 2025 májusa óta, és a SharePoint ACL szinkronizálás későbbi előnézetben követte. A SharePoint ACL előnézet most be tudja vinni a site-group metaadatokat az spg: prefix segítségével a 2026-05-01-preview API-ban, de a dokumentáció szerint megbízható érvényesítés csak az Entra-támogatott entitásoknál van garantálva, és az előnézet REST API/SDK útvonalai nem fednek le minden agent-deploy útvonalat.
Egyes egyedi (custom) RAG-pipeline-ok teljesen kikerülhetik az Azure AI Search réteget, és így az indexelés egy széles körű jogosultságú szolgáltatói fiók alatt történik, anélkül, hogy lekérdezés időben történő jogosultságellenőrzés futna — hacsak a fejlesztő nem épít be ilyet. Cioffi megoldása ilyen egyedi csőutat használt, ezért a natív lekérdezésidő-szűrés nem volt érvényben.
A probléma skálája és kapcsolódó kutatások
A Straiker red team több mint 1 700 sikeres kísérletet futtatott termelési asszisztenseken, és eredményeit a STAR Labs Threat Reportban publikálta júliusban. Az általuk említett 91%-os szám azt mutatja, hogy a vizsgált termelékenységi agentek esetén a sikeres támadások 91%-a adatkinyeréssel végződött anélkül, hogy észlelés történt volna; a jelentés hangsúlyozza, hogy ehhez nem kellett kártevő, és gyakran nem volt laterális mozgás sem — az agent egyszerűen visszaadta a hozzáférhető adatokat. A jelentés azonban nem bontja ki, hogy ezek közül mennyit okoztak konkrétan lekérdezéskor elmulasztott jogosultságellenőrzések.
Függetlenül ettől a Kutatások terén a U.K. AI Security Institute (UKASI) július 25–28. közti kibervizsgálatában 19 nem engedélyezett agent-műveletet dokumentált; az incidenst 2026. augusztus 4-én publikálták. Az UKASI vizsgálat célja az volt, hogy permisszív környezetben demonstrálja az agentek váratlan viselkedését; ez inkább containment (tartás) hibát mutatott, de az átfedés a Cioffi-ügygel az, hogy mindkettőnél hiányzott a futásidejű (runtime) scope-ellenőrzés.
Működés és kockázat: mi a helyzet a jogosultságokkal
Adriel Desautels, a Netragard alapító-vezérigazgatója azt mondta, hogy ez strukturális hozzáférés-ellenőrzési hiba: ha egy indexelő szolgáltatási identitás széles jogosultságokkal rendelkezik, az indexbe kerülő tartalom alapján az alacsonyabb jogosultságú felhasználó is hozzáférhet ahhoz az asszisztensen keresztül, ha nincs identity-aware (azonosítás-alapú) lekérdezés. A gyakorlatban az agentek gyakran egyetlen, hosszú életű, emberi felhasználótól független identitással futnak, amely széles körű jogosultságokat tartalmaz, és az értékelések ritkán vizsgálják a promptokat, kimeneteket, átírásokat, memóriát és naplókat, amelyek révén az információ olvasható vagy manipulálható lehet.
Cioffi megoldása és következményei
Cioffi egyszerű, a lekérdezési útra helyezett szűrőt (query-path filter) épített be: a filter lekérdezéskor ellenőrzi, hogy a kérdező felhasználó SharePoint-jogosultsága megengedi-e az adott dokumentumot, mielőtt az a modell kontextusába bekerülne. Ez indexidő helyett lekérdezésidő ellenőrzés; így a felhasználó számára meg nem nyitható tartalom nem kerül az asszisztens kontextusába.
A szűrő szűkítette az asszisztens által elérhető tartalmat, de az automatizált e-mailfelek megoldási arányát továbbra is nagyjából 60%-on tartotta, Cioffi közlése szerint. A kompromisszum az, hogy egyes korábban használt források most kimaradnak, ha a felhasználói jogosultság nem éri el őket — ez a díja a jogosultsági határok betartatásának.
Az identitásgazdálkodás és a lekérdezésidő-szűrés különböző rétegek
Az identitásgazdálkodási (identity governance) platformok azt ellenőrzik, hogy milyen szolgáltatói fiókok léteznek, mire képesek és mikor járnak le a tokenjeik; ez a hitelesítő adatok életciklusát kezeli. Azonban ez nem kezeli azt a pillanatot, amikor egy helyesen konfigurált szolgáltatói fiók lekérdez egy dokumentumot a felhasználó nevében, aki kisebb jogosultságokkal rendelkezik.
Azure AI Search natív query-time ACL trimmingje és a Cioffi-féle query-path filter ugyanannak a rétegnek a megoldásai: a lekérdezéskor érvényesülő jogosultságellenőrzés rétegének. Mindkettőre szükség lehet: az egyik a hitelesítő adatok életciklusát, a másik pedig a lekérdezés-permission határt kezeli.
Mit tehetnek a csapatok most: egy egyszerű teszt
A szerzők javaslata világos és gyorsan lefuttatható: kérdezzék meg, hogy melyik identitás jogosultságaival fut a lekérdezés, amikor az asszisztens forrást hoz be. Ha Azure AI Search + SharePoint indexer + Entra-principals az üzemeltetési útvonal, ellenőrizzék, hogy a query-time ACL trimming engedélyezve van-e, és hogy a felhasználói populáció nem SharePoint site-groupokra támaszkodik-e. Egyedi csővezeték használatakor a lekérdezésidő-biztonság gyakran hiányzik.
A gyakorlati teszt: használjanak két fiókot (egy magas és egy alacsony jogosultságút). Tegyék fel ugyanazt a kérdést mindkettővel, majd hasonlítsák össze a válaszokat és a SharePointon közvetlenül elérhető tartalmukat. Ha az asszisztens többet ad vissza, mint amit az alacsony jogosultságú fiók közvetlenül elérhet, akkor a lekérdezésidő jogosultsági határ nincs érvényben. A teszt két fiókkal körülbelül 30 percet vesz igénybe.
Összegzés
Cioffi ügye világosan mutatja, hogy egyedi Azure OpenAI csővezetékekben a lekérdezéskor hiányzó jogosultságellenőrzés maradandó rés lehet, amelyet a hagyományos válaszminőség-alapú értékelések nem fognak fel. A megoldás — vagy a platform natív query-time ACL trimmingjének használata, vagy egy lekérdezésidő-szűrő beépítése — csökkenti a kockázatot, de hatással lehet az asszisztens által elérhető tartalomra és ezzel a válaszok lefedettségére. Egy egyszerű, kétfiókos teszttel bármely csapat gyorsan kiderítheti, melyik oldalon áll a rendszerük.
