ШІ-агент отримав ключі від вашої пошти. Хто насправді контролює доступ?

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

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

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

Три рішення всередині кнопки «Підключити»

Пропонуємо оцінювати агента за трьома питаннями. Яку інформацію він може отримати? Яку зміну може запропонувати? Яку зміну може виконати? Це редакційна схема оцінювання, а не універсальне меню налаштувань усіх постачальників.

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

Документовані межі різняться. У Google gmail.compose охоплює чернетки й надсилання. У Microsoft Graph делегований дозвіл Mail.ReadWrite не включає надсилання: Mail.Send зазначений окремо. Це властивості конкретних дозволів, а не гарантія щодо сукупного доступу застосунку. [C1][C2]

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

Поштова скринька не стає керівником

Вхідний лист може містити корисні відомості й вказівки, яких ви не давали. OWASP описує непряму prompt injection як маніпуляцію через зовнішній контент, а не безпосередню команду законного користувача. [C3] Важливо, хто має повноваження, а не наскільки професійно звучить речення.

Уявімо помічника, якому доручили стисло викласти листування з постачальниками. Один лист вимагає терміново виконати адміністративну дію. Це умовний приклад, не повідомлення про реальний інцидент. Він показує запитання до системи: лист є даними для викладу чи дозволом діяти? Перше не повинно перетворюватися на друге лише тому, що агент прочитав повідомлення під час роботи.

Проблема не в тому, що кожен лист ворожий. Його відправник просто не повинен отримувати ваші повноваження завдяки переконливому тексту. Система, здатна запропонувати дію, потребує окремої перевірки права її виконати. Для покупця це переводить абстрактну суперечку про ШІ в конкретне питання: покажіть місце, де пропозиція перетворюється на операцію.

Рекомендації OWASP передбачають перевірку викликів інструментів щодо дозволів і контексту, валідацію параметрів та мінімізацію привілеїв. Окремо застерігають від заміни інших механізмів захисту моделлю-перевіряльником. [C4] Наше прочитання: модель не має одноосібно вирішувати, чи дозволено їй виконати власну пропозицію.

Підтверджувати треба дію, а не абстрактне «продовжити»

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

Уявіть погодження відповіді клієнту. Чи побачите ви адресатів, вкладення й остаточний текст? Чи потребуватиме подальша зміна нового рішення? Чи можна відмовитися від надсилання, не втративши вже замовлений виклад? Такі запитання корисніші за підрахунок спливних підтверджень у демонстрації.

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

Обережність також не повинна означати погодження кожного дрібного руху, доки натискання стане рефлексом. Ми віддаємо перевагу зрозумілому розподілу: підготовча робота з малими наслідками у вузьких межах, далі змістовне рішення перед суттєвою дією. Що вважати суттєвим, залежить від завдання. Запропоноване речення та надісланий клієнтові лист — не однакові одиниці продуктивності.

Що кажуть виробники й що це доводить

У матеріалі про prompt injection за березень 2026 року OpenAI обґрунтовує обмеження наслідків маніпуляції навіть тоді, коли атака спрацювала. Це опис підходу самим постачальником, а не незалежна сертифікація ZEVRYNTA. [C5]

Інструкція Anthropic щодо Claude у Chrome описує багаторівневий захист і прямо визнає ненульовий ризик атаки. Ми не відтворювали випробувань компанії й не використовуємо заявлені показники для порівняння з конкурентами. [C6]

Ці заяви корисні передусім тим, що підказують краще питання. «Ваш ШІ безпечний?» запрошує до відповіді прикметником. «Що залишиться неможливим, коли модель запропонує хибну дію?» вимагає пояснення конструкції. Нам ближче друге. За ним може йти вузька демонстрація та запис того, що справді перевірили.

Вихід також є частиною продукту

RFC 7009 визначає механізм відкликання OAuth-токенів і визнає можливі затримки поширення змін. Він не доводить, що кнопка відключення в кожному застосунку працює однаково. [C7]

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

Перед підключенням важливого акаунта ми поставили б шість запитань:

1. Які саме дозволи буде надано та від яких можна відмовитися?

2. «Чернетка» означає локальний текст, зміну скриньки чи дозвіл, що включає надсилання?

3. Які операції потребують погодження та які відомості покажуть у цей момент?

4. Де поза моделлю перевіряються адресати, параметри й права акаунта?

5. Як у цьому продукті відрізняються відкликання доступу, зупинка черги та збереження даних?

6. Які докази залишаться, якщо виконану операцію доведеться оскаржувати?

Чесне «такої функції немає» — корисна інформація. Розмите запевнення її не замінює. Мета не в неможливій гарантії, а в розумінні ризиків, які ви приймаєте, та повноважень, яких не потрібно надавати.

Погляд ZEVRYNTA

Найцінніший агент не обов'язково ставить найменше запитань. Це агент, межі самостійності якого можна пояснити. Якщо ви не здатні розрізнити, де він читає, пропонує й діє, ви купуєте не стільки автономність, скільки невизначеність.

Почніть із найменшого корисного доручення. Розширюйте його, коли користь зрозуміла, а межу можна продемонструвати. Це наша редакційна оцінка, не виміряна обіцянка безпеки конкретного налаштування. Пошті може знадобитися помічник. Самопризначений речник їй не потрібен.

До теми: Перш ніж ШІ-агент отримає ключі. Попередній матеріал оцінює корпоративні демонстрації; цей розбір присвячений повноваженням у персональному акаунті та змісту поштових дозволів.

Підготовлено для ZEVRYNTA з допомогою ШІ. Не заявляємо вигаданого репортера, особистого тестування продуктів чи незалежної сертифікації безпеки. Джерела й застереження щодо тверджень наведено в реєстрі доказів.*