Agent-Apps: Kann ein öffentlicher POC zum privaten MVP werden?

Ein öffentlicher POC beweist die Produktschleife. Ein privates MVP beweist, dass du in einem abgeschotteten Netzwerk überlebst.

Das sind unterschiedliche Architekturen. Täusch das Zweite nicht vor, indem du weitere Env-Dateien hinzufügst.

Ein POC ist darauf optimiert, die Agentenschleife zu verstehen. Ein MVP ist darauf optimiert, wer auf welcher Ebene was erreichen kann.

Abbildung 1. Stufe nach Ebene. Ein POC kann öffentlich oder per IP gefiltert sein. Ein MVP braucht privaten Ingress, privaten Egress, verknüpftes DNS und gehärtete Identität. Ordner umzubenennen verschiebt keine Ebene.

Kontext und Rahmenbedingung

Agent-Shells können in einem einzigen Schritt von "läuft auf meinem Rechner" zu "vom privaten DNS blockiert" wechseln. Das Modell hat sich nicht verschlechtert. Die Netzwerkebene hat sich geändert.

Öffentlicher Ingress (oder eine enge IP-Allowlist) ist eine legitime Wahl für einen POC. Private Endpoints, VNet-Integration, private DNS-Zonen und Referenzen auf Key Vault sind die Wahl für ein MVP. Das ist nicht dasselbe Diagramm mit anderen .env-Werten.

Microsoft beschreibt die Trennung bei App Service ausdrücklich: Ein Private Endpoint deckt den eingehenden privaten Zugriff auf die App ab. Die regionale VNet-Integration deckt ausgehende Aufrufe der App ins virtuelle Netzwerk ab. Oft brauchst du beides. Wer die beiden in einem README verwechselt, liefert ein "MVP" aus, das weiterhin auf dem öffentlichen Hostnamen antwortet.

Abbildung 2 zeigt das Learn-Muster für Private Endpoints bei App Service. Behandle es als Kontrolle des eingehenden Verkehrs, nicht als Synonym für "alles privat".

Abbildung 2. Private-Endpoint-Muster für App Service. Eingehender privater Zugriff ist kein ausgehender privater Zugriff. Quelle: Microsoft Learn: App Service private endpoints.

Trenne die Stufen nach den Unterschieden, die du wirklich meinst

Schreib eine Architekturtabelle, bevor du Ordner klonst.

POC. Öffentlicher oder per IP gefilterter Ingress. Schnellere Iteration. Endpoints der Agentenplattform, die eventuell noch aus dem Internet erreichbar sind. Kurzlebige Secrets oder eng begrenzte App Settings. Genug Entra, um Leute anzumelden und App-Rollen zu beweisen. Gut für das Verhalten der Shell, Streaming-Chat und Upload-Schleifen.

MVP. Private Endpoints auf der Shell-API und auf Abhängigkeiten der Datenebene, die nicht öffentlich sein dürfen. VNet-Integration, damit die App privaten Key Vault, Storage und Plattform-Endpoints aufrufen kann. Privates DNS, verknüpft mit dem Integrations-VNet, damit Namen zu privaten IPs aufgelöst werden. Klarere Identität: Managed Identity für die App, App-Rollen für die Nutzer, Conditional Access, wo nötig. Die Verantwortlichen für Netzwerk, privates DNS und Monitoring werden zu vollwertigen Beteiligten.

Was gemeinsam bleibt: die Produktformen (SPA, API, Agent-Schnittstellen), das Autorisierungsmodell und die Testmatrix der Rollen. Was nie mitgenommen werden darf: übrig gebliebene Connection Strings, alte Registry-Zugangsdaten und "vorübergehende" öffentliche Allow-Regeln.

1. Zeichne Ingress und Egress als getrennte Kästen

Eingehender privater Zugriff ist kein ausgehender privater Zugriff. Private Endpoints geben der App (oder einer Abhängigkeit) eine private IP für Aufrufer im Netzwerk. Die VNet-Integration lässt die App-Service-Worker über ein delegiertes Subnetz private Ressourcen erreichen. Microsoft dokumentiert, dass diese Subnetze nicht dieselben sein dürfen. Wenn dein Diagramm eine einzige Wolke mit der Beschriftung "privat" hat, zeichne es neu. Abbildung 3 zeigt die Trennung.

Abbildung 3. Ingress und Egress sind getrennte Kästen. Der Private Endpoint legt fest, wer die Shell erreichen kann. Die VNet-Integration legt fest, wie die Shell Key Vault, Storage und Plattform-Endpoints erreicht.

2. Behandle privates DNS als Produktabhängigkeit

Der Fehler liegt fast immer beim DNS: Der Hostname wird weiterhin öffentlich aufgelöst, oder privat für ein Subnetz und für ein anderes nicht. Verknüpfe die Azure Private DNS-Zonen mit dem VNet, in das die App integriert ist. Wenn du ein eigenes DNS betreibst, sorge dafür, dass es korrekt weiterleitet. Debugge das nicht drei Tage lang als Anwendungsfehler.

3. Härte Entra, wenn du das Netzwerk härtest

Agent-Apps für Nutzer brauchen auch dann eine klare Identitätsgeschichte, wenn das Netzwerk abgeschottet wird. Entra entscheidet, wer die Shell öffnen darf. App-Rollen auf der API entscheiden weiterhin, welche Agent-Funktionen und Routen es gibt. Netzwerkisolation verringert, wer die Ebene berühren kann. Sie ersetzt keine Autorisierung pro Agent. Beide Schichten sind wichtig; sie lösen unterschiedliche Bedrohungen.

Abbildung 4 erinnert auf Learn daran, dass Apps für Nutzer auch dann eine Identitätsgeschichte brauchen, wenn das Netzwerk gehärtet wird.

Abbildung 4. Apps für Nutzer brauchen auch dann eine klare Identitätsgeschichte, wenn das Netzwerk gehärtet wird. Quelle: Microsoft Learn: authentication flows and app scenarios.

4. Hol die Secrets aus "für immer in gitignore"

App Settings im POC und lokale .env-Dateien sind für einen Spike in Ordnung. Ein MVP sollte Referenzen auf Key Vault (oder etwas Gleichwertiges) verwenden, die über private Netzwerke erreicht werden, wo der Plattformstandard das verlangt. Langlebige Secrets in klonbaren Vorlagen werden zum nächsten Incident.

5. Erfasse Registries, Pläne und Rollen

Container Registries, SKUs von App-Service-Plänen und Rollenzuweisungen für Managed Identities sind zwischen den Stufen nicht ohne Diagramm austauschbar. Ein privates MVP braucht oft eine höhere Planstufe für VNet-Integration und Private Endpoints. Plane das als Architektur ein, nicht als überraschende Kosten.

Häufige Fehler

Env-Datei-Theater. Zwölf Vorlagen namens poc, mvp, prod, die nur URLs ändern, während das Netzwerk öffentlich bleibt. Das README sagt MVP. Das öffentliche Internet sagt etwas anderes.

Private Endpoint ohne privates DNS. Die App sieht im Portal privat aus und wird trotzdem falsch aufgelöst. Die Symptome sehen aus wie zufällige 403-Fehler und Timeouts.

Die Annahme, dass VNet-Integration den Ingress abschottet. Ausgehende Integration macht die App nicht privat. Für die Kontrolle des eingehenden Verkehrs brauchst du weiterhin Private Endpoints oder Zugriffsbeschränkungen.

Identität wird auf "nach dem Netzwerk" verschoben. Du härtest die Ebene und lässt jeden angemeldeten Nutzer als vertrauenswürdigen Agent-Operator stehen. Netzwerkkontrollen schützen die Ebene; sie ersetzen keine Autorisierung pro Funktion.

POC-Secrets werden komplett übernommen. Alte Platzhalter, geteilte Schlüssel und öffentliche Storage-Endpoints fahren ins MVP mit, weil jemand den Ordner kopiert hat.

Ein Subnetz für alles. Private Endpoints und VNet-Integration streiten sich um dasselbe delegierte Subnetz. Die Plattform erfindet keine Kapazität für dich.

So übernehmen oder anpassen

So übernehmen

• Ingress-Modell pro Stufe (öffentlich oder per IP gefiltert für den POC; Private Endpoint für die MVP-Shell und kritische APIs).
• Ausgehendes Modell für das MVP (regionale VNet-Integration, Route All, wenn der ausgehende Verkehr geprüft werden muss).
• Eine Liste der privaten DNS-Zonen und der VNets, mit denen sie verknüpft sind.
• Identität für die App (Managed Identity), die Nutzer (Entra + App-Rollen) und die Erreichbarkeit der Agentenplattform.
• Speicherort und Rotation der Secrets; keine langlebigen Secrets in Dateien unter gitignore als Dauerlösung.
• Promotion-Regel: Netzwerk und Identität entscheiden über die Stufenbezeichnung; die Konfigurationsdateien folgen. Öffentliche Ausnahmen brauchen einen Verantwortlichen und ein Prüfdatum.

Abbildung 5. Promotion-Gates statt Env-Theater. Zuerst Netzwerk und Identität. Die Secrets folgen über privaten Zugriff. Erst dann verdient die Stufe die Bezeichnung MVP.

Vor dem Einsatz anpassen

Ein privates MVP aufzusetzen dauert länger. Du brauchst die Verantwortlichen für Netzwerk, DNS und Identität mit am Tisch. Das Tempo des POC sinkt, wenn jede Änderung auf einen Private Link wartet.

Du verlierst Bequemlichkeit: Demos im Portal und curl von außerhalb des VNet. Plane ein VPN oder einen Bastion-Zugang ein, statt still den öffentlichen Ingress wieder zu öffnen. On-Behalf-Of-Flows lassen sich schwerer debuggen, wenn der Egress abgeschottet ist; halte Identitätstests und Netzwerktests getrennt, damit du weißt, welche Ebene kaputt ist.

Wichtigste Quellen: App Service private endpoints, App Service VNet integration und authentication flows and app scenarios.

Wenn dein MVP noch über einen öffentlichen Hostnamen mit POC-Secrets erreichbar ist, hast du kein MVP. Du hast eine lautere Demo.