Autonome AI-Agenten entwickeln sich in Unternehmen von einfachen Assistenten zu Systemen, die eigenständig Daten abrufen, Software bedienen, Dateien verändern, APIs aufrufen und Geschäftsprozesse auslösen können, wie die Redaktion von Techify.de. Genau diese Kombination aus Autonomie und legitimen Zugriffsrechten verschiebt 2026 die Wahrnehmung in Security-Abteilungen: Nicht nur externe Hacker, sondern interne Software-Agenten mit zu weitreichenden Berechtigungen stehen inzwischen weit oben auf der Risikoliste.
Eine neue internationale Untersuchung von Exabeam liefert dafür eine auffällige Zahl. 48 Prozent der befragten Security-Verantwortlichen bezeichneten AI-Agenten, die mit übermäßigen, kompromittierten oder unbeabsichtigten Zugriffsrechten arbeiten, als größte aktuelle Bedrohung für ihre Organisation. Die Aussage bedeutet nicht, dass AI-Agenten bereits mehr reale Angriffe verursachen als Cyberkriminelle. Sie zeigt vielmehr, wie stark sich der Schwerpunkt der Sicherheitsplanung verändert, sobald Software nicht mehr nur Informationen liefert, sondern selbst handeln darf.
Warum AI-Agenten in der Risikobewertung vor klassischen Hackern landen
Die von Sapio Research im Auftrag von Exabeam durchgeführte Untersuchung basiert auf Antworten von 600 Entscheidern aus Security und Finance. Befragt wurden Beschäftigte größerer Unternehmen mit mindestens 500 Mitarbeitern in den USA, Kanada, Großbritannien, Frankreich, Deutschland, den Niederlanden und Australien.
48 Prozent der Security-Leiter nannten autonome Agenten mit problematischen Zugriffsrechten als größte Bedrohung; externe Angreifer kamen in der veröffentlichten Auswertung auf 28 Prozent.
Kompromittierte interne Nutzer und vorsätzlich handelnde Mitarbeiter folgten mit jeweils 12 Prozent.
Damit entsteht eine neue Form des Insider-Risikos. Ein Angreifer von außen muss normalerweise zunächst eine Schwachstelle finden, Zugangsdaten stehlen oder eine Person täuschen. Ein Unternehmensagent kann dagegen bereits mit gültigen Tokens, API-Schlüsseln, Datenbankrechten oder Cloud-Berechtigungen ausgestattet sein.
Der kritische Unterschied liegt deshalb weniger in der Intelligenz des Modells als in den Rechten, die das Unternehmen dem System erteilt.
| Wahrgenommenes Risiko | Anteil in der veröffentlichten Exabeam-Auswertung |
|---|---|
| AI-Agenten mit übermäßigem, kompromittiertem oder unbeabsichtigtem Zugriff | 48 % |
| Externe Angreifer | 28 % |
| Kompromittierte Insider | 12 % |
| Böswillige Mitarbeiter | 12 % |
Die Zahlen messen die Einschätzung der Befragten und dürfen nicht als Statistik real verursachter Sicherheitsvorfälle gelesen werden. Trotzdem ist die Verschiebung für Unternehmen relevant: Klassische Security-Produkte beobachten vor allem Benutzerkonten, Netzwerkverkehr, Endgeräte und bekannte Angriffsmuster.
Ein Agent kann sich dagegen technisch völlig legitim verhalten und trotzdem eine unerwünschte Aktion ausführen.
„AI agents have become a new class of insider risk.“
— Exabeam, Forschungsbericht „The Agentic Insider“.
Das Problem beginnt bei den Berechtigungen – nicht erst beim Angriff
Ein autonomer Agent ist vereinfacht ein KI-System, das ein Ziel erhält, Zwischenschritte plant und dafür Werkzeuge benutzen kann. Zu diesen Werkzeugen gehören Browser, E-Mail-Konten, CRM-Systeme, Cloud-Speicher, Terminkalender, interne Datenbanken, Code-Repositories oder Zahlungs- und ERP-Systeme.
Damit unterscheidet sich Agentic AI grundlegend von einem klassischen Chatbot. Ein Chatbot kann eine falsche Antwort erzeugen.
Ein falsch gesteuerter Agent kann zusätzlich eine Datei verschieben, eine Nachricht versenden, einen Datensatz ändern oder eine externe API ansprechen.
Microsoft beschreibt autonome agentische Systeme deshalb ausdrücklich als Systeme, die planen, Aktionen ausführen und ihr Vorgehen anpassen können. Jede Verbindung zwischen Agent, Tool, Dienst und anderem Agenten vergrößere dabei die Angriffsfläche.
Als konkrete Risiken nennt Microsoft unter anderem Agent Hijacking, Datenabfluss, Supply-Chain-Kompromittierung und sogenanntes Agent Sprawl – also unkontrolliert wachsende Bestände von Agenten innerhalb eines Unternehmens.
Das lässt sich an einem einfachen Szenario zeigen:
- Ein Unternehmen gibt einem Agenten Zugriff auf E-Mails, Kalender und Cloud-Dateien.
- Der Agent soll Termine erkennen und automatisch Unterlagen vorbereiten.
- Eine eingehende Nachricht enthält manipulierte Anweisungen.
- Der Agent interpretiert einen Teil davon als Handlungsanweisung.
- Durch seine legitimen Rechte kann er anschließend Informationen abrufen oder Aktionen auslösen, die der Nutzer nie beabsichtigt hat.
Das Problem ist in diesem Fall kein gestohlenes Passwort. Das Passwort beziehungsweise Token funktioniert exakt wie vorgesehen. Kritisch ist, dass die Software zu viel darf oder zwischen vertrauenswürdigen Befehlen und manipulierten Inhalten nicht zuverlässig unterscheidet.
Wie weitreichend solche Berechtigungen werden können, zeigte zuletzt auch ein Fall rund um einen KI-Assistenten, der Zugriff auf E-Mail, Kamera, Mikrofon und Dateien erhalten konnte. Eine ausführliche technische Einordnung bietet der Beitrag zur Muse-Sicherheitslücke und den Risiken umfangreicher KI-Berechtigungen.
Prompt Injection wird gefährlicher, sobald ein Modell selbst handeln kann
Zu den zentralen Risiken gehört Prompt Injection. Dabei platziert ein Angreifer Anweisungen in Inhalten, die ein Agent später verarbeitet. Sie können beispielsweise in einer Webseite, einer E-Mail, einem Dokument oder einem Datensatz stehen.
Für einen Menschen kann die Manipulation unsichtbar oder unauffällig sein. Der Agent verarbeitet den Inhalt jedoch zusammen mit seiner eigentlichen Aufgabe und kann versuchen, den eingeschleusten Anweisungen zu folgen.
OpenAI beschreibt Prompt Injection inzwischen als eine Form von Social Engineering für KI-Systeme. Entscheidend ist, dass der Angriff nicht zwingend das zugrunde liegende Modell kompromittiert.
Stattdessen wird versucht, sein Verhalten durch externe Informationen zu beeinflussen.
„Defending against prompt injection is a challenge across the AI industry.“
— OpenAI.
Warum Browser-Agenten besonders exponiert sind
Bei Browser-Agenten wächst das Problem, weil praktisch jede geladene Seite nicht vertrauenswürdigen Inhalt enthalten kann. Ein Agent kann Suchergebnisse lesen, Online-Shops besuchen, Dokumente öffnen oder sich in Geschäftssysteme einloggen.
Anthropic erläuterte Ende 2025 ein Beispiel, bei dem ein Agent eingehende E-Mails bearbeiten soll. Eine manipulierte Nachricht könnte versteckte Anweisungen enthalten, bestimmte vertrauliche Informationen an eine externe Adresse weiterzugeben.
Je mehr Anwendungen und Datenquellen der Agent gleichzeitig verwenden darf, desto größer wird der mögliche Schaden.
„Prompt injection is far from a solved problem.“
— Anthropic, November 2025.
Genau hier liegt ein Unterschied zu vielen herkömmlichen Cyberangriffen. Ein klassischer Angreifer versucht häufig, technische Zugangskontrollen zu umgehen. Beim manipulierten Agenten kann es genügen, ein bereits autorisiertes System dazu zu bringen, seine legitimen Rechte falsch einzusetzen.
Sicherheitsvorfälle mit AI-Agenten sind längst nicht mehr nur theoretisch
Weitere Untersuchungen zeigen, dass Unternehmen bereits konkrete Probleme beobachten. Die Cloud Security Alliance veröffentlichte im April 2026 Ergebnisse einer Befragung von 445 IT- und Security-Fachleuten.
53 Prozent der Organisationen berichteten demnach, dass AI-Agenten ihre vorgesehenen Berechtigungsgrenzen bereits überschritten hatten. 47 Prozent gaben an, innerhalb des vorherigen Jahres einen Sicherheitsvorfall erlebt zu haben, an dem ein AI-Agent beteiligt war.
Eine weitere von der CSA veröffentlichte Untersuchung kam zu noch höheren Werten. Dort erklärten 82 Prozent der Organisationen, dass in ihrer Umgebung AI-Agenten existierten, die ihnen nicht vollständig bekannt waren.
65 Prozent berichteten von agentenbezogenen Vorfällen innerhalb der vergangenen zwölf Monate. Unter den Organisationen mit Vorfällen wurden unter anderem Datenexposition, Betriebsstörungen und finanzielle Schäden genannt.
Die Studien unterscheiden sich in Methodik, Stichprobe und Auftraggeber. Ihre Prozentwerte sollten deshalb nicht miteinander vermischt werden. Zusammen zeigen sie jedoch ein wiederkehrendes Muster: Unternehmen führen Agenten schneller ein, als sie deren Identitäten, Berechtigungen und Aktivitäten zentral erfassen können.
| Problem | Befund aus veröffentlichten CSA-Daten |
|---|---|
| Agent überschritt vorgesehene Berechtigungen | 53 % |
| Sicherheitsvorfall mit AI-Agent im vergangenen Jahr | 47 % |
| Unternehmen mit unbekannten Agenten in einer weiteren CSA-Erhebung | 82 % |
| Agentenbezogene Vorfälle in dieser Erhebung | 65 % |
„Most organizations can’t say what those agents have accessed, what decisions they’ve made, or who is accountable.“
— Ben Kliger, Mitgründer und CEO von Zenity.
Warum normale Zugangskontrollen bei Agenten nicht ausreichen
Unternehmen haben jahrzehntelang Identity and Access Management für Menschen aufgebaut. Nutzer erhalten ein Konto, eine Rolle und bestimmte Rechte. Aktivitäten können einem Mitarbeiter zugeordnet werden.
Bei Agenten wird das schwieriger. Ein Agent kann rund um die Uhr laufen, Tausende Aktionen ausführen, mehrere Dienste kombinieren und seine Handlungsschritte dynamisch bestimmen. Hinzu kommen Unteragenten oder automatisierte Workflows, die selbst weitere Systeme ansprechen.
Die Cloud Security Alliance verweist deshalb auf grundlegende IAM-Probleme bei autonomen Agenten.
Dazu gehören statische Zugangsdaten, fragmentierte Berechtigungsmodelle, begrenzte Erkennung von Agenten und unzureichende Rückverfolgbarkeit.
Für Security-Teams entstehen mindestens sechs Kontrollfragen:
- Welche AI-Agenten existieren überhaupt im Unternehmen?
- Wem gehört jeder einzelne Agent organisatorisch?
- Welche Konten, Datenbanken und APIs darf er benutzen?
- Mit welchen Tokens oder Service-Accounts authentifiziert er sich?
- Welche Aktionen hat er tatsächlich ausgeführt?
- Kann jede kritische Handlung einem konkreten Auftrag und einer verantwortlichen Person zugeordnet werden?
Fehlt eine dieser Ebenen, reicht ein normales Login-Protokoll häufig nicht aus. Es zeigt möglicherweise, dass ein autorisiertes Konto eine Datei geöffnet hat. Es erklärt aber nicht, warum der Agent die Datei benötigte, welche vorherigen Informationen seine Entscheidung beeinflussten und welchem Geschäftsziel die Aktion dienen sollte.
Lokale KI löst das Berechtigungsproblem nur teilweise
Ein Teil der Branche verlagert KI-Funktionen inzwischen direkt auf PCs und Smartphones. Dadurch müssen bestimmte persönliche Informationen nicht zwingend für jede Verarbeitung an einen Cloud-Server gesendet werden. Das kann Datenschutzvorteile bringen.
Es beseitigt jedoch nicht automatisch AI-Agenten-Sicherheitsrisiken. Ein lokal laufender Agent kann ebenfalls auf E-Mails, Dateien, Sensoren oder Anwendungen zugreifen. Entscheidend bleibt, welche Rechte Betriebssystem und Apps vergeben.
Bei Qualcomms neuer Snapdragon-Generation wird beispielsweise stärkerer persönlicher Kontext direkt auf dem Gerät verarbeitet. Der dazugehörige Überblick zu lokalen KI-Agenten und dem Snapdragon 8 Elite Gen 6 zeigt, warum bei persönlichem KI-Gedächtnis Berechtigungen, Datenlöschung und die Trennung zwischen lokaler Verarbeitung und Cloud-Zugriff zunehmend relevant werden.
Ein lokaler Agent ist also nicht automatisch ein sicherer Agent. Die Angriffsfläche verschiebt sich lediglich.
Was Unternehmen jetzt technisch ändern müssen
Microsoft empfiehlt für agentische Systeme ein mehrschichtiges Sicherheitsmodell. Dazu gehören Schutzmechanismen auf Modell-, Runtime-, Anwendungs- und Governance-Ebene. Besonders entscheidend ist die Anwendungsebene, weil Unternehmen dort festlegen können, welche Aktionen tatsächlich erlaubt werden.
„The physics of cybersecurity are changing.“
— Hayete Gallot, Executive Vice President Microsoft Security, Juli 2026.
Für den praktischen Betrieb ergibt sich daraus kein einzelnes Sicherheitsprodukt, sondern eine Kombination mehrerer Kontrollen.
1. Jeder Agent braucht eine eigene Identität
Gemeinsam verwendete API-Schlüssel und Service-Accounts erschweren die Rückverfolgung. Unternehmen sollten autonome Systeme wie eigenständige digitale Identitäten behandeln.
Ein Agent für Rechnungsprüfung benötigt andere Rechte als ein Agent für Softwareentwicklung. Beide über dasselbe privilegierte Konto laufen zu lassen, vergrößert den möglichen Schaden unnötig.
2. Least Privilege muss auch für Maschinen gelten
Agenten sollten nur die Ressourcen erreichen können, die sie für die konkrete Aufgabe benötigen. Schreibrechte sind zu vermeiden, wenn Lesen ausreicht.
Besonders sensible Funktionen können getrennt werden:
| Aktion | Sinnvolle Kontrolle |
|---|---|
| Dokument lesen | beschränkter Read-only-Zugriff |
| Datei löschen | explizite Freigabe oder Sperre |
| E-Mail extern versenden | Bestätigung vor Versand |
| Überweisung auslösen | menschliche Freigabe |
| Benutzerrechte ändern | privilegierter separater Workflow |
| Code in Produktion bringen | Review und Deployment-Gate |
3. Kritische Aktionen brauchen Grenzen
OpenAI empfiehlt bei Agenten unter anderem klar definierte Workflows, strukturierte Datenausgaben und begrenzte Tool-Rechte. Frei formulierte Inhalte sollten nicht ungeprüft direkt in privilegierte Systembefehle umgewandelt werden.
Strukturierte Schnittstellen können beispielsweise nur bestimmte vorher definierte Aktionen erlauben. Statt einem Agenten beliebige Shell-Befehle zu ermöglichen, erhält er eine API mit wenigen zulässigen Funktionen.
4. Human-in-the-loop bleibt bei Hochrisiko-Aktionen relevant
Die CSA berichtete, dass 68 Prozent der Befragten menschliche Kontrolle als „essential“ oder „very important“ einstuften. Besonders häufig verlangten Unternehmen Freigaben beim Zugriff auf sensible Daten, bei Systemänderungen, Finanztransaktionen und der Vergabe von Berechtigungen.
Das Ziel ist nicht, jede Kleinigkeit manuell abzunicken. Kontrollpunkte sollten dort liegen, wo eine Fehlentscheidung schwer rückgängig zu machen wäre.
Monitoring muss Verhalten statt nur Logins erkennen
Die Exabeam-Untersuchung zeigt eine weitere Lücke. 60 Prozent der Security-Leiter setzen laut Bericht bereits spezielle AI-Security- oder Governance-Werkzeuge ein. Gleichzeitig nannten 27 Prozent fehlenden Verhaltenskontext und unzureichende Korrelation als größte Einschränkung ihrer aktuellen Überwachung.
Das ist technisch nachvollziehbar. Ein Agent kann mit korrekter Identität, erlaubtem API-Schlüssel und zulässiger Netzwerkverbindung arbeiten – und dennoch eine Aktion ausführen, die für seinen Auftrag ungewöhnlich ist.
Security-Systeme müssen deshalb nicht nur fragen: „War dieser Zugriff erlaubt?“
Zusätzlich wird relevant:
- Passt die Aktion zur Aufgabe des Agenten?
- Ist die Datenmenge ungewöhnlich?
- Greift er plötzlich auf neue Systeme zu?
- Ändert sich sein normales Verhaltensmuster?
- Folgte der Aktion zuvor ein nicht vertrauenswürdiger Inhalt?
- Beginnt der Agent neue Tools oder Unteragenten zu verwenden?
- Lassen sich alle Schritte einer eindeutigen Nutzeranforderung zuordnen?
Diese Form der Überwachung ähnelt teilweise der bisherigen User and Entity Behavior Analytics. Allerdings müssen künftig neben menschlichen Mitarbeitern auch nichtmenschliche Identitäten und ihre mehrstufigen Entscheidungen berücksichtigt werden.
AI wird gleichzeitig Angriffsfläche und Verteidigungswerkzeug
Die Entwicklung ist nicht einseitig. Dieselben agentischen Systeme, die neue Risiken schaffen, werden zunehmend in Security Operations Centers eingesetzt. Microsoft beschreibt Agentic AI beispielsweise für Erkennung, Untersuchung und Reaktion auf Bedrohungen.
Eine im Juli 2026 veröffentlichte wissenschaftliche Übersichtsarbeit untersuchte 144 peer-reviewte Studien aus den Jahren 2021 bis 2025 zu LLM-basierten Cyberabwehrsystemen.
Die Autoren sehen Fortschritte unter anderem bei Threat Detection und SOC-Automatisierung, stellen aber zugleich fest, dass viele Systeme weiterhin nur mit geringer Autonomie betrieben werden und robuste Sicherheits-, Koordinations- und Governance-Mechanismen fehlen.
Damit entsteht ein technisches Wettrennen: Angreifer können AI nutzen, um Recherche, Codeanalyse und Teile eines Angriffs zu beschleunigen. Verteidiger können dieselbe Technologie einsetzen, um Warnungen zu priorisieren, Muster zu erkennen oder Untersuchungen zu automatisieren.
Microsoft fasste diese Entwicklung im Juli so zusammen, dass autonome Systeme kontinuierlich analysieren und handeln können, während gleichzeitig die Kosten offensiver Aktivitäten sinken.
Die größte Gefahr ist nicht der „böse Roboter“, sondern falsch konfigurierte Autonomie
Der Begriff autonomer AI-Agent erzeugt schnell das Bild einer künstlichen Intelligenz, die sich bewusst gegen ein Unternehmen richtet. Die aktuell dokumentierten Sicherheitsprobleme sind wesentlich nüchterner.
Die wichtigsten Risikofaktoren sind bislang:
- zu umfassende Berechtigungen;
- nicht dokumentierte Agenten;
- gemeinsame oder langlebige Zugangsdaten;
- Prompt Injection;
- unsichere Tool-Aufrufe;
- fehlende Begrenzung von Schreib- und Löschaktionen;
- mangelhafte Protokollierung;
- Agenten, deren Entscheidungen keinem Menschen klar zugeordnet werden können;
- Drittanbieter-Plugins und APIs in der Lieferkette;
- unkontrollierte Verbindungen zwischen mehreren Agenten.
Eine Microsoft-Research-Analyse zu toolfähigen Agenten kommt zu einem ähnlichen Ergebnis. Viele Risiken entstehen demnach nicht ausschließlich durch völlig neue Schwachstellen, sondern durch überprivilegierte Tools, Unterschiede zwischen beabsichtigter Aufgabe und tatsächlicher Fähigkeit sowie sogenannte „ambient authority“ – Rechte, die einem Prozess bereits zur Verfügung stehen, obwohl er sie für die aktuelle Aufgabe gar nicht benötigt.
Genau deshalb kann ein autonomer Agent für Security-Verantwortliche problematischer wirken als ein externer Hacker. Der Hacker muss oft erst hinein. Der Agent ist bereits drin.
Was Security-Teams 2026 konkret prüfen sollten
Unternehmen, die bereits AI-Agenten einsetzen oder deren Einführung planen, benötigen zuerst ein vollständiges Inventar. Dazu gehören selbst entwickelte Agenten ebenso wie Funktionen, die über SaaS-Produkte, Browser-Erweiterungen, Entwicklungswerkzeuge oder Office-Plattformen eingebunden werden.
Anschließend sollte für jeden Agenten dokumentiert werden:
- Besitzer und verantwortliche Abteilung.
- Geschäftszweck.
- Verwendetes Modell.
- Verbundene Datenquellen.
- Tools und APIs.
- Identität und Zugangsdaten.
- Maximale Berechtigungen.
- Aktionen ohne menschliche Freigabe.
- Aktionen mit verpflichtender Freigabe.
- Logging und Aufbewahrung der Protokolle.
- Verfahren zur sofortigen Abschaltung.
- Prozess zum Entzug der Berechtigungen bei Stilllegung.
Gerade der letzte Punkt wird häufig unterschätzt. Eine CSA-Erhebung meldete, dass nur 21 Prozent der Befragten einen formalen Prozess zur Außerbetriebnahme von AI-Agenten besitzen. Bleiben Tokens, Service-Accounts oder Integrationen nach dem Ende eines Projekts aktiv, entsteht eine dauerhafte Schattenidentität innerhalb der Infrastruktur.
Fragen und Antworten zu autonomen AI-Agenten
Warum gelten autonome AI-Agenten als Sicherheitsrisiko?
Weil sie nicht nur Inhalte erzeugen, sondern mit echten Unternehmenssystemen interagieren können. Je nach Berechtigung dürfen sie Dateien lesen, Daten ändern, Anwendungen bedienen oder APIs aufrufen. Fehlkonfigurationen oder manipulierte Eingaben können deshalb reale Folgen haben.
Sind AI-Agenten tatsächlich gefährlicher als Hacker?
Die aktuelle Exabeam-Studie zeigt eine Risikoeinschätzung der befragten Security-Leiter: 48 Prozent stuften problematisch berechtigte AI-Agenten als größte Bedrohung ein. Daraus folgt nicht, dass Agenten statistisch bereits mehr reale Angriffe verursachen als externe Täter.
Was ist bei AI-Agenten eine Prompt Injection?
Dabei werden manipulierte Anweisungen in Inhalte eingebaut, die ein Agent verarbeitet. Der Agent soll dadurch zu einer Handlung gebracht werden, die nicht dem ursprünglichen Auftrag des Nutzers entspricht. Besonders relevant ist das bei Systemen mit Browser-, E-Mail- oder Tool-Zugriff.
Welche Berechtigungen sollten AI-Agenten erhalten?
Nur diejenigen, die für die jeweilige Aufgabe zwingend erforderlich sind. Read-only-Zugänge sind Schreibrechten vorzuziehen, wenn keine Änderungen notwendig sind. Hochkritische Aktionen sollten zusätzliche Freigaben benötigen.
Reicht klassisches IAM für autonome Agenten aus?
Bestehende IAM-Systeme bleiben wichtig, wurden aber primär für menschliche Nutzer entwickelt. Für Agenten kommen Anforderungen wie kurzlebige Maschinenidentitäten, detaillierte Tool-Rechte, Verhaltensüberwachung und lückenlose Zuordnung autonomer Aktionen hinzu.
Wie können Unternehmen das Risiko kurzfristig reduzieren?
Der schnellste Ansatz ist ein Agenten-Inventar kombiniert mit Least Privilege. Unternehmen sollten unbekannte Agenten identifizieren, ungenutzte Tokens entfernen, privilegierte Zugänge begrenzen und für irreversible oder finanzielle Aktionen menschliche Freigaben verlangen.
Die aktuelle Entwicklung zeigt damit keinen Ersatz klassischer Cybersecurity, sondern eine zusätzliche Sicherheitsebene. Firewalls, Endpoint-Schutz, MFA und Zugriffskontrollen bleiben notwendig. Gleichzeitig müssen Unternehmen erstmals Software überwachen, die mit legitimen Rechten selbstständig Entscheidungen treffen und mehrere Systeme miteinander verbinden kann.
Genau diese Kombination erklärt, warum autonome AI-Agenten in den Risikomodellen vieler Security-Verantwortlicher so schnell nach oben gerückt sind. Die zentrale Frage lautet nicht mehr nur, ob ein Angreifer Zugang zu einem System erhält. Unternehmen müssen ebenso nachvollziehen können, was ihre eigenen Agenten mit einem bereits vorhandenen Zugang tun dürfen – und was tatsächlich geschieht.
Sie können dies und weitere nützliche Informationen auf unserer Website nachlesen. Wir empfehlen Ihnen außerdem die Lektüre folgender Artikel: Passkeys auf Android übertragen: Passwortmanager wechseln, ohne Schlüssel neu einzurichten
