Почему изоляция и есть фича
Чем способнее агенты, тем шире их потенциальный радиус поражения. Агент, который может поднять серверы, водить браузер и переписать ваши шаблоны по собственной инициативе, чрезвычайно полезен — и запускать его без песочницы по-настоящему плохая идея. Инженерный вопрос не в том, позволять ли агентам действовать, а в том, как ограничить то, до чего может дотянуться неудачный ход.
Ответ Forge — изоляция на каждом слое, где она имеет значение.
Докажи это на одноразовом окружении
Прежде чем изменение вольётся, персонаж QA разворачивает полную матрицу сервисов на изолированный одноразовый стенд — со своим поддоменом <run-id>--app, — прогоняет смоук по живым эндпоинтам и затем всегда его уничтожает. Вердикт опирается на свидетельство реально обслуживаемого трафика, а не на «CI был зелёный». Поскольку стенд одноразовый и убирается сборщиком, оставить его поднятым невозможно по конструкции.
Ограниченные доступы вместо всемогущих токенов
Каждый прогон исполняется под корнем JWT, выданным на вызов и ограниченным его парой (сессия, ход) — узкая граница доверия, отделённая от ключа шифрования. Прогон дотягивается ровно до того, что разрешает его манифест, и не дальше. Вместе с ограниченными секретами
скомпрометированный или запутавшийся агент попросту не имеет охвата, чтобы нанести широкий ущерб.
Изоляция арендаторов, проверяемая аудитом
Мультиарендность с самого основания: воркеры, сессии и данные одной организации невидимы другой; это обеспечивается на уровне воркеров и RBAC и проверяется аудитом на каждом пути межорганизационного доступа. Изоляция здесь не обещание в документации — она проверяется.
Подробный рассказ — в статье Relentlessly proactive agents need relentlessly isolated stacks .