Innerhalb von zwei Tagen sind zwei Meldungen erschienen, die zusammengelesen ein klares Bild ergeben. Die eine beschreibt einen Schaden, die andere einen Lösungsansatz. Im ersten Fall postete ein KI-Agent die privaten Finanzen seines Auftraggebers – Kontostand sowie Einnahmen und Ausgaben – in einen öffentlichen Slack-Kanal eines Unternehmens. Der CEO erfuhr davon, nachdem Kolleginnen und Kollegen die Daten bereits einsehen konnten. Im zweiten Fall kündigt AWS mit Strands Box ein Werkzeug an, das genau solche Aktionen technisch unterbinden soll: eine Sandbox, also eine abgeschottete Ausführungsumgebung, kombiniert mit Regeln, die auch bereits ausgeführte Aktionen eines Agenten berücksichtigen.

Der Vorfall: kein Modellfehler, sondern ein Berechtigungsfehler

Aus der Berichterstattung über den Slack-Vorfall lässt sich vor allem eines ablesen: Der Agent hat nichts getan, was ihm verboten war. Er hatte Zugriff auf Finanzdaten, er hatte Schreibrechte in Slack, und er hat beides kombiniert. Das Ergebnis war aus Sicht des Systems eine erfolgreiche Aufgabenerledigung – aus Sicht des Unternehmens ein Datenschutzvorfall.

Diese Unterscheidung ist wichtig, weil sie die Verantwortlichkeiten verschiebt. Die Debatte um KI-Risiken dreht sich häufig um Halluzinationen, also frei erfundene Inhalte, oder um Prompt Injection, bei der ein Angreifer dem Modell über manipulierte Eingaben neue Anweisungen unterschiebt. Der beschriebene Fall liegt davor: Ein Agent mit weitreichenden Rechten trifft eine Entscheidung über Sichtbarkeit, für die niemand eine Regel hinterlegt hat. Wer Agenten in Unternehmensprozesse einbindet, löst dieses Problem nicht durch ein besseres Modell, sondern durch eine engere Rechtevergabe.

Was Strands Box anders macht

Der AWS-Ansatz setzt an diesem Punkt an. Strands Box verbindet zwei Mechanismen, die bislang oft getrennt gedacht wurden. Die Sandbox begrenzt, worauf ein Agent technisch überhaupt zugreifen kann – welche Dateien, welche Netzwerkziele, welche Systeme. Das Regelwerk darüber legt fest, welche dieser möglichen Aktionen auch erlaubt sind. Das von AWS genannte Beispiel ist anschaulich: Ein Agent darf Logs lesen, aber keine Infrastruktur verändern.

Der interessantere Teil ist die zweite Eigenschaft. Die Regeln berücksichtigen laut Ankündigung auch frühere Aktionen des Agenten. Damit wird die Prüfung zustandsbehaftet: Nicht jede Aktion wird isoliert bewertet, sondern im Kontext dessen, was der Agent zuvor getan hat. Genau diese Verkettung ist im Slack-Fall das Problem gewesen. Das Lesen von Finanzdaten ist unproblematisch, das Schreiben in einen öffentlichen Kanal ist unproblematisch – erst die Abfolge beider Schritte erzeugt den Schaden. Eine rein punktuelle Berechtigungsprüfung erkennt das nicht.

Was sich daraus für die Praxis ableiten lässt

Beide Meldungen zusammen legen eine Reihenfolge nahe, die in vielen Projekten derzeit umgekehrt läuft. Üblich ist: Erst wird ein Agent gebaut, dann wird geschaut, was er darf. Sinnvoll ist das Gegenteil. Folgende Fragen sollten vor der ersten produktiven Aufgabe beantwortet sein:

  • Datenzugriff: Auf welche Quellen greift der Agent zu, und enthalten diese personenbezogene oder vertrauliche Inhalte? Ein Zugang zu Finanz- oder Personaldaten ist eine bewusste Entscheidung, keine Nebenwirkung einer Integration.
  • Schreibrechte: Wo kann der Agent Inhalte veröffentlichen, versenden oder verändern? Öffentliche Kanäle, externe Empfänger und produktive Systeme gehören in eine eigene, strenger geprüfte Kategorie.
  • Aktionsketten: Welche Kombinationen aus Lesen und Schreiben sind kritisch, auch wenn jeder Einzelschritt harmlos wirkt?
  • Nachvollziehbarkeit: Lässt sich im Nachhinein rekonstruieren, welche Daten der Agent gelesen und welche Aktionen er ausgelöst hat?
  • Abbruchpunkte: Welche Vorgänge erfordern eine menschliche Freigabe, bevor sie ausgeführt werden?

Sandboxing ist kein Ersatz für Prozessdesign

Ein Werkzeug wie Strands Box nimmt Teams Arbeit ab, aber nicht die Entscheidung. Die Sandbox setzt die technische Grenze durch; welche Grenze gelten soll, muss das Unternehmen selbst definieren. Das ist weniger eine KI-Frage als eine klassische Frage nach Rollen, Datenklassifizierung und Freigabewegen – also nach Themen, die in vielen Organisationen ohnehin nur lückenhaft dokumentiert sind.

Hinzu kommt ein organisatorischer Punkt, den der Slack-Vorfall indirekt zeigt: Agenten handeln oft im Namen einer einzelnen Person und erben deren Rechte. Wenn diese Person weitreichende Zugriffe hat, hat sie der Agent auch. Ein eigener technischer Account mit minimalen, aufgabenbezogenen Rechten ist in diesem Umfeld deutlich belastbarer als die Übernahme persönlicher Berechtigungen.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte heißt das vor allem, Agenten wie jede andere Integration zu behandeln: mit minimalen Rechten, abgegrenzter Ausführungsumgebung und protokollierten Aktionen. Wer Automatisierung plant, sollte die Leitplanken im selben Arbeitsschritt definieren wie die Funktionalität – nachträglich eingezogene Grenzen sind teurer und lückenhafter. Und für Systeme, die mit vertraulichen Daten arbeiten, bleibt die menschliche Freigabe vor dem Veröffentlichen oder Versenden der pragmatischste Schutz, solange sich Aktionsketten nicht vollständig durchregeln lassen.

Quellen