ШІ як прискорювач: від хмарних зламів до квантового деву

У лютневому випуску технічних новин High Bar Journal Макс Березанський, Tech Lead у Keiki з екосистеми Genesis, аналізує, як ШI одночасно пришвидшує розробку і атаки, чому генерація коду не дорівнює швидшим релізам та чому великі гравці вже готують розробників до квантового майбутнього.

ШІ пришвидшив злам AWS: адмін-доступ за 8 хвилин

У лютому Sysdig Threat Research опублікували звіт про атаку на AWS-середовище, де зловмисник отримав адміністративний доступ менш ніж за 8 хвилин. Ключова особливість інциденту — активне використання LLM для автоматизації атаки.

Почалося все з банальної, але критичної помилки: у публічному S3 bucket залишилися відкриті credentials. Саме вони стали точкою входу. Далі атакер, маючи лише ReadOnlyAccess, провів ескалацію привілеїв через інʼєкцію коду в існуючу Lambda-функцію та ітеративний підбір доступів — і вийшов на адміністративний акаунт.

За даними дослідників, під час атаки LLM використовувалися для:

• збору інформації про хмарне середовище;

• генерації шкідливого коду;

• швидкого перебору ролей і акаунтів;

• прийняття рішень у реальному часі.

  
  

Атака рухалася через 19 різних AWS principal’ів і супроводжувалася латеральним переміщенням між ролями. Дослідники навіть зафіксували ознаки «галюцинацій» у спробах assume-role — характерну рису генеративних моделей.

Окрім отримання доступу, зловмисник:

• ексфільтрував дані;

• створив GPU-інстанси в EC2;

• використав Amazon Bedrock для виклику LLM-моделей (LLMjacking);

• приймав ліцензійні угоди в AWS Marketplace від імені жертви.

  
  

Важливо: сама інфраструктура AWS не була вразливою. Причиною інциденту стала помилка конфігурації — відкритий S3 bucket із ключами доступу.

Цей кейс ще раз підкреслює: security — це не формальність і не чекбокс у процесі. ШI може бути як інструментом захисту, так і потужним прискорювачем атак. Час реагування скорочується з годин до хвилин, і традиційного «буфера» для виявлення вторгнення стає дедалі менше.

Саме тому варто регулярно проводити ревізію своїх credential-політик, переглядати підходи до зберігання ключів, мінімізувати довгоживучі access keys та будувати архітектуру з принципом security by design — коли нові фічі та ініціативи одразу плануються з урахуванням безпеки, а не «допрацьовуються» після інциденту.

У 2026 році ШI стає не лише інструментом розробки, а й повноцінним фактором у ландшафті кіберзагроз. Ігнорувати це вже не можна.

Microsoft відкрила Quantum Development Kit і інтегрувала його з VS Code та Copilot

Microsoft зробила свій Quantum Development Kit (QDK) open source та інтегрувала його з Visual Studio Code і GitHub Copilot. Компанія фактично переносить квантову розробку в знайоме середовище для інженерів — без окремих дослідницьких платформ і спеціалізованих тулчейнів.

Оновлений QDK дозволяє писати, тестувати й симулювати квантовий код локально, підтримує кілька мов, зокрема Q#, OpenQASM, Qiskit і Cirq, та містить бібліотеки для експериментів у квантовій хімії й корекції помилок. Copilot може допомагати з синтаксисом і структурою квантових програм.

Йдеться не про прорив у «залізі» — квантові комп’ютери досі залишаються обмеженими. Але Microsoft робить ставку на формування software-екосистеми вже зараз: щоб розробники могли експериментувати з квантовими підходами у звичному workflow.

Якщо квантові обчислення почнуть масштабуватися, ті, хто вже знайомий із квантовими моделями та мовами, матимуть перевагу. І тут виникає логічне питання: хто швидше освоїть нові квантові мови — люди чи ШI?

Cloudflare винесла self-hosted ШІ-агентів на edge

Cloudflare показала Moltworker — open-source рішення, яке дозволяє запускати self-hosted ШI-агента (Moltbot) не на власному сервері чи VPS, а прямо на інфраструктурі Cloudflare — на edge.

Простими словами: якщо раніше для персонального ШI-агента потрібно було тримати окрему машину або орендувати сервер і все це підтримувати, то тепер його можна розгорнути в екосистемі Cloudflare без управління «залізом».

Архітектура виглядає так: сам агент працює в ізольованих контейнерах (Sandboxes), запити обробляє Cloudflare Worker, а пам’ять діалогів і сесії зберігаються в R2. Для роботи з моделями використовується AI Gateway, для браузерної автоматизації — Browser Rendering, а доступ захищений через Zero Trust.

Cloudflare одразу уточнює: це proof of concept, а не повноцінний продукт. Але сигнал зрозумілий — агентні системи можна запускати ближче до користувача, масштабувати й ізолювати без власної інфраструктури.

Для тих, хто вже використовує self-hosted ШI-агентів, це може бути цікавим варіантом: такий підхід потенційно спрощує сетап і здешевлює його, бо зникає необхідність підтримувати окремий сервер або постійно адмініструвати VPS.

Загалом тренд очевидний: ШI-агенти поступово стають інфраструктурним шаром, а не експериментом. І тепер питання не лише в тому, якого провайдера моделей ви обираєте, а й де фізично працює ваш агент — локально, у хмарі чи на edge.

GitLab: ШI допомагає писати код, але не прискорює релізи в ентерпрайзі

Попри активне впровадження ШI-кодинг-асистентів, більшість великих компаній не почали випускати софт швидше. Про це заявив CEO GitLab Білл Стейплс, посилаючись на розмови з клієнтами: розробники задоволені інструментами, але швидкість інновацій не зростає.

Проблема в тому, що написання коду — лише 10–20% робочого часу інженера. Решта — це code review, пайплайни, білди, security-сканування, compliance-перевірки та деплой. ШI пришвидшує саме генерацію коду, але не автоматизує вузькі місця далі по ланцюгу. У результаті швидше написаний код просто накопичується в чергах.

GitLab бачить рішення у повній автоматизації SDLC через свою Duo Agent Platform. Ідея — не окремий кодогенератор, а агентні workflow, які проходять шлях від issue до merge request із урахуванням контексту: баг-репортів, історії пайплайнів, тестів і політик безпеки. Як говорять у компанії, саме контекст, а не просто генерація коду, є ключем до реального прискорення.

Із цією тезою складно не погодитися. Сетапи в різних компаніях можуть суттєво відрізнятися — десь розробники дійсно пишуть код більшу частину часу, десь меншу. Але сам підхід із фокусом на контекст виглядає логічним. Якою б потужною не була ШI-модель, вона добре працює з локальними, відносно ізольованими задачами.

Коли ж ідеться про складні, комплексні зміни з великою кількістю залежностей, ризик зростає: можна витратити більше часу на перевірку результату та передачу необхідного контексту, ніж на виконання роботи вручну.

Новина важлива тим, що вона ставить під сумнів популярний наратив «ШI = швидший реліз». У корпоративному середовищі вузьким місцем часто є не написання коду, а процеси навколо нього. І поки ШI не інтегрований у весь lifecycle, приріст продуктивності залишатиметься локальним.

Для команд це означає просту річ: якщо ви впроваджуєте ШI лише на рівні автодоповнення коду, очікувати кратного прискорення поставок не варто. Реальний ефект з’являється там, де автоматизація охоплює весь процес — від планування до деплою.