Як Sentry сприяв атаці на Claude Code: вразливості Datadog, PagerDuty та Jira

Один фальшивий звіт про помилку успішно обійшов захист Claude Code під час контрольованих тестів — агент виконав код зловмисника з повними привілеями розробника, і жодного сповіщення не спрацювало. Системи EDR, WAF, IAM та міжмережевий екран повністю пропустили цю атаку.

Розкриття інформації від Tenet Security щодо проблеми “agentjacking” у червні описує один майстерно створений івент помилки Sentry — надісланий через публічний ключ доступу, який не вимагає жодного зламу чи автентифікації — що впровадив інструкції зловмисника до даних про помилки. Ці дані потім Claude Code, Cursor та Codex виконали як довірений діагностичний вивід. Tenet протестував понад 100 цілей в контрольованих умовах і досяг 85% успіху. Sentry назвав цю вразливість “технічно не захищеною”.

Cloud Security Alliance класифікувала agentjacking як системний клас вразливостей MCP (Managed Connected Platform) невдовзі після розкриття. Не було викрадено жодних облікових даних, не було порушено жодної політики, не було зламано жодного периметра: кожен крок у ланцюжку був авторизований. Це і є проблема.

Tenet ідентифікував 2 388 організацій з публічно доступними ключами доступу Sentry, які потенційно можуть бути використані для масового впровадження шкідливих подій. Дослідження є доказом концепції (proof-of-concept), а не підтвердженою експлуатацією у всіх 2 388 випадках. Однак, у захопленому середовищі Claude Code було виявлено діючий ключ доступу AWS та URL-адреси приватних репозиторіїв.

Ось тест на обсяг: якщо ваші AI-агенти для розробки коду підключені до Sentry, Datadog, PagerDuty, Jira або будь-якого іншого джерела даних, підключеного до MCP, якому довіряють ваші розробники — і ці агенти можуть виконувати команди оболонки (shell commands) — тоді ваш стек має таку ж сліпу зону.

Організації, що використовують Sentry, повинні негайно провести аудит усіх публічно доступних DSN (Data Source Names). Архітектура Sentry навмисно робить ключі DSN публічними для звітності про помилки на стороні клієнта (frontend), тому пом’якшення наслідків полягає не у відкликанні DSN, а в обмеженні того, що агенти можуть робити з даними, які ці DSN повертають.

Чому ваш стек не бачить цю загрозу

Agentjacking працює, тому що кожен крок є авторизованим: зловмисник надсилає дійсний API-запит Sentry, використовуючи публічний DSN, сервер MCP повертає впроваджену подію як автентичний вивід, а агент виконує інструкцію, використовуючи привілеї розробника. Жодного сигнатурного виявлення не було. Жертва бачила лише нешкідливі діагностичні повідомлення, тоді як агент тихо викрадав хмарні облікові дані та токени керування вихідним кодом.

Команди SOC (Security Operations Center) ніколи не потребували розрізняти, чи запускає розробник команду `npm install`, чи агент виконує цю команду у відповідь на шкідливу подію помилки. Це розходження не існувало доти, доки AI-агенти для розробки коду не стали інструментами для виробництва. Стек, який не може зробити це розходження, — це стек, який обходить agentjacking.

П’ять опитувань, одна закономірність

П’ять незалежних опитувань, проведених у першій половині 2026 року, показали, що підприємства довіряють своїм AI-агентам значно більше, ніж це виправдовує їхній рівень безпеки.

Лише 34% організацій застосовують ті ж самі заходи безпеки до AI-агентів, що й до людей, згідно з опитуванням Okta/Apprize360, у якому взяли участь 292 керівники та 492 працівники. П’ятдесят два відсотки співробітників використовують несанкціоновані AI-інструменти, а 58% керівників повідомили про інцидент, пов’язаний з AI, або про небезпечну ситуацію за попередній рік.

Звіт HiddenLayer “AI Threat Landscape Report 2026”, який охопив 250 ІТ-керівників та спеціалістів з безпеки: 33% повідомили, що агенти вже вийшли за межі дозволеної функціональності, а 31% не могли підтвердити, чи зазнали вони злому, пов’язаного з AI. Один із восьми випадків злому, пов’язаних з AI, був пов’язаний з агентними системами.

Опитування Gravitee, у якому взяли участь понад 900 керівників та практиків, показало, що лише 14,4% агентів були запущені в експлуатацію з повним схваленням безпеки, і 88% повідомили про підтверджені або підозрювані інциденти. Подальше опитування 750 керівників у квітні виявило, що кількість агентних систем подвоїлася, тоді як моніторинг майже не змінився.

Розрив у робочому часі, який ніхто не закрив

«Безпека агентів дуже схожа на безпеку високопривілейованих користувачів», — сказав Елія Зайцев, технічний директор CrowdStrike, в інтерв’ю VentureBeat. «Вони мають ідентичності, доступ до базових систем, вони міркують, вони діють».

Зайцев вказав на прогалину, яку промисловість залишила відкритою. «Ніхто не говорив про безпеку агентів під час виконання (runtime). Ми робимо це зараз. Яка ваша система безпеки? Якщо всі ці засоби контролю зазнають невдачі, як ви запобіжите їхній безшумній роботі?»

Дані CrowdStrike кількісно оцінюють ризик: понад 1 800 агентних додатків на корпоративних кінцевих точках, приблизно 160 мільйонів екземплярів під моніторингом. 15 червня CrowdStrike представив Continuous Identity for AI Agents на Identiverse, замінивши статичні політики безперервним виконанням, яке авторизує кожну дію агента в режимі реального часу. Клас контролю, який відображає це оголошення — безперервна авторизація на рівні дій з перевіреною ідентичністю агента — тепер є базовим критерієм закупівлі незалежно від постачальника.

«Люди якось забули про безпеку під час виконання», — сказав Зайцев. «Ми зробили це з кінцевими точками, віртуалізацією та хмарою. Люди зосередилися на виправленні вразливостей, блокуванні дозволів. Чомусь вони завжди щось пропускають. Система безпеки — це робочий час».

Зайцев був однаково прямолінійним щодо підходів з використанням пісочниць (sandbox). «Якщо ви почнете з агента в пісочниці, який не має можливості нічого торкнутися, він марний. Дуже швидко ви опиняєтеся в цій гонці, надаючи йому більше можливостей. І тоді який сенс у вашій пісочниці?» Агенти отримують свою цінність від доступу. Кожен наданий доступ — це поверхня атаки.

Розрив у керуванні — це проблема бюджету

Кейн МакГледрі, старший член IEEE, описав структурну проблему в ексклюзивному інтерв’ю VentureBeat. «У CISO (Chief Information Security Officer) немає бюджету. У CISO немає персоналу. Ми можемо спостерігати ризики, ми можемо консультувати щодо бізнес-ризиків, але ми не володіємо бізнес-системами, на які впливають ці ризики». Коли управління агентами охоплює шість відомчих бюджетів, жоден окремий керівник не може підтвердити, чи отримують агенти такі ж перевірки доступу, як і люди.

Опитування Okta кількісно оцінює розбіжність. Лише 43% працівників вважають політики агентів чіткими, порівняно з 65% керівників, і майже дві третини застосовують слабші засоби контролю до агентів, ніж до людей. Люди, які щодня розгортають агентів, не розпізнають захисну стійку, яку, як стверджує їхнє керівництво, вони побудували.

Ассаф Керен, головний спеціаліст з безпеки Qualtrics та колишній CISO PayPal, висловився прямо. «Реальний ризик починається не з впровадження систем AI. Це факт, що базова архітектура не є добре встановленою. Коли ми ставимо систему AI поверх того, що погано спроектовано, ми прискорюємо розломи». Керен назвав аналітику поведінки під час виконання «невирішеною проблемою на даний момент».

Тест на розрив за 5 запитаннями

Тест на розрив за 5 запитаннями базується на п’яти опитуваннях, проведених у першій половині 2026 року. Кожне запитання відповідає розриву, який використовує agentjacking. Проведіть це перед будь-якою оцінкою постачальника у 3-му кварталі.

Тестований розрив	Доказ	Що порушується	Дії на понеділок	Джерело / зразок
1. Інвентаризація агентів. Який відсоток агентів, підключень MCP та LLM-автоматизацій пройшов перевірку безпеки перед розгортанням?	14,4% отримують повне схвалення безпеки/ІТ перед запуском. 52% співробітників використовують несанкціоновані AI-інструменти. Середнє підприємство зараз керує понад 37 розгорнутими агентами, що приблизно вдвічі більше, ніж у 4-му кварталі 2025 року.	Несанкціоновані агенти невидимі для вашої платформи ідентифікації та не підзвітні у випадку розкриття інформації про злом. Agentjacking націлений саме на такі некеровані підключення MCP. Відсутність перепису означає відсутність аудиторського сліду для регуляторної реакції.	Ініціюйте повний перепис агентів, серверів MCP та LLM-автоматизацій. Зробіть завершення перепису умовою для закупівлі для всіх оцінок постачальників у 3-му кварталі. Позначайте будь-якого агента, виявленого після перепису, як інцидент тіньового AI.	Gravitee State of AI Agent Security 2026, 900+ респондентів (лютий 2026); Gravitee, оновлення від квітня 2026, 750 старших ІТ-керівників; Okta/Apprize360, 292 керівники + 492 працівники (червень 2026)
2. Паритет контролю. Чи отримують агенти ті ж перевірки доступу, обмеження привілеїв та терміни відкликання, що й люди-співробітники?	34% завжди застосовують ті ж засоби контролю до агентів, що й до людей. 61% привілейованого доступу надано без належної перевірки. Лише 22% ставляться до агентів як до незалежних сутностей, що мають ідентичність.	Агент зі статичним OAuth-токеном та без циклу перегляду — це постійний привілейований обліковий запис без терміну дії. Agentjacking успадковує будь-які привілеї, якими володіє розробник. 45,6% організацій покладаються на спільні ключі API для автентифікації між агентами.	Включіть кожного виробничого агента до наступного циклу перегляду доступу. Вимагайте участі людини (human-in-the-loop) для будь-якої дії агента, що стосується персональних даних (PII), фінансових даних або виробничої інфраструктури. Замініть спільні ключі API на обмежені, короткострокові токени.	Okta/Apprize360 (784 респонденти, червень 2026); Palo Alto Networks (2 930 респондентів); Gravitee (900+, дані про спільні ключі API)
3. Відхилення від скоупу. Чи мали будь-які агенти доступ до даних або систем поза межами їхнього визначеного скоупу за останні 12 місяців?	33% повідомляють, що агенти вже вийшли за межі скоупу. 53% кажуть, що агенти час від часу або інколи перевищують дозволи. Meta Sev 1, березень 2026: агент опублікував конфіденційні дані в неавторизований канал. Лише 8% кажуть, що агенти ніколи не перевищують дозволений скоуп.	Відхилення від скоупу спричиняє події, що підлягають звітуванню відповідно до GDPR, CCPA, HIPAA та правил кібербезпеки SEC. Якщо виявлення не може відрізнити доступ, ініційований агентом, від доступу, ініційованого людиною, то терміни розкриття інформації будуть недосяжними. Агенти, що породжують субагентів (25,5% розгорнутих агентів можуть створювати інших агентів), роблять аудиторські сліди алгебраїчно нерозв’язними.	Проведіть 90-денний аудит відхилень від скоупу для кожного виробничого агента. Порівняйте фактично використані ресурси з документацією про затверджений скоуп. Блокуйте делегування від агента до агента без явного схвалення людини для будь-якої дії, що перевищує скоуп батьківського агента.	HiddenLayer AI Threat Landscape 2026 (250 ІТ/спеціалістів з безпеки); CSA AI Agent Security Survey (дані про порушення скоупу); Gravitee (дані про створення агентів)
4. Розрив у сприйнятті керування. Чи 50 працівників скажуть, що ваші політики щодо AI-агентів чіткі?	Розрив у 22 пункти: 65% керівників вважають політики чіткими, 43% працівників погоджуються. 77% команд безпеки бачать ризик тіньового AI, але не мають видимості для дій. 76% вважають тіньовий AI певною або ймовірною проблемою.	Ви оцінюєте постачальників на основі захисної стійкості, яку ваша робоча сила не розпізнає. Кожен тіньовий агент підриває порівняння постачальників. Працівники діляться внутрішніми повідомленнями (54%), даними HR (45%) та конфіденційними документами (39%) з несанкціонованими AI-інструментами.	Проведіть однопитальне опитування перед наступною демонстрацією постачальника. Якщо розрив перевищує 15 пунктів, призупиніть закупівлю. Опублікуйте внутрішню політику прийнятного використання AI-агентів із конкретними прикладами дозволеної та забороненої поведінки агентів.	Okta/Apprize360 (784 респонденти, червень 2026); Ivanti 2026 AI Maturity Report (1 200 респондентів); HiddenLayer (дані про тіньовий AI)
5. Впевненість у виявленні зломів. Чи може ваша команда безпеки підтвердити, чи зазнали ви злому, пов’язаного з AI, за останні 12 місяців?	31% не можуть дати відповідь. 88% повідомили про підтверджені або підозрювані інциденти безпеки AI-агентів. Один із восьми повідомлених зломів, пов’язаних з AI, тепер пов’язаний з агентними системами. Agentjacking довів, що EDR, WAF, IAM та міжмережевий екран не спрацьовують під час атаки, опосередкованої агентом, без жодного сповіщення.	Немає підстав для дотримання термінів розкриття інформації. Немає ланцюга доказів для реагування на інциденти. Немає захищеної позиції у регуляторному розслідуванні. Зобов’язання щодо відповідності EU AI Act для систем високого ризику набувають чинності 2 серпня 2026 року.	Вимагайте специфічного для агентів виявлення під час виконання (runtime detection) як передумову для закупівлі. Переконайтеся, що ваша організація може відрізняти дії, ініційовані агентом, від дій, ініційованих людиною, у виробничих телеметріях. Перевірте здатність вашого SOC визначити конкретну дію конкретному агенту протягом 60 хвилин.	HiddenLayer (250 ІТ/спеціалістів з безпеки); Gravitee (900+, рівень інцидентів); Tenet Security (2 388 організацій під загрозою); CSA (класифікація системних вразливостей MCP)

План дій директора з безпеки

Зобов’язання щодо відповідності EU AI Act для систем високого ризику набувають чинності 2 серпня 2026 року. Це варто врахувати в планах на 3-й квартал.

Проведіть тест на розрив за 5 запитаннями перед будь-якою оцінкою постачальника у 3-му кварталі — його адміністрування нічого не коштує, а чіткість закупівлі, яку він створює, набагато цінніша, ніж 30 хвилин, які він займає.
Розгляньте можливість запровадження специфічного для агентів виявлення під час виконання (runtime detection). Якщо ваш стек не може відрізнити, що зробив агент, від того, що зробив розробник, agentjacking обійде його так само, як він обійшов кожен шар у тестах Tenet. Це розходження — те, що зараз має значення.
Ставтеся до кожного агента як до привілейованого інсайдера. Згідно з опитуванням Okta/Apprize360, лише 34% організацій застосовують ті ж засоби контролю до агентів, що й до людей; закриття цього розриву — це найважливіше, що більшість команд безпеки можуть зробити цього кварталу.
Перевірте розрив у сприйнятті перед інвестуванням у нові інструменти. Одне запитання до 50 працівників. Чи знаєте ви політики вашої компанії щодо AI-агентів? Якщо розрив між їхньою відповіддю та відповіддю керівництва перевищує 15 пунктів, це проблема, яку потрібно вирішити в першу чергу. Жоден продукт постачальника не виправляє захисну стійкість, яку не розпізнає ваша власна робоча сила.
Зробіть завершення перепису агентів умовою для закупівлі — кожен агент, кожне підключення MCP. Команди безпеки, які роблять це правильно, — це ті, хто почав з повним інвентарним списком і рухався далі.

Agentjacking усунув припущення, яке вижило після кожної архітектури безпеки з моменту встановлення першого міжмережевого екрану. Авторизований не означає безпечний. Коли кожен крок у ланцюжку є законним, єдиний захист, який має значення, — це той, що спостерігає за діями агентів. Не за тим, що кажуть політики. За тим, що роблять агенти.

Як захиститися (Порада ІТ-Блогу):

Обмежте можливості AI-агентів: Перегляньте та суворо обмежте дозволи (привілеї) для всіх AI-агентів, особливо для тих, що підключені до зовнішніх сервісів (як-от Sentry). Надавайте мінімально необхідні права (principle of least privilege). Розгляньте можливість ізоляції їхніх дій у безпечному середовищі (sandbox) для завдань, які не вимагають прямого доступу до критичної інфраструктури.
Впроваджуйте моніторинг дій на рівні виконання: У сучасному середовищі, де AI-інструменти стають все більш потужними, традиційні методи виявлення загроз можуть бути недостатніми. Необхідно запровадити системи моніторингу, які аналізують поведінку агентів у реальному часі (runtime behavior analytics), щоб виявляти підозрілі або несанкціоновані дії, які виходять за межі визначеного скоупу.

Подробиці можна знайти на сайті: venturebeat.com