Warum diese Seite
Die Plattform entwickelt sich schnell, und manche Bausteine sind implementiert, aber noch nicht in jedem Szenario abschließend verifiziert. Statt solche Punkte über viele Seiten zu verstreuen, führt diese Seite sie konsolidiert und unverblümt auf — damit du eine belastbare Betriebsentscheidung treffen kannst.
1. Cloud-Gateways sind experimentell
Neben den offiziellen Vendor-APIs gibt es Adapter für die Cloud-Gateways AWS Bedrock, Google Vertex AI und Azure OpenAI. Diese sind implementiert, aber noch nicht live end-to-end getestet.
- Der produktive Einsatz eines Gateways sollte erst nach einer kundenseitigen Verifikation mit echten Cloud-Zugangsdaten erfolgen.
- Die direkten Vendor-APIs (Anthropic, OpenAI, Google Gemini) sowie der on-prem-Betrieb über Ollama/vLLM sind davon nicht betroffen.
2. Parallele Läufe nur mit Feature-Flag — und nur auf einem Host
Bis v0.20 lief pro Projekt genau ein Run. Seit v0.21 gibt es eine Workflow-Ebene darüber: ein Vorhaben zerfällt in Tasks, die als eigenständige Child Runs parallel laufen — jeder in einem eigenen git-Worktree. Das ist standardmäßig abgeschaltet.
- Ohne das Feature-Flag
softwarefabrik.workflow.enabledverhält sich die Plattform wie vorher: ein Lauf je Workspace. - Mit Flag laufen höchstens drei Child Runs gleichzeitig je Workflow. Die Grenze ist bewusst niedrig: Jeder Lauf kostet Tokens, und mehr Parallelität erhöht vor allem den Integrationsaufwand.
- Die Sperre gilt seit v0.21 dem Workspace, nicht mehr dem Projekt. Zwei Agenten im selben Verzeichnis bleiben ausgeschlossen — sonst wäre keine Änderung mehr einem Lauf zurechenbar.
- Kein verteilter Worker-Pool. Alle Child Runs laufen als Prozesse auf einer Maschine.
- Merge-Konflikte und Vertragsbrüche löst ein Mensch. Beide halten den Workflow an und warten auf eine Entscheidung; ein Agent, der den Branch selbst in Einklang bringt, ist geplant, aber nicht gebaut.
3. Ausführung generierten Codes — isolierte Umgebung empfohlen
Build-Runs führen von Agenten erzeugten Code aus (z.B. mvn verify, npm run build). Solcher Code sollte grundsätzlich als nicht vertrauenswürdig behandelt werden.
- Betreibe Build-Runs auf einer isolierten bzw. vertrauenswürdigen Umgebung, nicht auf einem Host mit sensiblen Zugängen.
- Die Container-Sandbox (
execution.sandbox.variant=container, mit Netzwerk-, CPU- und Speicher-Limits) kapselt den Build und die Scans des generierten Projekts (mvn verify, trivy). - Die Agent-CLIs selbst (Claude Code, Codex, Gemini, Aider, Kimi) laufen dagegen als Prozess auf dem Host — seit v0.31 mit leerem, ephemerem HOME, sodass Konfiguration und Zugangsdaten des Betriebsnutzers nicht mehr hineinreichen. Gegen gezieltes Lesen über absolute Pfade schützt das nicht; das leistet erst ein Agent-Container (geplant, eigener ADR).
4. Repo-Anbindung: Pull-Requests und CI-Rückkopplung nur für GitHub
Push, Pull-Request, CI-Statusabfrage und GitHub-Release sind gegen die GitHub-API implementiert.
- GitLab, Bitbucket und Azure DevOps sind noch nicht angebunden. Für diese Hosts greift der lokale Merge in den Base-Branch; Branch-Isolation, Quality-Gate und Korrektur-Schleife funktionieren unverändert.
- Die PR-/CI-Rückkopplung ist bewusst opt-in (
git.pr-feedback.enabled, Default aus): unbeaufsichtigte periodische Remote-Kontakte sollen eine bewusste Betriebsentscheidung sein. - Der fabrikweite GitHub-Token wird nur für Hosts der Allowlist verwendet (
git.allowed-hosts, Defaultgithub.com).
5. Budget-Obergrenzen wirken je Mandant, nicht je Nutzer
Token-Verbrauch und Kosten werden je Projekt, Run, Provider, Mandant und je Seat (auslösender Nutzer) erfasst und als CSV exportiert.
- Der harte Budget-Cap greift auf Mandantenebene. Eine seat-scharfe Obergrenze gibt es nicht — die Seat-Sicht wertet aus, sie begrenzt nicht.
- Wer nutzerscharf begrenzen muss, trennt über Mandanten.
6. MCP-Nullzustand: was er leistet und wo er endet
Seit v0.31 erreicht kein Agentenlauf mehr einen MCP-Server, den die Fabrik nicht ausdrücklich freigibt (ADR-0017). Die Grenzen dieser Isolation:
- Workspace-Konfiguration anderer CLIs (etwa
.codex/,.gemini/,.kimi-code/im Repository) kann in nicht regulierten Profilen wirken. Sie wird aber vor und nach jeder Ausführung erfasst und in der Audit-Kette festgehalten; der Canary-Harness weist je CLI-Version aus, ob sie wirkt. - In den Profilen BAIT/MaRisk/DORA und BSI/VS-NfD laufen Agent-CLI-Adapter nur mit einem bestandenen Isolationsnachweis für die installierte CLI-Version. Bis ein Admin ihn per Canary erzeugt hat, ist dort nur der Mock-Adapter nutzbar — bewusst fail-closed.
- Zwei Quellen lassen sich nicht per Marker nachweisen: die systemweite Managed-Ebene (ohne Root-Rechte nicht platzierbar — eine vorgefundene Datei mit Servern lässt den Nachweis scheitern) und die claude.ai-Connectors eines Abo-Logins (per Umgebungsvariable abgeschaltet, im Protokoll als ungeprüft geführt).
- Ein Nachweis gilt für die Umgebung, in der er entstand. Nach einem CLI-Update ist ein neuer Canary-Lauf nötig; bis dahin greift die Sperre automatisch.