Технічний контекст
Я люблю такі кейси не за драму, а за чесну механіку атаки. Тут все надто знайоме для тих, хто впроваджує AI-інтеграції в реальних компаніях: сторонній AI-сервіс, широкі права OAuth, один скомпрометований акаунт, і далі ефект доміно.
За даними Vercel, точка входу була не у них, а в Context.ai, яким користувався співробітник. Через компрометацію цього стороннього інструменту зловмисник перехопив Google Workspace-акаунт працівника Vercel, а вже звідти дістався до частини внутрішніх середовищ та змінних оточення, які не були позначені як чутливі (sensitive).
Критичний нюанс у тому, що змінні, позначені як sensitive, за словами Vercel, не були доступні в читабельному вигляді. І ось тут я справді зупинився: вся різниця між «неприємним інцидентом» і «повним жахом» впиралася в банальну дисципліну класифікації секретів.
З додаткового контексту картина ще жорсткіша. У Context.ai, судячи з опублікованих даних, вкрали токени OAuth після зараження машини співробітника інфостілером, потім використали вже видані доступи, щоб зайти не через периметр, а через довірену інтеграцію. Це майже підручник з атаки на ланцюг постачання (supply-chain), тільки з AI-ярликом зверху.
Мене тут найбільше чіпляє не сам факт витоку, а те, наскільки легко команди досі сприймають AI-інструменти як «просто зручний SaaS». Ні, це вже частина вашого простору ідентичності та вашої AI-архітектури, особливо якщо сервіс просить доступ до Workspace, пошти, документів, логів чи токенів для розгортання.
Що це змінює для бізнесу та автоматизації
Перше: OAuth для AI-сервісів треба розглядати як доступ до продакшену, а не як нешкідливу кнопку «Увійти через Google». Якщо ви будуєте AI-автоматизацію і підключаєте зовнішні інструменти до Workspace, Slack, GitHub або Vercel, у вас вже є поверхня для атаки на ланцюг постачання.
Друге: змінні оточення без нормальної класифікації тепер виглядають як забута міна. Неважливо, чи вважаєте ви їх «не дуже чутливими», якщо через них можна розгорнути бічний рух (lateral movement), зібрати API-ключі або токени для деплою.
Третє: виграють команди, у яких є підхід нульової довіри (zero-trust) до будь-якого AI-агента та сторонньої інтеграції. Програють ті, хто роздає широкі права (scopes), не перевіряє видані токени і зберігає секрети за принципом «потім розберемося».
Я у клієнтів постійно бачу одну й ту саму помилку: хочуть швидкого впровадження штучного інтелекту (artificial intelligence), але безпеку підключень вважають вторинним завданням. А потім саме вона визначає, буде у вас прискорення процесів чи дорогий інцидент.
Якщо у вас вже росте зоопарк AI-інструментів, я б на вашому місці прямо зараз пройшовся по OAuth-дозволах, класифікації секретів та доступах агентів. Якщо потрібно, ми в Nahornyi AI Lab можемо спокійно розібрати вашу схему і зібрати AI-автоматизацію так, щоб вона економила час, а не відкривала бічні двері для наступного злому.