Ich versuche zu verstehen, wie Menschen n8n-Workflows mit KI-Agenten sicher betreiben.
Insbesondere bin ich neugierig auf Aktionen wie das Versenden von externen E-Mails, das Aktualisieren von Kundendatensätzen, den Zugriff auf Drive/Notion, die Ausstellung von Rückerstattungen oder den Aufruf von APIs von Drittanbietern.
Welche Aktionen lässt du einen KI-Schritt niemals automatisch ausführen?
Wo nutzt du derzeit Wait-Knoten, Slack-Genehmigungen, manuelle Überprüfungen oder benutzerdefinierten Code?
Hattest du schon mal einen Workflow, der etwas Unerwartetes getan hat, weil ein KI-Schritt Daten falsch interpretiert hat?
Ist es in deinem aktuellen Setup schwierig, zu überprüfen, „warum diese Aktion ausgeführt wurde
Ein echtes Beispiel statt einer allgemeinen Meinung, da du danach gefragt hast: Diese Woche habe ich einen Agent-Workflow getestet, bei dem das Versenden einer E-Mail hinter einer Policy-Überprüfung mit einer Allowlist-Regel für die Empfänger-Domain blockiert wird. Beim ersten Testlauf wurde eine E-Mail abgelehnt, die hätte durchgehen sollen. Es stellte sich heraus, dass zwei überlappende Policy-Regeln dieselbe Aktion beobachteten, und eine hatte ein einzelnes versehentliches Leerzeichen in den zulässigen Wert eingegeben. Nichts stürzte ab, nichts warf einen Fehler – es fiel einfach stillschweigend in den Ablehnungsmodus zurück – und herauszufinden, warum, erforderte echtes Graben im Audit-Log, das selbst einen kleinen Anzeigebug hatte, der verwirrt machte, welche Regel es tatsächlich verursacht hatte.
Das ist die ehrliche Antwort auf deine letzte Frage – das Auditing von „warum ist das passiert
Ich kann nur zur Geldseite sprechen — ich bin Gründer bei Sequence (getsequence.io), wir bauen Payment-Infrastruktur, auf der viele AI-Agenten laufen — aber da Rückerstattungen/Zahlungen auf deiner Liste stehen, hier ist, wo unsere Nutzer tatsächlich die Grenze ziehen:
Nie automatisch: erste Zahlung an eine neue Gegenpartei oder ein neu hinzugefügtes Bankkonto. Egal wie klein. Wiederkehrende Zahlungen an bekannte Gegenparteien werden normalerweise nach ein paar Wochen automatisiert, sobald die Leute dem Ablauf vertrauen.
Schwellenwerte, keine pauschalen Genehmigungen: Das übliche Muster ist unter $X vollautomatisch, $X–$Y Slack-Genehmigung, über $Y zwei Genehmiger. Pauschale „alles genehmigen
Konkretes Muster, das ich verwendet habe: Der KI-Agent erhält niemals ein Tool, das die sensitive Aktion direkt ausführt (Rückerstattung, externe E-Mail, Datensatz-Update). Er erhält nur ein „propose action"-Tool, das eine strukturierte Payload — Aktionstyp, Ziel, Parameter und die Begründung des Agenten — in eine Queue (Sheets/Postgres) schreibt.
Ein separater Branch nimmt diese Zeile auf, sendet eine Slack-Nachricht mit Genehmigen/Ablehnen-Buttons und wartet auf einen Wait-Node, der durch einen Webhook wiederaufgenommen wird — nicht durch ein Timeout. Also wird nichts ausgeführt, nur weil niemand es rechtzeitig angesehen hat. Erst nach der Genehmigung läuft der echte Action-Node (Gmail, HTTP Request usw.), mit den exakten Parametern, die die Person sah — nicht mit dem, was der Agent bei einem zweiten Aufruf möglicherweise produzieren würde. Das ist der Teil, der „genehmigte X, führte Y aus
Das Propose-Action-Muster von @nathan3 ist die richtige Architektur. Auf der Audit-Seite würde ich noch eines hinzufügen: Speichere den rohen Reasoning-Text des Agenten zusammen mit der vorgeschlagenen Aktion in derselben Queue-Zeile, nicht nur die Tool-Call-Args. Wenn später etwas schiefgeht, ist „Agent hat sich entschieden, X per E-Mail zu versenden, weil es Regel Y entsprach
Gute Ergänzung, die Execution ID + ON CONFLICT DO NOTHING ist sauberer als das, was ich gemacht habe. Ich habe die Trigger-Payload manuell gehasht und vor dem Insert überprüft, aber das ist ein zusätzlicher Read-then-Write-Schritt mit einem Race Condition-Fenster zwischen der Überprüfung und dem Insert. Die Uniqueness-Einschränkung auf die DB zu verschieben, entfernt dieses Fenster vollständig. Wechsle dazu über.
Guter Punkt, ich hätte veraltete Genehmigungen nicht berücksichtigt. approved_at + expires_at auf der Warteschlangen-Zeile und das Gating des Execute-Branches auf beide ist genau die Art von billiger Lösung, die man leicht überspringt, bis sie dir auf den Fuß fällt.
Ich würde sogar einen Schritt weiter gehen, auch innerhalb des TTL-Fensters: Den zugrunde liegenden Zustand direkt vor der Ausführung erneut überprüfen (Rechnung noch unbezahlt, Preis unverändert), nicht nur die Aktualität der Genehmigung. TTL erfasst die offensichtliche Veraltung, aber speziell bei Zahlungen kann sich die Welt in Minuten ändern, nicht nur in Tagen – die Genehmigung ist „aktuell
Ein anderer Blickwinkel auf die obigen Antworten, denn bisher hat jeder Schreibvorgänge kontrolliert: Geld, E-Mails, Einträge. Die Aktion, die ich lernen musste zu kontrollieren, ist diejenige, die nichts schreibt – die KI, die einem Kunden direkt antwortet.
Ein Chatbot, der einer echten Person antwortet, ist auch eine irreversible externe Aktion. Sobald er etwas Falsches gesagt hat, kann man es nicht rückgängig machen. Aber die üblichen Instinkte greifen nicht, denn es wurde nichts eingefügt, kein externes API wurde aufgerufen, keine Zeile verändert. Es sieht nicht wie die gefährliche Klasse von Aktion aus, daher bekommt es normalerweise überhaupt kein Gate.
Stattdessen verwende ich anstelle eines Genehmigungsschritts durch einen Menschen – denn man kann keinen Menschen vor eine Live-Chat-Antwort stellen, ohne das Produkt zu ruinieren – ein Konfidenz-Gate zwischen Abruf und Antwort. Wenn die abgerufenen Belege zu schwach sind oder die Ähnlichkeit zu gering ist, darf das Modell nicht antworten. Es sagt, dass es diese Information nicht hat, und leitet an einen Menschen weiter. Ablehnung ist die Standardeinstellung und Antwort ist das, das verdient werden muss. Dieselbe Struktur wie eine Allowlist, nur auf die Frage angewendet, ob das Modell sprechen darf, anstatt ob es handeln darf.
Zwei Dinge, die ich falsch gemacht habe und die wahrscheinlich der Mühe wert sind, weitergegeben zu werden.
Zum Audit-Thema: Ich protokolliere die abgerufenen Chunks und ihre Ähnlichkeitswerte neben jeder Antwort, nicht nur den Finaltext. Ohne das ist „warum hat es das gesagt