Die AgentinNICOLENDERS.COM
DEEN
← Depeschen

EinordnungDIE AGENTENFÜHRERINDIE TECHNIKERIN

Agents Build It. You Ship It.

Veröffentlicht

Verriegeltes FörderbandKI-generiert
Govern MCP tools by using an AI gatewayMicrosoft Learn

Am 1. September hat GitHub eine Einstellung veröffentlicht, mit der Copilot code review einen pull request approven darf. Die Approval zählt gegen die Regel für erforderliche Reviews. Ich habe den Changelog zweimal gelesen, weil damit etwas passiert, worüber vor einem Jahr noch niemand ernsthaft geredet hat: Ein Agent schreibt den Code, ein Agent prüft ihn, ein Agent gibt ihn frei. Und wenn das, was ausgeliefert wird, selbst ein Agent ist, sitzt im ganzen Loop kein Mensch mehr an einer Stelle, an der er zwingend vorbeimuss.

In diesem Artikel gehe ich einen solchen Loop einmal komplett durch: Ein GitHub Issue wird vom Copilot cloud agent aufgegriffen, von agentischer code review geprüft und nur gemergt, wenn es Gates besteht, die ein Mensch aufgeschrieben hat. Ausgeliefert wird ein Foundry Agent, und die Evaluationen laufen nach dem Go-live weiter. Die These passt in einen Satz: Instructions sind eine Bitte, ein Gate ist eine Entscheidung.

Der Loop ist schneller und robuster geworden

Der Copilot coding agent ist seit September 2025 GA und heißt seit April 2026 Copilot cloud agent, weil er nicht mehr an pull requests gebunden ist. Du weist ihm ein Issue zu, er arbeitet in einer GitHub-Actions-Umgebung, die du über .github/workflows/copilot-setup-steps.yml vorbereitest, und öffnet einen pull request. Ein einzelner Lauf ist hart auf 59 Minuten begrenzt. Für ein gut geschnittenes Issue reicht das, für ein schlecht geschnittenes nicht, und das ist eine nützliche Disziplin.

An den Leitplanken hat GitHub sichtbar gearbeitet. Der Agent pusht nur auf eigene copilot/-Branches. Er kann seinen pull request weder approven noch mergen, und wer ihn beauftragt hat, darf den pull request nicht selbst freigeben. Workflows auf seinen Branches laufen erst, wenn jemand mit Schreibrechten sie ausdrücklich startet. CodeQL, secret scanning und der Abgleich mit der Advisory Database laufen automatisch mit, seit Juni 2026 auch für Claude und Codex, die über Agent HQ als Public Preview im selben Ablauf arbeiten.

Copilot code review läuft seit März 2026 auf einer agentischen Architektur mit tool calling und ist dafür GA. Über ein Ruleset lässt sich die Review automatisch anfordern. Das kostet: Seit Juni 2026 rechnet GitHub in AI Credits ab, und die Review verbraucht zusätzlich Actions-Minuten. Plan es ein, statt es auf der Rechnung zu entdecken.

Instructions sind eine Bitte

.github/copilot-instructions.md, .github/instructions/*.instructions.md, AGENTS.md: Alle drei lesen sowohl der cloud agent als auch code review. Sie sind sinnvoll, und sie sind keine Kontrolle. GitHub schreibt selbst, dass Copilot den Anweisungen wegen der nicht-deterministischen Natur von KI nicht jedes Mal gleich folgt.

Anthropic formuliert es für Claude Code noch deutlicher. CLAUDE.md wird als Kontext behandelt, ausdrücklich nicht als erzwungene Konfiguration. Wer eine Aktion sicher verhindern will, soll einen Hook verwenden.

Zwei Hersteller, dieselbe Aussage. Daraus folgt die wichtigste Designentscheidung für dein Repository: Alles, was zwingend gelten muss, steht nicht in einer Markdown-Datei für das Modell, sondern in einem Mechanismus, den die Plattform durchsetzt.

Ein Gate ist eine Entscheidung

Ein Repository für agentische Entwicklung sollte deshalb strikt zwischen den beiden Kategorien trennen.

Die letzte Zeile verdient einen genauen Blick. Die Firewall des cloud agents gilt laut Dokumentation nur für Prozesse, die der Agent über sein Bash-Tool startet. MCP-Server und Setup-Schritte fallen nicht darunter, und GitHub nennt sie selbst keine umfassende Sicherheitslösung.

Die Approval durch code review ist seit dem 1. September Public Preview und standardmäßig aus. Meine Empfehlung: Lass sie für den Anwendungscode an, wenn dein Team das will, aber schließ jeden Pfad aus, der ein Gate definiert. .github/, die Rulesets als Code und die Eval-Schwellen gehören unter CODEOWNERS mit menschlicher Review. Sonst kann ein Agent die Regel lockern, an der der nächste Agent gemessen wird.

Was ausgeliefert wird, ist ein Agent

Auf der anderen Seite des Merges steht Microsoft Foundry. Der neue Foundry Agent Service ist seit März 2026 GA, baut auf der Responses API auf und versioniert Agents. Für einen SDLC ist das der entscheidende Punkt: Ein Deployment ist eine Version, ein Rollback ist die vorherige. Hosted Agents sind seit Juli 2026 GA. Die visuellen Workflows dagegen stellt Microsoft am 1. Dezember 2026 ein und verweist auf das Microsoft Agent Framework, das seit April 2026 als 1.0 vorliegt.

Für die Modellwahl nutze ich den Model router. Er ist GA und entscheidet pro Request zwischen den Modellen eines Pools, in den Modi Balanced, Quality oder Cost. Der Trade-off: Dein Agent läuft nicht mehr auf einem Modell, sondern auf einer Verteilung. Das Context Window richtet sich nach dem kleinsten Modell im Pool. Und eine Evaluation, die nur einen Modus misst, sagt über die anderen nichts.

Guardrails and controls kennen vier Intervention Points: user input, tool call, tool response und output. Für reine Modelle sind die beiden äußeren GA. Auf Agent-Ebene ist das Ganze Preview, und die Dokumentation enthält einen Satz, den du kennen solltest: Risiken, die Agents noch nicht unterstützen, greifen nicht, auch wenn du sie konfiguriert hast. Ein Guardrail, der still nichts tut, ist schlimmer als keiner.

Vor den Modellen sitzt das AI Gateway auf Basis von Azure API Management. Es setzt TPM-Limits und Token-Quotas pro Projekt durch. Bei vielen parallelen Requests kann der Verbrauch die Grenze kurz überschreiten, das steht so in der Doku.

Der Haken: Tool calls, die nie an deinem Gateway ankommen

Hier liegt die Lücke, über die die Produktseiten wenig sagen. Die Governance von Tools über ein AI Gateway ist Preview, und die Dokumentation ist unmissverständlich: "AI gateways support only MCP tools." Foundry-Tools wie SharePoint, code-first MCP-Tools, Tools mit managed OAuth und OpenAPI-Tools laufen nicht durch. Erfasst werden nur neue MCP-Tools, die im Portal angelegt wurden. Bestehende Tools werden nicht nachträglich einbezogen, und Tool-Traces loggt das Gateway nicht.

Das heißt praktisch: Dein Gateway ist ein Gate für Tokens, nicht für Aktionen. Ein Agent, der über ein OpenAPI-Tool in ein Fachsystem schreibt, tut das an deinen Token-Limits und Traffic-Policies vorbei. Die Kontrolle für Aktionen liegt woanders: im tool-call-Guardrail (Preview), in Network Egress Controls für Hosted Agents (Preview) und in einer Entra Agent ID mit minimalen Rechten.

Microsoft hat die Richtung erkannt. Die neue AI-Gateway-Stufe von API Management, seit Juli 2026 Public Preview in zwei Regionen und ohne SLA, soll Modelle und Tools hinter einem Endpoint vereinen. Darauf würde ich heute keine Produktionsentscheidung bauen.

Wo die Quellen auseinandergehen

Der GA-Post zum Agent Service vom März nennt kontinuierliches Production Monitoring als Teil des GA-Umfangs. Die Dokumentation des Monitoring-Dashboards markiert recurring evaluations, Red-Team-Scans und Alerts dagegen als Preview. Vermutlich stimmt beides, weil der Dienst GA ist und einzelne Oberflächen nicht. Für deine Planung zählt die strengere Lesart.

Was ich nicht beurteilen kann: ob die Modellaufrufe, die ein Agent intern macht, und die Built-in Tools wie Code Interpreter oder File Search über das Gateway laufen. Die Dokumentation spricht nur von Modell-Deployments und von MCP-Tools. Prüf das in deiner Umgebung mit Traces. Bis dahin behandle ich es als nicht abgedeckt.

Exkurs: Claude Code, weil die Muster übertragbar sind

Claude Code trennt Bitte und Entscheidung besonders sauber. CLAUDE.md ist Kontext. Hooks laufen dagegen deterministisch an festen Punkten im Lebenszyklus, und ein PreToolUse-Hook mit Exit-Code 2 blockiert den tool call, bevor die Berechtigungsregeln überhaupt ausgewertet werden. Deny-Regeln gehen vor Allow-Regeln und werden vom Client durchgesetzt, nicht vom Modell. Über anthropics/claude-code-action läuft das Ganze auch in GitHub Actions, auf Wunsch mit Inferenz über Microsoft Foundry, wo Claude seit Juni 2026 GA ist.

Interessant ist, dass die Lücke dieselbe Form hat. Die Sandbox von Claude Code isoliert nur Shell-Befehle, MCP-Server und Hooks laufen außerhalb. Bei GitHub deckt die Firewall nur das Bash-Tool ab. Bei Foundry erreicht nur ein Teil der Tools das Gateway. Drei Hersteller, drei Kontrollpunkte, und überall ist der Tool-Pfad der Teil, den du selbst absichern musst.

Die Checks, die halten müssen, bevor Agents ausliefern

  1. Kein Merge ohne erforderliche Status-Checks, deren Schwellen ein Mensch festgelegt hat, inklusive Evaluation des Agents.
  2. Gate-Dateien unter CODEOWNERS mit menschlicher Review. Copilot-Approval für diese Pfade ausgeschlossen.
  3. Jedes Deployment ist eine gepinnte Agent-Version im Foundry Agent Service, der Rollback ist getestet.
  4. Model router mit festem Modell-Subset, evaluiert in jedem Modus, den du in Produktion nutzt.
  5. Ein Tool-Inventar mit einer Spalte "läuft über das Gateway: ja oder nein". Für jedes Nein eine eigene Kontrolle.
  6. Tool-call- und tool-response-Guardrails aktiv, als Preview eingeplant und mit einem Test belegt, dass sie auf Agent-Ebene greifen.
  7. Evaluationen laufen nach dem Go-live weiter, mit Alert und einer benannten Person, die ihn bekommt.
  8. Ein Kostenmodell für AI Credits, Actions-Minuten und Token-Quota, bevor der erste Agent automatisch reviewt.

Meine Einschätzung

Ich halte die Richtung für richtig. Der Loop ist heute schnell und deutlich belastbarer als die Demos von vor einem Jahr, und die Plattformen liefern die Bausteine für echte Gates. Zwei Vorbehalte behalte ich. Ausgerechnet die Kontrollen, die Agenten-Aktionen betreffen, sind Preview. Und der Tool-Pfad liegt bei allen drei Herstellern teilweise außerhalb der zentralen Kontrolle.

Agents bauen es. Du lieferst es aus. Das ist keine Arbeitsteilung, sondern eine Haftungsfrage, und deshalb gehört die Entscheidung in ein Gate und nicht in einen Prompt. Keine losen Enden.

Quellen

Microsoft Foundry · Development