KI-Unternehmen rennen darum, Agenten über den Chat hinaus nützlich zu machen, und das bedeutet in der Regel, ihnen Wege zu externen Software-, Daten- und Geschäftssystemen zu geben. Doch mit der Ausweitung dieser Connector-Schicht wächst auch der Sicherheitsperimeter rund um jede Bereitstellung.

Das ist die zentrale Warnung, die sich aus der Berichterstattung von The Register ergibt und die hervorhebt, wie die Anbindung von KI-Agenten an externe Dienste das von ihnen beschriebene Risikoradius dramatisch vergrößern kann. Selbst ohne detaillierte öffentliche Vorfalldaten im verfügbaren Quellenmaterial ist die Richtung klar: In dem Moment, in dem ein Agent aus Drittanbieter-Tools lesen oder in ihnen handeln kann, vervielfachen sich die Fehlermodi – von falschen Antworten bis hin zu realen operativen, finanziellen und sicherheitsrelevanten Folgen.

Warum connector-basierte Agenten das Risikoprofil verändern

Ein eigenständiger Assistent, der nur Text generiert, kann zwar weiterhin Probleme verursachen, aber die meisten dieser Probleme bleiben auf Fehlinformationen, Compliance-Fehler oder schlechte Nutzererfahrung beschränkt. Anders ist es bei einem mit externen Diensten verbundenen Agenten. Er kann Zugriff auf interne Dokumente, Kundendaten, Finanztools, Code-Repositories, Cloud-Systeme und Messaging-Plattformen erhalten. Damit verschiebt sich die Frage von der Genauigkeit des Modells hin dazu, ob die gesamte Handlungskette sicher ist.

Die Einordnung von The Register ist deshalb wichtig, weil sich der KI-Markt schnell in Richtung von Tools nutzenden Systemen bewegt. Anbieter aus dem Bereich Enterprise-KI positionieren Agenten als digitale Mitarbeiter, die Informationen abrufen, Workflows auslösen und Aufgaben über mehrere Anwendungen hinweg koordinieren können. Dieses Versprechen ist für Produktteams und CIOs attraktiv, weil es KI-Ausgaben mit messbarer Arbeit verknüpft – nicht nur mit Experimenten.

Doch jeder Connector wird faktisch zu einer neuen Vertrauensbrücke. Wenn ein Agent auf Slack, Salesforce, GitHub, Google Workspace, Microsoft 365, Jira, ServiceNow oder AWS zugreifen kann, dann können falsch konfigurierte Berechtigungen, Prompt Injection, zu weit gefasste Zugriffstokens und schwache Freigabekontrollen allesamt zu Wegen realer Schäden werden. Das Problem ist nicht nur, ob das zugrunde liegende Modell sich korrekt verhält. Es geht darum, ob die umgebende Orchestrierungsschicht das Modell bei adversarialen Eingaben oder mehrdeutigen Anweisungen ausreichend eng begrenzt.

Der Sprung vom Beantworten von Fragen zum Ausführen von Aktionen

Die größte Veränderung im KI-Betrieb des vergangenen Jahres war der Übergang von Copiloten zu KI-Agenten. Ein Copilot schlägt vor. Ein Agent führt aus. Diese Unterscheidung klingt einfach, hat aber tiefgreifende Folgen für das Risikomanagement.

Sobald ein Agent in ServiceNow Tickets öffnen, Datensätze in Salesforce aktualisieren, in Slack posten, Code in GitHub verändern oder Datenbanken über AWS-Dienste abfragen kann, vergrößert sich die Wirkung einer einzigen Fehlentscheidung. Eine schlechte Zusammenfassung ist ärgerlich. Eine fehlerhafte Datenbankaktion, eine unbeabsichtigte Repo-Änderung oder eine irrtümliche Kundenkommunikation kann handfeste Konsequenzen haben.

Das ist besonders relevant für Arbeitsplatzautomatisierungs-Programme, die eingeführt werden, bevor Governance-Modelle ausgereift sind. Viele Unternehmen begannen mit risikoarmen Pilotprojekten in der Wissenssuche oder bei interner Schreibunterstützung. Die nächste Stufe umfasst oft autonome oder halbautonome Aktionen. Genau dort müssen Enterprise-KI-Verantwortliche entscheiden, wie viel Autorität ein Agent erhält, welche Freigaben erforderlich sind und wie Aktionen im Nachhinein geprüft werden.

Die Warnung von The Register deckt sich mit seit Langem von Sicherheitsforschern geäußerten Bedenken: Verbundene Agenten können die Schwachstellen jedes Systems übernehmen, mit dem sie interagieren. Ein Modell kann durch feindliche Inhalte getäuscht werden. Ein Connector kann zu viele Daten offenlegen. Einer Orchestrierungsplattform können klare Richtliniengrenzen fehlen. Ein Mitarbeiter merkt möglicherweise nicht, dass ein Agent breitere Privilegien besitzt als der Nutzer, der ihn aufgerufen hat. Keine dieser Schwachstellen erfordert ein dramatisches Modellversagen. Sie entstehen aus dem Integrationsdesign.

Was die Belege zeigen – und was nicht

Das für diese Geschichte verfügbare Quellenmaterial beschränkt sich auf die Überschrift und Zusammenfassung von The Register, ohne den vollständigen Artikeltext. Deshalb ist Vorsicht geboten. Bestätigen lässt sich der zentrale Nachrichtenwinkel: die wachsende Sorge, dass die Anbindung von KI-Agenten an externe Dienste die Sicherheits- und Betriebsrisiken erheblich ausweitet. Auf Grundlage der hier vorliegenden Belege können wir The Register jedoch keine konkreten Vorfälle, Namen von Anbietern, zitierte Experten oder neu offengelegte Schwachstellen zuschreiben.

Diese Unsicherheit ist wichtig, weil sich bei diesem Thema Marktsprache oft schneller bewegt als dokumentierte Belege. Viele Unternehmen bewerben KI-Agenten, MCP-ähnliche Integrationen und No-Code-Connectoren als die nächste Ebene von Produktivitätssoftware. Diese Fähigkeiten sind real, aber die stärksten Aussagen über Sicherheit, Autonomie und Zuverlässigkeit stammen häufig von den Anbietern selbst und werden nicht immer durch unabhängige Audits bestätigt.

In der Praxis sollten Unternehmen, die KI-Agenten evaluieren, drei Arten von Behauptungen voneinander trennen. Erstens bestätigte Produkteigenschaften, etwa ob eine Plattform Connectoren zu Tools wie Google Workspace oder Microsoft 365 bietet. Zweitens Anbieterbehauptungen über Schutzmechanismen, etwa Berechtigungssteuerung, Human-in-the-Loop-Prüfung oder Richtliniendurchsetzung. Drittens weitergehende Annahmen, dass verbundene Agenten die Arbeitslast senken, ohne ausgleichende Sicherheits-, Rechts- oder Betriebskosten zu verursachen. Die letzte Kategorie ist am wenigsten belegt und am stärksten von der Qualität der Implementierung abhängig.

Was Entwickler und Unternehmen jetzt ändern müssen

Für Entwickler lautet die Botschaft, dass Tool-Zugriff nicht nur ein Feature ist, sondern die zentrale Sicherheitsarchitektur. Jedes Team, das KI-Agenten ausliefert, sollte davon ausgehen, dass externe Tools, Dokumente, Websites und Nachrichten bösartige oder irreführende Anweisungen enthalten können. Prompt Injection ist nicht mehr nur ein theoretisches Ärgernis, wenn das Modell tatsächlich handeln kann.

Das bedeutet, dass Prinzipien der geringsten Privilegien Standard sein sollten, nicht optional. Ein Agent, der ein Ticket lesen muss, sollte es nicht automatisch schließen dürfen. Ein Agent, der Dokumente aus Google Workspace zusammenfasst, sollte keine breiten Schreibrechte erben. Ein mit GitHub verbundener Coding-Assistent sollte Änderungen nicht ohne explizite Freigaben mergen dürfen. Dieselbe Logik gilt für AWS-Ressourcen, ServiceNow-Workflows und Daten in Microsoft 365.

Unternehmen brauchen außerdem besseres Logging und bessere Richtliniendurchsetzung. Wenn ein Agent Salesforce-Datensätze berührt, eine Nachricht in Slack sendet oder eine Änderung in Jira auslöst, sollten Administratoren nachvollziehen können, warum es geschah, welche Eingaben verwendet wurden und welche Berechtigungen ausgeübt wurden. Traditionelle Anwendungslogs reichen nicht aus, wenn der Entscheidungsweg teilweise modellgesteuert ist.

Für Sicherheitsteams besteht die operative Herausforderung darin, dass KI-Agenten Kategorien verwischen. Sie sind nicht einfach nur Apps, und sie sind nicht einfach nur Nutzer. Sie verhalten sich eher wie delegierte Akteure mit bedingtem Schlussfolgern. Das macht klassisches Identity- und Access-Management notwendig, aber nicht ausreichend. Governance muss Agentengedächtnis, Richtlinien für Tool-Nutzung, Freigabeschritte, Datenherkunft und Segmentierung auf Connector-Ebene abdecken.

Für Startups, die in diesem Bereich bauen, ist das auch eine Marktchance. Die Verbreitung von KI-Agenten dürfte die Nachfrage nach Agenten-Observability, Policy-Engines, sicheren Connector-Frameworks, Red-Teaming-Tools und Laufzeitkontrollen schaffen, die auf modellgetriebene Systeme zugeschnitten sind. Je mehr Unternehmen Arbeitsplatzautomatisierung einführen, desto mehr benötigen sie Infrastruktur, die KI-Agenten als eigene Klasse von Softwarerisiko behandelt.

Warum das im breiteren KI-Markt wichtig ist

Der kommerzielle Druck hinter verbundenen Agenten ist leicht zu verstehen. Einfache Chat-Oberflächen werden zunehmend zur Massenware. Was Plattformen heute unterscheidet, ist die Fähigkeit, Arbeit über Systeme hinweg abzuschließen. Deshalb konzentrieren sich so viele Enterprise-KI-Roadmaps inzwischen auf Orchestrierung, Connectoren und handlungsorientierte Workflows statt auf reine Modellleistung.

Doch dieser Markttrend erzeugt ein Paradox. Genau die Fähigkeiten, die KI-Agenten wertvoll machen, sind dieselben, die sie gefährlich machen. Wenn ein Anbieter einen Agenten zu stark einschränkt, sehen Kunden möglicherweise kaum Rendite. Öffnet der Anbieter die Autonomie zu schnell zu weit, übernimmt der Kunde mehr Risiko, als viele Governance-Programme verkraften können.

Diese Spannung wird den Wettbewerb in der Enterprise-KI im kommenden Jahr prägen. Käufer werden wahrscheinlich Plattformen bevorzugen, die starke Kontrollen rund um Integrationen mit Slack, Salesforce, GitHub, Google Workspace, Microsoft 365, Jira, ServiceNow und AWS nachweisen können – nicht nur die Zahl der Connectoren auf einer Folie. Zuverlässigkeit, Rückrollmöglichkeiten, Freigabeabläufe und forensische Transparenz könnten ebenso wichtig werden wie die Modellwahl.

Das wäre ein wichtiger Wandel darin, wie der Markt KI-Agenten bewertet. Anstatt nur zu fragen, was das Modell in einem Benchmark kann, werden Käufer zunehmend fragen, was passiert, wenn es in einem laufenden Geschäftssystem falsch liegt.

Worauf man als Nächstes achten sollte

Die nächsten Signale, auf die man achten sollte, sind praktischer und weniger rhetorischer Natur.

Erstens: Beobachten Sie, ob Unternehmen nach ersten Piloten die Berechtigungen von Agenten einschränken. Wenn größere Bereitstellungen zu Nur-Lesen-Standardeinstellungen und schrittweisen Freigaben übergehen, deutet das darauf hin, dass Käufer Eindämmung über vollständige Autonomie stellen.

Zweitens: Achten Sie darauf, ob mehr Anbieter sichere Connector-Frameworks, Audit-Trails und Richtlinienkontrollen rund um KI-Agenten betonen. Produktstarts, die eher Governance als rohe Leistungsfähigkeit in den Mittelpunkt stellen, wären ein Zeichen dafür, dass der Markt das Problem erkannt hat.

Drittens: Achten Sie auf Veröffentlichungen von Sicherheitsforschern. Demonstrationen von Prompt Injection gegen mit Slack, Salesforce, GitHub, Google Workspace, Microsoft 365, Jira, ServiceNow oder AWS verbundene Agenten würden konkretere Belege dafür liefern, wo heutige Abwehrmaßnahmen versagen.

Und schließlich: Beobachten Sie das Beschaffungsverhalten. Wenn Enterprise-KI-Deals zunehmend Red-Team-Ergebnisse, klarere Berechtigungsabgrenzungen und bessere Incident-Response-Pläne für KI-Agenten verlangen, dann zeigt das, dass das Connector-Problem vom theoretischen Risiko zu einem Kriterium auf Vorstandsebene geworden ist.

Creati.ai-Perspektive

Die zentrale Erkenntnis ist nicht, dass verbundene KI-Agenten eine schlechte Idee sind. Sie lautet vielmehr, dass die Branche in eine Phase eintritt, in der Nutzen und Risiko gemeinsam steigen. Die Connector-Schicht wird zur eigentlichen Produktoberfläche für Enterprise-KI, und das bedeutet, dass Sicherheit nicht länger als Hülle um das Modell herum behandelt werden kann.

Für Entwickler und Käufer gleichermaßen wird das erfolgreiche Muster wahrscheinlich in eingeschränkter Autonomie liegen: KI-Agenten, die systemübergreifend arbeiten können, aber nur mit eng begrenzten Berechtigungen, sichtbaren Denkschritten, starkem Logging und menschlichen Kontrollpunkten dort, wo die Folgen groß sind. In der Enterprise-KI könnte der wichtigste Wettbewerbsvorteil nicht darin liegen, wie viele Aktionen ein Agent ausführen kann, sondern wie sicher man ihm zutrauen kann, sie auszuführen.