GitHub представила архитектуру Agentic Workflows — набора инструментов для безопасного запуска ИИ-агентов в рамках GitHub Actions. Компания подробно описала угрозы, связанные с автономными агентами в CI/CD-пайплайнах, и подход к их снижению за счёт изоляции, ограничений на операции записи и масштабного логирования.
Агенты в GitHub Agentic Workflows могут анализировать состояние репозитория и принимать решения во время выполнения. Это повышает эффективность разработки, но создаёт риски: агент обрабатывает внешние данные, может взаимодействовать с инфраструктурой и вносить изменения без прямого контроля в реальном времени. GitHub исходит из предположения, что агент будет пытаться читать и изменять лишние данные, использовать неожиданные каналы связи и выполнять нежелательные действия.
По умолчанию Agentic Workflows работают в строгом режиме безопасности. Дизайн основан на четырёх принципах: многоуровневая защита, отсутствие доверия к агентам при работе с секретами, этапная проверка всех записей и полное логирование действий.
Архитектура безопасности построена в виде трёх уровней: базовый слой (substrate), конфигурационный слой и слой планирования. Каждый уровень ограничивает возможный ущерб от сбоев выше него и обеспечивает свои свойства безопасности.
На базовом уровне используется виртуальная машина GitHub Actions runner и несколько доверенных контейнеров, которые ограничивают ресурсы, доступные агенту. Этот уровень отвечает за изоляцию компонентов, фильтрацию привилегированных операций и системных вызовов, а также за границы коммуникаций, которые обеспечиваются ядром системы. Это снижает риск даже при компрометации пользовательского компонента внутри контейнера.
Конфигурационный уровень использует декларативные артефакты и инструменты, которые на их основе строят безопасную структуру системы и связи между компонентами. Здесь задаётся, какие компоненты запускаются, как они соединены, какие каналы связи разрешены и какие привилегии назначены. Внешние токены (ключи агентов, GitHub access tokens) выступают входными данными, а конфигурация определяет, в какие контейнеры и в каком виде они могут быть загружены.
Планировочный уровень формирует пошаговый рабочий процесс с явными обменами данными между компонентами. Он отвечает за то, какие компоненты активны в каждый момент времени. Ключевой элемент этого уровня — подсистема безопасных выходов (safe outputs), которая управляет тем, как и что агент может записывать в систему.
Одно из базовых решений — агенты без доступа к секретам. Поскольку GitHub Actions по умолчанию работают в общем домене доверия на виртуальной машине, переменные окружения и конфигурации с токенами и ключами потенциально видны всем процессам. Это опасно из-за атак через prompt injection, когда злоумышленник подсовывает агенту специально подготовленные данные (страницы, issue, комментарии), чтобы вынудить его прочитать и утечь секреты.
Для снижения рисков GitHub изолирует агент в выделенный контейнер с жёстко контролируемым исходящим трафиком: доступ в интернет фильтруется через файрвол, взаимодействие с MCP-серверами идёт через доверенный MCP-шлюз, а запросы к большим языковым моделям (LLM) — через отдельный API-прокси. Сам шлюз MCP работает в другом доверенном контейнере, запускает MCP-серверы и имеет эксклюзивный доступ к их данным авторизации.
Агенты (например, Claude, Codex, Copilot) обязаны общаться с LLM по аутентифицированному каналу, но токены для этого не попадают в контейнер агента. Вместо этого они хранятся в изолированном API-прокси, через который проксируется весь трафик к моделям. Так агент не может напрямую прочитать и утечь ключи доступа.
GitHub отмечает, что подход с агентами без секретов требует компромисса между безопасностью и полезностью. Для работы с кодом агентам нужен широкий доступ к компиляторам, интерпретаторам, сценариям и состоянию репозитория, однако разворачивать полноценную среду внутри контейнера было бы избыточно и расширило бы список разрешённых сетевых направлений.
Вместо этого GitHub использует монтирование томов и chroot jail. В контейнер агента подключается файловая система хоста по пути /host в режиме только чтение, а отдельные пути перекрываются временными файловыми системами (tmpfs). Агент запускается в chroot в корне /host. Такой подход сохраняет готовую среду хоста, но ограничивает те части файловой системы, которые агент может изменять и даже находить.
Даже без доступа к секретам агент может нанести урон: завалить репозиторий бессмысленными issue и pull request, добавить нежелательные ссылки и контент. Для этого подсистема компиляции Agentic Workflows разбивает процесс на явные этапы и для каждого этапа фиксирует допустимые действия записи и связанные ограничения.
Во время работы агент может читать состояние GitHub через GitHub MCP server, а записи делает только через safe outputs MCP server. После завершения работы агента все накопленные операции записи проходят серию проверок в подсистеме safe outputs.
Safe outputs выполняет три типа контроля. Во-первых, авторы рабочей схемы задают, какие именно операции записи разрешены: например, какие типы объектов в GitHub агент вправе создавать (issue, комментарии, pull request). Во-вторых, задаются количественные лимиты, например не более трёх pull request за один запуск. В-третьих, содержимое обновлений анализируется на наличие нежелательных паттернов, таких как URL, которые могут быть автоматически удалены. Лишь прошедшие весь конвейер артефакты продолжают выполнение.
Даже при отсутствии доступа к секретам и проверках записей агент остаётся мощным инструментом, способным неожиданным образом комбинировать данные и инструменты или пытаться выйти за рамки наложенных ограничений. Для последующего анализа инцидентов необходима полная картина его действий.
В Agentic Workflows наблюдаемость встроена в архитектуру: на всех границах доверия ведётся расширенное логирование. На уровне файрвола фиксируется сетевая активность и направления трафика, API-прокси записывает метаданные запросов и ответов моделей и все аутентифицированные запросы, а MCP-шлюз и MCP-серверы логируют вызовы инструментов.
Дополнительно внутри контейнера агента собираются данные об операциях, связанных с потенциально чувствительными действиями, например доступами к переменным окружения. Совокупность этих журналов позволяет восстанавливать цепочку событий от начала до конца, проверять выполнение политик и быстрее обнаруживать аномальное поведение агента.
Масштабное логирование также создаёт базу для будущих механизмов контроля потоков данных. Там, где сейчас можно только наблюдать коммуникацию, в дальнейшем можно будет её ограничивать. Уже сейчас Agentic Workflows поддерживают режим блокировки GitHub MCP server (lockdown mode), а в ближайшие месяцы GitHub планирует добавить дополнительные защитные механизмы, которые будут применять политики к MCP-серверам с учётом видимости данных (публичные/приватные) и роли автора объекта репозитория.
GitHub приглашает разработчиков к участию в обсуждении Agentic Workflows через Community и специализированный канал #agentic-workflows в Discord GitHub Next. Компания ожидает, что пользователи будут делиться сценариями использования и обратной связью по безопасности и удобству.
Agentic Workflows уже доступны в формате technical preview. Они позволяют строить автоматизации на базе кодовых агентов в GitHub Actions для задач триажа, документации, контроля качества кода и других процессов разработки.
По данным GitHub, в экосистеме также развиваются связанные решения: система памяти для агентов в GitHub Copilot, которая помогает им обучаться на всём цикле разработки, начиная с кодового агента, CLI и ревью кода; агент GitHub Security Lab Taskflow для поиска уязвимостей вроде обхода аутентификации, IDOR, утечек токенов; а также инструменты автоматизации code review в Copilot.
Источник: блог GitHub.
