ИИ-агент в моей эксплуатации: ограничители, которые делают его безопасным

Последние месяцы большая часть моей эксплуатации — и в домашней лаборатории, и на работе — идёт через ИИ-агента в терминале (Claude Code). Не чат-бот, который отвечает на вопросы, а агент, который запускает kubectl, читает логи, правит манифесты, пушит в git и вызывает облачные API.

Скорость — простая часть. Агент с шеллом и доступами — ещё и самый быстрый способ сломать прод, который у меня когда-либо был. Поэтому интересный вопрос не «насколько быстрее», а «что делает это безопасным». Ниже — устройство, которое на него отвечает.

Репозиторий — это память

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

• методология: как ведётся диагностика, в каком порядке и чего не делаем никогда;
• runbook’и по симптомам: «под в CrashLoopBackOff», «апгрейд падает с another operation in progress», «сертификат истёк за прокси»;
• карта каждой среды: топология, workload’ы, сеть, хранилище, кто чем владеет, и датированный снимок состояния;
• журнал решений по каждой среде.

Знания копятся в git, а не в окне чата. Когда начинается инцидент, среда уже описана, и агент читает её до того, как что-то трогать.

Правило 1: сначала только чтение

Каждый шаг идёт по схеме гипотеза → read-only проверка → вывод, и только потом изменение. Диагностика движется от лёгкого тира к тяжёлому: сначала get, describe, события и логи, потом PromQL для трендов и сатурации, потом вопрос, от которого зависит, кто чинит: это приложение или платформа?

Симптом — не причина. «Иногда работает» или «само починилось» — удача с таймингом, а не фикс; агент продолжает искать.

Правило 2: у каждого изменения откат виден до запуска

Агенту можно менять, но никогда молча. Перед мутацией я вижу точную команду, куда сделан бэкап, и команду, которая всё вернёт. Изменения с широким blast radius — drain ноды, удаление namespace, scale в ноль — сначала получают явное предупреждение.

В домашней лаборатории нет клиентов и SLA, поэтому там агенту разрешены big-bang изменения. В этом и смысл лабы: разведка боем до того, как то же изменение попадёт в среду, где нужны окно и согласование.

Правило 3: короткоживущие узкие доступы

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

Агент не брал ключ на весь аккаунт. Он выпустил токен на одну зону, только с правами на управление ботами, живущий один час, сделал изменение и отозвал токен в блоке finally. Первая попытка упала: для чтения настройки нужно было ещё право на чтение зоны. Токен всё равно отозвался — отзыв не зависел от успеха. Текущее состояние сохранили до изменения, вместе с откатом в одну строку.

Секреты не попадают ни во что, что уходит с машины: никаких токенов, внутренних хостов и адресов в веб-поиске, а доступы хранятся зашифрованными в git, а не раскиданы по чатам.

Правило 4: кластер знает не всё

Инфраструктура у меня гибридная: часть сервисов в Kubernetes, часть на обычных VM. Кластер знает только про себя, поэтому агенту запрещено делать вывод «сервис мёртв» по данным кластера. Ноль endpoints или отсутствующий Deployment — факт про кластер. Проверка — DNS против адресов ingress и балансировщика, а потом реальный запрос к сервису.

Соседнее правило появилось после случая «чуть не»: у всех kubeconfig-контекстов одинаковое имя, поэтому агент опознаёт кластер по адресу API и нодам, а не по контексту.

Правило 5: решения записываются в момент принятия

Значимое решение получает датированную запись в момент принятия: что выбрали, какие были альтернативы, почему, чем платим и при каком условии пересматриваем. Через месяц вопрос всегда звучит «почему тогда выбрали X», и ответ должен быть в журнале, а не в истории чата.

Где агент ошибался

Ошибается, и именно ограничители это ловят. Три примера за один день:

• Неверная дата из-за сломанной кодировки. Агент прочитал страницу в старой кириллической кодировке, и первая сводка назвала не тот месяц публикации. Повторная загрузка с перекодировкой показала настоящую дату в структурированных данных.
• Уверенная рекомендация, которая оказалась неверной. Агент посоветовал удалить навык в LinkedIn как мусор — а это был локализованный «Site Reliability Engineering». Он исправился, как только увидел полный список.
• План, который не мог сработать. Агент собирался разрешить внедрённый скрипт в Content Security Policy по его хешу. Проверка трёх ответов показала, что хеш меняется на каждый запрос, и от идеи отказались, вместо того чтобы ослабить политику.

Ни одна из этих ошибок не поймана потому, что модель умная. Их поймали потому, что каждое утверждение сверяется с реальной системой раньше, чем от него что-то начинает зависеть. Доверие даёт проверка, а не модель.

Второе мнение от разных моделей

Для рискованных изменений и непонятных инцидентов у меня есть небольшой «совет»: несколько моделей от разных вендоров, у каждой своя оптика (платформа, приложение, сеть, скептик). Они спорят, допрашивают друг друга и голосуют, пока никто не блокирует, а на выходе — письменный отчёт с сохранённым особым мнением. Это не голосование, которому я подчиняюсь, а дешёвый способ найти вопрос, который я не задал.

Что это меняет, а что нет

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

Выводы

• Дайте агенту письменную методологию и карты сред в git; не полагайтесь ни на его память, ни на свою.
• Сначала только чтение, и никаких изменений без видимого отката.
• Выпускайте узкие короткоживущие доступы под задачу и отзывайте их в finally.
• Не позволяйте агенту делать выводы о сервисе только по кластеру.
• Записывайте решения в момент принятия.
• Ждите ошибок и проектируйте их поимку: проверка и есть ограничитель.