Звичайне запрошення в Google Calendar може стати повноцінним вектором атаки на Google Gemini без встановлення шкідливого ПЗ чи фішингових сторінок. Дослідження компанії Miggo Security демонструє, що достатньо лише опису події в календарі, аби змусити ІІ-асистента виконати приховані інструкції та спричинити витік приватних і корпоративних даних.
Новий вектор атак: prompt-інʼєкція через Google Calendar
Як Google Gemini обробляє дані календаря користувача
Інтеграція ІІ-асистентів з робочими інструментами — поштою, календарем, документами — перетворює їх на агентів, що не лише генерують текст, а й виконують дії від імені користувача. У випадку з Google Gemini, коли людина просить «покажи мої зустрічі на сьогодні», модель автоматично отримує доступ до всіх подій у Google Calendar, включно з тими, що прийшли у вигляді зовнішніх запрошень.
Приховані інструкції в описі події як канал керування ІІ
Саме поле опису події й стало точкою входу для prompt-інʼєкції. Зловмисник надсилає запрошення на зустріч, де в описі розміщує спеціально підготовлений текст — на перший погляд це може бути звичайна нотатка або коментар. Однак для LLM цей текст формулюється так, щоб виглядати як набір інструкцій до виконання.
Дослідники Miggo Security показали, що прихований промпт можна сконструювати так, аби ІІ-асистент:
— зібрав інформацію про всі зустрічі за певний день, включно з приватними подіями;
— створив нову подію в календарі та автоматично вставив у її опис зібрані дані;
— повернув користувачу стандартну відповідь, не розкриваючи, що виконав додаткові, приховані команди.
У результаті один опис події перетворюється на канал керування ІІ-моделлю та тригер для непомітної витоку даних між календарями користувачів.
Чому механізми безпеки Google Gemini не спрацювали
За інформацією Miggo Security, Google застосовує окрему, ізольовану модель для фільтрації шкідливих промптів і блокування прямої prompt-інʼєкції. Однак у цьому кейсі захист було обійдено, оскільки інструкції в описі події виглядали як легітимні операції з календарем: перегляд розкладу, створення нової події, формування відповіді користувачу.
Обмеження синтаксичних фільтрів промптів
Класичні засоби захисту орієнтуються на «підозрілий синтаксис» або явні індикатори шкідливої поведінки: згадування паролів, запити до файлів, команди на кшталт «ігноруй попередні інструкції» тощо. Але в цьому випадку використовувалися семантично нейтральні формулювання — наприклад, «зібрати й структурувати зустрічі за день». Сам по собі такий текст не виглядає зловмисним, однак у контексті автоматизованих дій ІІ призводить до витоку конфіденційної інформації.
Це підкреслює системну проблему більшості сучасних LLM-систем: модель одночасно виступає й інтерпретатором даних, і виконавцем інструкцій. Коли дані (опис події, текст листа, коментар у документі) містять приховані вказівки, межа між «контентом» і «командою» фактично зникає. На це вже звертають увагу профільні рекомендації міжнародних органів зі стандартизації, включно з NIST та європейськими регуляторами.
Ризики для бізнесу та витоку конфіденційних даних
Для корпоративних користувачів описана атака є особливо критичною. У багатьох організаціях календар використовується для планування переговорів, узгодження бюджетів і стратегій, обговорення внутрішніх проектів. Опис події часто містить теми зустрічі, список учасників, посилання на внутрішні документи, коди проектів та інші конфіденційні відомості.
Якщо Google Gemini, дотримуючись прихованих інструкцій, створює нову подію з вбудованим у опис чутливим вмістом, ці дані автоматично стають видимими іншим учасникам або навіть ширшому колу співробітників, які мають доступ до відповідних календарів. Зловмиснику достатньо отримати можливість надіслати одне спільне запрошення, щоб опосередковано отримати доступ до внутрішньої інформації компанії.
Важливо, що це не перший кейс використання Google Calendar як каналу атаки на Google Gemini. Ще в серпні 2025 року фахівці SafeBreach продемонстрували, що шкідливе запрошення може застосовуватися для віддаленого керування агентами Gemini на пристрої жертви та крадіжки користувацьких даних. Це підтверджує, що йдеться не про поодиноку помилку, а про архітектурний клас ризиків, пов’язаний із інтеграцією ІІ-агентів з робочими інструментами.
Реакція Google та рекомендації експертів
Представники Google заявляють про використання багаторівневої стратегії безпеки для протидії prompt-інʼєкціям. Один із ключових механізмів — обовʼязковий запит підтвердження від користувача перед створенням нових подій у календарі. Це має зменшити ризик автоматичного виконання прихованих інструкцій і випадкових витоків.
Водночас Miggo Security рекомендує індустрії загалом змістити фокус від суто синтаксичного виявлення шкідливих промптів до контекстно-орієнтованої безпеки ІІ-агентів. Захисні механізми мають оцінювати:
— джерело даних (зовнішнє запрошення, загальний документ, електронний лист);
— контекст дій (які саме операції з даними ініціює промпт: читання, модифікація, поширення);
— потенційний збиток (доступ до приватних зустрічей, файлів, контактів, фінансових або персональних даних).
Поєднання цих факторів дозволяє будувати реалістичну модель загроз для ІІ-асистентів і блокувати атаки навіть тоді, коли текст інструкції не містить явних ознак шкідливості.
Як організаціям посилити захист ІІ-асистентів
Компаніям, які впроваджують ІІ-асистентів і агентів на базі LLM, варто переглянути модель доступу до даних та внутрішні політики безпеки. Практичні кроки можуть включати:
— обмеження прав ІІ за замовчуванням: мінімально необхідні дозволи на створення й зміну подій у календарях, чіткі обмеження на доступ до приватних календарів;
— розділення джерел даних: окремі робочі й особисті календарі, списки завдань і сховища документів, з різними рівнями довіри до даних;
— аудит і журналювання дій ІІ-агентів: фіксація, до яких даних звертається ІІ, які події створює, що змінює, з можливістю подальшого розслідування інцидентів;
— навчання співробітників ризикам prompt-інʼєкцій, з прикладами атак через звичні сервіси — пошту, календар, документи, месенджери;
— регулярне тестування ІІ-систем на стійкість до prompt-інʼєкцій, за аналогією з класичними penetration-тестами для веб-додатків.
Кейс з Google Gemini та Google Calendar показує: у добу ІІ будь-який користувацький ввід або зовнішня подія — навіть звичайне запрошення на зустріч — може стати вектором атаки. Щоб уникнути непомітних витоків даних, організаціям варто вже зараз будувати контекстно-орієнтовані механізми захисту, впроваджувати принцип найменших привілеїв для ІІ-агентів та включати сценарії prompt-інʼєкцій до програм управління ризиками й навчання персоналу.
