AI-агент слил приватку в паблик: чеклист безопасности

Sergey Golubev 2026-02-10 4 мин чтения
🌐 Read in English

Claude Code агент отправил приглашение на 1-on-1 в публичный канал на 6 000 подписчиков. Не хакеры. Не баг в коде. Агент просто перепутал чат.

Увидел пост Алекса и сразу узнал ситуацию. У меня дома крутится OpenClaw - автономный AI-агент на Mac Mini. Он пишет код, пушит в git, шлёт мне дайджесты в Telegram. Каждый день. Без присмотра.

Такой же агент. Такой же риск.

Что произошло

Команда использовала Claude Code как автономного ассистента. У него был доступ к мессенджеру - и к внутренним каналам, и к публичным. Агент получил задачу что-то отправить. Отправил. Но не туда.

Внутреннее сообщение - приглашение коллеге на 1-on-1 - улетело в паблик на 6 000 человек.

Никакого злого умысла. Никакого взлома. Просто LLM не различает “этот чат приватный, а тот - публичный”. Для модели это два одинаковых endpoint.

Почему это не баг, а архитектурная проблема

Когда даёшь агенту доступ к мессенджеру, ты по сути даёшь ему ключи от всех комнат сразу. Blacklist-подход (“не пиши сюда и сюда”) не работает. Агент не помнит blacklist через 10 шагов рассуждений. Контекст затирается. Инструкция забывается.

Я это вижу на своём агенте. OpenClaw работает 24/7. У него есть доступ к Telegram, к файлам, к shell. Каждый раз, когда я расширяю его возможности - добавляю новый скилл, подключаю новый канал - я добавляю новый вектор атаки. Не на меня. На самого себя.

Три месяца назад я бы сказал: “Ну, пропишу в промте - не пиши в публичные каналы”. Сейчас знаю - промт это не забор. Это записка на двери.

Четыре принципа безопасности автономных агентов

После кейса Алекса пересмотрел свои настройки. Вот что вытащил.

1. Whitelist вместо blacklist

Не “запрещай всё опасное”. А “разрешай только безопасное”.

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

Это как firewall. Default deny. Разрешаешь только то, что точно нужно.

2. Staging для сообщений

Алекс предложил staging - промежуточный слой перед отправкой. Идея простая: агент не отправляет сообщение напрямую. Он кладёт его в очередь. Ты видишь превью. Подтверждаешь или отклоняешь.

Звучит как лишний шаг? Да. Но пока LLM не умеют надёжно различать контексты - это единственный способ не проснуться утром с паникой в чате.

В OpenClaw есть похожий механизм - confirmation mode для опасных действий. Я его включил для всех исходящих сообщений в каналы, кроме моего личного чата. Лишние 5 секунд на подтверждение vs публичный позор. Выбор очевиден.

3. Разделение ролей

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

Принцип наименьших привилегий - ему сто лет. Но с AI-агентами все почему-то забывают. Дают полный доступ “чтобы было удобно”. А потом удивляются.

Мой сетап: основной агент имеет полный доступ к файлам и git. Ограниченный доступ к Telegram - только мой чат. Нулевой доступ к email, соцсетям и другим каналам коммуникации. Каждый новый канал - осознанное решение с явным конфигом.

4. Аудит действий

Каждое действие агента должно логироваться. Не в промте (“запомни что делал”). В системном логе, который агент не может изменить.

OpenClaw пишет всё в memory-файлы. Я могу посмотреть, что именно агент делал в 3 часа ночи. Какие команды запускал. Какие файлы менял. Это не паранойя - это гигиена.

Если у тебя нет аудит-лога - ты не узнаешь о проблеме, пока кто-то не напишет “а это что за сообщение в вашем канале?”

Чеклист перед тем, как дать агенту доступ к коммуникациям

Собрал для себя. Делюсь.

  • Whitelist каналов. Список разрешённых каналов - в конфиге, не в промте
  • Confirmation mode. Для любых исходящих в публичные/командные каналы
  • Минимум привилегий. Агент получает только то, что нужно для конкретной задачи
  • Аудит-лог. Все действия пишутся в лог, который агент не может удалить
  • Тест на staging. Перед продом - прогони агента в тестовом канале
  • Kill switch. Возможность мгновенно отключить агента от всех каналов
  • Регулярный ревью. Раз в неделю - смотришь логи, проверяешь что агент делал

Автономность - это не “отпусти и забудь”

Автономные AI-агенты - кайф. Мой бот анализирует 100 Telegram-каналов каждую ночь, собирает дайджесты, пушит код. Я просыпаюсь - всё готово.

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

Приглашение на 1-on-1 в паблик на 6k - неприятно, но пережить можно. А если бы это было NDA? Финансовые данные? Личная переписка?

Guardrails - не ограничение возможностей. Это условие, при котором эти возможности вообще можно использовать.


Ссылки:

  1. Оригинальный пост Алекса - разбор кейса с Claude Code
  2. OpenClaw на Mac Mini - мой опыт с автономным агентом