AI-асистент Microsoft Copilot проігнорував конфіденційність даних
Протягом чотирьох тижнів, починаючи з 21 січня, інструмент Microsoft Copilot несанкціоновано читав та узагальнював конфіденційні електронні листи, незважаючи на те, що всі ярлики чутливості та політики запобігання втраті даних (DLP) забороняли йому це робити. Критичні точки контролю безпеки в конвеєрі Microsoft вийшли з ладу, і жоден із захисних інструментів не зміг це виявити. Серед постраждалих організацій була Національна служба охорони здоров’я Великої Британії, яка зафіксувала інцидент під кодом INC46740412. Цей випадок демонструє масштаб збою, що сягнув сфер регульованої охорони здоров’я. Microsoft відстежував цю проблему під номером CW1226324. Звіт, про який вперше повідомило видання BleepingComputer 18 лютого, свідчить, що це вже другий випадок за вісім місяців, коли механізм отримання даних Copilot порушив встановлені межі довіри. Це означає, що система штучного інтелекту отримала доступ до даних або передала їх, хоча їй було категорично заборонено це робити. Перший випадок був ще серйознішим. У червні 2025 року Microsoft випустила патч для вразливості CVE-2025-32711, яку дослідники з Aim Security назвали “EchoLeak”. Ця критична вразливість дозволяла зловмисним електронним листам обходити класифікатор впровадження підказок Copilot, видалення посилань, політику безпеки контенту (Content-Security-Policy) та механізми згадок, щоб непомітно викрадати корпоративні дані. Для цього не потрібні були жодні кліки чи дії користувача. Microsoft оцінив цю вразливість за шкалою CVSS у 9.3 бали. Причиною двох різних збоїв стали різні фундаментальні помилки, проте результат був ідентичним: AI-система обробляла дані, доступ до яких їй було заборонено, а система безпеки не виявила жодних ознак проблеми.
Чому EDR та WAF залишаються архітектурно сліпими до подібних інцидентів?
Системи виявлення та реагування на кінцевих точках (EDR) відстежують поведінку файлів і процесів. Міжмережеві екрани веб-додатків (WAF) аналізують HTTP-трафік. Жодна з них не має категорії виявлення для “ваш AI-асистент щойно порушив власні межі довіри”. Цей пробіл існує через те, що конвеєри отримання даних для великих мовних моделей (LLM) розташовані за шаром примусового виконання, який традиційні інструменти безпеки не були розроблені для моніторингу. Copilot обробив позначений електронний лист, який мав бути проігнорований, і вся дія відбувалася всередині інфраструктури Microsoft, між індексом отримання даних і моделлю генерації. Жодні дані не записувалися на диск, аномальний трафік не перетинав периметр, і не запускалися процеси, які міг би відстежити агент на кінцевій точці. Система безпеки повідомляла про відсутність загроз, оскільки не бачила рівня, де сталося порушення. Згідно з повідомленням Microsoft, помилка CW1226324 спрацювала через помилку в коді, яка дозволила повідомленням з папок “Надіслані” та “Чернетки” потрапити до набору даних Copilot, незважаючи на ярлики чутливості та правила DLP, які мали б їх заблокувати. “EchoLeak” спрацював тому, що дослідники Aim Security довели, що зловмисний електронний лист, сформульований як звичайна ділова кореспонденція, міг маніпулювати конвеєром генерації з доповненим отриманням даних Copilot, спонукаючи його отримати доступ до внутрішніх даних та передати їх на сервер, контрольований зловмисником. Дослідники Aim Security охарактеризували це як фундаментальний недолік дизайну: агенти обробляють довірені та недовірені дані в одному процесі мислення, що робить їх структурно вразливими до маніпуляцій. Цей недолік дизайну не зник після того, як Microsoft виправила “EchoLeak”. CW1226324 доводить, що шар примусового виконання навколо нього може вийти з ладу незалежно.
П’ять кроків аудиту, що охоплюють обидва сценарії збою
Жоден із цих збоїв не викликав жодного сповіщення. Обидва були виявлені через канали інформування постачальника, а не через SIEM, EDR чи WAF. CW1226324 став публічно відомим 18 лютого. Постраждалі орендарі були під загрозою з 21 січня. Microsoft не розголошує, скільки організацій постраждало або які дані були доступні протягом цього періоду. Для керівників служби безпеки саме ця прогалина є ключовою: чотиритижневе розкриття даних у конвеєрі виведення результатів постачальника, невидиме для всіх інструментів у системі, виявлене лише тому, що Microsoft вирішила опублікувати повідомлення.
- 1. Тестуйте примусове застосування DLP безпосередньо щодо Copilot. CW1226324 існував протягом чотирьох тижнів, тому що ніхто не перевірив, чи Copilot насправді дотримується ярликів чутливості для папок “Надіслані” та “Чернетки”. Створюйте тестові повідомлення з мітками в контрольованих папках, робіть запити до Copilot і переконайтеся, що він не може їх отримати. Виконуйте цей тест щомісяця. Конфігурація — це не примусове виконання; єдиним доказом є невдала спроба отримання даних.
- 2. Блокуйте надходження зовнішнього вмісту до контекстного вікна Copilot. “EchoLeak” спрацював тому, що зловмисний електронний лист потрапив до набору даних Copilot, а впроваджені інструкції виконувалися так, ніби вони були запитом користувача. Атака обійшла чотири різні рівні захисту: класифікатор впровадження між запитами Microsoft, видалення зовнішніх посилань, засоби контролю безпеки контенту та захист від згадок, згідно з інформацією Aim Security. Вимкніть зовнішній контекст електронної пошти в налаштуваннях Copilot та обмежте рендеринг Markdown у вихідних даних AI. Це усуває клас збоїв, пов’язаних із впровадженням підказок, шляхом усунення поверхні атаки.
- 3. Аудитуйте журнали Purview на предмет аномальних взаємодій Copilot протягом періоду викриття з січня по лютий. Шукайте запити Copilot Chat, які повернули вміст з позначених повідомлень між 21 січня та серединою лютого 2026 року. Жоден клас збою не генерував сповіщень через наявні EDR або WAF, тому ретроспективне виявлення залежить від телеметрії Purview. Якщо ваш орендар не може реконструювати, до яких даних Copilot мав доступ під час періоду викриття, офіційно задокументуйте цю прогалину. Це важливо для відповідності нормативним вимогам. Для будь-якої організації, яка підлягає регуляторній перевірці, незадокументована прогалина в доступі до даних AI під час відомого вікна вразливості є приводом для аудиторського висновку.
- 4. Увімкніть обмежене виявлення вмісту (Restricted Content Discovery) для сайтів SharePoint з конфіденційними даними. RCD повністю виключає сайти з конвеєра отримання даних Copilot. Це працює незалежно від того, чи виходить порушення довіри від помилки в коді, чи від впровадженої підказки, оскільки дані взагалі не потрапляють до контекстного вікна. Це шар стримування, який не залежить від збою точки примусового виконання. Для організацій, які обробляють конфіденційні або регульовані дані, RCD не є опціональним.
- 5. Створіть план реагування на інциденти для збоїв виведення результатів, розміщених у постачальника. Плани реагування на інциденти (IR) потребують нової категорії: порушення межі довіри в межах конвеєра виведення результатів постачальника. Визначте шляхи ескалації. Призначте відповідальних. Встановіть графік моніторингу повідомлень про стан послуг постачальника, які впливають на обробку AI. Ваш SIEM наступного разу також не виявить проблеми.
Шаблон, що виходить за межі Copilot
Опитування Cybersecurity Insiders 2026 року показало, що 47% керівників відділів інформаційної безпеки (CISO) та старших керівників з питань безпеки вже спостерігали, як AI-агенти демонструють ненавмисну або несанкціоновану поведінку. Організації впроваджують AI-асистентів у виробництво швидше, ніж встигають створити для них систему управління. Ця тенденція має значення, оскільки ця структура не є специфічною для Copilot. Будь-який асистент на основі RAG (Retrieval-Augmented Generation), який отримує дані з корпоративних джерел, проходить через той самий процес: шар отримання вибирає вміст, шар примусового виконання контролює, що модель може бачити, і шар генерації створює вихідні дані. Якщо шар примусового виконання виходить з ладу, шар отримання надає моделі заборонені дані, а система безпеки ніколи цього не бачить. Copilot, Gemini for Workspace та будь-який інструмент з доступом до внутрішніх документів несе такий самий структурний ризик. Виконайте п’ять кроків аудиту перед вашим наступним засіданням правління. Почніть з тестових повідомлень з мітками в контрольованій папці. Якщо Copilot їх отримає, вся політика нижче — це лише формальність. Відповідь для правління: “Наші політики були налаштовані правильно. Примусове виконання вийшло з ладу в межах конвеєра виведення результатів постачальника. Ось п’ять контролів, які ми тестуємо, обмежуємо та вимагаємо перед повторним увімкненням повного доступу для критично важливих робочих навантажень”. Наступний збій не надішле сповіщення.
Порада від ІТ-Блог:
Ця новина надзвичайно важлива для будь-якого бізнесу, який використовує або планує використовувати AI-інструменти на кшталт Microsoft Copilot. Вона підкреслює необхідність не лише налаштовувати політики безпеки, а й постійно перевіряти їхнє реальне функціонування, особливо в контексті нових технологій. Усвідомлення цих ризиків та впровадження запропонованих кроків аудиту допоможе мінімізувати потенційні загрози витоку конфіденційних даних.
Подробиці можна знайти на сайті: venturebeat.com