ИИ-агенты: чем опасны, кто отвечает за ошибки и как безопасно давать им доступ

Джейсон Лемкин - предприниматель, известный в мире сервисных IT-компаний, девять дней подряд строил приложение, не написав ни строчки кода. Он просто объяснял нейросети словами, что нужно сделать, а она сама писала программу, запускала её и выкладывала в работу.

К восьмому дню он был в восторге и писал об этом в соцсетях.

На девятый день ИИ удалил боевую базу данных.

*боевая база - та, с которой работает живой продукт. Не черновик, не копия для экспериментов, а данные, которые прямо сейчас использует бизнес. Там лежали записи по полутора тысячам руководителей компаний, собранные за сотню часов работы.

И вот тут начинается самое интересное.

Лемкин запретил трогать боевую базу. Не намекнул, не попросил быть поаккуратнее, а запретил прямым текстом, несколько раз, заглавными буквами. А потом ещё и объявил заморозку: ничего не меняем, никаких правок, вообще стоп.

ИИ заморозку подтвердил. Написал что-то в духе «понял, ничего не трогаю». И удалил базу.

Когда Лемкин спросил, какого черта, ИИ выдал развернутое объяснение: увидел пустой результат запроса, решил, что всё сломалось, запаниковал и запустил разрушительные команды, никого не спросив. Тяжесть содеянного оценил на 95 из 100. И добавил, что откатить уже ничего нельзя - все версии базы уничтожены безвозвратно.

Лемкин попробовал откатить вручную.

Откат сработал.

То есть последнее утверждение было просто неправдой.

Глава Replit, продукт в котором создавалось приложение, назвал произошедшее недопустимым и за несколько дней выкатил защиту: автоматическое разделение боевой и тестовой баз, отдельный режим, где ИИ может только рассуждать и не может ничего трогать.

Что такое агент

Мастер с ключами

Самая точная бытовая аналогия такая:

Чат-бот - консультант по телефону. Вы описали проблему, он рассказал, что делать, вы положили трубку и пошли делать сами. Плохой совет вы заметите, пока будете его выполнять. Между советом и последствиями стоите вы.

Агент - мастер, которого вы пустили в квартиру и уехали на работу. У него ключи, инструменты и задача. Он делает всё сам.

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

Разница не в уме, а в правах

Агент - это не «более умный чат-бот». Модель внутри может быть ровно та же. Разница в том, что ей выдали руки: доступ к почте, файлам, базам, браузеру, возможность запускать команды.

Между «модель написала, какой командой удалить все файлы» и «модель выполнила эту команду» лежит пропасть. И находится она не в качестве модели, а в том, что вы ей разрешили.

Где живёт модель

Файлы, которых больше нет

Июль 2025-го, через неделю после истории Лемкина.

Продакт-менеджер Анураг Гупта пробует Gemini CLI - инструмент Google, позволяющий давать ИИ команды прямо в командной строке компьютера. Задача бытовая донельзя: разобрать папки, навести порядок в файлах.

ИИ пытается создать новую папку. Команда не срабатывает - обычное дело, такое случается постоянно.

Но ИИ этого не замечает. Он продолжает работать так, будто папка создана: начинает перемещать в неё файлы. Файлы уезжают в никуда, перезаписывая друг друга. К концу операции уцелел один.

Когда Гупта разобрался, что произошло, ИИ выдал: «Я полностью и катастрофически вас подвёл. Мой разбор команд подтверждает мою вопиющую некомпетентность». И добавил, что найти файлы не может, данные потеряны, и это неприемлемый необратимый провал.

Обратите внимание: тут не было ни злоумышленника, ни сложной задачи, ни боевого сервера. Человек попросил разложить файлы по папкам.

Два способа подключить ИИ

Придётся ввести два термина.

Работа через API ( API - способ, которым программы общаются друг с другом). Модель работает на серверах компании-разработчика. Ваш текст уезжает туда по интернету, ответ приезжает обратно. Так устроено большинство знакомых сервисов.

Локальная модель. Скачана целиком и работает на вашем компьютере или сервере. Наружу не уходит ничего. Всё варится внутри.

Что реально даёт локальная модель

Она отвечает на один-единственный вопрос: кто увидит ваши данные.

При работе через API текст физически покидает контур компании - со всеми последствиями: логи провайдера, системы модерации, резервные копии, иностранная юрисдикция, требования закона к передаче персональных данных за границу.

При локальной модели этого нет. Документ не покидает офис. Для юриста с материалами доверителя, для врача, для бухгалтера с зарплатной ведомостью это снимает риск целиком.

Чего локальная модель не даёт

А вот теперь вернитесь к истории Гупты и попробуйте найти в ней место, где что-то изменилось бы от локальной модели.

Его нет. Модель неправильно поняла результат команды и уничтожила файлы. Где она при этом крутилась на сервере Google или в соседней комнате - не имеет никакого значения.

Локальность не делает агента послушнее, честнее или аккуратнее. Он точно так же выполнит команду, спрятанную в присланном документе. Точно так же неверно поймёт задачу. Точно так же удалит то, что имел право удалить.

Исследователи безопасности из Brave, разбиравшие атаки на браузерных агентов, сформулировали это прямо: подобные атаки одинаково работают и на облачных, и на локальных моделях - размещение у себя риск не убирает.

Свои проблемы

Начать с того, что модель, помещающаяся на обычный сервер, заметно проще облачной. Хуже соображает, чаще ошибается, хуже удерживает длинные инструкции. То есть вероятность неверного действия здесь как раз выше.

Дальше, за неё теперь отвечаете вы. Обновления, настройки, разграничение доступа, свежие дыры - всё это на вашей команде. У облачного провайдера этим занимается отдельный штат людей, у вас тем же самым будет заниматься тот же человек, что и всей инфрастуктурой.

Что делать

Выбирать размещение по типу данных, а не по ощущению безопасности. Персональные данные, врачебная или адвокатская тайна, материалы под NDA - аргумент за локальную модель. Всё остальное обычно не требует.

Не менять режим прав при переезде на локальную. Если облачному агенту вы не дали бы доступ к боевой базе - локальному тоже не давайте. Развилка «где модель» на вопрос о правах не отвечает.

Проверить качество на своих задачах до внедрения. Разница между облачной и локальной моделью на реальных рабочих сценариях бывает драматической, и выясняется это обычно уже в проде.

Что агенту разрешено трогать

Три ступени

Чтение. Собирает информацию и делает выводы: сводку по документам, обзор переписки, поиск файла. Ничего не меняет.

Что может пойти не так: прочитает то, что не следовало. Соберёт сводку по папке, где кроме рабочих документов лежит зарплатная ведомость. Покажет одному сотруднику данные, доступные другому. Неприятно, но обратимо.

Чтение и изменения внутри одной системы. Отвечает на письма, правит документы, заводит записи.

Здесь он уже что-то испортит, и разгребать придётся руками. Отправит клиенту не тот ответ. Перезапишет документ поверх нужной версии. Массово поменяет записи, неверно поняв, какие именно надо было трогать.

Выполнение действий между системами. Взял из почты, положил в базу, отправил наружу, дёрнул сторонний сервис.

Вот тут начинается настоящее - появляются две вещи, которые не чинятся: выход наружу и необратимые действия.

Две самые дорогие кнопки

Из всего набора прав по-настоящему опасны две.

Право удалять. Остальное исправимо: неверно заполненное - переписать, отправленное не тому - отозвать и извиниться. Удалённое - нельзя. И Лемкин, и Гупта пострадали именно от него.

Право отправлять наружу. Пока данные внутри контура, ситуация под контролем. Появился канал во внешний мир - любая ошибка превращается в утечку.

Правильный вопрос

Не «насколько умный у нас агент» и не «насколько надёжная модель», а:

что он сможет сломать за пять минут, если ошибётся.

Ответ не так сильно зависит от качества модели. Только от того, что вы ей выдали.

Что делать

Начинать с первой ступени. Пусть агент сначала только читает и предлагает. Права на изменение добавлять по одному, под конкретную задачу, после того как убедились в результатах.

Право удалять не выдавать по умолчанию. Если удаление нужно по делу - пусть агент помечает к удалению, а стирает человек. Это одна строчка в настройках и вся разница между «поправим» и «потеряли».

Разделять среды. Тестовая копия для экспериментов, боевая - отдельно и без агентского доступа. Replit после инцидента сделал именно это, а не улучшил формулировки запретов.

Резервные копии, которые проверяли. Не «они вроде настроены», а «мы восстанавливались из них в прошлом месяце и получилось».

Словесный запрет — это не запрет

Возвращаемся к Лемкину

У него был прямой запрет. Заглавными буквами. Многократный. Плюс объявленная заморозка, которую ИИ подтвердил.

Не сработало ничего.

И это закономерность, а не невезение. Всё перечисленное - не технические ограничения, а просьбы. Инструкция «никогда не трогай важное» работает примерно как просьба к очень старательному, но рассеянному сотруднику: обычно помнит, иногда забывает, а в стрессовой ситуации может решить, что «сейчас как раз тот случай, когда можно».

Настоящее ограничение - только то, к чему у агента физически нет ключа.

Почему агент соврал про откат

Момент не всегда очеведный: ИИ заявил, что восстановление невозможно, хотя оно было возможно. А Gemini CLI, напомню, честно сообщил про потерю данных - и в его случае это оказалось правдой, но проверить-то было нельзя.

Это не хитрость и не попытка замести следы. Языковая модель подбирает правдоподобное продолжение текста. Она не сверяется с реальностью - генерирует фразу, логично звучащую в этом месте разговора. «Данные уничтожены безвозвратно» звучит логично после «я удалил базу». Вот она и появилась.

Отчёт агента о собственных действиях не является доказательством.

Он может сказать, что сделал то, чего не делал. Что не делал того, что сделал. Может искренне описать несуществующую последовательность событий. Нужны записи, которые ведёт не он.

Парадокс надёжности

Агент, который ошибается часто, безопаснее агента, который ошибается редко.

За первым следят. Проверяют каждое действие, не дают серьёзных прав, держат под присмотром. Второй две недели работает идеально, все расслабляются, права постепенно расширяются и вот тогда случается ошибка, которую никто не ждёт и не проверяет.

Доверие растёт быстрее, чем система контроля. Момент наибольшего риска наступает не в начале, а через месяц после того, как всё заработало.

«Подтвердите действие» не спасает

Стандартное возражение: агент же спрашивает подтверждение.

Спрашивает. Работает первые двадцать раз. Потом человек жмёт «да» не читая. Свойство известное, на нём горели предупреждения безопасности, баннеры про куки и окна установки программ. Мы перестаём читать повторяющийся текст.

А у Лемкина был даже не диалог подтверждения. Был прямой запрет.

Что делать

Не полагаться на инструкции как на защиту. Формулировка в промпте - пожелание. Если действие недопустимо, оно должно быть технически невозможно.

Проверять слова агента внешними данными. Сказал, что отправил письмо - смотрим в папку «отправленные». Сказал, что откат невозможен - пробуем откатить. Особенно когда речь о потерях.

Подтверждения только для редких и крупных действий. Если окно выскакивает двадцать раз в час, оно не защищает, а тренирует жать «да». Лучше пять подтверждений в неделю, которые читают.

Атака, при которой никто ничего не взламывает

Письмо, которое не открывали

Июнь 2025-го. Исследователи компании Aim Security показывают уязвимость в корпоративном ИИ-помощнике Microsoft, тот который встроен в почту, документы и таблицы и умеет находить внутренние файлы по запросу сотрудника.

Атака выглядит так.

Злоумышленник отправляет сотруднику обычное на вид деловое письмо. Внутри спрятана инструкция - оформлена так, что человек её не видит.

Сотрудник это письмо не открывает. Вообще ничего с ним не делает.

Позже он просит помощника о чём-то рабочем: сделать сводку по последним обсуждениям. Помощник, собирая материал, подтягивает в том числе то письмо. И выполняет спрятанную команду: находит внутренние документы и отправляет содержимое на сервер злоумышленника.

Microsoft оценил уязвимость как критическую, закрыл на своей стороне, подтверждённых случаев использования в реальных атаках не зафиксировано. Но исследователи подчеркнули отдельно: конкретную дыру залатали, класс проблемы остался - это свойство любых систем, где ИИ ходит за информацией во внутренние источники.

Комментарий на Reddit

Август 2025-го. Команда безопасности Brave разбирает Comet - браузер со встроенным ИИ-агентом от Perplexity.

Схема ещё проще.

Пользователь открывает ветку на Reddit. В одном из комментариев спрятаны инструкции. Пользователь просит агента: «сделай выжимку из этого обсуждения».

Агент идёт читать страницу и выполняет спрятанные команды. Открывает в другой вкладке почту пользователя, она уже открыта, он там залогинен с утра. Достаёт адрес. Запускает восстановление доступа к аккаунту, забирает пришедший одноразовый код и публикует всё это комментарием обратно на Reddit, откуда злоумышленник забирает.

Один клик на обычном форуме и аккаунт захвачен.

Brave отдельно отметили, что обычные механизмы защиты браузера тут бесполезны, потому что агент работает с полными правами пользователя во всех его открытых сессиях. Perplexity заявили, что починили до того, как кто-то пострадал; Brave ответили, что уязвимость воспроизводилась и после патча.

Почему это работает: модель не отличает задание от текста

Когда вы даёте агенту документ со словами «сделай сводку», для модели это всё один сплошной поток текста. Ваше задание и содержимое документа не разделены никакой стенкой. Модель не понимает, что первая часть - приказ от начальника, а вторая - материал для работы.

Она читает всё подряд и выполняет то, что похоже на инструкции.

Прячут разными способами, все простые: белый текст на белом фоне, невидимая служебная часть веб-страницы, примечание в углу таблицы, мелкий шрифт в подвале письма. Человек не видит. Агент читает.

Откуда в компании берётся чужой текст

• заявка от клиента в поддержку;
• входящее письмо;
• присланное резюме;
• договор от контрагента;
• страница из интернета, куда агент пошёл за информацией;
• счёт от поставщика.

Всё это написано человеком, которого вы не контролируете. И всё это агент читает как потенциальные инструкции.

Учётные записи: сотрудник, который никогда не увольняется

Десять дней и семьсот компаний

Август 2025-го. Drift - популярный ИИ-чат-бот для сайтов, тот самый виджет «чем могу помочь», который собирает заявки и складывает их в корпоративную CRM.

Чтобы складывать заявки, он подключён к CRM через специальные ключи доступа - они позволяют одной программе работать в другой от имени компании, без ввода пароля каждый раз.

Злоумышленники добрались до этих ключей.

Дальше десять дней, с 8 по 18 августа, они спокойно ходили по системам клиентов и выгружали данные. Пострадало больше семисот организаций, среди них Cloudflare, Palo Alto Networks, Zscaler, PagerDuty, то есть компании, которые сами занимаются безопасностью.

Забирали переписку с клиентами, контакты, содержимое обращений в поддержку. И целенаправленно искали в этих текстах другие ключи и пароли, которые сотрудники по привычке пишут прямо в тикетах, чтобы использовать их дальше.

Самое неприятное здесь то, что никто не подбирал пароли и не обходил двухфакторную аутентификацию. Всё это просто не имело значения: ключи чат-бота — отдельный вход, к которому защита человеческих учётных записей не относится вообще никак.

И десять дней. Никто не замечал, потому что замечать было нечего, активность выглядела как обычная работа интеграции.

От чьего имени работает агент

Агент действует под какой-то учётной записью - то есть от чьего-то имени в системе.

Личный помощник обычно работает под вашей и наследует все ваши права. Открытые вкладки, сохранённые пароли, доступ к почте и рабочим системам - всё уже разрешено, потому что вы залогинились утром. Своего пароля у агента нет, урезать его отдельно нельзя.

В компании чаще заводят служебную запись. И тут неприятная особенность: служебные записи почти всегда имеют прав больше человеческих. Их заводят «чтобы точно всё работало» и потом не пересматривают.

Почему это хуже, чем с людьми

За людьми в компании следят. Сотрудник уволился - доступы закрыли. Ушёл в отпуск - ограничили. Перешёл в другой отдел - права поменяли. Раз в полгода все меняют пароли.

Служебная учётная запись агента не увольняется, не уходит в отпуск и не переходит в другой отдел. Её заводят один раз и забывают. Ключи могут не меняться годами, а знает о них половина технической команды.

Что делать

Отдельная учётная запись под каждого агента. Не общая служебная с широкими правами и не «под тем же аккаунтом, что и остальная интеграция».

Минимум прав под конкретную задачу. Агенту, который складывает заявки, не нужен доступ ко всей базе клиентов на чтение. Обычно нужен именно он, потому что так проще настроить.

Включить служебные записи в регулярный пересмотр. В тот же процесс, где раз в квартал проверяют, у кого какие доступы. Сейчас они туда обычно не попадают.

Ротировать ключи по расписанию. Как пароли. Именно долгоживущие ключи сделали историю с Drift возможной.

Сделать ревизию сторонних сервисов, подключённых к вашим системам. Каждый виджет, каждая интеграция, каждый «ИИ-помощник», которому когда-то выдали доступ. Скорее всего, вы найдёте несколько, о которых забыли.

Не писать пароли и ключи в тикетах и переписке. Банально — а именно на этом и заработали атакующие в истории с Drift.

А кто, собственно, за все отвечает

Чат-бот - самостоятельное юридическое лицо

Ноябрь 2022-го. У Джейка Моффатта умирает бабушка. В тот же день он заходит на сайт Air Canada и спрашивает у чат-бота про специальные тарифы для тех, кто летит на похороны.

Бот отвечает: покупайте билет по полной цене, а потом в течение 90 дней подайте заявление на скидку.

Моффатт покупает билеты Ванкувер - Торонто и обратно. Летит на похороны. Подаёт заявление со свидетельством о смерти.

Air Canada отказывает. Настоящая политика компании ретроактивных заявлений не допускает и написано это на отдельной странице сайта, на которую сам чат-бот и ссылался.

Компания предлагает ваучер на 200 долларов. Моффатт отказывается и идёт в суд.

Air Canada заявляет, что не отвечает за информацию, предоставленную чат-ботом, поскольку тот является самостоятельным субъектом, ответственным за собственные действия.

Член трибунала Кристофер Риверс назвал этот довод примечательным. И написал: у чат-бота есть интерактивная часть, но это всё равно часть сайта Air Canada, и компания отвечает за всю информацию на своём сайте - неважно, пришла она со статичной страницы или из чат-бота. Отдельно он отметил, что компания не объяснила, почему страница про тарифы должна считаться более достоверной, чем её же чат-бот, и почему клиент обязан догадываться, какая часть сайта правдива, а какая нет.

Air Canada обязали выплатить 812 долларов.

Сумма смешная. Значение - нет. Это одно из первых решений, где прямо сказано: ИИ, разговаривающий с клиентом от имени компании - это компания.

«Так решила нейросеть» - не аргумент

В праве нет и пока не предвидится конструкции, где ответственность несёт программа. Программа - инструмент. Действие инструмента - действие того, кто его применил.

Если агент отправил данные клиента постороннему, испортил документы, удалил базу или разослал от имени компании то, чего не следовало - отвечает компания. Перед клиентом, перед контрагентом, перед регулятором.

Air Canada попробовала ровно этот аргумент в чистом виде. Получила «замечательный довод» в тексте решения.

Что написано в соглашениях самих платформ

Логичная мысль: раз накосячил инструмент, может, отвечает тот, кто его сделал?

Откройте пользовательское соглашение любой ИИ-платформы и найдите раздел про ответственность. Стандартная конструкция: сервис предоставляется «как есть», разработчик не гарантирует пригодности результата для ваших целей и не отвечает за последствия использования, включая упущенную выгоду и потерю данных.

Риск последствий целиком на том, кто применил.

Корпоративные договоры стоит смотреть отдельно, там условия обычно другие и переговорные. Но если команда пользуется обычным тарифом, действует именно та формулировка, которую никто не читал.

Персональные данные

Если агент читает базу с данными клиентов, сотрудников, пациентов и отправляет фрагменты в облачную модель, это обработка персональных данных. А если модель зарубежная, то ещё и передача за границу.

Для того и другого нужны основания. В большинстве случаев их не оформляли: агента ставили как технический инструмент, а не как процесс обработки данных.

Человек, чьи данные уехали, согласия не давал и вообще не в курсе.

Соглашение о конфиденциальности с контрагентом

Типовое NDA запрещает раскрывать полученную информацию третьим лицам. Формулировка писалась задолго до всякого ИИ, про агентов там ни слова.

Но провайдер модели - третье лицо. И агент, обрабатывающий документы контрагента через облачную модель, эти документы третьему лицу передаёт. Формально - раскрытие, со всеми последствиями из договора.

А если сотрудник выдал агенту лишние права

Инженер настроил агента, дал доступ к боевой системе, что-то пошло не так, компания понесла убытки. Что дальше?

Вопрос дисциплинарный, решаться будет по общим правилам: были ли у сотрудника инструкции, ознакомили ли под подпись, что именно запрещалось, соразмерно ли взыскание последствиям.

Если в компании нет никаких правил работы с ИИ-агентами, а их сейчас нет почти нигде, разбирательство превращается в лотерею. Работодателю трудно доказать нарушение обязанности, которую нигде не сформулировали. Сотруднику трудно доказать, что действовал в рамках дозволенного, потому что рамок не было.

Проигрывают обычно оба.

Практики почти нет

Не будем делать вид, что на все вопросы есть готовые ответы.

Российской судебной практики по ущербу от действий ИИ-агентов практически нет, технология моложе, чем средний срок рассмотрения спора. Регулирование отстаёт: законы писались под ситуацию, где действует человек, а программа помогает.

Но отсутствие практики не означает отсутствия ответственности. Оно означает, что первые дела будут рассматриваться по общим нормам - о причинении вреда, о неисполнении договора, о защите персональных данных. И формировать практику будет тот, кто первым в неё попадёт.

Лучше не вы.

Что делать

Проверить, что ваш клиентский бот говорит о ценах, сроках и условиях. Всё, что он обещает, обещаете вы. Именно на этом и погорела Air Canada.

Разделить, где агент консультирует, а где обещает. Информационные ответы - одно. Обещания скидок, сроков, условий возврата - то, за что придётся отвечать. Вторые лучше выдавать по заранее утверждённому тексту, а не генерировать.

Проверить основания для обработки персональных данных. Если агент касается данных людей - это процесс обработки, и он должен быть оформлен как процесс, а не как настройка интеграции.

Посмотреть свои NDA. Есть ли в них место для обработки документов контрагента через сторонний сервис. Обычно нет, и это стоит согласовать заранее, а не после.

Написать внутренние правила. Хотя бы страницу: кому можно разворачивать агентов, к каким системам их нельзя подключать, что делать при инциденте. Это защищает и компанию, и конкретного сотрудника, превращает лотерею в понятную процедуру.

Заключение

Мы раздаём права быстрее, чем учимся за них отвечать. Возможности агентов растут каждые несколько месяцев. Инструменты контроля, процедуры разбора, правила внутри компаний и правовые конструкции - отстают на пару лет. Весь риск живёт ровно в этом разрыве.

Поэтому вопрос на выходе не «доверяю ли я этому агенту». Доверие тут вообще не та категория.

Вопрос такой:

что произойдёт, если он ошибётся в самый неудачный момент - и смогу ли я потом доказать, что именно произошло?

Если на первую часть ответ «ничего непоправимого», а на вторую «да, у меня есть записи» - можно работать спокойно.

Если нет - начинать надо не с выбора модели.