Für Azure DevOps
Wenn KI-Agents Code schneller schreiben, als ein Team ihn prüfen kann, braucht es Prüfung, die mitwächst. Polier soll daraus geprüfte Pull Requests machen – in einer eigenen Instanz für Sie, in Deutschland.
Registrierung noch nicht geöffnet
#4799 Reject expired session tokens
Acceptance criteria
✓ expired token → 401 · ✓ test covers expiry · ✓ no API change
tag: polierBoardsclaimed
1. src/Auth/SessionService.cs · guard expiry
2. tests/Auth/SessionServiceTests.cs · add case
3. docs/auth.md · note
auth change → waiting for /approve
worktree agent/4799-session-ttl
$ egress
blocked by default
@ -42,2 +42,3 @ public Session? Create(Token token)− return Issue(token.UserId);+ if (token.ExpiresAt <= clock.UtcNow) return null;+ return Issue(token.UserId);
$ dotnet test
Passed SessionServiceTests.ExpiredTokenIsRejected
Passed SessionServiceTests.ValidTokenIssuesSession
214 passed · 0 failed · exit 0
reviewer-agent non-blocking
Reject expired tokens before issuing a session.
@ -42,2 +42,3 @ public Session? Create(Token token)− return Issue(token.UserId);+ if (token.ExpiresAt <= clock.UtcNow) return null;+ return Issue(token.UserId);
Draft PR !812 → main
Build · 214 tests passed
reviewer-agent · required ✓
Branch policy · 1 human approval
Polier wird gebaut, um aus Work Items in Azure Boards getestete, geprüfte Pull Requests in Azure Repos zu machen. Vorgesehen: Sie registrieren sich selbst, und für Ihr Unternehmen entsteht automatisch eine eigene Instanz in unserem Azure in Deutschland. Modelle und Tokens sind im Abo enthalten, und Ihre eigenen Branch Policies gelten.
In Entwicklung, noch nicht erhältlich
0Merge- und Deploy-Rechte für Agent-Identitäten (Vorgabe)
3 · 2 · 2Runden bis zur Übergabe an einen Menschen: Tests, Review, Pipeline (Standardwerte)
Vorgesehen: je Kunde eine eigene Instanz in unserem Azure in Deutschland · Azure DevOps Services. „In Entwicklung“ heißt: Code ist vorhanden und gegen Test-Doubles geprüft, aber noch nicht gegen eine echte Azure-DevOps-Organisation.
Ein Agent sollte niemals selbst mergen.
Ein Agent braucht Zugriff auf Code und Work Items. Für Teams auf Azure DevOps mit strengen Vorgaben kann das Gespräch dort enden: bei der Sicherheitsabteilung, beim Datenschutz oder beim Betriebsrat.
Ein Agent arbeitet mit Code-Kopien und Transkripten. Das heißt Vertragsprüfung und die Frage, wo die Daten liegen und mit wem sie sich eine Umgebung teilen. Unsere Antwort soll einfach sein: eine eigene Instanz je Kunde, in Deutschland.
Microsofts KI-Dienste für Azure DevOps, etwa Copilot Code Review, gab es nach unserem Stand vom 24.10.2026 nur für Azure DevOps Services. Azure DevOps Server unterstützt Polier noch nicht; es ist geplant.
Ein Agent, der selbst pusht und merged, ist schwer zu begründen. Sie brauchen harte Grenzen, nicht nur gute Prompts.
Jeder Schritt hinterlässt Spuren in Azure DevOps. Der Agent selbst merged nie; wo ein Mensch entscheidet, legen Sie fest.
In Entwicklung: So wird Polier gebaut. Stand 01.11.2026: Nichts davon läuft bei einem Kunden.
Beschreiben Sie ein Vorhaben in Ihren Worten, als Text oder per Sprache (die Diktatfunktion der Konsole nutzt die Spracherkennung Ihres Browsers). Der Planer stellt höchstens eine Runde Rückfragen und macht daraus Epics, Features und Work Items mit Fertig-Kriterium, Abhängigkeiten, Reihenfolge, Größe und Risikoklasse; Sie geben den Plan als Ganzes frei. Für einen Bug oder eine Einzelaufgabe taggen Sie stattdessen ein Work Item in Azure Boards mit „polier“. Aufgaben startet nur, wer auf dem Ziel-Repository Schreibrecht hat und für das Projekt freigeschaltet ist.
Polier liest den Code und schreibt einen Plan als Kommentar ins Work Item. Bei riskanten Änderungen – etwa an Infrastruktur, Pipelines, Authentifizierung oder Agent-Regeldateien – wartet Polier auf ein „/approve“ einer dafür konfigurierten Person. Ab Risikostufe 2 darf das nicht die Person sein, die die Aufgabe gestellt hat; die Freigabe gilt nur für genau diesen Plan.
Ein Coding-Agent arbeitet in einem eigenen Git-Worktree, in einer Sandbox pro Aufgabe. Der Netzwerkverkehr ist gesperrt bis auf den Weg zum Modell-Proxy. Die Sandbox ist die Grenze, nicht die Werkzeugliste. Im Eigenbetrieb ist das eine Linux-Sandbox (bubblewrap); für Kunden sind Azure Container Apps Sandboxes je Aufgabe geplant. Bis es sie gibt, führt eine Instanz keinen Code von Kunden aus.
Build und Tests laufen vor jedem Push. Es zählt der Exit-Code, nicht die Selbsteinschätzung des Agents. Rote Ergebnisse gehen zurück an den Agent, höchstens dreimal.
Ein separater Reviewer (eine eigene, nur lesende Sitzung) prüft den Diff und setzt den Status „polier/review“ am Pull Request. Als Pflicht-Status in Ihren Branch Policies setzt Azure DevOps ihn bei neuen Änderungen zurück. Der Status kann einen Merge blockieren, nie allein freigeben.
Der Dispatcher öffnet einen Draft-PR auf einem agent/*-Branch, verknüpft mit dem Work Item. Gepusht wird genau der Stand, den der Reviewer geprüft hat. Ihre Pipelines und Branch Policies entscheiden. Im Standard merged ein Mensch; weitergehende Automatisierung (Auto-Merge, Staging, Produktion) sollen Sie je Repository und Umgebung einstellen können – das ist geplant und noch nicht gebaut.
Nach festen Rundengrenzen übergibt Polier mit einer Zusammenfassung an einen Menschen, statt endlos weiterzuprobieren.
Stand 01.11.2026: Der Ablauf ist gebaut und gegen Test-Doubles geprüft. Ein echter Lauf gegen Azure DevOps und ein echtes Modell hat noch nicht stattgefunden; deshalb stehen hier keine Zahlen.
Kontext
Der Planer liest vor jedem Plan das Repository und das Board, nicht nur den Diff – und nur das, was Sie ihm freigeben.
In Entwicklung: So wird Polier gebaut. Stand 01.11.2026: Nichts davon läuft bei einem Kunden.
Regeldateien wie AGENTS.md und die README vom geschützten Stand Ihres Zielbranches – von Menschen gemergt, nie vom Agent-Branch – gehen als gekennzeichnete, nicht vertrauenswürdige Eingabe in die Aufgabe.
Titel, Beschreibung, Akzeptanzkriterien und bis zu 50 letzte Kommentare, frisch per REST gelesen. Der Hook-Payload allein zählt nicht als Beleg.
Offene Work Items mit dem Tag „polier“, damit ein neuer Plan nicht doppelt plant, was schon im Board steht.
Ihr Text, Ihre Antworten auf die Rückfragen und, wenn Sie das wollen, eine Produktplan-Datei. Nach jedem gemergten Pull Request kann der Plan neu bewertet werden.
Geplant: Fremder Text – Work-Item-Texte, PR-Kommentare, Regeldateien aus Kunden-Repositories – läuft vorher durch Azure AI Content Safety (Prompt Shields).
Was Läufe gezeigt haben, schlägt Polier als Entwurfs-Pull-Request gegen die Regeldatei Ihres Repositorys vor, mit Belegen, von festem Code geschrieben. Ein Mensch prüft und merged; selbstlernend ohne Review ist es nicht.
Instanz
Geplant: Bei der Registrierung entsteht automatisch eine Instanz nur für Sie, ohne dass jemand dazwischensteht. Ihr Code läuft dann bei uns, deshalb sind wir Auftragsverarbeiter. Heute läuft noch keine Instanz.
In Entwicklung: So wird Polier gebaut. Stand 01.11.2026: Nichts davon läuft bei einem Kunden.
Illustration mit Beispieldaten, kein Ergebnis eines echten Laufs.
Eigene Datenbank, eigener Speicher, eigener Key Vault, eigener Service Bus und eine eigene Container-Apps-Umgebung in der Azure-Region Germany West Central.
Microsoft-Geschäftskonto, Firma, Instanzadresse: Mehr soll es nicht brauchen. Die Instanz entsteht automatisch, mit einer Testphase und einem kleinen KI-Kontingent.
Eine geführte Seite in der Instanz: Eine Microsoft-Entra-Administration stimmt einmal zu, ein Project Collection Administrator von Azure DevOps meldet sich einmal an, alles andere läuft automatisch. Service Principals, keine persönlichen Zugriffstokens. Vorerst nur Azure DevOps Services.
Alle Kunden arbeiten auf unseren Modellen von Azure. Tokens sind als Kontingent je Paket enthalten, und Sie können es erhöhen. Niemand bringt einen Schlüssel oder ein Modell mit.
Ihr Code läuft nur in einer Sandbox je Aufgabe (Azure Container Apps Sandboxes, geplant), nie auf einem Entwicklungsserver. Solange es diese Sandbox nicht gibt, führt eine Instanz keinen Code von Kunden aus.
Branch Policies, Pipelines und Freigaben bleiben die von Azure DevOps. Polier bekommt keine Rechte, sie zu umgehen.
Leitplanken
Was ein Agent nicht darf, verhindern Rechte, Richtlinien und Netzwerk – nicht ein Satz im Prompt.
In Entwicklung: So wird Polier gebaut. Stand 01.11.2026: Nichts davon läuft bei einem Kunden.
Illustration mit Beispieldaten, kein Ergebnis eines echten Laufs.
Agent-Identitäten bekommen kein Schreibrecht auf Ihre Hauptzweige und kein „Bypass policies“; die Aktionsregeln lehnen Pushes und Merges aus einem Lauf ab. Im Standard merged ein Mensch. Mehr Automatisierung stellen Sie später je Repository ein (geplant).
Der Agent-Prozess hält keine Zugangsdaten: Pushes erledigt der Dispatcher aus einem frischen Klon außerhalb der Sandbox (nur der geprüfte Stand, nur auf agent/*), Pakete holt die Vorstufe vor dem Start, und den Authorization-Header für Modellaufrufe setzt ein Proxy außerhalb der Sandbox.
Lesen und lokale Änderungen laufen automatisch. Netzwerk, Kosten, Löschen und Produktion brauchen eine Freigabe, ebenso Schreibzugriffe auf geschützte Pfade wie Pipelines, infra/ und Agent-Regeldateien. Dateien im Repository können Regeln nur verschärfen.
Hinweise bei 50, 75 und 90 Prozent. Bei 100 Prozent startet nichts Neues; offene Aufgaben werden geparkt und laufen später weiter. Die Grenzen legen Sie fest.
Ein Schalter hält den Dispatcher an: laufende Sitzungen werden unterbrochen, neue Aufgaben nicht mehr angenommen, bis ein Mensch fortsetzt. Der Schalter ist gebaut; ausgelöst wird er in der Konsole oder über einen Pause-Endpunkt, etwa durch einen Kostenalarm in Azure. Der Befehl vom Handy folgt.
Jeder Stopp der Leitplanken und jede Freigabe wird in einer nur anhängenden Spur festgehalten. Geplant: pro Lauf ein unveränderbarer Audit-Datensatz im Speicher Ihrer Instanz (Auslöser, Identitäten, Modell und Datenpfad, Tests, Review, Freigaben, Kosten), Transkripte getrennt und nach einer Frist gelöscht. Die Unveränderlichkeit des Speichers ist noch nicht eingerichtet.
Mehr als Pull Requests
Reviewer, Watchdog und Nachtschicht sind gebaut und gegen Test-Doubles geprüft – noch nicht gegen echte Alarme, ein echtes Modell und eine echte Organisation. Stand 01.11.2026.
Illustration mit Beispieldaten, kein Ergebnis eines echten Laufs.
Ein Pflicht-Status statt bloßer Kommentare, eine Antwort auf Rückfragen („@polier“ im Pull Request) und Prüfung nur mit Leserechten. Heute Teil jedes Laufs; als eigener, leicht einzuführender Einstieg für Pull Requests Ihres Teams geplant.
Ein Azure-Monitor-Alarm oder ein roter Lauf auf einer Hauptlinie startet einen Ermittler mit reinen Leserechten. Sie erhalten eine Diagnose aufs Handy; repariert wird erst, wenn eine dafür berechtigte Person „Builder soll fixen“ klickt.
Routinen laufen nachts nach Playbooks, die Sie festlegen – alle sind zunächst ausgeschaltet –, innerhalb eines Nachtbudgets: etwa Paket-Updates als normale Aufgaben mit Review und Pull Request. Um 7:00 Uhr (Berlin) liegt ein Bericht bereit, ohne Modellaufruf aus den Büchern erstellt.
Azure DevOps Server ist geplant, nicht vor 2027; vorerst unterstützen wir nur Azure DevOps Services.
Für Betriebsrat und Datenschutz, ein Produktgrundsatz von Polier: keine Produktivitätskennzahlen einzelner Personen, keine Ranglisten, keine Stimmungsauswertung.
Polier ist in Entwicklung und noch nirgends im Einsatz. Wir wollen es zuerst in unseren eigenen Produkten einsetzen und hier datierte Zahlen mit Methode veröffentlichen: Agent-PRs, den Anteil, der ohne manuelle Codeänderung gemergt wurde, und die Kosten pro Aufgabe – dazu ein ungeschnittenes Video eines Laufs, auch eines gescheiterten.
Noch keine veröffentlichten Zahlen. Stand: 01.11.2026
Noch keine Kunden, deshalb keine Logos. Ein Logo steht hier erst, wenn ein Kunde es erlaubt. Mehr zur Methode
Nein. Polier soll klar beschriebene Aufgaben übernehmen und Pull Requests liefern. Die Freigabe des Plans, die Review-Entscheidung und der Merge bleiben bei Ihrem Team.
Alle Kunden arbeiten auf unseren Modellen von Azure: Modelle, die Azure selbst verkauft (Azure OpenAI und von Azure gehostete Modelle anderer Anbieter). Welches Modell der Standard wird, messen wir gerade; entschieden ist das nicht. Tokens sind als Kontingent je Paket im Abo enthalten, und Sie können es erhöhen. Einen Schlüssel oder ein Modell bringt niemand mit. Nur im Enterprise-Paket soll sich später ein eigener Zugang freischalten lassen, gegen eine höhere Plattformgebühr; gebaut ist das nicht.
Geplant: Sie registrieren sich mit Ihrem Microsoft-Geschäftskonto, nennen Firma und Instanzadresse, und die Instanz entsteht automatisch. Danach führt eine Seite in der Instanz durch die Anbindung an Azure DevOps: Eine Microsoft-Entra-Administration stimmt einmal zu, ein Project Collection Administrator meldet sich einmal an, alles andere läuft automatisch. Persönliche Zugriffstokens brauchen Sie dafür nicht.
Nein. Polier arbeitet mit Azure Boards, Azure Repos und Azure Pipelines.
Nach festen Grenzen – standardmäßig drei Testrunden, zwei Review-Runden, zwei Pipeline-Runden – übergibt Polier mit einer Zusammenfassung an einen Menschen. Bei einem Rate-Limit oder erreichtem Budget wird die Aufgabe geparkt und läuft später an derselben Stelle weiter.
Für Polier selbst nicht: Die Instanz läuft in unserem Azure, und es spielt keine Rolle, wie Sie Azure sonst beziehen. Sie brauchen eine Azure-DevOps-Organisation, die mit Microsoft Entra ID verbunden ist. Jede Agent-Identität belegt dort eine Basic-Zugriffsstufe; die ersten fünf Basic-Plätze sind nach Microsoft kostenlos, darüber rechnet Microsoft direkt mit Ihnen ab.
Es gibt noch keine Preisliste. Auf der Seite Preise stehen vorläufige Beträge je Paket. Tokens sind als Kontingent enthalten; dessen Höhe ist noch offen.
Nein. Polier ist in Entwicklung, bisher nur gegen Test-Doubles geprüft und noch nirgends bereitgestellt. Deshalb gibt es hier weder Kundenlogos noch Zahlen.
Vorgesehen ist eine eigene Instanz für Sie in der Azure-Region Germany West Central, mit eigener Datenbank und eigenem Speicher. Modellaufrufe laufen auf Azure, die genaue Region je Modell kommt mit dem Katalog. Die Daten bleiben dabei bei Microsoft, die Anbieter der Modelle sehen sie nicht. Weil Ihr Code bei uns läuft, sind wir Auftragsverarbeiter; den Vertrag dazu schließen Sie bei der Registrierung ab.