# Действия AI-агентов с облачными расходами требуют жёсткой границы

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

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

## Отчётность не должна давать право тратить деньги

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

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

Различие стирают команды с безобидными названиями. Конечная точка «рекомендация» может создавать выгрузку. Конечная точка «обязательство» в зависимости от одного поля может рассчитывать цену, покупать, изменять или отменять обязательство. Запрос мощности у одного провайдера может быть оценкой, а у другого, обязательным изменением. Читайте точное описание операции в документации API провайдера, а не подпись над кнопкой в консоли.

Руководство Cloud FinOps от FinOps Foundation разделяет информирование, оптимизацию и эксплуатационные действия. Это полезная бизнес-модель, но она не создаёт модель авторизации. Человек или агент может информировать, не имея права выполнять изменения. Считайте этот разрыв осознанной частью дизайна, а не формальностью.

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

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

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

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

## Классифицируйте действие по последствиям, а не по глаголу API

Глагол вроде `update` почти ничего не говорит о риске. Классифицируйте действие по тому, что оно меняет, насколько далеко распространяется эффект и насколько трудно его отменить.

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

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

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

```json
{
  "action": "resize_compute_group",
  "scope": {
    "billing_account": "finance-prod",
    "region": "eu-west-1",
    "resource_group": "batch-workers"
  },
  "before": {"instance_type": "c6i.2xlarge", "minimum": 6},
  "after": {"instance_type": "c6i.xlarge", "minimum": 6},
  "expected_monthly_delta": {"currency": "USD", "amount": -412},
  "service_effect": "rolling replacement of batch workers",
  "rollback": "restore c6i.2xlarge and wait for replacements",
  "approval": "per_call"
}
```

Этот документ предотвращает повторяющийся сбой: агент отправляет корректный запрос к цели, которую проверяющий никогда не видел. Провайдер проверяет только возможность выполнить полезную нагрузку. Он не проверяет, имелся ли в виду `finance-prod`, использует ли прогноз правильную цену и достаточно ли свободной мощности у группы рабочих узлов.

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

## Рекомендация это доказательства, а не инструкция

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

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

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

Тот же подход нужен для рекомендаций по обязательствам. Агенту требуется подходящее использование, а не общие расходы. Обязательство, действующее только для определённого семейства, региона, операционной системы, модели аренды или варианта покупки, не покроет всё в широкой категории сервиса. Важнее не кажущаяся скидка, а объём стабильного использования, который действительно подходит.

Попросите агента явно отказаться от рекомендации, если доказательств недостаточно. Хороший отказ выглядит так:

> Я обнаружил низкую загрузку CPU у этих рабочих узлов, но не нашёл метрик памяти и данных об их плановом пике. Я могу подготовить запрос на изменение размера после того, как владелец подтвердит пиковую нагрузку и окно отката.

Такой ответ полезнее уверенной рекомендации, которая заставляет оператора заново восстанавливать пропущенные предпосылки. Модели склонны продолжать знакомые шаблоны. Интерфейс действий должен давать им предусмотренный способ остановиться.

## Обязательства требуют отдельной проверки покупки

Резервирования, обязательства по экономии, блоки мощности и похожие скидки требуют отдельной проверки покупки, даже если арифметика агента верна. Они превращают прогноз использования в обязательство.

Обычно слабое правило звучит так: «подтверждать обязательства выше определённого порога». Оно популярно, потому что его легко объяснить и автоматизировать. Но оно не работает: дешёвое обязательство может раздробить покрытие между множеством команд, а крупное может соответствовать документированному базовому уровню, уже одобренному финансовым отделом. Порог измеряет размер заявки, а не качество решения.

Требуйте, чтобы предложение простыми словами указывало:

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

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

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

Документация провайдера обычно подробно описывает правила применимости, а консоли биллинга часто пересказывают их упрощённо. Если представления расходятся, считайте источником истины документацию API и биллинга. «Расчётная экономия» в консоли это сценарий, а не проверка контракта.

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

## Изменение мощности может сломать сервис раньше, чем сэкономит деньги

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

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

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

Запрос на выполнение должен фиксировать все селекторы цели. Никогда не пропускайте через границу авторизации свободную команду вроде `resize all nonproduction workers`. Сначала разрешите список целей, покажите его и отправляйте идентификаторы, а не запрос по тегу, который после подтверждения может найти новые ресурсы.

Полезная последовательность выполнения состоит из четырёх частей:

1. Агент собирает метрики и определяет точные ресурсы.
2. Он создаёт запись изменения с текущей и предлагаемой конфигурацией, откатом и условием проверки.
3. Человек подтверждает неизменяемую запись для названных ресурсов.
4. Исполнитель действий отправляет запрос, сохраняет идентификатор операции провайдера и сообщает только результаты проверок, предусмотренные контрактом.

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

## Закрытие аккаунта требует других учётных данных и подтверждения человека

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

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

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

Разделяйте закрытие и очистку. Агент может составить инвентаризацию простаивающих ресурсов и подготовить план удаления. Он не должен считать, что удаление этих ресурсов даёт право закрыть аккаунт. Экономией от очистки и решением о прекращении аккаунта занимаются разные владельцы.

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

## Подтверждение должно относиться к точному вызову

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

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

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

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

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

В тексте подтверждения проверяющий должен видеть, что именно получит провайдер. Не просите одобрить название инструмента вроде `cloud.execute`. Покажите `resize_compute_group`, точную группу, старые и новые значения и условие отката. Если интерфейс не вмещает эту информацию, контракт действия слишком широк.

## Храните запись аудита, которую агент не может переписать

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

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

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

NIST SP 800-92, Guide to Computer Security Log Management, рекомендует защищать целостность журналов и обеспечивать их доступность для проверки. Совет не устаревает, потому что проблема старая: команды собирают журналы там, где тот же взломанный процесс может их редактировать. Для действий агентов держите средство записи аудита вне прямого доступа агента к файловой системе и учётным данным.

Sallyport формирует журналы Sessions и Activity из защищённого от записи зашифрованного аудита с цепочкой хешей, а `sp audit verify` может проверить цепочку офлайн без ключа хранилища. Именно такое свойство следует требовать от любого шлюза действий: агент может получить результаты, но не может изменить запись того, что он запросил.

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

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

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

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

Передачу учётных данных оставляйте внутри исполнителя действий. Агент должен получать структурированные результаты, а не bearer-токены, закрытые SSH-ключи, временный вывод команд с секретами или заполнители, которые он случайно выведет в стенограмму. Это защищает учётные данные и снижает вероятность того, что агент перенесёт полномочия в несвязанные инструменты.

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

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