Der 10-Schichten-Stack war bereits der tiefste in der Kategorie
Als wir unseren Governance-Stack letzten Monat ausgeliefert haben, war er bereits der umfassendste in der AI-Automatisierungskategorie. Zehn Schichten, die Identität, Datenschutz, menschliche Aufsicht, Compliance und Observability abdecken. Kein Wettbewerber hatte etwas Vergleichbares.
Aber ein 10-Schichten-Stack hat eine Lücke. Sie können kontrollieren, wer einen Workflow ausführt. Sie können kontrollieren, auf welche Daten der Workflow zugreift. Sie können menschliche Genehmigung verlangen, bevor der Workflow ausgeführt wird. Was Sie nicht kontrollieren konnten, war welche spezifischen Tools ein Agent während der Ausführung aufruft.
Die Lücke: Tool-Level-Governance
Betrachten Sie einen Workflow, der MCP-Server für Slack, Gmail und Salesforce verwendet. Der Workflow ist zur Ausführung genehmigt. Der Agent hat die richtigen Berechtigungen. Aber sollte dieser Agent eine E-Mail über Gmail ohne explizite Genehmigung senden können? Sollte er einen Salesforce-Datensatz autonom aktualisieren?
n8n hat diese Lücke erkannt und Human-in-the-Loop auf der Ebene einzelner Tool-Aufrufe hinzugefügt. Ihre Implementierung lässt einzelne Benutzer Tool-Aufrufe während der Ausführung genehmigen. Aber sie ist benutzergesteuert, nicht admin-gesteuert. Es gibt keine organisatorische Richtlinienebene.
Wir haben einen anderen Ansatz gewählt.
Tool-Genehmigungsgates: Die 10. Schicht
Tool-Genehmigungsgates geben Administratoren granulare Kontrolle darüber, welche Tools menschliche Genehmigung vor der Ausführung erfordern. Das ist keine Workflow-Level-Pause. Es ist ein Tool-Level-Gate.
So funktioniert es:
- Admin konfiguriert genehmigungspflichtige Tools in den MCP-ACL-Einstellungen. Jedes Tool im MCP-Server-Katalog des Accounts kann markiert werden.
- Während der Workflow-Ausführung, wenn der Agent versucht, ein markiertes Tool aufzurufen, pausiert die Ausführung.
- Eine Genehmigungsanfrage wird erstellt, die den Tool-Namen, die Eingabeparameter, die der Agent senden möchte, und den Agent-Identitätskontext zeigt.
- Ein Genehmiger prüft und entscheidet — genehmigen zum Fortfahren, ablehnen zum Überspringen, oder das Timeout automatisch ablehnen lassen.
- Die Ausführung wird fortgesetzt, wobei die Entscheidung im Audit-Trail aufgezeichnet wird.
Der Hauptunterschied zu n8ns Ansatz: Genehmigungsrichtlinien werden von Administratoren festgelegt, nicht von einzelnen Benutzern. Der Genehmiger kann als Sponsor des Agenten, als jeder Benutzer mit einer Mindestrolle oder als spezifische benannte Benutzer konfiguriert werden. Timeout- und Benachrichtigungseinstellungen sind organisatorische Richtlinien, keine benutzerbezogenen Präferenzen.
Der vollständige 10-Schichten-Stack
Hier ist, was jede Schicht leistet:
| # | Schicht | Was sie regelt |
|---|---|---|
| 1 | Role-Based Access Control | Wer was tun darf (6 Rollen, 24 Berechtigungen, Abteilungs-Scoping) |
| 2 | Agent-Identität | Pro-Agent-Berechtigungen, Rate Limits und Audit-Kontext-Propagierung |
| 3 | Audit-Protokollierung | 280+ Aktionstypen mit unveränderlichen, exportierbaren Nachweisen |
| 4 | PII-Erkennung + Tokenisierung | Automatische Erkennung und reversible Tokenisierung sensibler Daten |
| 5 | Abgestufte Autonomie | 4 Vertrauensstufen (manuell bis voll automatisch) mit richtliniengesteuerter Eskalation |
| 6 | Tool-Genehmigungsgates | Admin-kontrollierte Pro-Tool-Genehmigung vor der Ausführung |
| 7 | Datenspeicherort-Kontrollen | HIPAA-, GDPR-, PCI-DSS-, SOX-, FedRAMP-Compliance-Voreinstellungen |
| 8 | Envelope-Key-Verschlüsselung | AES-256-GCM mit HKDF-SHA256-Schlüsselableitung für BYOK |
| 9 | Compliance-Dashboard + SOC 2 | 21 Richtlinien, 17 TSC-Kontrollen, Nachweisexport, Vanta-Integration |
| 10 | EU AI Act Compliance Engine | 10-Artikel-Zuordnung (Art. 9-17, 52), Risikoklassifizierung, Nachweisgenerierung |
| 10 | Governance-Bereitschaftsbewertung | Self-Service-Bewertung über alle Governance-Schichten mit Empfehlungen |
Jede Schicht arbeitet unabhängig, integriert sich aber mit den anderen. Agent-Identität (Schicht 2) propagiert durch Tool-Genehmigungsgates (Schicht 6), sodass Genehmiger genau sehen, welcher Agent Tool-Zugriff anfordert. Audit-Protokollierung (Schicht 3) zeichnet jede Genehmigungsentscheidung auf. Das Compliance-Dashboard (Schicht 9) verfolgt Tool-Genehmigungs-Compliance über die gesamte Organisation.
Warum Tiefe wichtiger ist als Breite
Microsoft, OpenAI und Anthropic investieren alle in Governance. Microsofts Agent Framework fügt grundlegende Rollenzuweisung hinzu. OpenAI Frontier hat Pro-Agent-Identität. Anthropic bietet Enterprise-Admin-Kontrollen.
Das sind wichtige erste Schritte. Aber Governance-Tiefe wird in Schichten gemessen, nicht in Features. Eine Plattform mit rollenbasiertem Zugriff aber ohne PII-Erkennung hat eine Governance-Lücke. Eine Plattform mit Audit-Protokollierung aber ohne Tool-Level-Kontrollen hat eine Governance-Lücke. Eine Plattform mit Compliance-Voreinstellungen aber ohne EU AI Act-Zuordnung hat eine Governance-Lücke.
10 Schichten bedeuten, dass 10 potenzielle Fehlerpunkte abgedeckt sind. Nicht weil wir 10 als Zahl gewählt haben, sondern weil Enterprise-AI-Bereitstellungen mindestens 10 unterschiedliche Governance-Anforderungen haben.
Was als Nächstes kommt
Das Governance-Wettrüsten beschleunigt sich. Jede große Plattform liefert Governance-Features aus. Die Frage ist nicht mehr ob AI-Agenten geregelt werden sollen, sondern wie tief.
Wir werden weiterhin Schichten hinzufügen, wenn neue Governance-Anforderungen entstehen. Der Stack ist zum Wachsen konzipiert.
Governance-Stack erkunden | Governance-Bereitschaftsbewertung ausprobieren