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

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

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

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

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

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