Graphen-Engineering für KI-Agenten: Verbindungen steuern

Unternehmen steuern geschäftskritische Abläufe nicht, indem sie jeden Gedanken jedes Mitarbeiters, Dienstes oder Anbieters zu kontrollieren versuchen. Sie steuern die Schnittstellen dieser Abläufe: welche Systeme erreichbar sind, welche Aktionen eine zweite Freigabe erfordern, welche Anmeldedaten verwendet werden dürfen, wie hoch die Ausgaben sein dürfen, welche Informationen Grenzen überschreiten dürfen und welche Aufzeichnungen hinterlassen werden. KI-Agenten benötigen denselben institutionellen Instinkt – mit einer wichtigen Ergänzung. Modelle müssen dennoch evaluiert werden. Tests und Monitoring zeigen Ihnen, wie sich eine Komponente unter definierten Bedingungen verhält; Laufzeitkontrollen bestimmen, was diese Komponente tun darf, wenn sie mit Produktionssystemen verbunden ist.

Diese Unterscheidung ist der sinnvollste Ansatz, um über Graph Engineeringnachzudenken. Der Begriff ist noch neu, aber das technische Problem ist bereits konkret: Eine Agenten-Landschaft ist ein Graph aus Modellen, Tools, Diensten, Datenquellen, Sandboxes, Menschen und anderen Agenten. Jede geschäftskritische Verbindung trägt Autorität. Die Aufgabe des Unternehmens besteht nicht darin, sich zwischen der Evaluierung des Knotens und der Steuerung des Graphen zu entscheiden. Es geht darum, beides zu tun – und zu wissen, welche Ebene für welche Kontrolle verantwortlich ist.

1. Evaluierung des Knotens; Steuerung der Verbindungen

Es ist verlockend, die Agenten-Governance als Reaktion auf die Undurchsichtigkeit von Modellen zu betrachten: Da das Modell intern schwer zu prüfen ist, sollten nur die Schnittstellen gesteuert werden. Das greift zu kurz. Das AI Risk Management Framework des NIST fordert eine Evaluierung unter einsatznahen Bedingungen vor der Nutzung sowie ein Monitoring des KI-Systemverhaltens in der Produktion; die Agenten-Sicherheitsrichtlinien von OWASP kombinieren Adversarial Testing mit dem Prinzip der geringsten Rechte, Autorisierung, Freigaben, Protokollierung und Monitoring. Die ausgereifte Haltung ist daher komplementär: Evaluierung schätzt das Verhalten ein; Verbindungskontrollen begrenzen die Autorität.

Die institutionelle Analogie wird nützlich, sobald sie auf diese Weise eingegrenzt wird. Ein Finanzteam verlässt sich nicht allein auf das Urteilsvermögen eines Mitarbeiters; es beschränkt zudem den Kontozugriff und verlangt Gegenzeichnungen. Ein Produktions-Agent sollte sich nicht allein auf Prompt-Anweisungen verlassen; seine Laufzeitumgebung und Gateways sollten sensible Grenzen explizit und durchsetzbar machen. Die Analogie ist nicht wörtlich zu nehmen – Menschen und Modelle sind nicht dieselbe Art von Akteur –, aber die Kontrollziele lassen sich erstaunlich gut übertragen.

Discovery ist keine Sicherheitsgrenze

Diese Unterscheidung ist besonders für die Tool-Discovery wichtig. TrueForge dokumentiert das verzögerte Laden von Tools und andere Mechanismen des Context-Engineerings, die den aktiven Kontext kleiner halten. Dies kann die Qualität der Auswahl verbessern und unnötige Offenlegungen von Tool-Schemas reduzieren. Es autorisiert jedoch nicht von sich aus den Aufruf. Die Autorisierung auf Ebene der gesamten Infrastruktur gehört in eine Zugriffskontrollschicht, die den Aufrufer identifiziert und Richtlinien anwendet. TrueFoundrys Zugriffskontrollen für das AI Gateway steuern den Modellzugriff für Benutzer, Teams und Anwendungen; das Authentifizierungs- und Sicherheitsmodell des MCP Gateways löst eingehende Identitäten, Tool-/Server-Berechtigungen und nachgelagerte Anmeldeinformationen separat auf.

2. Entworfene Graphen und ausgeführte Graphen sind unterschiedliche Objekte

Ein Architekturdiagramm ist eine Absichtserklärung. Produktionsdaten sind ein Protokoll dessen, was das instrumentierte System tatsächlich beobachtet hat. Beide weichen aus alltäglichen Gründen voneinander ab: Ein Prototyp-Tool bleibt verbunden, eine Fallback-Route wird aktiviert, eine delegierte Aufgabe wird aufgefächert, eine OAuth-Berechtigung ändert sich oder ein Agent schlägt einen Weg ein, den der Ersteller des Diagramms nicht vorgesehen hat. Genau in dieser Lücke wird Graph-Governance operativ statt nur architektonisch.

Doch die Aussage „der tatsächliche Graph steckt in den Traces“ ist ebenfalls zu kurz gegriffen. Keine einzelne Trace-Quelle ist automatisch vollständig. Eine nützliche Rekonstruktion kombiniert die Beweise, die jede Ebene liefert:

• Orchestrator: Graphentopologie, Knotenstatus, Routing, Wiederholungsversuche, Joins und Delegationsentscheidungen.
• Harness: Schritte der Modell-/Tool-Schleife, Sandbox-Nutzung, Genehmigungs-Checkpoints, Sitzungsstatus und für die Laufzeit sichtbare Ereignisse.
• Gateway: Authentifizierte Modell-/MCP-Aufrufe, Ergebnisse von Zugriffsrichtlinien, Budgets/Ratenbegrenzungen, Latenz, Kosten und für das Gateway sichtbare Anfrage-Traces.
• Nachgelagerte Systeme: Maßgebliche Aufzeichnungen über geschäftliche Auswirkungen – die Datenbankänderung, Ticket-Aktualisierung, Zahlung, Bereitstellung oder Berechtigungsänderung, die tatsächlich stattgefunden hat.

Die richtige Audit-Frage lautet daher nicht „Stimmt der Trace mit dem Diagramm überein?“, sondern „Können wir die beabsichtigte Topologie mit genügend Laufzeit- und Systemdaten korrelieren, um eine folgenschwere Aktion zu erklären?“ Das ist ein deutlich höherer Anspruch – und ein weitaus nützlicherer.

3. TrueForge: Sorgen Sie für eine transparente Ausführungsschleife

Auf der Ebene des Harness stellt sich die Governance-Frage, ob operative Entscheidungen rund um das Modell sichtbar und konfigurierbar sind. Das öffentliche Repository von TrueForge beschreibt die Laufzeitumgebung klar: Es führt die Agenten-Ausführungsschleife über Modellaufrufe, MCP-Tools, Skills, Sandboxing, Freigaben, Kontextverwaltung und Sitzungsstatus hinweg aus. Dasselbe Repository dokumentiert Sandbox-as-a-Tool mit im Harness gespeicherten Geheimnissen, menschlichen Kontrollpunkten, Sub-Agenten, verzögertem Laden von Tools, Auslagerung großer Ergebnisse, Komprimierung sowie lokalen und gehosteten Modi. Das Repository positioniert den lokalen Modus explizit als Pfad für die Evaluierung auf einer einzelnen Maschine, nicht als Produktions- oder internetfähiges Setup; für die gemeinsame Nutzung oder den produktiven Einsatz ist der gehostete Modus vorgesehen. Es wird unter der MIT-Lizenz bereitgestellt.

Diese Offenheit ist nicht nur aus Lizenzgründen nützlich, sondern auch aus Governance-Sicht. Die Verfügbarkeit des Quellcodes ermöglicht die Überprüfung und Anpassung auf Implementierungsebene. Dies beweist zwar nicht, dass eine bereitgestellte Instanz sicher, korrekt konfiguriert oder identisch mit einem bestimmten Commit ist – dafür sind weiterhin Kontrollen der Software-Lieferkette und des Betriebs erforderlich. Aber es gibt Plattform-Teams etwas, das geschlossene Laufzeitumgebungen nicht bieten: die Möglichkeit, die Ausführungsmechanismen, denen sie vertrauen sollen, zu überprüfen und bei Bedarf selbst auszuführen oder anzupassen. Der Launch-Beitrag von TrueFoundry, Introducing TrueForge, macht diese Positionierung explizit, und Why Agent Harnesses Should Be Open benennt den geschäftlichen Kompromiss direkt: Halten Sie das Harness offen und fügen Sie eine zentralisierte Governance erst dann hinzu, wenn das Unternehmen sie tatsächlich benötigt.

Der überzeugendste Weg, TrueForge zu bewerben, besteht nicht darin, zu behaupten, es kontrolliere den gesamten Graphen. Das tut es nicht. Ein beliebiger Multi-Agenten-Orchestrator kann die Topologie oberhalb des Harness steuern, und angebundene Systeme behalten ihre eigene Autorisierungs- und Audit-Semantik bei. Die Rolle von TrueForge ist begrenzter und glaubwürdiger: die Ausführungsschleife an der Laufzeitgrenze überprüfbar, portabel und steuerbar machen.

4. TrueFoundry: Fügen Sie eine Richtlinienebene hinzu, wenn aus dem Bestand eine Flotte wird

Ein einzelnes Harness kann seine eigene Ausführung verwalten. Ein Bestand an Agenten schafft jedoch ein zweites Problem: Anmeldedaten, Zugriffsrichtlinien, Ausgabenkontrollen und Nachweise beginnen sich über Teams hinweg zu fragmentieren. Genau hier setzen die Gateways von TrueFoundry als ergänzende Ebene an.

Das AI Gateway bietet eine einheitliche Modellschnittstelle mit zentralisierter Zugriffskontrolle, Ratenbegrenzung, Budgetierung und Beobachtbarkeit. Dessen Budgetregeln können Ausgaben nach Benutzer, Team, Modell, virtuellem Konto oder Metadaten begrenzen. Das Metrics Dashboard aggregiert LLM- und MCP-Aktivitäten, Kosten, Fehler, Routing, Guardrails und andere operative Signale. Das MCP-Gateway trennt eingehende Authentifizierung, Tool-/Server-Zugriffskontrolle und ausgehende Authentifizierung, sodass Agenten nicht jeweils die gesamte Anmeldeverwaltung übernehmen müssen.

Das sorgt für eine saubere Architektur:

‍