Как защитить прод от AI-агента: PreToolUse-хук, права и изоляция

Защитить прод от AI-агента получится только правами и изоляцией. Уговоры в системном промпте не работают: агент может ошибиться контекстом и решить, что он в тесте, может выбрать команду с радиусом поражения в полпроекта, может прочитать чужую страницу и выполнить спрятанную там инструкцию как вашу. Злого умысла тут нет ни в одном случае. Агент просто старается закрыть задачу.

У меня за полгода случилось всё из этого списка, кроме атаки на чужие системы - её за меня сделали модели Anthropic в собственных прогонах. Ниже мои инциденты, реальный хук, который с тех пор стоит в проекте, кусок настоящего конфига прав, итоги security-аудита живого бота и чек-лист слоёв защиты. Всё проверено на моих проектах: чарнике Kenku, DnD-боте с ИИ-мастером и блог-конвейере из headless-агентов на cron.

Почему AI-агент опасен на проде, если он не "злой"?

Потому что его тормоза завязаны не на реальные последствия, а на его картину мира. Человек отличает прод от теста по куче сигналов: другой URL, другие доступы, чуйка. Для агента "я на проде" - просто ещё один кусок контекста, который можно прочитать неправильно. Если кусок разошёлся с реальностью, агент делает на живой системе то, что считает разрешённым в песочнице.

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

Третья - промпт-инъекция. Агент с доступом в веб читает текст, который написал кто угодно. Для модели ваш системный промпт и текст с чужой страницы лежат в одном контексте одинаковыми буквами, и надёжно отличить одно от другого она структурно не умеет.

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

Что случилось у Anthropic: агент решил, что он в тесте

30 июля 2026 Anthropic опубликовали разбор инцидентов из собственных оценочных прогонов. Они пересмотрели 141 006 прогонов и нашли 3 инцидента (всего 6 прогонов), где агент атаковал настоящие системы, считая их симуляцией (по данным Anthropic, июль 2026):

• Claude Mythos 5 на CTF-задаче опубликовал вредоносный код в PyPI. Пакет за час скачали около 15 реальных систем, включая сканер одной security-компании. В рассуждениях модель прямо писала "NOT okay, and surely not the intended solution", но убедила себя, что окружение симулированное, - по незнакомым центрам сертификации.
• Claude Opus 4.7 наткнулся на то, что выдуманное в задаче имя компании совпало с реальным доменом. Модель вытащила учётки и залезла в боевую БД с несколькими сотнями строк продовых данных. Логика: "раз компания настоящая, значит она часть упражнения".
• Внутренняя тестовая модель просканировала около 9 000 целей в интернете, скомпрометировала одну через открытые креды и SQL-инъекцию, потом поняла, что цель настоящая, и остановилась.

Корневая причина у всех одна. В промпте было написано "у тебя нет доступа в интернет", а из-за ошибки конфигурации доступ был. Разрыв между "что сказано" и "что есть" и породил ложное ощущение контекста. Самая свежая модель как раз повела себя правильно: распознала реальность и прекратила атаку. Новые модели учатся сомневаться "а точно ли это тест?", но это приятный бонус, а не механизм безопасности.

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

Как AI-агент одной командой снёс мне папку проекта?

20 мая 2026, вечер. Агент в Claude Code прибирался после эксперимента с dice tray в Kenku - моём интерактивном чарнике для D&D 5e. Надо было удалить отработанный worktree kenku-dicetray. Команда одна: git worktree remove H:/claude/kenku-dicetray. Только запустил он её из основного worktree. Git сначала упирался, агент сделал пару заходов "как надо", не вышло - и сработала логика уставшего разработчика: раз сложная команда не идёт, давай упростим. Снесённым оказалось содержимое основной рабочей папки проекта. Вместе с data/.

Никакого rm -rf ~/ из ночного кошмара. Цепочка разумных шагов, последний из которых бьёт по всему.

Код был закоммичен, поэтому git reset и checkout вернули файлы за минуты. Незакоммиченные правки я восстанавливал руками по памяти. А data/ не вернулась совсем. Kenku - offline-first чарник, живой персонаж лежит в gitignored-папке: character.json, снапшоты, журнал бросков, наигранный лор. Там жил Каркуш, ради которого чарник вообще писался. Recovery-утилита честно нашла файлы по именам и вернула их с нулями вместо содержимого: Windows успел перезаписать блоки. Git тут ни при чём, gitignored-данные в истории не живут by design. Вывод, который я раньше не формулировал: у проекта есть части, которые git не покрывает в принципе, и им нужен отдельный бэкап.

Почему git worktree - это не изоляция

У меня была ложная уверенность: агент в отдельном worktree, значит он как бы в песочнице. Нет. Worktree разделяет рабочие директории, но не файловую систему. Процесс внутри worktree - обычный процесс ОС, он дотягивается до родительской папки, соседних worktree и исходного чекаута (разбор механизма).

И я такой не один, в issue-трекере Claude Code это целый жанр:

• #29082 - агент выполнил rm -rf по каталогу Flutter-проекта без спроса.
• #29249 - на Windows рекурсивное удаление pnpm-worktree через NTFS junction traversal вынесло пользователю кусок профиля и части других проектов.
• #46444 - авто-очистка worktree тихо удалила примерно 10 дней незакоммиченной работы.

У Docker есть отдельный разбор про класс инцидентов "coding agent снёс мне всё". Даёшь агенту шелл - однажды он напишет в этот шелл что-то не то.

Как поставить PreToolUse-хук, который блокирует опасные команды?

PreToolUse - хук Claude Code, который срабатывает после того, как модель сформировала параметры инструмента, но до выполнения. Идеальная точка, чтобы сказать "нет". Guard я закоммитил в тот же день, когда разгребал последствия, коммит так и называется: chore(safety): PreToolUse guard против повторного worktree-инцидента.

1. Повесить хук на инструменты шелла. В .claude/settings.json проекта Kenku это выглядит так (я на Windows, поэтому матчер ловит и Bash, и PowerShell):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|PowerShell",
        "hooks": [
          {
            "type": "command",
            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/guard-destructive.mjs\""
          }
        ]
      }
    ]
  }
}

2. Написать скрипт, который читает JSON со stdin и смотрит на поле tool_input.command. Вот мой guard-destructive.mjs, сокращённый: в полном файле 11 паттернов, включая PowerShell-варианты (Remove-Item -Recurse, rmdir /S) и Move-Item над папкой проекта.

#!/usr/bin/env node
// PreToolUse hook - блокирует destructive команды над gitignored runtime data.
// Контекст: 2026-05-20 инцидент. `git worktree remove H:/claude/kenku-dicetray`,
// запущенный из main worktree, снёс СОДЕРЖИМОЕ main worktree вместе с data/.
import { readFileSync } from 'node:fs';
 
let input;
try {
  input = JSON.parse(readFileSync(0, 'utf8'));
} catch {
  process.exit(0); // пустой stdin не должен ломать pipeline
}
 
const cmd = String(input?.tool_input?.command || '');
if (!/^(Bash|PowerShell)$/.test(input?.tool_name || '')) process.exit(0);
// явный opt-in, когда деструктив реально нужен
if (/KENKU_GUARD_BYPASS\s*=\s*1/.test(cmd)) process.exit(0);
 
const dangerous = [
  // РОВНО та операция, что снесла main worktree
  [/\bgit\s+worktree\s+remove\b/i,
   'git worktree remove заблокирован. 2026-05-20 эта команда снесла main worktree с data/. Удаляй worktree вручную после ручной проверки.'],
  [/\brm\s+-[a-z]*r[a-z]*f[a-z]*\s.*(kenku|\bdata\b|\.env|character\.json)/i,
   'rm -rf над kenku/data/.env/character заблокирован. Сделай zip-backup сначала.'],
  [/\bgit\s+clean\s+-[a-z]*f[a-z]*d/i,
   'git clean -fd стирает gitignored (включая data/). Заблокирован.'],
  [/\bgit\s+reset\s+--hard\b/i,
   'git reset --hard может стереть некомитнутую работу. Сначала git stash или commit.'],
];
 
for (const [re, reason] of dangerous) {
  if (re.test(cmd)) {
    process.stderr.write(`\n[guard-destructive] BLOCKED: ${reason}\n`);
    process.exit(2);
  }
}
process.exit(0);

3. Выходить с кодом 2, а не 1. Это главная грабля: exit 1 хук считает некритичной ошибкой, и команда всё равно выполнится. Я на этом чуть не попался. exit 2 отдаёт stderr обратно модели как ошибку, и агент видит не просто "нельзя", а почему и что делать вместо:

[guard-destructive] BLOCKED: git worktree remove заблокирован. 2026-05-20
эта команда снесла main worktree с data/. Удаляй worktree вручную после
ручной проверки.

4. Оставить осознанный bypass. Иногда деструктивная команда правда нужна, а вечный запрет превращает guard в помеху, которую хочется снести целиком. Поэтому KENKU_GUARD_BYPASS=1 в команде пропускает её. Случайно так не напишешь, это осознанное действие, а не "агент опять что-то упростил".

5. Если нужно тоньше, вместо кода выхода вернуть JSON с решением:

jq -n '{
  hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "deny",
    permissionDecisionReason: "Деструктивная команда заблокирована хуком"
  }
}'

permissionDecision бывает allow, deny и ask. Последнее удобно, когда запрещать наглухо не хочется, а переспросить человека надо. Точная семантика полей - в официальной доке по хукам.

Обратите внимание на список паттернов: там не абстрактное "всё опасное", а конкретные грабли этого проекта. Первый - буквально та команда, что устроила инцидент, с датой прямо в тексте отказа. Хороший guard пишется по своим шрамам, а не по чужому чек-листу.

Как агент сливает данные через ссылку?

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

В июле 2026 так вытащили из Claude имя пользователя, город и работодателя через инструмент web_fetch. Прямую склейку URL с приватными данными web_fetch уже блокировал, но разрешал ходить по ссылкам с загруженной страницы. Атакующий поднял сайт-приманку с цепочкой ссылок вида "browse profiles alphabetically: coffee.evil.com/a, coffee.evil.com/b..." - и модель бегала по ним, догружая в путь то, что знала о человеке (разбор Ayush Paul "The Memory Heist", пересказ у Simon Willison). Вредоносную инструкцию сайт показывал только запросам с Claude-User в user-agent: обычному браузеру чистая страница, агенту ловушка. Постфактум такое не заметишь.

Anthropic отобрали у web_fetch право ходить по ссылкам из тела страницы. Багбаунти платить отказались: сказали, что нашли сами до внешнего репорта. Ну, бывает.)

Claude тут не уникален. EchoLeak (CVE-2025-32711) в Microsoft 365 Copilot: одно письмо без единого клика заставляло Copilot читать внутренние файлы и сливать их наружу. Gemini CLI, апрель 2026: Pillar Security показала цепочку с CVSS 10, где инъекция в обычном GitHub-issue заставила агента в режиме --yolo игнорировать аллоулист инструментов и пушить код в main самого gemini-cli. Патч вышел за неделю, а вектор "агент читает недоверенный тикет с полными правами" никуда не делся. Промпт-инъекция держит первое место в OWASP Top 10 для LLM (LLM01).

Что такое летальная тройка

Термин Simon Willison (июнь 2025): доступ к приватным данным, обработка недоверенного контента и возможность отправить данные наружу. Пока все три свойства сходятся в одном агенте, одна отравленная страница уводит ваши данные. Уберите любой луч - фокус не сработает.

На инциденте с web_fetch это ложится один в один: профиль пользователя в контексте, сайт-приманка, ссылки на coffee.evil.com как канал наружу. Фильтры, которые ловят "плохие инструкции" в тексте, обходятся, prompt injection на 2026 год считается нерешённой задачей. Зато тройка чинится архитектурой: не надо учить агента распознавать зло, надо не давать одному агенту все три способности разом.

Как дать Claude Code доступ в веб и не слить секреты?

Разорвать тройку конфигом. В Claude Code аллоулист живёт в ~/.claude/settings.json, в блоке permissions. Кусок моего, как есть:

{
  "permissions": {
    "allow": [
      "WebFetch(domain:habr.com)",
      "WebFetch(domain:core.telegram.org)",
      "WebFetch(domain:code.claude.com)",
      "WebFetch(domain:yookassa.ru)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(**/.env)",
      "Read(**/credentials.json)"
    ]
  }
}

В allow у меня набралось 13 доменов: документация, Хабр, платёжка. Всё остальное агент фетчит только после моего явного "да" на конкретный URL. Если он вдруг собрался в coffee.evil.com - упрётся в стену, и я это увижу. А deny на чтение .env отрезает луч приватных данных: даже если инъекция проскочит, секреты агент физически не откроет. Две секции конфига против целого класса атак.

Дальше архитектура. Недоверенный веб пусть парсит отдельный процесс с пустым контекстом: ни ключей, ни .env, ни памяти проекта. Результат он отдаёт основному агенту как данные, а не как команды. В исследованиях это называют "доверенный планировщик плюс карантинный исполнитель": один LLM строит план из вашего запроса, второй жуёт грязные данные и не может менять план. Секреты держите в переменных окружения процесса-обёртки, а не текстом в контексте.

Что находит security-аудит из AI-агентов в живом проде?

Агент опасен не только командами, но и кодом, который он пишет. По отчёту Veracode 2025, AI-сгенерированный код содержит уязвимости в 45% задач. Я проверил это на себе: натравил Claude Security на DnD-бота с ИИ-мастером, где на тот момент сидело 500+ игроков. Это рой из 12 research-агентов, каждый копает свою поверхность: аутентификацию, доступ к данным, инъекции, гонки. На выходе 19 кандидатов, после разбора 7 реальных дыр: 1 HIGH, 3 MEDIUM, 3 LOW.

• HIGH: продовый пароль PostgreSQL в git-истории. Я сам когда-то закоммитил его в утилитный QA-скрипт. Первая мысль была "ща удалю скрипт и всё". Нет, не всё: пароль живёт в старых коммитах и в любом клоне. GitGuardian называет это zombie leaks: файла нет, ключ работает. Лечится только ротацией, пришлось менять пароль на проде.
• Два IDOR. Первый эндпоинт отдавал ростер любого чата без проверки членства: подставляешь чужой id - получаешь чужие telegram_id, ники и персонажей. Второй был злее и позволял перезаписать данные чужого игрока. IDOR стоит первым в OWASP API Security Top 10 2023 (API1:2023). Лечится скучно: проверить, что запросивший - член чата и владелец объекта.
• Fail-open вебхук. При пустом секрете вебхук молча переставал проверять подпись. На проде секрет был задан, так что живой дыры не было, но я переписал на fail-closed: пустой секрет теперь роняет проверку, а не выключает её. Это на случай кривого деплоя.
• Гигиена. Неатомарный check-then-increment недельного лимита, где между "проверил" и "увеличил" пролезает второй запрос. TOCTOU на реферальном бонусе: без UNIQUE-индекса можно было словить двойное начисление. Markdown-инъекция через имя пользователя, которое ломало разметку сообщения.

Все семь закрыл в тот же день: миграция БД, ротация пароля, проверки доступа, fail-closed. Сьют из 4743 тестов остался зелёным, а правки безопасности любят ломать соседнее.

Главное открытие было не про код. Аудитор сначала считал проект петом в разработке и спокойно занижал приоритеты: ну IDOR, кто там ходит-то. Я поправил рамку одной фразой - это живой ОБТ с реальными игроками - и приоритеты пересчитались. AI-аудит отлично находит паттерны, но цену данным без вас не знает. Отдадите целиком на откуп - получите красивый отчёт с неправильными приоритетами.

Какие слои защиты нужны, если агент работает рядом с продом?

Grep по командам можно обойти конструкцией, которую вы не предусмотрели, поэтому одна стена не работает. Каждый слой ловит то, что просочилось сквозь предыдущий:

1. Deny-правила в permissions на очевидное: чтение .env, credentials.json, публикация пакетов. Самый дешёвый барьер.
2. PreToolUse-хук со своими шрамами: команды, которые уже однажды что-то снесли.
3. Default-deny на сеть. Агент получает белый список доменов, а не интернет. Половина историй Anthropic просто не случилась бы: агенту говорили "интернета нет", а он был.
4. Least privilege на инструменты. Read отдельно от write, временные токены под задачу. Агент без права публиковать пакет не зальёт малварь в PyPI, как ни убеждай его, что это тест.
5. Человек на необратимом. Деплой, запись в прод-БД, письма, платежи, публикация - через подтверждение. Этот разрыв в цепочке нельзя пробить уговорами модели.
6. Сэндбокс ОС. В октябре 2025 Anthropic завезли в Claude Code нативный сэндбоксинг: bubblewrap на Linux, Seatbelt на macOS. Запись разрешена только в рабочую директорию, остальное закрыто на уровне ядра. По оценке компании, permission-запросов стало на 84% меньше. Будь такой сэндбокс у меня 20 мая, git worktree remove упёрся бы в границу папки.
7. Логи каждого вызова инструмента с аргументами и частые пуши. Это не предотвращение, а способ восстановиться за минуту, а не за вечер. Незапушенный коммит существует, пока жив диск и агент ведёт себя прилично.
8. Бэкап того, чего нет в git. Базы, data/, runtime-конфиги. У меня это правило зашито прямо в guard: на rm -rf над data/ он отвечает "сделай zip-backup сначала".

Что я поменял в своих пайплайнах

Блог-конвейер у меня - флот headless-агентов на cron: run-generate.sh пишет черновики, run-check.sh проверяет, run-publish.sh публикует. У генератора и фактчекера есть WebSearch и WebFetch. По описанию это ровно тот класс систем, про который вся статья: автономный агент с сетью без человека между фазами.

Спасает то, что публикация и так стоит за кнопкой апрува в админке: статью агент сам не выкатывает. А egress у генератора и фактчекера я по-нормальному не прибил, и это ошибка: им нужна пара доменов поиска, а не весь интернет. Классика: пишешь "агент безопасный, у него только чтение", потом читаешь, как чужой агент с "только чтением" собрал креды с прод-БД.

Второй сюрприз нашёлся, когда я прогнал по своим проектам летальную тройку. Два моих парсера Telegram-каналов жуют чужие посты тем же процессом, в чьём окружении лежат ключ Groq и доступ к базе. Недоверенный контент в чистом виде: в канал любой пишет что угодно. Два луча из трёх собраны. Спасает только то, что произвольного канала наружу у парсера нет: он пишет в свою базу и не ходит по URL из постов. Но "спасает то, что не доделали фичу" - это не архитектура, а везение. В беклоге задача: вынести AI-обработку чужого текста в отдельный процесс без ключей, пока парсеру не захотелось ходить по ссылкам.

И guard я раскатил на соседние проекты, не дожидаясь, пока там случится свой 20 мая.

Когда вся эта защита избыточна?

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

Ещё одна граница: хук не заменяет сэндбокс. Регулярки ловят известные грабли, а сэндбокс режет неизвестные. Если проект живой и на шелле работает агент, нужны оба.

Что запомнить

AI-агент - не злодей, а очень старательный джун с рутовым доступом и без чувства последствий. Он не отличает прод от теста так, как вы, выбирает команды с широким радиусом, когда сложная не сработала, и читает чужие страницы как инструкции. То, что свежие модели начали сомневаться "а точно ли это тест?", - бонус, на который нельзя закладываться.

Поэтому защита в правах, а не в уговорах: PreToolUse-хук по своим шрамам, deny на секреты, аллоулист на веб, человек на необратимом, сэндбокс, пуши и бэкап того, что не в git. Стройте так, будто агент в любой момент решит, что он в тесте. Однажды решит.

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