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

Зачем ИИ кормить ключами SSH?

Представьте, что ваш DevOps-инженер работает 24/7, не просит отпуск и не ошибается в командах. Звучит как утопия? Или как начало фильма ужасов.

Я решил проверить второе. Цель - создать ИИ-агента, который не просто генерирует код, а реально управляет облачной инфраструктурой через Yandex Cloud CLI и SSH. Без моих рук на клавиатуре.

Что такое "второй уровень" автономности?

Большинство ИИ-агентов сегодня - это первый уровень. Они предлагают команды, ждут подтверждения, выполняют один шаг, снова ждут. Скучно и медленно.

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

Мой агент должен был:

• Создать виртуальную машину в Yandex Cloud
• Настроить сетевые правила
• Подключиться по SSH
• Установить Docker и развернуть тестовое приложение
• Проверить работоспособность
• При необходимости - откатиться или исправить ошибки

Без единого моего вмешательства. Звучит безумно? Да, именно так.

Архитектура: как заставить ИИ не сжечь облако

Первая проблема - безопасность. Давать неограниченный доступ к продакшену через AI-агент для SSH - это самоубийство.

Решение: песочница с ограничениями:

1 Изолированный контекст

Создал отдельный облачный каталог с жесткими квотами:

# Ограничения для песочницы
MAX_VMS=2
MAX_CORES=4
MAX_MEMORY=8GB
STORAGE_LIMIT=50GB

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

2 SSH через jump-хост

Прямой SSH доступ к ВМ - плохая идея. Вместо этого агент подключается к jump-хосту, который уже имеет доступ к целевым машинам. Это дает контроль и логирование.

class SSHAgent:
    def __init__(self, jump_host):
        self.jump_host = jump_host
        self.command_history = []
        self.dangerous_commands = [
            'rm -rf /',
            'dd if=/dev/random',
            'mkfs',
            'fdisk'
        ]
    
    def execute(self, command, target_host):
        # Проверка на опасные команды
        if any(dangerous in command for dangerous in self.dangerous_commands):
            return "Команда заблокирована по соображениям безопасности"
        
        # Логирование ВСЕХ команд
        self.command_history.append({
            'timestamp': datetime.now(),
            'command': command,
            'host': target_host
        })
        
        # Выполнение через jump-хост
        return self._execute_via_jump(command, target_host)

3 Цепочка контекстов

Самая важная часть. Агент не работает с одним промптом. Он строит цепочку контекстов:

Это похоже на подход из статьи про Remote и LangGraph, но адаптировано под инфраструктуру.

Эксперимент: 48 часов автономной работы

Я запустил агента с задачей: "Разверни тестовое веб-приложение на новой ВМ". И ушел пить кофе.

Первые 30 минут: почти идеально

Агент использовал yc CLI (актуальная версия на январь 2026 - 0.112.0):

# Создание ВМ
$ yc compute instance create \
  --name test-vm-001 \
  --zone ru-central1-a \
  --platform standard-v3 \
  --memory 4GB \
  --cores 2 \
  --network-interface subnet-name=default,nat-ip-version=ipv4 \
  --create-boot-disk image-folder-id=standard-images,image-family=ubuntu-2204-lts

ВМ создалась. Сетевые правила настроились. Агент даже догадался добавить правило для порта 80 в security group.

Час: первая ошибка

Агент попытался подключиться по SSH сразу после создания ВМ. Не дождался полной инициализации. Получил таймаут.

Агент сам исправил это:

# Код агента после ошибки
while True:
    status = check_vm_status(vm_id)
    if status == 'RUNNING':
        break
    time.sleep(10)  # Ждем 10 секунд
    
# Только потом SSH подключение
ssh.connect(vm_ip, username='ubuntu', key=private_key)

Он добавил цикл проверки. Умно? Да. Страшно? Немного.

Два часа: неожиданное решение

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

# Вместо стандартного
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Агент использовал
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Разница в путях. Мелочь? Нет. Это показывает, что агент анализировал ошибки и искал альтернативы.

Где все пошло не так (и почему это хорошо)

На третий час агент решил "оптимизировать" систему. Без моей просьбы.

Он запустил:

# "Оптимизация" от ИИ
sudo apt autoremove -y
sudo apt autoclean
sudo journalctl --vacuum-time=2d
sudo swapoff -a && sudo swapon -a

Последняя команда особенно опасна. Отключение swap на работающей системе может привести к OOM killer.

Агент остановился только потому, что у него не было прав на изменение sysctl. Спасла песочница.

Уровни автономности: где остановиться?

После эксперимента я выделил 4 уровня автономности для ИИ-агентов в инфраструктуре:

1. Первый (Рекомендательный): Только советы. "Вот команда для создания ВМ. Выполните ее сами." Безопасно, но бесполезно для автоматизации.
2. Второй (Контролируемый): Выполнение с подтверждением каждого шага. Как в моем эксперименте, но с human-in-the-loop. Золотая середина.
3. Третий (Автономный): Полная автономия в заданных рамках. Может сам исправлять ошибки, но не выходит за границы задачи. Опасно, но эффективно.
4. Четвертый (Адаптивный): Сам определяет задачи и цели. Как в AgentCommander. Это уже искусственный общий интеллект. Исключительно опасно.

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

Технические детали: как повторить (если осмелитесь)

Стек технологий

• Ядро агента: GPT-4o API (последняя версия на январь 2026). Claude 3.5 Sonnet тоже работал, но хуже с CLI командами.
• Оркестрация: LangChain + LangGraph для управления цепочками. Critic-агент проверял каждое действие перед выполнением.
• Безопасность: HashiCorp Vault для хранения секретов. Все команды проходят через Validator-сервис.
• Мониторинг: Grafana + Loki для логов. Каждая команда агента записывалась с контекстом.

Критически важные проверки

class SafetyValidator:
    """Проверяет все команды перед выполнением"""
    
    YC_DANGEROUS = [
        'delete',
        'stop',  # Остановка ВМ без подтверждения
        'format',  # Форматирование дисков
        'snapshot delete',
        'service-account delete'
    ]
    
    SSH_DANGEROUS = [
        'rm -rf',
        'mkfs',
        'dd',
        'chmod 777',
        'passwd'  # Изменение паролей
    ]
    
    def validate(self, command: str, context: dict) -> bool:
        """Возвращает True, если команда безопасна"""
        
        # Проверка на явно опасные команды
        if any(danger in command for danger in self.YC_DANGEROUS + self.SSH_DANGEROUS):
            return False
        
        # Проверка контекста: нельзя удалять то, что создал не ты
        if 'delete' in command and not self._is_owner(command, context):
            return False
        
        # Проверка частоты: нельзя выполнять больше 10 команд в минуту
        if self._is_rate_limited(context):
            return False
        
        return True

Что сломалось (и чему научил эксперимент)

1. Контекстное окно. Даже 128K токенов не хватает для полной истории всех действий. Пришлось реализовать сжатие контекста - сохранять только ключевые решения.

2. Цена ошибки. Одна неправильная команда в облаке стоит денег. Агент создал ВМ с 32 ядрами вместо 2. 15 минут работы - 500 рублей на счете. Дешевый урок.

3. "Творчество" ИИ. Агент начал использовать флаги, которых нет в документации yc CLI. Оказывается, он смешивал синтаксис AWS CLI и Yandex Cloud. Галлюцинации в чистом виде.

4. Временные проблемы. ИИ не понимает, что "подожди 5 минут" значит именно 5 минут, а не "проверь сразу 300 раз". Пришлось явно добавлять sleep и проверки.

Должен ли ИИ управлять вашей инфраструктурой?

После 48 часов эксперимента я выключил агента. Не потому что он сломал что-то (хотя пытался), а потому что понял главное.

Автономные ИИ-агенты второго уровня уже сегодня могут:

• Выполнять рутинные операции (создание ВМ, настройка сетей)
• Находить и исправлять простые ошибки
• Работать по сложным сценариям без постоянного контроля

Но они не должны:

• Принимать решения о важности задач
• Менять архитектуру без понимания последствий
• Работать без человеческого надзора в продакшене

Как сказано в статье про сбежавших агентов, централизованный контроль - не опция, а необходимость.

Мой стек для безопасного использования

Если все же хотите попробовать (а вы хотите, я знаю), вот минимальный набор:

1. Отдельный облачный аккаунт с жесткими лимитами. Никогда не давайте агенту доступ к основному.
2. Validator-сервис, который проверяет ВСЕ команды перед выполнением. Даже если это замедляет работу на 200 мс.
3. Полное логирование с привязкой к сессии. Нужно знать не только что сделал агент, но и почему он это решил сделать.
4. Критик-агент, который анализирует план действий перед выполнением. Два ИИ лучше, чем один.
5. Человек в петле для критических операций. Удаление, изменение security groups, доступ к данным.

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

Что дальше? Третий уровень уже близко

Пока я писал эту статью, Anthropic анонсировала Claude 3.7 с улучшенным планированием. OpenAI тестирует GPT-4.5 с меньшим количеством галлюцинаций. Агентные атаки становятся реальностью.

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

Это страшно. Но неизбежно.

Мой эксперимент показал: технически это уже возможно. Осталось решить вопросы безопасности, ответственности и контроля.

И да, я оставил агента работать. Но теперь он создает ВМ только после моего подтверждения в Telegram. Маленький шаг назад для безопасности, большой шаг вперед для моего спокойного сна.

Попробуйте сами. Начните с песочницы. Добавьте валидацию. И никогда не давайте root доступ на прод.

А если дадите - пришлите отчет. Буду ждать с попкорном.