KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „Agenten“

  • macOS Full Disk Access: Apple verschärft die Freigabe und nennt KI-Agenten als Risiko

    macOS Full Disk Access: Apple verschärft die Freigabe und nennt KI-Agenten als Risiko

    „We will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action.“ So formuliert Apple in seinem Developer-News-Beitrag vom 2. Oktober 2026 die geplante Verschärfung von macOS Full Disk Access. Neu ist vor allem die Begründung. Apple schreibt zunächst, manche Entwickler nutzten Full Disk Access so, dass Nutzer ohne ihr volles Wissen alles auf ihrem System offenlegen – Dateien, Mail, Nachrichten, sogar den Browserverlauf. Dann folgt der Satz, der die Ankündigung besonders macht: Mit zunehmender Leistungsfähigkeit und Autonomie von KI-Agenten würden die Risiken dieser Zugriffsstufe erheblich wachsen. Das Portal Forkast wertet das als ersten Fall, in dem ein großer Betriebssystemhersteller seine zentralen Zugriffsrechte ausdrücklich wegen KI-Agenten ändert – nicht wegen Malware und nicht wegen staatlich finanzierter Angreifer. Die Ankündigung verschiebt eine Grenze, die bisher niemand gezogen hat – weder Apple, noch Microsoft, noch die Linux-Welt.

    Was Full Disk Access so mächtig macht

    Die Berechtigung wurde ursprünglich für Backup-Werkzeuge wie SuperDuper oder Carbon Copy Cloner geschaffen, die das gesamte Laufwerk lesen müssen, um es kopieren zu können. Sie umgeht Apples TCC-System, jene Ebene, die normalerweise jede App einzeln fragt, ob sie auf Kamera, Mikrofon, Fotos oder andere sensible Ressourcen zugreifen darf.

    TCC lässt sich wie eine Grenzkontrolle mit vielen einzelnen Schranken vorstellen. Jede Ressource hat ihren eigenen Schlagbaum: Wer die Kamera nutzen will, braucht die Kamera-Schranke, wer Fotos lesen will, die Foto-Schranke, wer das Mikrofon ansprechen will, die Mikrofon-Schranke. Full Disk Access ist kein weiterer Schlagbaum, sondern ein Pass, der sämtliche Schranken gleichzeitig öffnet. Wer ihn hält, kommt an Mail, Messages, den Safari-Verlauf, Kontakte, Fotos und die Time-Machine-Backups. Für ein Backup-Werkzeug ist das die Arbeitsbeschreibung. Für einen dauerhaft laufenden KI-Agenten heißt es Zugriff auf fast alles, was auf dem Rechner liegt.

    Zwei Vorfälle und das strukturelle Problem dahinter

    Die Ankündigung fällt nicht in einen luftleeren Raum. Im September berichtete der Inc.-Kolumnist Jason Aten, Metas KI-Agent Muse habe seine privaten Nachrichten gelesen, ohne dass er bewusst eine Berechtigung erteilt habe. Meta widersprach dieser Darstellung und verwies darauf, dass drei ausdrückliche Nutzerhandlungen nötig seien: das Aktivieren von Full Disk Access, das Einschalten des Messages-Konnektors innerhalb der App und eine Bestätigung in einem macOS-Systemdialog.

    Unabhängig davon beschrieb Wired eine Schwachstelle in der ChatGPT-App für den Mac, die die Objective-See Foundation entdeckt hatte und die am 25. September geschlossen wurde. Angreifer hätten über eine als vertrauenswürdig eingestufte Skript-Komponente an Chat-Protokolle und Browsersitzungen gelangen können. Die beiden Fälle sind unterschiedlich gelagert – der eine dreht sich um eine Berechtigungsfrage, der andere um eine technische Lücke –, doch sie treffen sich an derselben Stelle: bei der Frage, welcher Code im Namen des Nutzers handeln darf.

    Der Objective-See-Forscher Patrick Wardle verglich Agenten mit einem Hausverwalter, der die Schlüssel zu allen Räumen besitzt. Sie bräuchten viel Zugriff, um ihre Aufgabe zu erfüllen. Könne dieser Verwalter korrumpiert oder unterwandert werden, sei das ein Problem – im schlimmsten Fall erlange nicht privilegierter Code Zugriff auf alles.

    Die betroffenen Anwendungen sind keine Randerscheinungen. Metas Muse, OpenAIs Dots, die ChatGPT-App für den Mac, Claude für Mac, OpenClaw und Hermes Agent fordern Full Disk Access regelmäßig an, um ihre Desktop-Funktionen überhaupt anbieten zu können. Das ist kein Missbrauch, sondern eine Folge des Designs. Ein Agent, der Kalender, Mail und Dateien koordinieren soll, braucht Blick auf genau diese Dinge – und überschreitet damit eine Grenze, die für klassische Anwendungen selbstverständlich war.

    Warum Apple auf ausdrückliche Zustimmung setzt statt auf ein Verbot

    Apple verbietet Full Disk Access nicht und entwirft auch kein neues Berechtigungsmodell für Agenten. Stattdessen baut der Konzern den Zustimmungsweg um: Wer einem Programm diese Zugriffstiefe geben will, soll das nur noch über eine sehr ausdrückliche Nutzerhandlung können. Nutzer sollen die Risiken verstehen, bevor sie diesen Zugriff erteilen, und informiert über ihre Daten entscheiden können.

    Das lässt sich als Nachrüstung bezeichnen. Ein altes, grob geschnittenes Recht bekommt ein strengeres Zeremoniell, ohne dass sich seine technische Form ändert. Ob das genügt, ist eine andere Frage. Ein Bestätigungsdialog erklärt dem Nutzer, dass er gerade sehr viel Zugriff vergibt. Er beantwortet aber nicht, ob ein Agent tatsächlich alles braucht, was er anfordert.

    Es ist ein Zustimmungswechsel, keine technische Sperre. Apple verschiebt nicht die Fähigkeiten von Programmen, sondern die Hürde, an diese Fähigkeiten zu gelangen.

    Die Lücke zwischen Ankündigung und Auslieferung

    Apple hat weder die macOS-Version genannt, in der die neuen Kontrollen erscheinen, noch einen Zeitrahmen. In dieser Lücke müssen Entwickler entscheiden, wie sie mit der Ankündigung umgehen. Die pragmatische Frage lautet: Fordern wir weiterhin Full Disk Access an, weil es bequem ist, oder zerlegen wir den Zugriff in kleinere Teile, die sich einzeln begründen und einzeln verweigern lassen?

    Ein Agent, der nur Mail lesen soll, braucht keinen Blick auf die Time-Machine-Historie. In der Praxis kostet diese Aufteilung Arbeit, und sie kollidiert mit einem Berechtigungsmodell, das nur Alles oder Nichts kennt. Full Disk Access wurde für Werkzeuge entworfen, die das Ganze brauchen. Agenten brauchen vieles, aber selten alles gleichzeitig.

    Windows und Linux haben bisher kein Gegenstück

    Windows regelt Rechteerhöhung über UAC und schränkt Store-Anwendungen über AppContainer ein, doch klassische Win32-Programme laufen standardmäßig mit dem vollständigen Token des angemeldeten Nutzers. Linux kennt AppArmor, SELinux und die Portale von Flatpak, aber die meisten Desktop-Distributionen erzwingen keinen einheitlichen Vermittler für Berechtigungen. Kein großes Betriebssystem liefert derzeit ein eigenes, zweckgebautes Berechtigungsmodell für autonome Agenten.

    Die Sicherheitsschichten, die derzeit in Unternehmen entstehen, liegen auf einer anderen Ebene. Ein Gateway steuert, welche APIs ein Agent aufruft. Sandbox-Lösungen wie Kubernetes Agent Sandbox isolieren Agenten-Workloads in Containern. Identitätsbasierte Zugriffsvermittler regeln, wer worauf zugreifen darf. All diese Schichten sind real und im Einsatz – aber sie arbeiten oberhalb des Betriebssystems. Apples Eingriff sitzt darunter, an der Stelle, an der das System selbst entscheidet, was ein Programm erreichen darf.

    Was das konkret bedeutet

    Für dich als Nutzer verschiebt sich zunächst wenig, solange die Kontrollen nicht ausgeliefert sind. Danach fällt die Entscheidung in dem Moment, in dem ein Dialog erscheint. Bisher war das eine Formalität, die man wegklickt. Künftig ist es die Stelle, an der beantwortet wird, wer im Namen des Nutzers handeln darf. Wer Full Disk Access vergibt, übergibt nicht eine Datei, sondern den Schlüssel zu allem, was auf dem Rechner liegt.

    Für Entwickler wird der bequeme Weg teurer: einmal um eine weitreichende Berechtigung bitten und danach in Ruhe arbeiten, wird künftig eine sehr ausdrückliche Zustimmung des Nutzers brauchen. Das ist kein Verbot, und es wäre ein Fehler, die Ankündigung als harte technische Sperre zu lesen. Es zeigt, dass die Alles-oder-Nichts-Frage bei Full Disk Access nicht mehr automatisch mit Ja beantwortet wird.

    Für die Branche ist es ein frühes Zeichen dafür, dass ein Hersteller die Existenz autonomer Agenten als Betriebssystemproblem behandelt und nicht als Frage der App-Gestaltung. Ob daraus ein Modell wird, das sich auf Windows und Linux übertragen lässt, ist offen. Ebenso offen ist, ob eine zusätzliche Bestätigung wirklich mehr Sicherheit schafft oder nur mehr Bewusstsein. Wer heute schon mit Agenten arbeitet, sollte prüfen, welcher seiner Werkzeuge welchen Zugriff wirklich benötigt. Die Antwort fällt meist kleiner aus, als die Standardeinstellung vermuten lässt.

    Quelle: forkast.news

  • Warum KI-Agenten Dokumentation statt Gedächtnis brauchen

    Warum KI-Agenten Dokumentation statt Gedächtnis brauchen

    Ein Memory-Plugin liest die Protokolle vergangener Sitzungen, zerlegt sie in rund tausend kleine Ausschnitte und legt diese als Vektoren in einer Datenbank ab. Bei jedem neuen Prompt zieht es die fünf ähnlichsten Ausschnitte zurück, hängt sie an den Kontext und hofft, dass die entscheidenden darunter sind. Zerlegt man diese Kette, bleibt kein Gedächtnis übrig, sondern ein Losverfahren mit anschließender Nachsuche, dessen Trefferquote niemand garantieren kann. Der Entwickler Kevin Liao, der seit über einem Jahr mit KI programmiert und dafür ein eigenes Werkzeug gebaut hat, formuliert daraus einen harten Vorwurf: Die Memory-Plugins lösen das falsche Problem.

    Seine Antwort lautet: Agenten brauchen kein Gedächtnis, sie brauchen Dokumentation. Das klingt zunächst nach Wortklauberei, denn beides dient demselben Ziel – der Agent soll wissen, woran er arbeitet. Zwischen den beiden Wegen liegt jedoch ein Unterschied, der die gesamte Architektur eines Werkzeugs verändert, nicht nur seine Feinabstimmung. Wer das für Spitzfindigkeit hält, sollte sich ansehen, wie Memory-Plugins konkret arbeiten und woran sie scheitern. Die entscheidende Frage ist nicht, ob ein Agent sich erinnert, sondern ob er nachschlagen kann.

    Fast alle Memory-Plugins arbeiten nach demselben Muster

    Die Architektur ist auffällig gleichförmig: Transkripte durchgehen, daraus Erinnerungen in Snippetform erzeugen, diese in eine RAG-Vektordatenbank schreiben, bei jedem Prompt die fünf ähnlichsten Treffer einblenden und dem Agenten zusätzlich ein Suchwerkzeug auf dieselbe Datenbank in die Hand geben. Alles Weitere ist Verzierung. Manche Systeme trennen Kurz- und Langzeitgedächtnis, andere lassen Hintergrundprozesse Erinnerungen zusammenführen oder über Nacht neu schreiben, wieder andere schieben einen Reranker zwischen Suche und Ausgabe. Jede dieser Funktionen kostet Tokens und Rechenzeit, ohne die Grundannahme zu berühren, dass Wissen aus der Vergangenheit rekonstruiert werden muss.

    Als Bild hilft ein Aktenschrank, in dessen Fächer jemand einen Stapel loser Zettel geworfen hat. Bei jeder Frage werden fünf Zettel herausgezogen, und wenn der Agent ratlos wirkt, darf er selbst weiterwühlen. Was dabei entsteht, ist kein geordnetes Wissen, sondern eine Momentaufnahme, die von der Formulierung des Prompts abhängt. Deshalb arbeiten diese Systeme unzuverlässig, egal wie viel Aufwand in die Zusatzfunktionen fließt.

    Ähnlichkeit ist kein Maß für Richtigkeit

    Alle Varianten beantworten letztlich eine einzige Frage: Wie nah liegen zwei Textausschnitte im Vektorraum beieinander? Das sagt nichts darüber, welcher Stand korrekt oder aktuell ist, und erst recht nichts über das, was fehlt. Ein Ausschnitt ist zudem zu klein, um Kontext, Motivation, Umgebung und die Lehren aus einem gescheiterten Versuch mitzutragen. Dazu kommt die stillschweigende Annahme, dass die Vergangenheit die Wahrheit sei. In einer Codebasis, die sich täglich ändert, ist das eine riskante Grundlage: Wie viele der fünfhundert Ausschnitte zur Authentifizierung sind heute noch gültig?

    Ein zweites Problem liegt im Suchen selbst. Selbst wenn der Agent ein Suchwerkzeug bekommt, weiß er nicht, wann er es benutzen soll, denn er weiß nicht, was er nicht weiß. Er kann nicht nach einer Entscheidung suchen, von deren Existenz er nichts ahnt. Hinzu kommt, dass solche Speicher kaum prüfbar sind. Zehntausend Embeddings in einer SQLite-Datei beantworten keine der Fragen, die ein Team stellen müsste: Welche Erinnerungen gibt es überhaupt, welche sind veraltet, welche wurden nie abgerufen, und welche verzerren still die Arbeit des Agenten?

    Auffällig ist, dass niemand außerhalb der KI-Welt so mit Wissen umgeht. Kein Team sieht sich ein Meeting von vor drei Jahren erneut an, um die Rahmenbedingungen eines Features zu rekonstruieren. Menschen schreiben Dinge auf und arbeiten danach mit diesen Aufzeichnungen. Der Vorschlag lautet deshalb, den Speicher nicht als Datenbank an den Agenten zu schrauben, sondern als Arbeitsbereich, den man lesen, ändern und teilen kann.

    AGENTS.md war ein Anfang, eine Datei reicht aber nicht

    Dass Agenten Kontext brauchen, war früh klar, deshalb entstanden AGENTS.md-Dateien, damit ein Agent nicht blind in eine fremde Codebasis springt. Das funktioniert. In vielen Projekten ist diese eine Datei aber die einzige Dokumentation, die überhaupt existiert. Sie kann die Anforderungen eines echten Projekts nicht tragen: Wie der Codereview abläuft, was mit dem Auftraggeber besprochen wurde, welche Bibliothek warum verworfen wurde, welche Entscheidung gilt und welche überholt ist.

    Was Liao stattdessen beschreibt, ist ein strukturierter Arbeitsbereich – Markdown-Dateien, in die der Agent ohne Aufforderung schreibt: Anweisungen für Prozesse, Spezifikationen aus Gesprächen, wiederverwendbare Recherche zu fremden APIs, Register, die den Einstieg erleichtern. Vor der Arbeit liest der Agent die passenden Dokumente und sieht den Zusammenhang statt eines Flickenteppichs. Nach der Arbeit aktualisiert er, was überholt ist, und legt neue Dokumente an, solange das Gesamtbild noch in seinem Kontext liegt.

    Der Arbeitszyklus verschiebt sich: erst nachschlagen, dann bauen

    Damit ändert sich der Ablauf: Aus prompt, bauen, vergessen wird prompt, nachschlagen, bauen, aktualisieren. Das Gedächtnis ist nicht mehr eine Datenbank, die man an den Agenten anschraubt, sondern ein Arbeitsmittel, das im Projekt selbst liegt. Weil alles einfache Textdateien sind, lässt sich der Wissensstand versionieren, in einem Commit nachvollziehen und im Team teilen. Der Zettelstapel bekommt Register und Beschriftungen, und jeder darf hineinschreiben.

    Der wichtigere Gewinn ist nicht Geschwindigkeit, sondern Prüfbarkeit. Einen falschen Satz in einer Markdown-Datei findet und korrigiert man in einer Minute. Ein falsch gewichtetes Embedding bleibt unsichtbar und wirkt trotzdem auf jede Antwort. Wer schon einmal versucht hat, einer Vektordatenbank eine falsche Erinnerung auszutreiben, kennt den Unterschied zwischen einem Fehler, den man sieht, und einem, den man nur vermutet.

    Aus einem internal-Ordner wurde das Plugin Operator Memory

    Liao beschreibt, wie er vor über einem Jahr beim Programmieren mit KI anfing und einen Weg suchte, Arbeit über Sitzungen hinweg zu erhalten. Er legte zunächst einen Ordner namens internal an, in den der Agent alles schreiben sollte: Spezifikationen, Pläne, Indizes. Dazu die Anweisung, vor der Arbeit die passenden Dokumente zu lesen und sie danach zu aktualisieren. Aus diesen Regeln wurde mit der Zeit ein Plugin namens Operator Memory, das er in allen seinen Projekten einsetzt. Der Essay ist damit auch Werbung in eigener Sache: Die Kritik an den Memory-Plugins mündet in Liaos eigenes Werkzeug.

    Technisch ist der Ansatz bewusst unspektakulär. Keine Vektordatenbank, keine Embeddings, keine Zusammenfasser, Kuratoren oder nächtlichen Hintergrundprozesse, keine Blackbox-Suche. Alles ist ein Markdown-Dokument, das man lesen, ändern, committen und mit dem Team teilen kann. Das Werkzeug ist kostenlos und quelloffen unter github.com/aerovato/operator-memory verfügbar.

    Was das im Alltag bedeutet

    Der Vorschlag klingt selbstverständlich und verlangt trotzdem Disziplin. Dokumente müssen gepflegt werden, und ein Agent, der selbst schreibt, produziert auch Unsinn, den ein Mensch lesen und aussortieren muss. Wer diese Disziplin nicht aufbringt, tauscht ein sichtbares Problem gegen ein unsichtbares. Für kurze Unterhaltungen mit einem Chatmodell braucht es all das nicht; dort reicht der Kontext der laufenden Sitzung.

    Wo Agenten aber über Wochen an einem Projekt arbeiten, verschiebt sich die Frage. Es geht dann nicht mehr darum, ob Dokumentation wichtiger ist als Erinnerung, sondern darum, wie viel Pflege ein Team investieren will. Ein Stapel loser Zettel, aus dem fünf zufällige gezogen werden, oder ein Register, in dem nachlesbar steht, was gilt – die Wahl ist nicht schwer. Wer KI-Agenten dauerhaft einsetzt, sollte ihnen ein Archiv geben, in das sie hineinschreiben dürfen, statt ein Gedächtnis.

    Quelle: liao.gg

  • Wie KI-Agenten die API-Architektur verändern: Identität, Governance und Design unter neuen Vorzeichen

    Wie KI-Agenten die API-Architektur verändern: Identität, Governance und Design unter neuen Vorzeichen

    „APIs sind die natürliche Brücke, die agentische KI überhaupt erst handlungsfähig macht.“ So beschreibt Bill Doerrfeld in einem Beitrag für CIO die Rolle der Schnittstellen. Der Satz klingt einleuchtend. Für gewachsene Schnittstellenlandschaften ist er trotzdem ein Problem – denn die meisten wurden für Menschen entworfen, nicht für Software, die Ziele interpretiert und im Sekundentakt Entscheidungen trifft.

    Die Zahlen aus Postmans State-of-the-API-Report stützen diese Spannung. 89 Prozent der Befragten nutzen generative KI-Werkzeuge im Arbeitsalltag. 60 Prozent entwerfen ihre API-Produkte aber weiterhin ausschließlich für menschliche Nutzung. Gleichzeitig äußern 50 Prozent Sorge über unautorisierte oder übermäßige API-Aufrufe, über Zugriff auf sensible Daten und über geleakte Credentials.

    Am besten lässt sich das mit einem Straßennetz vergleichen. Wenn du heute eine API planst, baust du im Grunde eine Straße mit Fahrspuren, Schildern und Ampeln. Diese Infrastruktur wurde für Wesen entworfen, die Kontext verstehen: Sie lesen ein Schild und wissen, warum es dort steht. Agenten lesen dasselbe Schild und befolgen es, ohne den Grund zu kennen. Oder sie ignorieren es, wenn die Karte eine Abkürzung kennt. Genau diese Verschiebung spielt sich gerade in der API-Architektur ab.

    Warum Agenten ein grundlegend anderer Konsumententyp sind

    Der Übergang von der Chatbot-Ära zur agentischen Ära ist noch jung. Für aktive Nutzer von KI-Werkzeugen begann er spürbar erst in den letzten ein bis zwei Jahren, mit Systemen wie OpenAI Operator, Codex oder Cowork. Der Unterschied ist nicht graduell: Ein Chatbot antwortet, ein Agent handelt. Er interpretiert ein Ziel, sucht sich Werkzeuge, trifft Entscheidungen und verkettet Aufrufe zu Abläufen, die für menschliche Beobachter oft schwer nachvollziehbar sind.

    Damit wird Software zu einem Konsumenten, der nicht mehr nur analysiert und empfiehlt, sondern ausführt. Über API-Integrationen koordiniert er Aktionen über mehrere Systeme hinweg und baut Workflows, die niemand explizit so programmiert hat. Art Anthony, der den zugrunde liegenden Beitrag für Nordic APIs geschrieben hat, formuliert es als unangenehme Wahrheit: Die meisten API-Ökosysteme wurden für menschliche Nutzer gebaut, nicht für autonome Agenten, die in hoher Frequenz arbeiten.

    Ein Forschungspapier der When2Tool-Macher liefert dazu einen konkreten Hinweis. Die Autoren konnten die Zahl der API-Aufrufe agentischer Werkzeuge um 20 bis 56 Prozent senken, ohne dass die Genauigkeit litt. Das legt nahe, dass Agenten APIs eher zu viel als zu wenig aufrufen. Bei kostenpflichtigen Schnittstellen ist das keine theoretische Frage, sondern eine Rechnung. Anthony zieht dafür den Vergleich zu Indiana Jones auf der Suche nach dem echten Gral: Agenten müssen lernen, klug zu wählen.

    Identität und Autorisierung: Agenten passen in kein klassisches Rollenmodell

    Die zentrale Schwierigkeit liegt in der Identität. Ein Agent handelt selten für sich selbst, sondern für einen Menschen, eine Organisation oder ein anderes Stück Software. Wer also handelt eigentlich, wenn ein Aufruf eintrifft? Die traditionellen Modelle, die auf Personen und Rollen aufbauen, greifen hier zu kurz – eine Lücke, an der sich bereits eigene Start-ups wie Oak versuchen. Wer es sich einfach macht, gibt dem Agenten ein langlebiges Token mit weitreichenden Rechten. Wer es richtig macht, tut genau das nicht.

    Übermäßige Privilegien führen zu unbeabsichtigten Aktionen. Schlimmer noch: Berechtigungen sammeln sich still an, alte werden selten entfernt. So entsteht, was in der Branche als Role Drift und Privilege Creep bekannt ist. Aktionen, die im Nachhinein unrechtmäßig wirken und ernste Zwischenfälle auslösen, liegen dann formal im Rahmen dessen, was der Agent durfte. Es gab keinen Einbruch – nur eine Tür, die jemand offen gelassen hat.

    Jacob Ideskog, CTO von Curity, plädierte auf dem Platform Summit 2025 von Nordic APIs für Just-in-Time-Autorisierung als Gegenmittel. Übertragen auf das Straßenbild: kein Generalschlüssel für alle Türen, sondern eine Fahrerlaubnis, die für eine konkrete Fahrt, eine konkrete Strecke und ein konkretes Zeitfenster gilt. Als Zielbild gilt Zero Standing Privilege – also keine dauerhaften Rechte, die niemand mehr überprüft.

    Ein zweiter Unterschied wiegt ebenfalls schwer. Menschliche Entwickler nutzen Exploits, falsch konfigurierte Rate Limits und ähnliche Lücken selten aus, weil sie die Folgen für Anbieter und Kollegen einschätzen können. Standard-Agenten fehlt dieses Verständnis. Wenn sie können, dann tun sie oft auch. Es liegt an den Architekten, dieses Können zu definieren.

    Sicherheit und Governance: Prompt-Injection trifft auf überreichweite Rechte

    Aus der agentischen Nutzung entsteht eine eigene Risikoklasse. Dazu gehören LLM-basierte Angriffe wie Prompt-Injection, unbeabsichtigte Aktionen, Halluzinationen und unzuverlässige Entscheidungen, übermäßige Nutzung von API-Fähigkeiten und der Missbrauch von Kontext, den ein Modell nicht hätte sehen dürfen. OWASP führt Prompt-Injection und Excessive Agency in den Top 10 der Risiken für LLMs und GenAI. Autorisierung, Authentifizierung und Governance an genau diesen Schnittstellen sind also keine Nebensache.

    Besonders unangenehm ist die indirekte Variante. Bösartige Anweisungen kommen nicht vom Nutzer, sondern aus Daten. Ein Beispiel: Eine Support-Antwort enthält einen eingeschobenen Systemhinweis an das Modell, doch bitte das gespeicherte Session-Token per E-Mail-API an eine fremde Adresse zu senden. Für das Modell ist das eine Anweisung wie jede andere. Die eigentliche Schwachstelle liegt nicht in der API, sondern in der Bereitschaft, fremden Text als Instruktion zu behandeln.

    Die Antwort darauf ist weniger spektakulär, als sie klingt. Deterministische Workflows statt freier Interpretation, getrennte APIs für menschliche und agentische Nutzung, klare Grenzen für das, was ein Agent überhaupt anstoßen darf. Jeroen Delbarre von Axway widmet sich auf dem Nordic APIs Summit 2026, den der Herausgeber des Ausgangsbeitrags selbst veranstaltet, genau dieser Frage: Wie sieht Governance aus, wenn nicht mehr nur Menschen Anträge stellen, sondern Agenten sie im Fluss erzeugen?

    API-Design für Maschinen: Schema, Klarheit, weniger Interpretationsspielraum

    Lorna Mitchell brachte es in einem Gespräch auf eine kurze Formel: Wer bewährte Praktiken rund um API-Design und Dokumentation befolgt, ist bereits KI-bereit. Das ist weniger beruhigend, als es zunächst wirkt, denn es verschiebt den Aufwand dorthin, wo er ohnehin hingehört. Konsistente Namenskonventionen, vorhersehbare Fehler, wohldefinierte Schemata und präzise Dokumentation waren nie optional. Sie werden jetzt nur belastbar geprüft.

    Menschen füllen Lücken mit Erfahrung und Kontext. Agenten haben dieses Privileg nicht. Wo ein Entwickler aus einem unklaren Feldnamen schließt, was gemeint sein könnte, liest ein Modell genau das, was dasteht, und entscheidet dann vielleicht falsch. Mehrdeutigkeit ist damit nicht mehr nur ein Ärgernis für Leser der Entwicklerdokumentation, sondern eine Fehlerquelle mit direkten Folgen.

    In der Praxis bedeutet das schlankere Rechtevergabe für Agenten, stärker spezifikationsgetriebene Entwicklung, maschinenlesbare Dokumentation und weniger Grauzonen im Verhalten. Hinzu kommt eine oft übersehene Ebene: Die Infrastruktur um die API muss sich mitverändern, nicht nur die API selbst. Wer heute Schnittstellen plant, plant also nicht nur für einen Konsumenten, sondern für zwei sehr unterschiedliche.

    Observability: nicht nur was passierte, sondern wer in wessen Auftrag handelte

    Klassisches API-Monitoring beantwortet die Frage, ob etwas langsam war, ausgefallen ist oder Fehler geworfen hat. Bei agentischer Nutzung reicht das nicht. Die entscheidende Information lautet jetzt: Welcher Agent hat die Anfrage gestellt, in wessen Auftrag, und war sie Teil einer Kette von Aufrufen? Ohne diese Einordnung bleibt jedes Logfile eine Liste von Ereignissen ohne Verantwortlichen.

    Agenten-Stacks liefern die passenden Daten, wenn man sie abfragt. Erweiterungen von OpenTelemetry greifen diese veränderten Konsummuster auf: Agent-Identifikatoren, Conversation IDs, Angaben zur Token-Nutzung. Im Bild des Straßenverkehrs ist das kein Radargerät, sondern ein Nummernschild samt Fahrtenbuch. Du weißt nicht nur, dass ein Fahrzeug zu schnell war, sondern auch, wer es geschickt hat und wohin die Fahrt ging. Andere Frameworks und Werkzeuge werden mit hoher Wahrscheinlichkeit nachziehen.

    Der Aufwand dafür ist real, aber begrenzt. Es geht nicht darum, bestehende Monitoring-Pipelines zu ersetzen, sondern sie um Identitäts- und Auftragskontext zu erweitern. Wer diese Erweiterung früh einplant, spart sich später die mühsame Rekonstruktion von Vorfällen, bei denen niemand sagen kann, welcher Agent eigentlich gehandelt hat.

    Was das für bestehende API-Landschaften konkret bedeutet

    Die gute Nachricht am Ende des Beitrags wird gern überlesen: Es ist nicht nötig, alles über API-Architektur über Bord zu werfen und neu anzufangen. Die wachsende agentische Nutzung verlangt Anpassungen, nicht Abriss. Zu einer Sammlung, die über Jahre gereift ist, kommen einige neue Regeln. Das ist deutlich weniger dramatisch als das Wort Zeitenwende, aber deutlich mehr als ein Update.

    Konkret heißt das für die Praxis: Berechtigungen kürzen und nicht dauerhaft vergeben, Identität für Agenten einführen, statt sie als anonyme Aufrufe zu behandeln, Dokumentation so schreiben, dass sie maschinenlesbar ist, und Beobachtbarkeit um die Frage erweitern, wer in wessen Auftrag gehandelt hat. Wer diese vier Punkte ernst nimmt, deckt den größten Teil der neuen Angriffsfläche ab, ohne seine bestehende Architektur zu verwerfen.

    Der Rest ist eine Frage der Reihenfolge. Identität und Autorisierung sind der Engpass, an dem alles andere hängt: Ohne verlässliche Angaben darüber, wer oder was da ruft, hilft auch die beste Governance nicht. Danach folgen Design und Observability, weil beide auf sauberen Schemata und klaren Berechtigungen aufbauen. Wer das in dieser Reihenfolge angeht, baut kein neues Straßennetz – sondern sorgt dafür, dass die vorhandenen Straßen auch von Fahrzeugen benutzt werden können, die keine Schilder lesen, sondern nur Karten.

    Quelle: nordicapis.com

  • Wie KI-Agenten die User Experience verändern: Jesse Zhang über den Kunden, der nie auf den Bildschirm schaut

    Wie KI-Agenten die User Experience verändern: Jesse Zhang über den Kunden, der nie auf den Bildschirm schaut

    „Amazon hat Muse blockiert. Shopify tat das Gegenteil und eröffnete einen eigenen Zahlungskanal für Muse.“ Der Satz stammt von Jesse Zhang, CEO des Kundenservice-KI-Anbieters Decagon, aus einem Beitrag auf X, den das koreanische Portal DigitalToday aufgegriffen hat. Er beschreibt eine Verschiebung, die mehr ist als eine Designfrage: Sie betrifft die Grundlage, auf der Kunden mit Unternehmen in Kontakt kommen. Wer das verstehen will, muss sich einen Kunden ansehen, der das Schaufenster gar nicht mehr betrachtet. Er liest nur noch das Preisschild.

    Ein Schaufenster funktioniert nur, solange jemand davor stehen bleibt und sich verführen lässt. Werbung, Reihenfolge, Farben, Dringlichkeit – all das zielt auf einen Blick, der verweilen kann. Ist die Gegenseite Software, fällt diese Ebene weg. Übrig bleibt eine Liste von Bedingungen. Darum geht es hier: nicht um ein neues Menü oder eine schönere Checkout-Seite, sondern um die Frage, was passiert, wenn der Kunde nicht mehr schaut, sondern verhandelt.

    Warum der Bildschirm als Verkaufsfläche an Bedeutung verliert

    Zhang bringt sein Argument auf einen Satz: „Wenn der Kunde ein Agent ist, ist die bestehende UX nur noch Ballast.“ Die Begründung ist nüchtern und kaum zu widerlegen. Agenten überspringen alles – Produktdarstellung, kaufauslösende Abläufe, Rabattlogiken, Kündigungen, die drei Bildschirme tief versteckt sind. Sie sehen sich keine Screens an, lesen keine Hinweistexte, klicken nicht auf „Nur heute“. Was jahrelang über Oberflächen durchgesetzt wurde, muss nun auf anderem Weg durchgesetzt werden.

    Hier verstehen viele Unternehmen ihre eigene Architektur falsch. Ein großer Teil der heutigen User Experience ist keine Freundlichkeit gegenüber dem Kunden, sondern ein Ringen um Aufmerksamkeit. Zeitdruck, Voreinstellungen, komplizierte Kündigungswege – all das funktioniert nur gegen Menschen. Die Geschäftsregeln dahinter bleiben aber bestehen: Wer bekommt welchen Preis, wer darf umbuchen, wer darf stornieren. Mit dem Bildschirm verschwindet der Ort, an dem diese Regeln bisher umgesetzt wurden. Deshalb wird UX für KI-Agenten zu einer Disziplin, die viel mit Schnittstellen, Berechtigungen und klaren Datenmodellen zu tun hat – und wenig mit Layout.

    Für dich heißt das: Die Frage ist nicht, ob deine Seite schön aussieht, wenn ein Agent sie aufruft. Die Frage ist, ob deine Regeln maschinenlesbar vorliegen. Steht eine Bedingung nur im Fließtext einer Hilfeseite, existiert sie für einen Agenten praktisch nicht.

    Ein Roboter mit Geldbeutel als neues Kundensegment

    Zhang beobachtet, dass persönliche Agenten wie Metas Muse – den Amazon vom Einkaufen aussperrt – oder Instinct stark zulegen, und nennt einen einfachen Grund: Sie erledigen tatsächlich Aufgaben. Bei Meta soll Muse Einkäufe direkt mit dem Geld der Nutzer abwickeln, abgesichert durch einen Käuferschutz von bis zu 1.000 Dollar pro Transaktion. Damit ist der Agent keine Empfehlungsmaschine mehr, sondern eine handelnde Partei mit Zahlungszugang. Zhangs Bild dafür: „Jeder Konsumartikel-Hersteller wird mit einem Kundensegment konfrontiert, das er nie eingeplant hat. Es ist ein Roboter mit einem Geldbeutel.“

    Er vergleicht die Tragweite mit dem Wechsel von offline zu online und dann zu mobilen Apps. Man muss diesen Vergleich nicht feiern, um ihn ernst zu nehmen. Jeder dieser Sprünge schuf nicht nur neue Kanäle, sondern verschob die Regeln, nach denen gehandelt wird. Wer die mobile Bestellstrecke damals als kleines Extra behandelt hat, hat später teuer nachgerüstet. In dieser Situation stehen Unternehmen wieder – nur ist die Gegenseite diesmal kein Gerät, sondern ein Akteur mit eigenen Interessen.

    Identität, Berechtigung und Verhandlungsgrenzen

    Der interessanteste Teil von Zhangs Beitrag beginnt da, wo er von Technik zu Verantwortung wechselt. Die Zusammenarbeit mit Agenten, hält er fest, endet nicht mit einer API und einer Seite Dokumentation. Er nennt fünf Bereiche; der erste ist Identität und Vollmacht. Ein Unternehmen muss prüfen, ob ein Agent wirklich für den Kunden handelt, und den Umfang seiner Vollmacht definieren. Stöbern und Kaufen sind zwei verschiedene Dinge, und eine Nachbestellung für 40 Dollar unterscheidet sich deutlich von einer Buchung für 4.000 Dollar.

    Der zweite Bereich sind Regeln und Verfahren. Ob eine Flugumbuchung, eine Neuausstellung der Karte oder ein Tarifwechsel zulässig ist, hängt vom Kundentyp ab, von gesetzlichen Vorgaben und internen Richtlinien. Solche Unterschiede lassen sich nicht in einer allgemeinen Antwort verstecken. Der dritte Bereich sind Verhandlungsgrenzen, und hier wird Zhang deutlich: „Wenn Sie nicht entscheiden können, wer wann einen Rabatt bekommt und wann Sie auf Prinzipien beharren, sichern Agenten jedes Mal die für das Unternehmen ungünstigsten Bedingungen.“ Die Begründung ist einfach und unbequem: Agenten werden nicht müde und nicht verlegen, und sie vergleichen Wettbewerbsangebote in Echtzeit.

    Das Argument reicht über die Technik hinaus. Ein menschlicher Kunde akzeptiert einen Preis, weil der Vergleich zu aufwendig ist oder die Situation unangenehm wird. Ein Agent kennt diese Ermüdung nicht. Damit wird die Frage, welche Spielräume ein Unternehmen offenlässt, zur strategischen Entscheidung – nicht zum Verhandlungsgeschick einzelner Mitarbeiter.

    Ausnahmen und Betrug im Maschinentempo

    Als vierten Punkt nennt Zhang den Umgang mit Ausnahmen. Trifft eine Anfrage nach der Rückgabefrist ein, sollte ein Kunde seit sechs Jahren anders behandelt werden als jemand, der gestern dazugekommen ist. Solche Entscheidungen brauchen Urteilsvermögen und lassen sich nicht vollständig in Regeln pressen. Zhang folgert daraus, dass auch diese Arbeit Agenten übernehmen sollten – allerdings solche, die urteilen, statt nur Regeln abzuarbeiten.

    Der fünfte Punkt ist der unbequemste und hat nichts mit Nutzerfreundlichkeit zu tun. Zhang weist darauf hin, dass Betrug im Maschinentempo stattfindet. Während ein legitimer Agent in 0,2 Sekunden Waren kauft, sucht ein bösartiger Agent zehntausend Mal pro Stunde nach Lücken in den Richtlinien. Eine Begrenzung der Anfragefrequenz allein hält das nach seiner Einschätzung nicht auf. Daran sieht man, wie eng KI-Agenten im Customer Experience mit Sicherheit, Missbrauchserkennung und Identitätsprüfung verwoben sind.

    Der Endzustand: Maschine handelt mit Maschine

    Am Ende steht ein Bild, das Zhang selbst zeichnet. Menschen legen fest, was sie wollen – etwa „kaufe zum niedrigsten Preis“ –, Unternehmen geben die Richtung vor: „schütze die Marge und halte treue Kunden“. Dazwischen handeln Systeme die Transaktion aus. Das Gespräch zwischen Konsument und Unternehmen führen dann nicht mehr auf beiden Seiten Menschen, sondern Software, die im Auftrag handelt. Die UX, wie wir sie kennen, wird in diesem Modell nicht besser oder schlechter. Für einen großen Teil der Vorgänge wird sie schlicht nicht mehr benutzt.

    Daraus leitet Zhang eine Erwartung ab: Ein Unternehmen, das mit Kunden zu tun hat, muss künftig mit Menschen und mit KI-Assistenten umgehen können. Wer sich nicht anpasst, bleibt zurück, so seine Formulierung. Dazu eine Beobachtung, die oft übersehen wird: Fällt der Aufwand für ein einzelnes Gespräch gegen null, steigt die Zahl der Gespräche stark an. Daraus entsteht wirtschaftliches Potenzial, das bisher ungenutzt blieb, weil der Aufwand pro Kontakt zu hoch war.

    Was das für Unternehmen konkret bedeutet

    Man kann diese Prognose teilen oder für übertrieben halten. Die Beobachtungen dahinter sind jedenfalls nicht exotisch: Agenten mit Zahlungszugang existieren, ihre Zahl wächst, und die Frage, wer haftet, wenn ein Agent falsch handelt, ist in vielen Fällen offen. Der Käuferschutz von bis zu 1.000 Dollar pro Transaktion ist ein Signal, aber keine Antwort auf Haftungsfragen. In dieser Lücke liegt derzeit das größte Risiko für Unternehmen, die früh aufspringen, ohne ihre Regeln zu klären.

    Praktisch heißt das: Fang mit drei Dingen an, die nichts kosten und viel Ordnung schaffen. Erstens: Prüfe, welche deiner Geschäftsregeln nur in Textform oder in der Oberfläche existieren, und schreibe sie so auf, dass ein System sie auswerten kann. Zweitens: Definiere getrennte Berechtigungsstufen für Suchen, Kaufen und Umbuchen, statt einen einzigen Zugang zu vergeben. Drittens: Lege fest, wo dein Unternehmen bewusst Grenzen zieht – damit nicht ein Agent die Bedingungen bestimmt, weil niemand sie vorher entschieden hat.

    Der Bildschirm verschwindet nicht, aber er verliert seine Rolle als Ort, an dem Regeln durchgesetzt werden. Wer heute eine Website baut, plant für einen Menschen, der verweilen kann. Wer morgen plant, plant für einen Kunden, der in Millisekunden entscheidet und dabei nichts sieht. Zwischen diesen beiden Welten liegt keine Designfrage, sondern eine Frage der Ordnung im eigenen Haus.

    Quelle: digitaltoday.co.kr

  • OpenRig: Wie ein Multi-Agenten-Harness Claude Code und Codex zu einem Team verbindet

    OpenRig: Wie ein Multi-Agenten-Harness Claude Code und Codex zu einem Team verbindet

    Wer mehrere Coding-Agenten parallel laufen lässt, etwa Claude Code und Codex in getrennten Terminals, verliert schnell den Überblick: Welcher Agent hat welche Aufgabe begonnen, wer sollte sie prüfen, und welcher Kontext gehört wozu? Nach einem Neustart ist dieser Zusammenhang oft weg. Hier setzt OpenRig an, ein Open-Source-Projekt auf GitHub, mit dem sich aus Claude Code, Codex und Pi ein eigenes Netzwerk von Agenten aufbauen lässt.

    Der Autor von OpenRig formuliert den Unterschied in einem Satz: Ein Harness umschließt ein Modell, ein Rig umschließt deine Harnesses. Das beschreibt, worum es geht. Du startest nicht mehr einzelne Coding-Agenten, sondern eine Mannschaft, die als System funktioniert. Wer schon länger mit KI-Coding-Agenten arbeitet, kennt das Problem: Ein einzelner Agent ist mächtig, aber sobald mehrere parallel laufen, entsteht Chaos.

    Was OpenRig von einem einzelnen Agenten unterscheidet

    Ein KI-Coding-Agent wie Claude Code oder Codex ist ein Werkzeug, das Anweisungen versteht und Code verändert. Er arbeitet in einer Sitzung, in einem Verzeichnis, mit einem Kontext. Für eine einzelne Aufgabe reicht das. Sobald aber ein Agent implementiert, ein zweiter prüft und ein dritter die Infrastruktur anpasst, brauchst du eine übergeordnete Ebene, die weiß, wer was tut. Diese Ebene ist OpenRig.

    Der Autor beschreibt sein System als Schicht über den Harnesses, nicht als Ersatz. Claude Code und Codex laufen weiter wie gewohnt, nur unter der Regie eines Daemons, der ihre Sitzungen kennt, ihre Rollen verwaltet und ihre Kommunikation weiterleitet. Statt loser Terminals entsteht ein beständiges Team, das einen Neustart übersteht und sich gegenseitig Nachrichten schicken kann.

    Die Rollenverteilung ist schlicht. In der Einsteiger-Anleitung steht ein Zweier-Team im Mittelpunkt: ein „Owner“, der eine Aufgabe umsetzt, und ein „Checker“, der die Änderung überprüft. Du sprichst mit dem Owner, der Owner koordiniert den Checker, am Ende bekommst du ein Ergebnis samt Review. Ein nüchternes Modell für ein Feld, in dem sonst gern von autonomen Agentenschwärmen die Rede ist.

    Das Agenten-Team in YAML definieren

    Die Topologie eines Teams wird nicht im Terminal zusammengeklickt, sondern in einer Datei beschrieben. OpenRig nennt dieses Format RigSpec und baut darauf Konzepte wie Pods, Edges und Continuity-Policies auf. Pods sind Gruppen zusammengehöriger Plätze (im Projektjargon „Seats“), Edges beschreiben, wie diese Plätze miteinander verbunden sind und wer wem schreiben darf. Continuity-Policies legen fest, wie ein Team einen Neustart übersteht.

    Wer schon CI-Pipelines oder Kubernetes-Manifeste geschrieben hat, erkennt das Muster: Zustand wird deklarativ beschrieben, das Werkzeug kümmert sich um die Ausführung. Ein Agententeam, das man per YAML definiert, lässt sich versionieren, teilen und reproduzieren. Das fehlt, solange jeder Agent als handgestartete Terminal-Sitzung existiert. Der Start läuft dann mit einem Befehl, rig up, der die nötigen tmux-Sitzungen, Harnesses und Startdateien anlegt und prüft, ob alles bereit ist.

    Das ist nicht nur ein Startskript. OpenRig erkennt bestehende Claude-Code- und Codex-Sitzungen in tmux und übernimmt sie in ein verwaltetes Rig. Man muss also nicht bei null anfangen. Auch der umgekehrte Weg ist vorgesehen: rig down –snapshot friert die aktuelle Topologie ein, rig up <name> holt sie wieder hervor.

    Die TUI als Kontrollzentrum

    Ohne eine Übersicht wäre ein Team aus mehreren Agenten kaum zu überblicken. OpenRig liefert deshalb eine Terminal-Oberfläche, die dieselben Rigs einmal als Graph und einmal als Tabelle zeigt. In der Tabelle stehen die einzelnen Plätze mit Laufzeit, Modell, Kontext und Zustand. Wer will, öffnet einen bestimmten Platz und sieht im Detail, was gerade passiert. Unspektakulär, im Alltag aber entscheidend.

    Zur Kommunikation zwischen den Agenten gibt es drei Befehle, die sich leicht merken lassen: rig send schickt eine Nachricht an einen bestimmten Platz, rig broadcast an mehrere, und rig chatroom öffnet einen gemeinsamen Raum. Wer selbst in einem Terminal tippt und nicht durch automatische Nachrichten unterbrochen werden will, kann mit rig seat set-typing-guard einen Platz schützen. Automatische Nachrichten werden dann zurückgehalten, statt mitten in die eigene Eingabe zu platzen.

    Das Dashboard lässt sich geteilt oder unabhängig öffnen. Ein geteiltes Dashboard verschwindet nicht, wenn man das Fenster schließt. Ein Detail, das darüber entscheidet, ob man ein Werkzeug ständig neu startet oder im Hintergrund laufen lässt.

    Was OpenRig auf deiner Maschine verändert

    Die README enthält einen eigenen Abschnitt: „What OpenRig changes on your machine“. Den sollte man lesen, bevor man irgendetwas installiert. OpenRig schreibt Konfiguration in Vertrauensdateien, legt Hooks an und erweitert Dateien wie ~/.tmux.conf, ~/.claude.json und die Codex-Konfiguration unter ~/.codex/config.toml.

    Konkret: Beim Start eines Rigs werden Workspace-Trust-Einstellungen gesetzt, Codex-Hooks aktiviert und Vertrauens-Hashes für bestimmte Befehle vorab eingetragen. Claude Code bekommt einen Statusline-Befehl und ausgewählte Activity-Hooks in die lokale Settings-Datei geschrieben. Die Aktivitäts-Relays senden Ereignistyp, Sitzungskennung und Zeitstempel an den eigenen Daemon, ausdrücklich ohne Prompt-Text und ohne Tool-Argumente. Wer Datenschutz ernst nimmt, sollte diese Liste lesen. Provider-Dateien und Instanz-Zustand sind getrennt, aber ein geänderter OPENRIG_HOME-Pfad isoliert die Provider-Konfiguration nicht automatisch.

    Vor dem ersten Start sollte man die betreffenden Dateien sichern. Manche Schreibroutinen behandeln unlesbare Einstellungsdateien als leere Objekte, und eine Garantie zur Wiederherstellung gibt es nicht. Der Befehl rig setup –dry-run zeigt den geplanten Eingriff an, ohne ihn auszuführen, deckt aber nicht jeden späteren Starteffekt ab.

    Berechtigungen: Der Punkt, an dem es ernst wird

    Ein Multi-Agenten-System für Coding-Agenten darf Dateien ändern, Befehle ausführen und im Grunde alles tun, wozu ein Agent eben in der Lage ist. OpenRig löst das nicht dadurch, dass es pauschal alles erlaubt. Der Autor beschreibt mehrere Stufen: Die Standardeinstellung für Codex ist ein Sandbox-Modus mit Schreibzugriff auf den Workspace, Claude Code startet mit --permission-mode acceptEdits. Ein vollständiger Bypass ist möglich, aber ausdrücklich nicht die Voreinstellung.

    Für einzelne Plätze lässt sich mit rig seat set-permissions ein auditiertes Modell wählen, das beim nächsten Start greift. Eine solche Auswahl verändert den laufenden Prozess nicht. Wer denkt, ein Befehl schalte sofort schärfere Rechte frei, täuscht sich. Gewünschte Einstellung und zuletzt verwendete Startargumente werden getrennt angezeigt, und keine der beiden Angaben beweist, dass die native Durchsetzung greift.

    In einem Umfeld, in dem Agenten gern als magische Helfer dargestellt werden, sagt der Autor klar, was sein Werkzeug kontrolliert und was nicht. Ein Multi-Agenten-Harness ist kein Sicherheitskonzept. Es ist eine Verwaltungsschicht, die dir den Überblick erleichtert und dich zwingt, dich mit Berechtigungen auseinanderzusetzen.

    Für wen sich der Einstieg lohnt

    OpenRig läuft auf macOS und Linux, benötigt Node.js 22 oder 24 und tmux. Auf Apple-Silicon-Macs empfiehlt der Autor Node.js 22, nativer Windows-Support fehlt bislang, WSL2 ist ungetestet. Die Installation erfolgt global über npm mit @openrig/cli, alternativ mit Bun. Danach folgt der erwähnte Trockenlauf, bevor etwas verändert wird.

    Wer nur gelegentlich einen einzelnen Coding-Agenten nutzt, braucht das nicht. Wer aber regelmäßig mehrere KI-Coding-Agenten parallel laufen lässt, kennt das Problem der auseinanderdriftenden Terminals. OpenRig macht aus verstreuten Sitzungen ein adressierbares Team, in dem du den Überblick behältst, in dem Aufgaben nachvollziehbar ankommen und in dem ein Neustart nicht bedeutet, alles neu aufzusetzen.

    Der Autor beschreibt den Einstieg klein: ein Repository, eine nützliche Änderung, ein Owner, ein Checker, ein überprüftes Ergebnis. Die Vorstellung, man definiere heute ein Agenten-Team in YAML und morgen erledige es die halbe Codebasis, hält der Praxis selten stand. Ein Rig aufzusetzen heißt, sich Gedanken zu machen: Wer prüft wen, welche Rechte bekommt welcher Platz, was passiert beim nächsten Reboot. Diese Fragen sind wichtiger als jeder zusätzliche Agent.

    Quelle: github.com

Weitere Beiträge