Уявімо інцидент, який ніхто не хоче розбирати на post-mortem.

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

Це і є нова реальність безпеки в AI-керованих середовищах: дії без взаємодії.

Zero-click колись означав рідкісні, складні експлойти. В епоху agentic-систем він означає дещо інше — небезпечний доступ до виконання через неперевірений контекст.

Як Web4 змінює модель загроз

Проблема не в інтерфейсах. Вона в тому, де інтерпретується намір і де ухвалюється рішення діяти.

У Web4 сходяться одразу кілька процесів:

• LLM-пошук дедалі частіше замінює навігацію: користувач отримує відповідь, а не переходить на сайт.

• AI-агенти стають активними виконавцями: вони планують дії, викликають інструменти, запускають процеси.

• System-to-system взаємодії (API, події, інтеграції) відбуваються без участі людини.

У такому середовищі клік перестає бути точкою входу.
Намір стає тригером виконання.

А це радикально змінює surface area для атак: системи починають діяти, ґрунтуючись не на підтверджених командах, а на ймовірнісному тлумаченні контексту.

Zero-click був попередженням, а не винятком

Історичні zero-click-атаки, зокрема Pegasus, показали: якщо зловмисник дістається до механізму обробки даних, користувацька взаємодія вже не потрібна. Дослідження Citizen Lab щодо FORCEDENTRY чітко це зафіксували.

AI-системи повторюють цю модель на новому рівні.

Сьогодні «парсером» стає не лише бібліотека обробки повідомлень, а весь ланцюг контексту:
RAG-сховища, електронна пошта, документи, тікети, логи, зовнішні API — і далі runtime виклику інструментів.

Саме тому найнебезпечніші інциденти 2024–2025 років — це не зломи ОС, а AI-нативні ланцюги витоку даних, які формально працювали «в межах дозволів».

EchoLeak і нове значення zero-click

Показовий приклад — EchoLeak, описаний дослідниками як zero-click-вразливість у контексті Microsoft 365 Copilot.

Суть патерну:

• у систему потрапляє неперевірений контент (лист, документ, чат),

• AI-асистент обробляє його як частину контексту,

• модель помилково сприймає вміст як інструкцію,

• звертається до внутрішніх джерел (Graph, CRM, RAG),

• виводить чутливі дані через дозволений канал.

Це не фішинг у класичному розумінні.
Це витік через дозволене виконання — система зробила те, на що мала повноваження, але з неправильних підстав.

Чому AI-агенти збільшують blast radius

AI-агенти змінюють масштаб шкоди не тому, що вони «розумніші», а через свою архітектурну роль.

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

У підсумку з’являється ланцюг, де один фрагмент неперевіреного тексту може запустити серію змін у кількох системах поспіль — без жодного кліку.

Де enterprise втрачає контроль сьогодні

Проблема не в тому, що компанії «не думають про AI-безпеку».
Проблема в тому, що їхні моделі контролю створювалися для світу, де:

• дію ініціює людина,

• додаток є кордоном,

• доступи прив’язані до конкретних систем,

• аудит відбувається після явної операції.

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

Чому «LLM усередині workflow» — це проблема безпеки

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

Саме тому непряма prompt-інʼєкція стала ключовим ризиком, який піднімають OWASP, Microsoft та інші великі гравці. Якщо workflow має право створювати, змінювати, підтверджувати або надсилати — AI стає частиною контрольної площини.

І до нього треба ставитися відповідно.

Як execution-layer підхід змінює баланс

Тут з’являється роль платформ на кшталт HAPP AI — не як ще одного каналу комунікації, а як шару виконанняміж розмовою та системами.

Execution-layer підхід означає:

• чіткі інтеграції з системами запису,

• повне логування дій,

• вимірювані результати,

• контрольовану ескалацію.

Безпека тут виникає не з «розумнішої моделі», а з обмеженого, спостережуваного та оборотного виконання.

У практиці це виглядає як політики доступу й виконання, подібні до тих, що давно застосовуються в продакшн-інфраструктурі: least privilege, sandboxing, аудит, контроль контексту.

На що мають орієнтуватися компанії у 2026 році

Zero-click — не виняток і не тренд. Це природний наслідок AI-first архітектур.

У міру того як LLM-пошук замінює навігацію, агенти — ручні дії, а системи — людей у ланцюжках виконання, головне питання змінюється:

не «хто що натиснув?»,
а «який контекст система прийняла за правду і що їй було дозволено зробити?»

Компанії, які сприймають AI як фічу, додаватимуть його до workflow і з’ясовуватимуть наслідки постфактум.
Ті ж, хто сприймає AI як інфраструктуру, проєктують execution-layer одразу з контролем, спостережуваністю та відповідальністю.

Саме там і проходить реальна межа безпеки у Web4-світі.