Überall tauchen neue KI-Agenten, Skills, MCP-Server, Erweiterungen und „Autopiloten“ auf. Fast jedes Projekt verspricht mehr Reichweite, mehr Gedächtnis, mehr Selbstständigkeit und weniger Arbeit. Die Installation soll am besten mit einem einzigen Befehl erledigt sein. Danach könne der Agent recherchieren, planen, schreiben, programmieren, Kontakte pflegen und sich angeblich sogar selbst verbessern.

Das klingt bequem. Es ist aber genau der Moment, in dem aus einer nützlichen Erweiterung eine neue Angriffsfläche werden kann.

Viele Nutzer unterscheiden nicht zwischen einem Agenten, einem Skill und einem Workflow. Deshalb installieren sie eine ganze Plattform, obwohl sie nur eine einzige Fähigkeit benötigen. Zusammen mit dieser Fähigkeit landen dann womöglich Shell-Zugriff, Cookies, Tokens, Hintergrunddienste, Telemetrie, externe Modellanbieter und fremde MCP-Server auf dem System.

Unsere Gegenposition ist einfach: Ein Agent wird nicht klüger, nur weil man ihm mehr Schlüssel gibt.

Der Agent ist die Rolle

Ein Agent beschreibt, wer handelt, welche Verantwortung er trägt und wo seine Grenzen liegen.

Ein E-Mail-Sekretär braucht andere Regeln als ein Programmieragent. Ein Redaktionsassistent muss Quellen prüfen, Tatsachen von Meinungen trennen und vor einer Veröffentlichung eine Freigabe einholen. Ein Serverassistent darf Diagnosen durchführen, aber nicht ohne Sicherung und Bestätigung mehrere Konfigurationen gleichzeitig verändern.

Die Rolle beantwortet Fragen wie:

• Wofür ist der Agent zuständig?
• Welche Entscheidungen darf er selbst treffen?
• Wann muss er den Menschen fragen?
• Auf welche Daten darf er zugreifen?
• Welche Handlungen sind grundsätzlich ausgeschlossen?

Ohne diese Grenzen ist „Autonomie“ nur ein freundliches Wort für unkontrollierte Berechtigungen.

Der Skill ist eine begrenzte Fähigkeit

Ein Skill beschreibt, wie eine konkrete Aufgabe zuverlässig erledigt wird. Das kann eine E-Mail-Triage, eine Sicherheitsprüfung, eine Podcastproduktion oder eine strukturierte Recherche sein.

Ein guter Skill ist klein genug, um verstanden und geprüft zu werden. Er legt nicht nur fest, was funktionieren soll, sondern auch, was nicht passieren darf. Eine Mail-Fähigkeit darf zum Beispiel Nachrichten lesen und Entwürfe anlegen, ohne automatisch zu antworten. Eine Recherchefähigkeit darf öffentliche Quellen auswerten, ohne Browser-Cookies oder private Kontositzungen einzusammeln.

Genau hier liegt ein verbreiteter Denkfehler: Wer eine neue Fähigkeit braucht, installiert häufig ein komplettes Agentensystem. Das ist so, als würde man für einen neuen Schraubendreher gleich eine fremde Werkstatt übernehmen – mitsamt Generalschlüssel und unbekanntem Personal.

Der Workflow ist der kontrollierte Prozess

Ein Workflow verbindet Rolle, Fähigkeiten, Wissen, Freigaben und Prüfungen zu einem nachvollziehbaren Ablauf.

Bei Darknight-Coffee bedeutet das zum Beispiel:

1. Eine Quelle oder Aufgabe kommt in den Eingang.
2. Inhalt und Herkunft werden geprüft.
3. Die aktive Arbeit liegt eindeutig unter „In Arbeit“.
4. Tatsachen, Hinweise und offene Fragen werden getrennt.
5. Vor externen Nachrichten oder Veröffentlichungen erfolgt eine ausdrückliche Freigabe.
6. Das Ergebnis wird öffentlich oder technisch überprüft.
7. Erst danach wandert es in „Veröffentlicht“ oder ins Archiv.

Der Workflow verhindert, dass ein Agent eine gute Idee mit einem ungeprüften Schnellschuss verwechselt. Er ist nicht das Gegenteil von Selbstständigkeit. Er ist die Voraussetzung dafür, dass Selbstständigkeit belastbar bleibt.

Open Source ist eine Einladung zur Prüfung – kein Freifahrtschein

Open Source ist für digitale Souveränität unverzichtbar. Der Quellcode kann untersucht, verändert und selbst betrieben werden. Doch eine freie Lizenz beweist weder Sicherheit noch Qualität.

Auch ein offenes Projekt kann veraltete Abhängigkeiten, unsaubere Installationsskripte, ungewollte Telemetrie oder gefährliche Standardrechte enthalten. Es kann Cookies verlangen, Daten an externe Dienste senden oder im Hintergrund Prozesse starten. Und selbst wenn der Quellcode sauber ist, können die empfohlenen Zusatzdienste das eigentliche Datenschutzproblem verursachen.

Die richtige Frage lautet deshalb nicht: „Ist es Open Source?“

Die richtige Frage lautet: „Welchen belegten Nutzen bringt es, welche Rechte verlangt es und wohin fließen unsere Daten?“

Der Angriff kann bereits im gelesenen Inhalt stecken

Nicht jede Gefahr muss installiert werden. Ein Agent kann auch über Inhalte angegriffen werden, die er lediglich lesen soll: eine manipulierte Webseite, ein GitHub-Issue, eine README, ein PDF oder eine fremde Skill-Datei. Darin können Anweisungen versteckt sein, die den Agenten dazu bringen sollen, seine eigentliche Aufgabe zu verlassen, Daten preiszugeben oder ungeprüfte Befehle auszuführen. Dieses Verfahren wird als Prompt Injection bezeichnet.

Deshalb sind externe Inhalte grundsätzlich Daten – keine vertrauenswürdigen Arbeitsanweisungen. Eine Webseite darf uns informieren, aber sie darf nicht unsere Sicherheitsregeln umschreiben. Ein GitHub-Text darf Installationsschritte beschreiben, aber er erhält dadurch keine Ausführungserlaubnis. Und ein Anhang bleibt potenziell riskant, auch wenn sein Dateiname harmlos klingt.

Die Stahltür beginnt also nicht erst beim Installationsbefehl. Sie beginnt bei der Frage, wem wir überhaupt erlauben, Anweisungen zu geben.

Härtung ist keine Dauerpanik

Zu einer verantwortlichen Sicherheitskultur gehört auch der Gegenpunkt: Nicht jede denkbare Gefahr wird tatsächlich eintreten. Ein kurzer Social-Media-Clip behauptet sogar, ein Experiment beweise, dass „99 Prozent unserer Sorgen niemals eintreffen“. Zu sehen sind viele herabfallende Bälle, von denen nur wenige ein Gefäß treffen. Das ist ein einprägsames Bild – aber kein wissenschaftlicher Beweis. Der Clip nennt weder Studie noch Stichprobe, Methode oder überprüfbare Quelle.

Gerade darin steckt eine doppelte Lehre. Wir dürfen ein spektakuläres Bild nicht mit belastbaren Daten verwechseln. Gleichzeitig müssen wir auch nicht vor jedem Ball davonlaufen. Gute Härtung unterscheidet zwischen bloß denkbaren Möglichkeiten und realistischen Risiken. Sie schützt die wichtigen Ziele, begrenzt Schäden und schafft einen Rückweg, ohne Menschen in permanente Angst zu versetzen.

Unsere Stahltür ist deshalb kein Ausdruck von Panik. Sie ist eine nüchterne Entscheidung: Kritische Daten und Schlüssel werden stark geschützt; harmlose Experimente dürfen in einer isolierten Umgebung stattfinden. Sicherheit soll Ruhe schaffen – nicht neue Unruhe.

Fallstudie RuFlo: große Versprechen, konkreter Fehler

Wir haben RuFlo isoliert geprüft, statt die angebotene Ein-Zeilen-Installation auf das laufende System loszulassen. Das Projekt verspricht Agentenschwärme, Gedächtnis, MCP, lokale Modelle, Autopilot, Daemons und eine große Pluginlandschaft.

Unser isolierter Test deaktivierte bewusst Installationsskripte, damit keine ungeprüften Lifecycle-Aktionen ausgeführt werden konnten. Unter genau diesen restriktiven Bedingungen fehlte die native SQLite-Bindung. Der lokale Memory-Baustein warnte deshalb selbst, dass die dauerhafte Speicherung möglicherweise nicht gewährleistet sei; die unmittelbar folgende Suche fand den eben gespeicherten Testeintrag nicht. Zusätzlich entstanden mehrere Konfigurations- und Datenbankdateien außerhalb des ausdrücklich gesetzten Testpfads.

Das beweist nicht, dass RuFlo grundsätzlich kein funktionierendes Gedächtnis besitzt. Es beweist aber, dass der Baustein unter unseren sicheren Installationsbedingungen nicht zuverlässig genug funktionierte. Damit war die Entscheidung klar: kein Autopilot, kein Daemon und keine Integration in Crow. Ein Gedächtnis, das in unserem Prüfweg nicht zuverlässig erinnert, ist für unser System kein Fortschritt.

Fallstudie Agent-Reach: sicherer Prüfmodus, aber Cookie-Falle

Agent-Reach verfolgt einen nachvollziehbaren Ansatz: Ein Agent soll Webseiten, RSS, GitHub, YouTube und soziale Netzwerke erreichen können. Der sichere Prüfmodus hielt in unserem Test tatsächlich seine Schreibgrenzen ein. RSS funktionierte ebenfalls.

Der entscheidende YouTube-Test scheiterte jedoch an der Bot-Prüfung des Plattformbetreibers. Der Zugriff verlangte eine Anmeldung beziehungsweise Cookies. Genau dort endet für uns der Nutzen. Browser-Cookies sind keine harmlosen Textschnipsel, sondern häufig vollständige Sitzungsschlüssel. Wer sie einem Tool übergibt, übergibt im schlimmsten Fall sein Konto.

Öffentliche Webseiten und GitHub konnten wir bereits mit vorhandenen Werkzeugen prüfen. Für einen kleinen Zusatznutzen eine neue Cookie- und Toolkette einzuführen, wäre schlechte Sicherheitspolitik gewesen. Also wurde auch diese Testinstallation wieder entfernt.

Fallstudie Comp AI CRM: die Ideen behalten, den Unterbau weglassen

Das offene Comp AI CRM enthält starke Grundsätze. Personenbezogene Angaben sollen nicht geraten werden. Beobachtungen erhalten einen Belegstatus. Wiedervorlagen brauchen einen konkreten Grund. Unsichere Zuordnungen werden einem Menschen vorgelegt.

Der technische Unterbau wäre für unseren Bedarf jedoch überdimensioniert: Docker, PostgreSQL, dauerhafte Agentenprozesse sowie eine starke Ausrichtung auf Google, Microsoft, Vercel und weitere externe Dienste.

Deshalb haben wir nicht das komplette CRM installiert. Wir haben die guten Regeln in unsere bestehende Sekretärsrolle übernommen:

• personenbezogene Angaben niemals erraten;
• Quellen als belegt, Hinweis oder offen kennzeichnen;
• Korrekturen nachvollziehbar dokumentieren;
• Wiedervorlagen begründen;
• bei Fälligkeit den Sachstand erneut prüfen;
• keine externe Nachricht allein wegen eines Termins automatisch versenden.

Das ist digitale Souveränität in der Praxis: die brauchbare Idee übernehmen, ohne sich den unnötigen Unterbau ans Bein zu binden.

Unser Härtungsweg: erst prüfen, dann entscheiden

Bevor eine neue Erweiterung dauerhaft auf ein Agentensystem kommt, sollte sie mindestens diese Prüfung bestehen:

1. Bedarf benennen: Welche konkrete Fähigkeit fehlt wirklich?
2. Quelle prüfen: Wer entwickelt das Projekt, wie aktiv ist es und welche Lizenz gilt?
3. Rechte prüfen: Braucht es Shell, Root, Cookies, Tokens, Browserprofile oder Zugriff auf private Daten?
4. Datenwege prüfen: Welche externen Dienste, Modellanbieter oder Telemetrie-Endpunkte werden verwendet?
5. Isoliert testen: Niemals zuerst auf dem laufenden Produktivsystem.
6. Fehlerfall provozieren: Speichert das Gedächtnis wirklich? Bleiben Schreibgrenzen erhalten? Was passiert ohne Netzwerk oder Schlüssel?
7. Rückweg vorbereiten: Vorher Backup und Wiederherstellung prüfen; Version und Herkunft festhalten.
8. Minimal übernehmen: Nur die tatsächlich benötigte Fähigkeit aktivieren.
9. Geheimnisse widerrufen können: Tokens, Cookies und Schlüssel müssen gezielt entzogen und ersetzt werden können.
10. Verifizieren und dokumentieren: Was wurde geändert, wie wird es vollständig entfernt und woran erkennt man einen Fehler?

Wenn ein Projekt diese Fragen nicht sauber beantwortet, kommt es nicht auf das System. Nicht heute, nicht aus Neugier und schon gar nicht wegen eines begeisterten Beitrags auf X, Instagram, Facebook oder YouTube.

Langsam ernährt sich das Eichhörnchen

Im KI-Markt gilt derzeit häufig das Gegenteil: möglichst viele Agenten, möglichst viele Tools, möglichst viele automatische Entscheidungen. Doch viele Köche verderben den Brei – besonders dann, wenn jeder Koch eigene Schlüssel, Datenleitungen und Hintergrundprozesse mitbringt.

Wir gehen bewusst langsamer. Wir prüfen, lernen, dokumentieren und härten. Was uns nachweislich weiterbringt, darf bleiben. Was nur beeindruckend klingt, fliegt wieder raus.

Unser Ziel ist kein digitaler Gemischtwarenladen. Unser Ziel ist ein verlässlicher Assistent mit klarer Rolle, begrenzten Fähigkeiten und sicheren Workflows. Ein System, das lange nutzbar bleibt, weil es nicht jedem Trend seine Türen öffnet.

Dabei ist es gleichgültig, woher der Druck kommt: aus der Politik, von einem Konzern, aus einem sozialen Netzwerk oder von Entwicklern, die sich ohne erkennbare Grenzen die nächste „Monster-KI“ zusammenbauen. Herkunft und Selbstbeschreibung ersetzen keine Prüfung. Niemand erhält Zutritt, nur weil er Sicherheit verspricht, „Open Source“ auf die Verpackung schreibt oder gerade besonders laut Reichweite erzeugt.

Im Zweifel kommt die sprichwörtliche Stahlplatte vor die Tür. Nicht aus Technikfeindlichkeit, sondern weil ein verweigerter Zugang leichter zu korrigieren ist als ein abgeflossenes Postfach, ein gestohlener Sitzungsschlüssel oder ein kompromittierter Server. Wir bauen lieber langsam an unserem eigenen Fort Knox, als fremden Automatismen vorschnell den Generalschlüssel zu geben.

Alles muss für unseren konkreten Zweck sicher, kontrollierbar und wieder entfernbar sein. Alles andere ist kalter Kaffee. Und kalter Kaffee kommt bei Darknight-Coffee nicht in die Kanne.

Oder mit einem alten Handwerkersatz: Schuster, bleib bei deinem Leisten. Ein Agent bleibt bei seiner klaren Rolle. Eine neue Fähigkeit kommt erst dazu, wenn Bedarf, Sicherheit und Rückweg geklärt sind.

Der Satz zum Mitnehmen lautet:

Installiere keine Plattform, wenn du nur eine Fähigkeit brauchst.

Diskussion: https://treff.darknight-coffee.eu

Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Quellen und Transparenz

• RuFlo: https://github.com/ruvnet/ruflo
• Agent-Reach: https://github.com/Panniantong/Agent-Reach
• Comp AI CRM: https://github.com/trycompai/crm

Die beschriebenen technischen Befunde stammen aus isolierten Prüfungen vom 26.08.2026. Sie sind Momentaufnahmen der damals getesteten Versionen und keine Behauptung, dass spätere Ausgaben dieselben Eigenschaften besitzen. Interne Adressen, Zugangsdaten und sensible Betriebsdetails wurden bewusst nicht übernommen.

Der erwähnte Social-Media-Clip wurde nur als redaktionelles Anschauungsmaterial geprüft. Da er keine überprüfbare Quelle für die eingeblendete 99-Prozent-Behauptung nennt, wird diese Zahl nicht als Tatsache übernommen; das Video selbst wird nicht veröffentlicht oder eingebettet.