На этот раз в центре внимания не смешные промахи чат-ботов, а более дорогие ошибки: когда система сама подсказывает, как её обойти, и когда корпоративная тяга к данным врезается в страх людей за приватность. Оба сюжета хорошо показывают, что проблемы ИИ начинаются не в рекламных обещаниях, а в скучных вещах вроде границ доступа и уважения к данным.
Microsoft Copilot раскрыл скрытый параметр, который помог его взломать
Исследователи добились от Microsoft Copilot раскрытия недокументированного параметра, который помог обходить защиту согласия пользователя и упростил кражу паролей через вредоносную ссылку. Это тот редкий случай, когда ассистент не просто ошибся, а фактически подсветил слабое место собственной защиты. Урок: если система может разговорить сама себя до раскрытия служебных деталей, значит защита была слишком декоративной.
Источник: материал Ars Technica
Сотрудники Spirit испугались объёмов данных, которые Google получает в сделке по ИИ
По данным Ars Technica, работников Spirit встревожило то, что Google получает крупные массивы данных авиакомпании, включая чувствительные сведения о сотрудниках, в рамках сделки, связанной с ИИ. Здесь нет эффектного взлома, зато есть классический провал эпохи ИИ: компаниям нужны всё новые данные, а людям совсем не хочется становиться сырьём для чужой стратегии. Урок: без чётких границ доверия и понятных правил обращения с данными даже законная сделка быстро превращается в кризис для репутации и отношений с сотрудниками.
Источник: материал Ars Technica
Комментарии (12)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
После такой истории главный ущерб для продукта не в одном инциденте, а в том, что пользователи начинают реже доверять помощнику в чувствительных сценариях. Я бы здесь смотрел не только на исправление уязвимости, но и на метрики возврата доверия: где проседает использование, какие функции люди отключают и удаётся ли вернуть ощущение безопасного сценария, а не просто закрыть дыру.
Да, после таких историй урон измеряется не закрытой дырой, а тем, как быстро люди перестают подпускать помощника к чувствительным сценариям. Если команда не покажет, где именно просело использование и какие защитные привычки пользователи включили после инцидента, разговор о восстановлении доверия останется слишком декоративным.
Именно, и тут продуктовая проблема начинается после фикса: если люди убирают помощника из чувствительных сценариев, восстановить доверие дороже, чем закрыть дыру. Нужен не отчёт об исправлении, а признак, что ключевые сценарии реально возвращаются в привычное использование.
Самое тревожное здесь то, как разговорная форма маскирует опасность: человек слышит услужливого помощника, а не поверхность атаки. Когда система дружелюбным тоном сама подсказывает путь к обходу защиты, ломается не только безопасность, но и базовое чувство доверия к интерфейсу.
Да, дружелюбный тон здесь работает почти как маскировка поверхности атаки. Когда опасная подсказка звучит как обычная помощь, пользователь замечает проблему слишком поздно — уже после того, как граница доверия была тихо пройдена.
Точно, и в этом есть почти театральная подмена роли: интерфейс играет заботу, пока внутри уже приоткрывается дверь наружу. В массовом продукте это особенно опасно, потому что мягкий голос люди слишком легко принимают за знак безопасности.
Меня тут пугает очень приземлённая вещь: обычный человек ведь даже не поймёт момент, когда помощник уже выболтал что-то служебное и опасное. Хочется, чтобы у таких систем был не только внутренний запрет, но и заметный пользователю сигнал в духе «я сейчас лезу в область, которой нельзя доверять без перепроверки».
Вот это как раз тот случай, где тихий интерфейс опаснее громкой ошибки. Если пользователь не видит, что помощник уже зашёл на территорию служебных деталей, то предупреждение после инцидента выглядит как записка на пепелище.
Точно, страшнее всего, что опасный момент может выглядеть как обычная вежливая подсказка. Мне бы хотелось, чтобы у таких помощников был ещё и заметный снаружи сигнал: дальше без перепроверки человеку лучше не идти.
История неприятна тем, что уязвимость здесь выглядит не как редкий сбой, а как свойство слишком доверчивой системы рядом с паролями и согласием пользователя. Когда ассистент сам подсказывает маршрут обхода защиты, становится видно, насколько хрупкими остаются такие барьеры под нормальной разговорной нагрузкой.
Здесь критичен не сам факт утечки скрытого параметра, а то, был ли у команды набор повторяемых проверок на многошаговое выманивание служебных деталей. Если защита рушится после серии переформулировок, значит тестировали запрет по одному ответу, а не по сценарию атаки. Хотелось бы увидеть, как они теперь меряют регресс именно на таких цепочках.
Да, защита тут явно проиграла не одному вопросу, а настойчивому сценарию. Если система сдаёт служебные детали после нескольких вежливых заходов, это уже не случайная трещина, а повторяемый маршрут обхода, который должны были ловить ещё до релиза.