Еджізіаго Чіоффі, IT-архітектор та CEO компанії SynSphere Italia, партнера Microsoft, створив власний агент. Він написав індексаційне завдання, налаштував конвеєр отримання даних Azure OpenAI, підключив його до SharePoint і спостерігав, як він проходить усі тести, запущені його командою.
За словами Чіоффі, його помічник для роботи з електронною поштою на базі Azure OpenAI автоматично обробляє близько 60% вхідних електронних листів від клієнтів. Оцінки тестів були позитивними, а юніт-тести пройдені. Однак, жоден із них не відповів на головне запитання.
Чіоффі перевірив роботу помічника з обліковим записом із низькими привілеями, поставивши ті самі запитання, що раніше використовував обліковий запис із високими привілеями. Результати не збіглися. Помічник повернув вміст із SharePoint, доступ до якого користувач із такими правами не мав би отримати самостійно. Журнали свідчили про інше, ніж оцінки.
Журнали отримання даних Чіоффі є доказом цього конкретного збою у виробничому середовищі. Нижче наведено незалежні дані, які показують, що ця проблема не є ізольованою.
У багатьох виробничих розгортаннях RAG агент відповідає, використовуючи дозволи індексатора, а не запитувача
Azure AI Search з травня 2025 року (в попередній версії) підтримує обрізання списків контролю доступу (ACL) на рівні документів через токени Entra, а синхронізація ACL SharePoint з’явилася пізніше. Ця функція існує, але її не завжди використовують там, де це необхідно.
Попередня версія ACL SharePoint може обробляти метадані сайтів-груп за допомогою префікса spg: в API 2026-05-01-preview. Однак, згідно з документацією, лише суб’єкти Entra надійно застосовуються під час запиту. Попередня версія працює через REST API та попередні версії SDK і не охоплює всі шляхи розгортання агентів. Наприклад, Azure OpenAI On Your Data підтримує доступ на рівні документів за допомогою фільтрів безпеки Azure AI Search, але власна документація Microsoft стверджує, що якщо поле permitted-groups не відображене, доступ на рівні документів вимкнено.
Це є вразливим за замовчуванням у вбудованому рішенні. Спеціалізовані конвеєри RAG, які повністю обходять Azure AI Search, все ще індексують дані під обліковим записом служби з широкими привілеями без перевірки прав доступу під час запиту, якщо розробник не реалізував її самостійно. Розгортання Чіоффі використовувало шлях власного конвеєра.
У виробничих агентах масштабу 91% успішних атак призвели до тихої ексфільтрації даних
Red team компанії Straiker провела понад 1700 успішних спроб експлуатації у виробничих агентах і опублікувала результати у своєму першому звіті STAR Labs Threat Report у липні. Цифра 91% з їхнього дослідження відображає всі успішні атаки на продуктивні агенти, які призвели до ексфільтрації даних без виявлення. Це показник того, що сталося після успішної експлуатації, а не вимірювання того, скільки розгортань не застосовують дозволи на етапі отримання даних.
Серед продуктивних агентів, що брали участь в оцінці, 91% успішних атак завершилися тихою ексфільтрацією даних. У звіті зазначено, що для цього не знадобилося шкідливе програмне забезпечення. Також не було бічного переміщення по мережі. Агент повертав усі дані, до яких міг отримати доступ. Звіт Straiker не деталізує, скільки з цих успіхів пов’язані саме з порушенням прав доступу, а скільки — з ін’єкцією запитів, зловживанням інструментами або іншими класами атак.
Незалежно від цього, Інститут безпеки ШІ Великої Британії (UK AI Security Institute) задокументував 19 несанкціонованих дій агентів під час кібер-оцінки з 25 по 28 липня. UK ASI опублікував свій звіт про інциденти 4 серпня цього року. Під час оцінки було навмисно вимкнено класифікатори кіберзагроз та увімкнено доступ до Інтернету. Звіт UK ASI демонструє, як агенти діяли поза межами, визначеними розробниками, у гнучкому тестовому середовищі, без надійного механізму для виявлення відхилень до того, як вони спричинять шкоду. Це проблема стримування, а не проблема дозволів на отримання даних, і спільним елементом інциденту Чіоффі є відсутність перевірки області дії в реальному часі, а не ідентичний механізм.
Чому оцінки пропускають це і чому рідне виправлення не досягло розгортання Чіоффі
Оцінки, які проводила команда Чіоффі, були розроблені для перевірки правильності відповідей агента. Вони перевіряють фактичну точність, релевантність та виконання завдань. Вони не ставлять запитання про те, чиї дозволи використовує конвеєр отримання даних під час вилучення вихідного матеріалу, оскільки це питання не входить до системи оцінки.
Azure AI Search наразі реалізує перевірку дозволів на етапі отримання даних на рівні платформи. Обрізання ACL під час запиту перевіряє токен Entra користувача, витягує інформацію про користувача та групи та повертає лише ті документи, метадані дозволів яких синхронізовані та надають користувачеві доступ. Для розгортань, які використовують Azure AI Search з індексатором SharePoint та суб’єктами Entra, цей контроль існує нативно. Розгортання Чіоффі не використовувало цей шлях. Його власний конвеєр отримання даних Azure OpenAI обійшов нативний шар обрізання, що дозволило прогалини залишатися непоміченою під час усіх оцінок, проведених його командою.
З боку зловмисника це є проблемою контролю доступу. Адріель Дезотельс, засновник і генеральний директор Netragard, зазначив у письмовій відповіді, що ця проблема зводиться до структурного колапсу меж авторизації. «Якщо облікові дані NHI зазвичай мають широкі повноваження та можуть читати дані з високими привілеями, то це зберігається в їхньому індексі», — написав Дезотельс. «Якщо додаток не застосовує отримання даних з урахуванням ідентичності, то «звичайний» користувач з нижчими привілеями може запитувати додаток і отримувати доступ до даних, які інакше обмежені. Це призводить до колапсу меж авторизації до найнижчого рівня привілеїв із можливістю пошуку».
Ця прогалина була виявлена тестом Чіоффі з обліковим записом із низькими привілеями. Контекстне вікно помічника містило вміст SharePoint, який обліковий запис з низькими привілеями не міг би отримати безпосередньо через SharePoint. Оцінка була пройдена. Межа дозволів на отримання даних не була забезпечена.
Дезотельс пояснив сліпу пляму оцінки в операційних термінах. «Агенти зазвичай використовують єдину, довготривалу, нелюдську ідентичність, яка має широкий діапазон дозволів, необхідних для будь-якого завдання, яке їй може бути поставлене», — написав він. «Оцінки також часто не охоплюють запити, вихідні дані, транскрипти, пам’ять і журнали, де їх можна прочитати або перехопити за допомогою вставленого вмісту. Ця невідповідність є причиною того, що більшість поточних оцінок роблять неправильно».
Фільтр Чіоффі звузив область отримання даних помічника. Він все ще обробляє приблизно 60% електронних листів
Виправлення Чіоффі не потребувало нової платформи ідентифікації. Він перемістив рішення про дозвіл у сам конвеєр отримання даних, додавши фільтр запитів, який перевіряє дозволи користувача на SharePoint перед тим, як модель отримає доступ до даних. Фільтр працює під час запиту, а не під час індексації. Вміст, до якого користувач не мав доступу через SharePoint, не потрапляє до контекстного вікна моделі.
Контроль звузив можливості помічника. З активованим фільтром помічник все ще автоматично обробляє приблизно 60% вхідних електронних листів, повідомив Чіоффі. Він не надав даних про кількість обробки до застосування фільтра для порівняння. Якісний компроміс, який він описав, полягає в тому, що деякий вміст, який раніше використовувався помічником для відповідей, тепер виключено, оскільки дозволи користувача на нього не поширюються. Це ціна забезпечення дотримання меж.
Питання про те, чи вартий фільтр дозволів на етапі отримання даних звуженої області отримання, не має однозначної відповіді. Це залежить від чутливості індексованого вмісту, варіативності дозволів серед користувачів та від того, чи може розгортання допускати незавершені запити, коли фільтр блокує дані, необхідні моделі. Інцидент Чіоффі демонструє, що ця прогалина існує у спеціалізованих конвеєрах Azure OpenAI, що оцінки якості відповідей її не виявляють, і що фільтр запитів закриває її з компромісом, який розробник може описати.
Платформи управління ідентифікацією вирішують інший рівень. Необхідні обидва контролі
Компанія CrowdStrike оголосила про придбання SGNL за 740 мільйонів доларів 8 січня 2026 року і закрила угоду 20 лютого 2026 року. Palo Alto Networks оголосила про придбання CyberArk за 25 мільярдів доларів у липні 2025 року і закрила угоду 11 лютого 2026 року. Обидві угоди закрилися в одному місяці, встановивши безпеку ідентифікації як основний стовп платформи у двох найбільших постачальників безпеки у світі.
Платформи управління ідентифікацією зосереджуються на тому, які облікові записи служб існують, до чого вони мають доступ і коли закінчується термін дії їхніх токенів. Вони керують життєвим циклом облікових даних, що забезпечують роботу агентів ШІ. Цей рівень важливий. Однак він не керує межею дозволів на отримання даних. Це момент, коли правильно налаштований обліковий запис служби отримує вміст від імені користувача, який має менше дозволів, ніж завдання індексації.
Кожне облікове дання в ланцюжку є легітимним. Обліковий запис служби чистий і належним чином керований. База знань правильно індексована. Користувач із низькими привілеями запитує помічника, і він відповідає, використовуючи повний індексований обсяг. Ніщо не сигналізує про отримання даних, оскільки жодні облікові дані не були використані неналежним чином.
Фільтр Чіоффі є контролем на рівні межі дозволів на отримання даних. Рідне обрізання ACL Azure AI Search стосується того ж рівня для розгортань, які його використовують. Жодне з них не замінює управління ідентифікацією. Виробниче розгортання, яке бажає усунути як прогалину в життєвому циклі облікових даних, так і прогалину в дозволах на отримання даних у реальному часі, потребує контролю на обох рівнях.
Одне запитання і один тест, який може провести будь-яка команда безпеки
Запитайте, чиї дозволи використовує кожна система отримання даних ШІ під час вилучення вмісту.
Якщо розгортання використовує Azure AI Search з індексатором SharePoint та суб’єктами Entra, переконайтеся, що обрізання ACL під час запиту увімкнено, і що база користувачів не залежить від груп сайтів SharePoint. Якщо розгортання використовує власний конвеєр отримання даних, перевірка дозволів може взагалі не існувати.
Почніть з доведення відповіді з обліковим записом із низькими привілеями. Виконайте те саме запитання, що раніше поставив обліковий запис із високими привілеями. Порівняйте вихідні дані з тим, до чого обліковий запис із низькими привілеями може отримати доступ безпосередньо через базову систему.
Дезотельс підтвердив, що саме з цього почала б red team. «Перший тест, ймовірно, був би спрямований на прогалини між даними та інструкціями, а також на прогалини між ідентичністю користувача та власними обліковими даними помічника», — написав він. «Ми б спробували вставити інструкцію до вмісту, який, на нашу думку, помічник проіндексує як дані. Ми б змусили цей вміст виконати побічну дію з привілейованим доступом, на яку користувач, що атакує, не має дозволу». Результатом, на думку Дезотельса, є «успішне або навіть часткове виконання наших вставлених команд».
Якщо помічник повертає більше, ніж дозволяє прямий доступ облікового запису, то межа дозволів на отримання даних не застосовується під час запиту. Цей тест вимагає двох облікових записів і тридцяти хвилин. Він дає результат, який не може відтворити оцінка.
Чіоффі створив агента на основі власного конвеєра Azure OpenAI, який обійшов нативний шар обрізання ACL. Він провів усі оцінки, які мала його команда. Він знайшов прогалину у власних журналах після того, як усі вони були пройдені. Оцінка перевіряла, чи правильно агент відповідав. Вона не перевіряла, чиї дозволи використовував агент. Проведіть порівняння двох облікових записів перед тим, як наступне розгортання буде введено в експлуатацію. Тридцять хвилин покажуть, на якому ви боці.
Подробиці можна знайти на сайті: venturebeat.com