Sicherheit & Daten
Was Polier tun soll, was es heute schon im Code gibt und was nicht. Wir schreiben nur auf, was wir vertreten können, und datieren es.
Stand 01.11.2026. Nichts davon ist bei einem Kunden im Einsatz.
Was heute gilt – und was nicht
- Polier ist in Entwicklung und nirgends bereitgestellt. Es hat noch keinen echten Lauf gegen Azure DevOps und ein echtes Modell gegeben.
- Die Bausteine sind gebaut und gegen Test-Doubles geprüft. Ob sie unter echten Bedingungen halten, zeigen erst die ersten Läufe.
- Wir haben keine Zertifizierung (etwa ISO 27001 oder SOC 2) und keinen externen Penetrationstest.
- Das Bedrohungsmodell und die Red-Team-Fälle sind geplant, aber noch nicht veröffentlicht.
- Die Datenschutz- und Vertragsunterlagen für Kunden, auch der Auftragsverarbeitungsvertrag, sind Entwürfe und noch nicht anwaltlich geprüft.
- Registrierung, automatische Instanzen und die Sandboxes je Aufgabe sind noch nicht in Betrieb. Solange die Sandbox nicht gebaut ist, führt eine Instanz keinen Code von Kunden aus.
Wo Polier laufen soll
Vorgesehen ist je Kunde eine eigene Instanz in unserem Azure, in Deutschland (Azure-Region Germany West Central): eigene Datenbank, eigener Speicher, eigener Key Vault, eigener Service Bus und eine eigene Container-Apps-Umgebung. Eine gemeinsame Datenbank für alle Kunden gibt es nicht. Die Instanz entsteht automatisch bei der Registrierung.
Ihr Code läuft damit bei uns, nicht bei Ihnen. Er läuft nur in einer Sandbox je Aufgabe (Azure Container Apps Sandboxes, geplant) und nie auf unserem Entwicklungsserver. Bis dieser Weg gebaut ist, führt eine Instanz keinen Code von Kunden aus. Unser Eigenbetrieb läuft getrennt davon.
Was Ihre Instanz verlassen soll
- Modellaufrufe an die Modelle von Azure (Datenpfad siehe unten) und, geplant, Prompt-Shields-Prüfungen an Azure AI Content Safety.
- Paket-Restores nur in der Vorstufe, bevor der Agent startet, und nur lesend von erlaubten Feeds.
- Lese- und Schreibzugriffe auf Ihre Azure-DevOps-Organisation: Work Items, Repositories und Pull Requests, mit den Service Principals der Agents.
- Container-Images kommen aus unserer Registry, signiert und per Digest gepinnt (geplant).
Modellzugang und Datenpfad
Stand 01.11.2026 nach Microsofts Dokumentation; bitte prüfen Sie die Angaben vor einer Entscheidung selbst nach.
| Weg | Datenpfad | Abrechnung |
|---|---|---|
| Modelle, die Azure selbst verkauft (Azure OpenAI und von Azure gehostete Modelle anderer Anbieter), für alle Kunden | Die Daten bleiben bei Microsoft: Microsoft betreibt die Modelle in Azure, die Anbieter der Modelle sehen Prompts und Antworten nicht. Gespeicherte Daten Ihrer Instanz sollen in Deutschland liegen; die Modellaufrufe laufen auf Azure, die genaue Region je Modell kommt mit dem Katalog. | Im Abo enthalten, als Kontingent je Paket; Sie können es erhöhen. |
| Eigener Zugang im Enterprise-Paket (geplant, noch nicht gebaut) | Wird festgelegt, wenn dieser Weg gebaut wird. | Höhere Plattformgebühr; nur im Enterprise-Paket. |
- Eine Verarbeitung der Modellaufrufe in Deutschland oder der EU versprechen wir nicht: Je nach Bereitstellungsart kann Azure Prompts und Antworten auch außerhalb einer Geografie verarbeiten.
- Welches Modell der Standard wird, ist nicht entschieden. Wir messen die Modelle mit denselben Fällen und legen ihn danach fest.
- Microsoft überwacht die Dienste auf Missbrauch: Stichproben von Prompts und Antworten können automatisch und, wenn nötig, von befugten Microsoft-Beschäftigten geprüft werden. Modelle in der Vorschau können abweichenden Regeln folgen.
Quelle: Microsofts Seite „Data, privacy, and security for Models sold by Azure“, gelesen am 01.11.2026: learn.microsoft.com
Identitäten und Rechte
Jede Rolle hat ihre eigene Identität: Service Principals in Ihrer Organisation, keine persönlichen Zugriffstokens. Eine Identität mit Deploy-Rechten gibt es nicht. Jede Identität belegt eine Basic-Zugriffsstufe in Azure DevOps; die ersten fünf Basic-Plätze sind nach Microsoft kostenlos, darüber rechnet Microsoft direkt mit Ihnen ab.
| Identität | Darf | Darf nicht |
|---|---|---|
| Eingang | Work Items lesen und schreiben, kommentieren, Leases halten. | Code schreiben. |
| Build | Auf „agent/*“ pushen und Pull Requests anlegen – nur durch den Dispatcher. | Auf Hauptlinien schreiben, Policies umgehen, Pull Requests abschließen. |
| Review | Code lesen, „Contribute to pull requests“, den Pflicht-Status setzen. | Einen Merge allein freigeben. |
| Ermittlung (in Entwicklung) | Lesen in freigegebenen Projekten und Ressourcengruppen. | Schreiben. |
| Deploy | Keine Agent-Identität. Deploys bleiben in Ihren Pipelines mit Ihren Environment-Freigaben. | – |
Leitplanken
„Gebaut“ heißt: Code und Tests sind auf unserer Hauptlinie, gegen Test-Doubles geprüft, aber noch nicht in einem echten Lauf. „Geplant“ heißt: nicht gebaut.
- gebaut
Rechte der Agent-Identitäten
Kein Merge, kein Deploy, keine Pushes außerhalb von „agent/*“. Die Branch-Rechte setzen Sie in Azure DevOps; die Aktionsregeln lehnen Pushes und Merges aus einem Lauf zusätzlich ab.
- gebaut
Aktionsklassen
Lesen, lokal Schreiben, Netzwerk, Kosten, Löschen, Produktion. Automatisch laufen nur Lesen und lokale Änderungen; Netzwerk, Kosten, Löschen und Produktion brauchen eine Freigabe. Repository-Dateien können nur verschärfen.
- gebaut
Sandbox
Jeder Prozess in einem Worktree läuft in einer Sandbox mit beschreibbarem Worktree, schreibgeschütztem Klon und Paket-Cache, leerem Home und Netzwerk nur zum Modell-Proxy. Build und Tests führen beliebigen Code aus; deshalb ist die Sandbox die Grenze, nicht die Werkzeugliste. Heute ist das die Linux-Sandbox unseres Eigenbetriebs; für Kunden sind Azure Container Apps Sandboxes geplant.
- gebaut
Keine Zugangsdaten im Agent
Ein Token-Proxy außerhalb der Sandbox setzt den Authorization-Header für Modellaufrufe; ein Token-Broker gibt die Azure-DevOps-Tokens nur an den Linux-Benutzer, dem die Rolle gehört.
- gebaut
Push-Gate
Gepusht wird nur der Stand, den der Reviewer geprüft hat (Tree-Hash), nach grünem Build und grünen Tests, auf einen Agent-Branch, ohne geschützte Pfade und ohne Änderungen mit Risikostufe 2, die der Plan nicht freigegeben hat.
- gebaut
Budget und Not-Aus
Grenzen je Lauf, Nacht und Monat mit Hinweisen bei 50, 75 und 90 Prozent und hartem Stopp. Ein Schalter hält den Dispatcher an; ausgelöst wird er in der Konsole oder über einen Pause-Endpunkt. Der Befehl vom Handy folgt.
- geplant
Prompt Shields
Fremder Text (Work-Item-Texte, PR-Kommentare, Regeldateien aus Kunden-Repositories) soll vor dem Modell durch Azure AI Content Safety laufen.
- geplant
Unveränderbares Audit, signierte Images
Pro Lauf ein unveränderbarer Audit-Datensatz im Speicher Ihrer Instanz, signierte Container-Images mit gepinnten Digests, eine SBOM. Heute gibt es eine nur anhängende Spur für Stopps und Freigaben; die Unveränderlichkeit des Speichers ist noch nicht eingerichtet.
KI-Kennzeichnung
Jeder Kommentar von Polier trägt den Hinweis „Polier (KI-Agent), im Auftrag von <Auftraggeber>“. Commits tragen den Trailer „Agent: Polier“ und Pull Requests das Label „ai-generated“. Polier misst keine Produktivität einzelner Personen und erstellt keine Ranglisten.
Datenschutz: Wir sind Auftragsverarbeiter
Ihr Code soll bei uns laufen. Deshalb sind wir für die Inhalte Ihrer Instanz Auftragsverarbeiter, und Sie sind Verantwortliche. Den Auftragsverarbeitungsvertrag (AVV) schließen Sie bei der Registrierung ab. Microsoft ist als Unterauftragsverarbeiter vorgesehen. Die Rechtstexte sind Entwürfe und noch nicht anwaltlich geprüft. Für Kontaktdaten aus E-Mails an uns sind wir Verantwortliche; siehe Datenschutzerklärung.
Sicherheitsmeldungen
Wenn Ihnen etwas auffällt, schreiben Sie uns bitte. Eine eigene Sicherheitsadresse gibt es noch nicht: info@ballmüllersolutions.de