В журналах уже видны повторные запуски сборок, а AI Agent запрашивает больше проектов, чем ему поручали.

Быстрое решение: TeamCity 2026.2 MCP можно вводить в корпоративный пилот, но начинать нужно с безопасного режима, проектной учётной записи и чтения логов; Brave Mode и прямое управление производственной линией пока не открывайте.

Эта статья для вас, если вы:

  • подключаете Claude Code, Codex или Cursor к TeamCity;
  • отвечаете за корпоративное управление AI Agent, аудит и минимальные права;
  • управляете Xcode-пулами, подписывающими узлами и удалёнными Mac.

Последнее обновление: 3 сентября 2026 года. Версия TeamCity и заявленные MCP-возможности сверены с официальными примечаниями к выпуску TeamCity 2026.2, документацией интеграции AI Agent, прав и токенов.

01

Решение по допуску: что разрешать в пилоте

Для TeamCity 2026.2 MCP корпоративная приёмка должна начинаться не с вопроса «подключается ли клиент», а с вопроса «какую операцию он может завершить». Официальная документация описывает MCP-интеграцию и инструменты для работы с Pipeline, включая чтение, создание, обновление и удаление. Это означает, что безопасный результат зависит от границ учётной записи и проекта, а не от одного факта успешной OAuth-авторизации. Подробнее состав возможностей указан в документации TeamCity по AI Agent Integration.

Возможность Пилот Промышленный допуск Обязательное доказательство
Просмотр статуса, лога и результата сборки Разрешить Разрешить при подтверждённой области проекта Реальный тест чтения разрешённого и запрещённого проекта
Запуск личной или тестовой сборки Разрешить с ограничением Разрешить через утверждённые Pipeline Журнал инициатора, параметров и результата
Создание или изменение Pipeline Только тестовый проект Только после отдельного согласования Разница конфигурации, запись одобрения и откат
Удаление Pipeline или проекта Запретить Запретить для общего Agent Отрицательный тест, журнал отказа и владелец исключения

Сейчас разумна поэтапная схема:

  1. безопасный режим и только чтение;
  2. контролируемый запуск в непроизводственном проекте;
  3. запись только в песочнице;
  4. отдельное решение для каждого производственного проекта;
  5. запрет удаления как постоянная базовая политика.

Brave Mode не должен становиться скрытым «режимом по умолчанию». Используйте его лишь в изолированном проекте, на короткое согласованное окно и с заранее проверенным способом отключения. Официальная документация по интеграции — основной источник для проверки границ безопасного режима и Brave Mode; демонстрация стороннего клиента не доказывает его производственную совместимость.

Важно: разрешение MCP, право TeamCity на проект и полномочия процесса Build Agent — разные уровни. Успешная команда на одном уровне не должна автоматически открывать следующий.

02

Платформенная команда: отдельная личность вместо администратора

Платформенная команда отвечает за то, чтобы внешний Agent не получил глобальные права «для удобства». В TeamCity нужно разделить как минимум четыре слоя:

  • MCP-клиент и его способ авторизации;
  • роль пользователя TeamCity;
  • разрешения на проект, конфигурацию и Pipeline;
  • локальный аккаунт, под которым работает Build Agent.

Роли TeamCity определяют доступ к операциям, а проектная модель может расширять видимость через наследование. Поэтому проверяйте не только назначенную роль, но и фактический список ресурсов. Документация TeamCity по ролям и разрешениям нужна здесь как карта доступных действий, а справочник REST-разрешений — как перечень конкретных проверок.

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

Проверьте для каждой интеграции:

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

Документация по управлению токенами доступа TeamCity подтверждает необходимость рассматривать токен как отдельный объект управления, а не как постоянную замену паролю. Не помещайте секрет в Pipeline, репозиторий или общий файл переменных. Для Agent используйте хранилище секретов, доступное только процессу, которому оно действительно нужно.

03

Команда безопасности: наследование и отрицательные тесты

Самая частая ошибка при приёмке — проверить разрешённое действие и не проверить запрещённое. Для каждого пилотного Agent создайте тестовый набор:

  • чтение разрешённого проекта;
  • чтение соседнего проекта;
  • просмотр конфигурации родительского проекта;
  • запуск сборки с недопустимым параметром;
  • изменение Pipeline;
  • удаление объекта;
  • обращение к секрету через косвенный сценарий.

Родительский проект особенно важен. Если разрешение наследуется сверху, Agent может увидеть дочерние конфигурации, которые команда считала изолированными. Сравнивайте экспорт ролей, страницу подтверждения OAuth, область токена и фактический результат запроса. В отчёте должны быть не только скриншоты успеха, но и доказательства отказа.

Отдельно проверьте сетевые ограничения. Корпоративный прокси, фильтрация исходящих соединений и правила браузерной авторизации могут изменить поведение OAuth PKCE. Если клиент подключается из рабочей станции разработчика, а TeamCity работает в закрытом сегменте, тестируйте полный маршрут: авторизация, вызов инструмента, ответ, повторный вызов и отзыв сессии.

Не делайте вывод «MCP безопасен» по результату одного клиента. Поведение Codex, Cursor и Claude Code нужно фиксировать в вашей сети, с вашей политикой прокси и вашей моделью TeamCity. Официальные документы описывают поддерживаемую интеграцию, но не обещают одинаковую работу любого внешнего клиента в вашей инфраструктуре.

04

Проектные владельцы: запись только через обратимый процесс

Владелец проекта отвечает за содержимое Pipeline и за возможность восстановить его после ошибочного действия. На этапе пилота запись должна быть ограничена песочницей. Для каждой операции изменения сохраните:

  • исходную версию конфигурации;
  • запрос Agent и инициатора;
  • разницу до и после;
  • одобрение ответственного;
  • команду отката;
  • результат повторной проверки.

Изменение Pipeline нельзя считать безопасным только потому, что оно прошло через TeamCity API. Риск возникает в параметрах, шагах сборки, источниках зависимостей и маршруте на Agent Pool. Даже без доступа к секрету неправильное изменение может направить сборку на неподходящий узел или включить публикацию артефакта.

Удаление следует оставить закрытым. Возможность удалить Pipeline официально заявлена среди инструментов TeamCity 2026.2, поэтому её нужно проверять отрицательным тестом, а не подразумевать. Если бизнесу всё же требуется автоматическое удаление временных конфигураций, оформите отдельную роль, короткое окно действия и независимое подтверждение. Общая учётная запись администратора для этого сценария не подходит.

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

05

Команда Mac: MCP управляет конвейером, но не доверенным ключом

AI Agent должен обращаться к TeamCity как к контрольной плоскости. Он не должен превращаться в прямой путь к производственному Mac, локальному macOS-аккаунту, Keychain или сертификату подписи.

Разделите Agent Pool по назначению:

  • диагностика и чтение логов;
  • сборка непроверенной ветки;
  • тестирование утверждённого кода;
  • производственная сборка и подпись.

TeamCity описывает Agent как отдельный узел, с которым сервер устанавливает связь по собственной модели подключения; базовые условия приведены в документации по коммуникации Build Agent. Распределение по пулам и ограничения назначения нужно проверять по настройкам Agent Pool.

Для iOS-сценария правило должно быть жёстким:

  • обычный Agent не видит хранилище ключей подписывающего узла;
  • тестовая ветка не получает маршрут на производственный пул;
  • публикация запускается только фиксированным Pipeline;
  • подпись происходит на отдельном доверенном узле;
  • MCP не получает SSH-доступ к этому узлу;
  • секреты не выводятся в лог и не передаются как параметры задачи.

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

06

Операционная команда: аудит должен отвечать на вопрос «кто и что сделал»

Аудит полезен только тогда, когда по нему можно восстановить цепочку действия. Для MCP-пилота фиксируйте:

  • пользователя или сервисную личность;
  • тип операции;
  • проект и Pipeline;
  • параметры запуска;
  • результат разрешения или отказа;
  • идентификатор сборки;
  • назначенный Agent Pool;
  • изменения конфигурации;
  • отзыв токена или завершение OAuth-сессии.

В TeamCity есть официальная функция отслеживания пользовательских действий; используйте документацию по User Actions для настройки нужных событий. Сопоставляйте её с журналами прокси, MCP-шлюза и самого Agent. Одного журнала сервера недостаточно, если невозможно связать запрос с конкретной сессией и узлом.

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

  1. отзовите токен во время ожидания сборки;
  2. завершите OAuth-сессию;
  3. отключите Brave Mode;
  4. отмените повторно инициируемую сборку;
  5. остановите тестовый Agent;
  6. восстановите конфигурацию из версии;
  7. подтвердите, что после восстановления маршрут и права не расширились.

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

07

Управленческое решение: три статуса вместо бинарного «включить или выключить»

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

Используйте три статуса:

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

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

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

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

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

08

План действий на ближайшую рабочую неделю

В первый день составьте реестр MCP-инструментов и разделите их на чтение, запуск, запись и удаление. Сразу отметьте, какие операции нужны конкретному Agent, а какие существуют только «на будущее».

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

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

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

В пятый день направьте тестовую Xcode-сборку на отдельный Agent Pool без производственных ключей. Проверьте маршрут задачи, локальную учётную запись, журналы, отмену сборки и поведение после перезапуска узла.

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

09

Частые вопросы руководителей

Может ли подключённый MCP изменить или удалить Pipeline

Да, в TeamCity 2026.2 официально заявлены инструменты чтения, создания, обновления и удаления Pipeline. Но это не означает автоматического разрешения для каждой учётной записи: действие определяется ролью и проектными правами. Без отрицательного теста удаления и проверки области токена нельзя считать подключение безопасным.

Как ограничить AI Agent одним проектом

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

Подходит ли Brave Mode для постоянного корпоративного использования

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

Как изолировать Mac с подписью от AI Agent

Разместите подписывающий узел в отдельном Agent Pool и разрешите ему принимать только фиксированный утверждённый Pipeline. MCP должен инициировать действие через TeamCity, но не получать SSH или локальный доступ к macOS. Проверьте, что тестовая ветка, диагностическая задача и непроверенный код не могут выбрать этот пул или прочитать Keychain.

10

Что делать с текущей схемой и удалённым Mac

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

Поэтому разумный следующий шаг — поднять один изолированный удалённый Mac как тестовый Agent Pool, прогнать настоящий Xcode-проект, проверить маршрутизацию и перезапуск, а затем отдельно принять решение о постоянном пуле или подписывающем узле. Такой подход не отменяет покупку собственного оборудования для длительной стабильной нагрузки и не подходит там, где нужны физические интерфейсы. Но для временного пилота, распределённой команды и контролируемой проверки MCP аренда у VpsMesh позволяет сначала подтвердить архитектуру, а уже затем увеличивать парк. Перед передачей корпоративных данных дополнительно изучите политику конфиденциальности VpsMesh.