Ein Sicherheits-Start-up namens Cathedral ist im Rahmen eines Bug-Bounty-Programms in interne Systeme des KI-Unternehmens Anthropic eingedrungen. Der Weg dorthin führte nicht über die Kernsysteme des Unternehmens, sondern über Software von Drittanbietern. Eingesetzt wurden dabei KI-Agenten, also Programme, die eigenständig Aufgaben planen, Werkzeuge aufrufen und ihre nächsten Schritte aus den Zwischenergebnissen ableiten.

Anthropic bestätigt, dass auf Vertriebs-, Personal- und IT-Daten zugegriffen wurde, widerspricht aber der Darstellung des vollen Umfangs. Unabhängig davon, wie weit der Zugriff im Detail reichte, bleibt der Kern der Geschichte bestehen: Auch ein Unternehmen, das selbst an vorderster Front an KI-Systemen arbeitet, ist über seine externen Abhängigkeiten angreifbar.

Warum das für ganz normale Webprojekte relevant ist

Die Konstellation ist nicht exotisch. Jedes mittelständische Unternehmen betreibt heute eine Kette aus Systemen, die miteinander sprechen: ein CMS, ein CRM, ein Ticketsystem, Chat-Werkzeuge, Marketing-Automation, Buchhaltung, Single Sign-on. Verbunden sind diese Systeme über Schnittstellen und Zugriffstoken, also technische Schlüssel, mit denen sich ein Dienst gegenüber einem anderen ausweist.

Diese Token sind oft großzügig vergeben. Sie werden einmal für eine Integration erzeugt, bekommen vorsichtshalber weitreichende Rechte und bleiben dann jahrelang gültig. Wer eine solche Verbindung kompromittiert, steht nicht vor der Haustür, sondern bereits im Flur.

Der beschriebene Fall macht zusätzlich deutlich, dass die Schwachstelle nicht im eigenen Code liegen muss. Ein Drittanbieter mit Zugang zu Ihren Systemen wird faktisch zu einem Teil Ihrer Angriffsfläche. Sein Sicherheitsniveau ist Ihr Sicherheitsniveau.

Was KI-Agenten an der Lage verändern

Angriffe auf Lieferketten von Software gibt es seit Jahren. Neu ist die Geschwindigkeit und Ausdauer, mit der sie sich durchführen lassen. Ein Agent kann hunderte Integrationen, Subdomains und Konfigurationsdateien durchgehen, Hinweise kombinieren und daraus den nächsten Schritt ableiten, ohne dass ein Mensch jede Abzweigung einzeln bewertet.

Damit verschiebt sich das Verhältnis von Aufwand und Ertrag. Angriffspfade, die früher zu mühsam waren, um sie gegen ein mittelgroßes Unternehmen zu verfolgen, werden wirtschaftlich. Gleichzeitig entstehen auf Verteidigungsseite dieselben Möglichkeiten: Auch die Prüfung der eigenen Landschaft lässt sich automatisieren.

Hinzu kommt ein zweiter Punkt, der in vielen Projekten noch unterschätzt wird. Wer selbst Agenten einsetzt, etwa zur Inhaltspflege, für Auswertungen oder im Support, gibt einem automatisierten System Zugriff auf Daten und Werkzeuge. Jede solche Berechtigung ist ein möglicher Hebel, wenn das System manipuliert wird, beispielsweise durch präparierte Inhalte, die der Agent verarbeitet.

Konkrete Ansatzpunkte in CMS- und Webprojekten

Die Lehren aus dem Vorfall lassen sich in überschaubare Maßnahmen übersetzen, die sich auch ohne eigenes Sicherheitsteam umsetzen lassen:

  • Bestandsaufnahme der Integrationen: Welche externen Dienste hängen am CMS, am Shop, am Intranet? Wer hat diese Verbindungen eingerichtet, und wird sie noch benutzt? Nicht genutzte Anbindungen sind der günstigste Sicherheitsgewinn, den es gibt.
  • Rechte konsequent eingrenzen: Ein Token für einen Import braucht Schreibrechte auf wenige Datensätze, nicht auf das ganze System. Lesen und Schreiben sollten getrennt sein, Administrationsrechte die Ausnahme.
  • Token mit Ablaufdatum: Zugangsschlüssel, die regelmäßig erneuert werden, verlieren an Wert für Angreifer. Das setzt voraus, dass dokumentiert ist, wo welcher Schlüssel verwendet wird.
  • Protokollierung mit Auswertung: Zugriffe über Schnittstellen sollten nachvollziehbar sein. Entscheidend ist weniger, dass protokolliert wird, sondern dass auffällige Muster jemandem auffallen.
  • Abhängigkeiten im Blick behalten: Erweiterungen, Bibliotheken und Pakete im Projekt sollten auf einem gepflegten Stand sein. In TYPO3-Projekten betrifft das sowohl den Kern als auch die eingesetzten Extensions.
  • Agentenzugriffe wie Benutzerkonten behandeln: Ein Agent bekommt ein eigenes, klar abgegrenztes Konto mit eigenen Rechten und eigener Protokollierung, kein geteiltes Administratorkonto.

Organisatorisch statt rein technisch denken

Viele dieser Punkte sind keine Programmieraufgaben, sondern Fragen der Zuständigkeit. Wer entscheidet, ob ein neues Werkzeug an das CMS angebunden wird? Wer prüft, welche Daten dabei abfließen? Wer bemerkt, dass ein Dienstleister das Projekt verlassen hat und seine Zugänge noch existieren?

In der Praxis entstehen Lücken selten durch eine falsche Codezeile, sondern dadurch, dass niemand zuständig ist. Ein knapper, aktueller Überblick über Systeme, Verbindungen und Verantwortliche ist deshalb oft wirksamer als eine weitere technische Schutzschicht.

Hilfreich ist außerdem, Sicherheit als Teil des Betriebs zu planen und nicht als einmaligen Projektschritt. Eine jährliche Durchsicht der Integrationen und Berechtigungen, mit festem Termin und klarem Ergebnis, kostet wenig Zeit und verhindert, dass sich über Jahre eine unübersichtliche Landschaft aufbaut.

Einordnung

Für Web- und Softwareprojekte verschiebt sich der Blickwinkel: Die eigene Anwendung ist nur so sicher wie die schwächste Verbindung in ihre Umgebung. Wer Schnittstellen, Zugriffsrechte und externe Abhängigkeiten dokumentiert und regelmäßig überprüft, reduziert das Risiko deutlich, ohne große Investitionen. Und wer KI-Agenten in eigene Abläufe integriert, sollte deren Berechtigungen von Beginn an so eng fassen, wie es die Aufgabe erlaubt.

Quellen