TeamCity 2026.2 MCP kann in einen Unternehmenspilot aufgenommen werden, aber nicht mit standardmäßig aktiviertem Brave Mode und nicht mit einem allgemeinen Agenten an der produktiven Release-Pipeline. Ihre Empfehlung für diese Woche: Sicherheitsmodus, projektbezogene Identität und schreibgeschützte Diagnose zuerst freigeben; Schreibaktionen auf ein Testprojekt begrenzen und Xcode-Builds sowie Signierung auf getrennten, vertrauenswürdigen Mac-Knoten ausführen.

Dieser Beitrag ist für Sie relevant, wenn Sie externe AI Agents an TeamCity anbinden, Berechtigungen und Auditnachweise verantworten oder einen Mac-Buildpool für iOS betreiben. Wenn Sie lediglich lokale Builds ohne MCP planen, benötigen Sie diese Abnahme nicht.

Letzte Aktualisierung: 03.09.2026. Die Angaben wurden anhand der offiziellen TeamCity-2026.2-Veröffentlichungsnotizen, MCP-Dokumentation sowie der Dokumentation zu Rollen, Tokens, Agent Pools und Benutzeraktionen geprüft.

01

Die Freigabe beginnt mit einer abgestuften Berechtigungsmatrix

Die zentrale Frage bei der TeamCity 2026.2 MCP-Unternehmensprüfung lautet nicht, ob die Verbindung funktioniert. Entscheidend ist, welche Aktion ein Agent mit welcher Identität in welchem Projekt ausführen darf. TeamCity 2026.2 dokumentiert MCP-Werkzeuge zum Lesen, Erstellen, Aktualisieren und Löschen von Pipelines. Diese Fähigkeiten dürfen Sie daher nicht pauschal als „sicher“ oder „unsicher“ bewerten, sondern müssen sie einzeln testen. Maßgeblich sind die offiziellen Release Notes für TeamCity 2026.2 und die Dokumentation zur MCP-Integration.

Fähigkeit Pilotfreigabe Produktionsentscheidung Nachweis
Nur Logs und Buildstatus lesen Ja, im Sicherheitsmodus Für klar abgegrenzte Projekte möglich Zugriffstest auf erlaubtes und verbotenes Projekt, Auditlog
Persönlichen Build kontrolliert auslösen Ja, nur mit Test- oder nicht produktivem Branch Schrittweise möglich Build-ID, verwendete Identität, Branchregel und Abbruchtest
Pipeline-Konfiguration ändern Nur im Sandbox-Projekt Erst nach Review, Diff und Rückrolltest Konfigurationshistorie, Genehmigung, Wiederherstellung
Projekt oder Pipeline löschen Im Pilot grundsätzlich sperren Nicht für einen allgemeinen Agenten freigeben Negativtest, Tokenumfang, dokumentierter Notfallprozess

Diese Matrix trennt vier Risikostufen. Ein Agent, der Logs lesen darf, besitzt nicht automatisch die Berechtigung, eine Pipeline zu ändern. Umgekehrt ist ein erfolgreicher Build-Trigger kein Beleg dafür, dass Löschaktionen ausreichend geschützt sind.

TeamCitys Sicherheitsmodus ist deshalb die belastbare Ausgangsbasis für den Pilotbetrieb. Brave Mode gehört in ein isoliertes Projekt, einen begrenzten Zeitraum und eine kontrollierte Branchgruppe. Eine dauerhafte Aktivierung für die gesamte TeamCity-Instanz wäre erst vertretbar, wenn Sie die Auswirkungen auf Projektgrenzen, Änderungsnachweise und Abbruchwege nachgewiesen haben.

02

Die Plattformverantwortung liegt bei Identität, Projektumfang und Token

Für die Plattformleitung besteht die erste Aufgabe darin, die Identitätskette zu dokumentieren. Ein MCP-Client, ein TeamCity-Benutzer, ein Zugriffstoken, ein Projekt und ein Build Agent sind unterschiedliche Ebenen. Werden sie in einer einzigen Administratoridentität zusammengeführt, wird ein späterer Audit unnötig schwer.

Bei einer browser- oder benutzergebundenen Autorisierung ist OAuth PKCE der relevante Prüfpunkt. Sie sollten festhalten, welcher Client die Autorisierung startet, welche Weiterleitung zugelassen ist und welche Sitzung beendet werden muss. Für automatisierte Abläufe benötigen Sie dagegen eine dedizierte technische Identität mit einem begrenzten Zugriffstoken. Die TeamCity-Dokumentation zu Zugriffstokens beschreibt die Verwaltung dieser Tokens; die konkrete Wirksamkeit müssen Sie in Ihrer Umgebung durch reale Zugriffe bestätigen.

Prüfen Sie mindestens diese Punkte:

  • eigenes Benutzerkonto oder eigener technischer Benutzer für den Agent;
  • keine Wiederverwendung eines globalen Administratorkontos;
  • dokumentierter Tokenumfang und zuständige verantwortliche Person;
  • definierter Ablageort für Geheimnisse, getrennt von Pipeline-Quelltext;
  • Verfahren für Sperrung, Austausch und sofortigen Widerruf;
  • protokollierte OAuth-Sitzung und getestete Sitzungsbeendigung.

Die Rollenprüfung darf nicht am direkt ausgewählten Projekt enden. TeamCity-Projekte können Berechtigungen vom übergeordneten Projekt übernehmen. Dadurch kann ein Agent mehr Projekte sehen, als der Name seines Tokens vermuten lässt. Exportieren Sie deshalb die Rollen und vergleichen Sie sie mit einem tatsächlichen Zugriffstest. Die offizielle Übersicht zu Rollen und Berechtigungen sowie die REST-Berechtigungsreferenz liefern dafür die fachliche Grundlage.

Ein sauberer Test besteht aus drei Ergebnissen: Der Agent sieht das freigegebene Projekt, er erhält beim verbotenen Projekt eine Ablehnung, und beide Vorgänge erscheinen eindeutig im Audit. Fehlt eines dieser Ergebnisse, ist die Projektgrenze nicht bewiesen.

03

Die Projektroute trennt Lesen, Auslösen, Schreiben und Löschen

Die Projektverantwortlichen sollten nicht nur die MCP-Funktionsliste abzeichnen. Sie müssen die tatsächlichen Auswirkungen an einer ungefährlichen Pipeline prüfen. Dabei gehören vier Aktionen in getrennte Testfälle: Konfiguration lesen, Build auslösen, Pipeline verändern und Pipeline löschen.

Beginnen Sie mit einer Sandbox, die keine Produktionsgeheimnisse und keine Signaturzertifikate verwendet. Der Agent darf zunächst den Status und Logs lesen. Danach wird ein Build auf einem nicht produktiven Branch ausgelöst. Erst wenn diese beiden Vorgänge nachvollziehbar sind, folgt eine absichtlich kleine Konfigurationsänderung. Die Änderung muss vor und nach der Ausführung als Diff vorliegen. Ein Rückrollvorgang gehört zum Test, nicht zur späteren Notfallplanung.

Brave Mode verändert die Risikobewertung, weil ein Agent dadurch weitergehende Aktionen ausführen kann. Behandeln Sie ihn nicht als Komfortschalter. Legen Sie einen Projektbesitzer, ein Ende des Testfensters und eine Abschaltperson fest. Nach jedem Schreibtest prüfen Sie:

  • Wurde ausschließlich das erwartete Projekt verändert?
  • Ist die Änderung in der Versions- oder Konfigurationshistorie sichtbar?
  • Existiert eine Genehmigung außerhalb der Agentensitzung?
  • Kann die vorherige Konfiguration ohne manuellen Rätselaufwand wiederhergestellt werden?
  • Wurde ein Löschversuch blockiert und protokolliert?

Die Pipeline-Schreibrechte sollten zunächst nur für ein Testprojekt und nicht produktive Branches gelten. Für die Produktionsfreigabe benötigen Sie eine menschliche Genehmigung, einen prüfbaren Diff und eine definierte Rückfallaktion. „Der Agent konnte sich verbinden“ ist hierfür kein ausreichender Abnahmenachweis.

04

Die Mac-Plattform bleibt eine getrennte Vertrauenszone

Bei iOS-Builds ist MCP der Zugang zum TeamCity-Steuerungsmodell. Es sollte nicht zum direkten Login auf einen produktiven Mac, zum Lesen des macOS-Schlüsselbunds oder zum Ausführen beliebiger Shell-Befehle auf einem Signierknoten werden.

Trennen Sie mindestens drei Aufgabenklassen:

  1. Diagnose und Loganalyse;
  2. Builds mit nicht vertrauenswürdigem oder zu prüfendem Code;
  3. geprüfte Release-Builds mit Signierung.

Dafür eignen sich getrennte Agent Pools. TeamCity beschreibt die Zuordnung und Verwaltung solcher Pools in der Dokumentation zur Agent-Pool-Konfiguration. Die MCP-Identität darf einen Build höchstens über eine geprüfte TeamCity-Pipeline anstoßen. Der Agent benötigt keinen lokalen macOS-Account auf dem Signierknoten.

Auf dem produktiven Mac gelten zusätzliche Grenzen:

  • kein interaktiver Fernzugriff für den allgemeinen Agent;
  • kein aus der Pipeline lesbarer privater Signaturschlüssel;
  • feste Agent-Pool-Zuordnung für geprüfte Release-Aufgaben;
  • separate Konten für Wartung und Build-Ausführung;
  • keine gemeinsame Nutzung von Test- und Produktionsartefakten;
  • nachvollziehbarer Weg von Commit, Pipeline und Build-ID bis zum signierten Artefakt.

Die TeamCity-Dokumentation zur Agent-Kommunikation erklärt die Verbindung zwischen Server und Agent. Sie belegt jedoch nicht automatisch, dass Ihre Xcode- und Signaturumgebung sicher isoliert ist. Genau diese Grenze muss Ihre Plattformmannschaft mit einer echten, repräsentativen Pipeline prüfen.

Ein typischer Fehlversuch sieht so aus: Der Agent darf einen Build starten, der Build läuft auf dem nächstbesten freien Mac, und derselbe Knoten besitzt sowohl Testzertifikate als auch Produktionsschlüssel. Die TeamCity-Berechtigung kann dabei korrekt sein, während die macOS-Trennung versagt. Deshalb müssen Sie Steuerungsberechtigung, Build-Agent-Rechte und lokale macOS-Rechte getrennt abnehmen.

Für die Auswahl geeigneter Mietknoten können Sie die Mac-mini-Mietpreise von VpsMesh als Beschaffungsreferenz heranziehen. Preise und Verfügbarkeit ersetzen aber keinen Sicherheitsnachweis. Vor einer dauerhaften Zuordnung sollte ein isolierter Remote Mac mit Ihrer Xcode-Pipeline, Ihrem Agent Pool und Ihren Abbruchregeln getestet werden.

05

Audit und Notfallbetrieb müssen vor der Freigabe funktionieren

Die Auditverantwortung beginnt vor dem ersten Pilot-Build. Legen Sie fest, welche Ereignisse Sie später rekonstruieren müssen: OAuth-Anmeldung, Tokenverwendung, Projektzugriff, Build-Trigger, Konfigurationsänderung, Löschversuch, Agent-Zuordnung und Abbruch.

TeamCity stellt Funktionen zur Nachverfolgung von Benutzeraktionen bereit. Die Dokumentation zur Aktionsverfolgung ist die Referenz für die Prüfung. Testen Sie nicht nur den Erfolgsfall. Ein sicherer Agent muss auch bei Fehlbedienung kontrollierbar bleiben.

Führen Sie diese sechs Prüfschritte durch:

  1. Legen Sie eine dedizierte Agent-Identität und ein Testprojekt an.
  2. Exportieren Sie Rollen, Projektvererbung und Tokenumfang vor dem ersten Zugriff.
  3. Testen Sie Lesen, kontrolliertes Auslösen, Schreiben und Löschen als getrennte Aktionen.
  4. Ordnen Sie Diagnose, Test-Build und Signier-Build unterschiedlichen Agent Pools zu.
  5. Widerrufen Sie das Token, beenden Sie die OAuth-Sitzung und schalten Sie Brave Mode ab.
  6. Vergleichen Sie danach Auditlogs, Buildstatus, Konfigurationshistorie und Mac-Zustand.

Zusätzlich sollten Sie hohe REST-Aktivität, wiederholte Trigger, Konfigurationsfehler und Löschversuche beobachten. Der TeamCity-Hinweis zu Upgrades gehört in die Betriebsakte, weil ein MCP- oder Berechtigungsverhalten nach einem Update erneut geprüft werden muss. Bei einem neuen Sicherheitsupdate, einer 2026.2.x-Korrektur oder einer Änderung der MCP-Werkzeuge ist die Abnahme zu wiederholen.

Definieren Sie einen Degradationspfad. Fällt die MCP-Integration aus, muss das Team Builds weiterhin über den normalen, geprüften TeamCity-Prozess starten können. Fällt ein Mac-Knoten aus, darf der Ersatz nicht automatisch auf einen Signierknoten mit weiterem Berechtigungsumfang ausweichen. Ein manueller Freigabeschritt ist in diesem Fall besser als eine unkontrollierte Umleitung.

06

Die Managemententscheidung folgt aus Belegen, nicht aus Funktionsumfang

Die technische Leitung kann nach dem Pilot drei Entscheidungen treffen:

  • Freigabe: Nur Lesezugriff und kontrollierte Trigger sind belegt; Schreib- und Löschrechte bleiben eingeschränkt.
  • Bedingte Freigabe: Pipeline-Schreiben ist ausschließlich im Sandbox-Projekt möglich, mit Diff, Genehmigung und Rollback.
  • Zurückstellung: Projektvererbung, Tokenwiderruf, Auditierung oder Mac-Isolation liefern kein eindeutiges Ergebnis.

Die folgende Übersicht fasst die Wahl zwischen einem eigenen physischen Mac, einer kontrollierten Remote-Mac-Umgebung und einer gemischten Architektur zusammen. Sie ist keine Leistungszusage für einen bestimmten Knoten. Die konkrete Lieferbarkeit, Region und Xcode-Kompatibilität müssen Sie vorab mit Ihrem Projekt testen.

Entscheidungsdimension Eigener Mac im Büro Remote Mac für Pilot und Buildpool Gemischte Architektur
MCP-Steuerung TeamCity lokal oder selbst betrieben TeamCity steuert einen getrennten Remote-Agent Steuerung zentral, Aufgaben nach Risiko verteilt
Projektisolierung Von Netzwerk und lokalen Konten abhängig Über Agent Pools, Projekte und Konten prüfbar Produktionssignierung lokal oder dediziert, Tests remote
Beschaffung Hohe Anfangsinvestition und Geräteverwaltung Nach Bedarf anmietbar, Verfügbarkeit prüfen Dauerhafte Kernkapazität plus flexible Testkapazität
Signaturschutz Physischer Zugriff muss streng begrenzt werden Dedizierter Knoten und geprüfte Pipeline erforderlich Höchste Trennung für Signierung, Remote-Knoten für Diagnose
Ausfallstrategie Ersatzgerät und Vor-Ort-Wartung nötig Ersatzroute und Wiederanlauf vorher testen Kritische Signierung bleibt separat, Builds können ausweichen
Geeignet, wenn Hardware dauerhaft und physisch benötigt wird Temporäre Agent Pools oder kontrollierte Piloten entstehen Teams gleichzeitig Sicherheit und flexible Kapazität benötigen

Die aktuelle On-Premises- oder allgemeine Cloud-Lösung ist langfristig nicht automatisch die bessere Wahl. Eigene Macs binden Kapital, erfordern Ersatzhardware und erschweren verteilten Teams den einheitlichen Zugriff. Eine beliebige Cloud-Instanz bietet dagegen nicht zwingend Apple-Silicon-Kompatibilität, physische macOS-Nähe oder eine belastbare Trennung der Signaturumgebung. Bei einem MCP-Pilot kommen außerdem Token-, Netzwerk- und Auditierungsaufwand hinzu.

Wenn Sie zunächst nur einen isolierten Test-Agent Pool, einen echten Xcode-Build und einen kontrollierten Wiederanlauf benötigen, ist ein gemieteter Remote Mac von VpsMesh oft der überschaubarere nächste Schritt: keine Geräteverteilung an jedes Teammitglied, keine sofortige Anschaffung zusätzlicher Macs und eine klar abgrenzbare Testumgebung. Für dauerhaft schwere Builds, zwingenden physischen Zugriff oder regulatorisch vorgeschriebene Schlüsselverwaltung kann der Kauf eigener Hardware dennoch sinnvoller sein. Prüfen Sie zuerst die Remote-Mac-Optionen von VpsMesh, führen Sie die Abnahme mit einem isolierten Knoten durch und erweitern Sie erst danach zum langfristigen Buildpool oder dedizierten Signierknoten.

07

Häufige Fragen zur Unternehmensprüfung

Die folgenden Antworten decken die typischen Such- und Abnahmefragen zu TeamCity 2026.2 MCP, OAuth PKCE, Brave Mode und Remote Mac ab. Sie ersetzen keinen Zugriffstest mit Ihren Rollen und Projekten.

Kann TeamCity 2026.2 MCP Pipelines standardmäßig ändern oder löschen?

Die bloße MCP-Verbindung bedeutet keine automatische Freigabe für Änderungen oder Löschungen. Ob ein Agent diese Aktionen ausführen kann, hängt von den tatsächlich zugewiesenen TeamCity-Rechten, dem Projektumfang und dem verwendeten Token ab. Prüfen Sie jede Schreibaktion in einem getrennten Testprojekt. Für Produktionsprojekte sollte zunächst nur lesender Zugriff oder ein kontrollierter Build-Trigger erlaubt sein.

Wie beschränken Sie einen AI Agent auf ein bestimmtes TeamCity-Projekt?

Verwenden Sie eine eigene Identität mit projektbezogenen Rollen und einem eingeschränkten Token, statt die Rechte eines globalen Administrators zu übernehmen. Prüfen Sie zusätzlich die Vererbung vom übergeordneten Projekt. Der Test muss mit einem erlaubten und einem ausdrücklich verbotenen Projekt erfolgen. Erst wenn beide Zugriffe im Audit sichtbar korrekt ausfallen, ist die Begrenzung belastbar.

Ist Brave Mode für einen dauerhaften Unternehmenseinsatz geeignet?

Brave Mode sollte nicht als allgemeine Standardfreigabe für produktive Projekte behandelt werden. Nutzen Sie ihn höchstens in einem isolierten Projekt mit begrenztem Zeitfenster, kontrollierten Branches und vollständiger Protokollierung. Vor einer dauerhaften Aktivierung müssen Sie nachweisen, dass Schreibvorgänge, Fehlkonfigurationen und Abbrüche nachvollziehbar bleiben und sich die Funktion sofort deaktivieren lässt.

Wie wird ein Mac-Signierknoten bei einem vom Agent gestarteten iOS-Build isoliert?

Der MCP-Zugang sollte nur das TeamCity-Steuerungsmodell erreichen, nicht das lokale macOS-Konto oder den Schlüsselbund des Signierknotens. Trennen Sie Diagnose-, Test- und Signieraufgaben über unterschiedliche Agent Pools. Der produktive Knoten akzeptiert ausschließlich eine geprüfte, feste Pipeline. Testen Sie dabei Tokenfluss, Kontorechte, Zertifikate, Abbruch und Wiederanlauf in einer echten Xcode-Pipeline.