KI-Agenten erhalten schneller Zugriff als Verantwortlichkeit nachkommt
Ihre KI-Agents haben bereits Zugriff auf Kundendaten, sensibles geistiges Eigentum und HR-Dateien. Wenn einer davon sich unerwartet verhält, steht Ihr Unternehmen vor der Frage, wer dafür verantwortlich ist.
Das ist das beunruhigende Bild, das die AI-Agent-Adoptionsumfrage von 1Password zeichnet. Befragt wurden 1.000 festangestellte US-Mitarbeiter in Unternehmen mit mindestens 250 Beschäftigten, gleichmäßig verteilt auf IT- und Security-Fachkräfte sowie Entwickler. Die Umfrage wurde vom 26. Mai bis 3. Juni 2026 durchgeführt. 71 Prozent der Befragten gaben an, dass KI-Agents in ihren Unternehmen Zugriff auf Kundendaten, sensibles geistiges Eigentum oder HR-Informationen haben. Nur 35 Prozent verwalten diese Agents im Rahmen bestehender Identity- und Access-Management-Prozesse.
Zugriff ist der sichtbare Teil. Die schwierigere Frage stellen Regulierungsbehörden, Auditoren oder gegnerische Anwälte nach einem Vorfall: Wer hat diesen Zugriff genehmigt, nach welcher Richtlinie, und wo ist der Nachweis? Ein Identity-Team kann sagen, wer es war. Nur eine Kontrolle auf Datenebene zeigt, was wann und unter welcher Richtlinie berührt wurde – und kann dies als Beweis vorlegen. Kiteworks Secure Data Exchange ist genau um diese Unterscheidung herum aufgebaut. Diese Perspektive liegt auch diesem Beitrag zugrunde.
Die Zahlen verdienen eine genaue Betrachtung, denn das Interessante ist nicht, wie viele Agents Zugriff haben, sondern wie wenig Einigkeit darüber herrscht, wer für sie verantwortlich ist.
Wichtige Erkenntnisse
1. Zugriff überholt Verantwortlichkeit.
71 Prozent der befragten US-Mitarbeiter sagen, dass KI-Agents auf Kundendaten, sensibles geistiges Eigentum oder HR-Informationen zugreifen können. Die Verantwortlichkeit für diese Agents ist jedoch auf Teams, Anwender und Führungskräfte verteilt.
2. Verantwortlichkeit ist ungeklärt.
65 Prozent sind der Meinung, dass jemand anderes als die aktuell verantwortliche Person zuständig sein sollte. Damit ist die Verantwortlichkeit für Agents eher eine offene Governance-Frage als ein klar geregeltes Organigramm.
3. Identity-Programme lösen nur einen Teil des Problems.
Nur 35 Prozent verwalten Agents im Rahmen bestehender Identity- und Access-Management-Prozesse. 21 Prozent haben noch keinen Ansatz zur Steuerung des Agent-Zugriffs formalisiert.
4. Zugangsdaten sind der stille Schwachpunkt.
86 Prozent berichten von Problemen mit Zugangsdaten bei nicht-menschlichen Identitäten. 27 Prozent berichten von Sicherheitsvorfällen oder Datenschutzverstößen durch überprivilegierte Agents.
5. Regulierungsbehörden verlangen Beweise, keine Absichtserklärungen.
Die entscheidende Kontrolle belegt, welcher Mensch welchem Agent welche Rechte übertragen hat, auf welche Daten zugegriffen wurde und unter welcher Richtlinie – und dieser Nachweis muss auf Anfrage vorlegbar sein.
Die Umfrage misst Mitarbeiterwahrnehmungen, keine Vorfallberichte
Bevor Sie ein Programm auf Basis einer Zahl aufbauen, klären Sie, was diese Zahl misst. Die 1Password-Umfrage fragte 1.000 US-Mitarbeiter nach ihren Beobachtungen im eigenen Unternehmen. Alle Angaben sind selbstberichtete Werte, die Stichprobe ist ausschließlich US-basiert, und 1Password verkauft Lösungen für Identity- und Secrets-Management – die Schlussfolgerungen zielen also auf die eigene Produktkategorie. Ein kritischer CISO sollte das berücksichtigen.
Das macht die Daten jedoch nicht wertlos. Sie geben eine Richtung vor – und das reicht, wenn sich das Muster in unabhängiger Forschung wiederholt, was später im Beitrag bestätigt wird. Die Umfrage teilt die Stichprobe sauber auf: 500 Entwickler und 500 IT- und Security-Fachkräfte. Dieser Vergleich ist besonders aufschlussreich: Entwickler, die Agents bauen und einsetzen, berichten häufiger von Sicherheitslücken im Agent-Management (67 Prozent) als IT- und Security-Mitarbeiter (57 Prozent).
Lesen Sie das noch einmal: Diejenigen, die den Agents am nächsten stehen, sehen mehr Lücken als die, die für deren Absicherung zuständig sind. Das ist kein Technologieproblem, sondern ein Problem der Transparenz – und Transparenz ist das Erste, was ein Auditor prüft.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es nachweisen?
Jetzt lesen
Governance ist noch im Entwurf, während Zugriff schon produktiv läuft
Beginnen wir mit der Einführung: Fast die Hälfte der Entwickler (46 Prozent) nutzt KI-Agents bereits produktiv, weitere 45 Prozent rechnen damit in den nächsten zwei Jahren. Die Agents sind keine Pilotprojekte in der Sandbox, sondern Teil des Workflows – und laut Umfrage greifen sie auf Daten zu, deren Verlust Haftungsrisiken birgt.
Von allen 1.000 Befragten berichten 62 Prozent von Sicherheitslücken im Agent-Management ihres Unternehmens. Dahinter verbirgt sich eine noch deutlichere Zahl: 33 Prozent der IT- und Security-Fachkräfte wissen nicht, wie viele nicht-menschliche Identitäten oder Agents im Unternehmen eingesetzt werden. Sie können keine Governance für ein Inventar betreiben, das Sie nicht erfassen – und Sie können kein Audit-Protokoll für einen Akteur liefern, den Sie nie registriert haben.
Es folgt die Prozesslücke: Nur 35 Prozent verwalten KI-Agents im Rahmen bestehender Identity- und Access-Management-Prozesse. 21 Prozent haben noch keinen Ansatz zur Steuerung des Agent-Zugriffs formalisiert.
Hier ist die Einordnung entscheidend: Agents sind eine zweite Identitätsklasse neben menschlichen Anwendern. Das Governance-Modell des Unternehmens muss beide unter einer Richtlinie abdecken – nicht ein Programm für Menschen und ein separates, schwächeres für Agents. Ein Role-Based-Access-Control-Modell für Mitarbeiter setzt voraus, dass eine Person Urteilsvermögen ausübt. Ein Agent tut das nicht. Er greift auf alles zu, was ihm erlaubt ist – und das mit Maschinengeschwindigkeit. Deshalb passt Attribute-Based-Access-Control, das bei jeder Anfrage geprüft wird, besser zu Agents als eine statische Rolle. Aus dem gleichen Grund muss AI Data Governance beim Schutz der Daten ansetzen, nicht beim Modell. Security-Teams, die das Problem als Modell-Sicherheitsfrage betrachten, stellen die falsche Frage an die falsche Person – ein Thema, das in why AI agents break traditional security models vertieft wird.
Verantwortlichkeit landet bei dem, der am nächsten dran ist – nicht bei dem, der sie haben sollte
Die Verantwortlichkeitsdaten sind der Teil der Umfrage, den ein Chief Compliance Officer ausdrucken sollte. Die Befragten wurden gefragt, wer in der Praxis für Agent-Aktionen verantwortlich ist. Die häufigste Antwort: Team- oder Abteilungsleitung mit 24 Prozent. Danach folgt der Anwender des Agents mit 19 Prozent, dann die Unternehmensleitung mit 17 Prozent und das Security-Team mit 13 Prozent. Fünf Prozent sagten, der Agent selbst sei verantwortlich.
Denken Sie kurz über diese letzte Zahl nach: Rund jeder zwanzigste Befragte arbeitet in einem Unternehmen, in dem ein Stück Software als verantwortliche Partei gilt. Kein Regulator, Gericht oder Aufsichtsrat akzeptiert diese Antwort, denn Software kann weder bestraft noch sanktioniert oder befragt werden.
Die Verteilung auf die anderen vier Antworten zeigt das eigentliche Problem: Es gibt keinen eindeutigen Verantwortlichen. Und als 1Password fragte, ob die aktuell verantwortliche Person die richtige sei, sagten 65 Prozent, jemand anderes sollte es sein. Das ist ein Verantwortlichkeitsvakuum, das entsteht, wenn eine Funktion Zugriff gewährt und eine andere das Risiko trägt. Das spiegelt das Argument in the authority gap in AI workflows wider, wo delegierte Zuständigkeiten nie dokumentiert werden.
Bei diesen Befragten ist die Zuständigkeit für KI-Sicherheit ungeklärt – erwarten Sie also keine Lösung durch ein sauberes Organigramm. Behandeln Sie die Unklarheit als zu schließendes Problem, indem Sie für jeden Agent einen namentlich benannten Verantwortlichen festlegen.
Der regulatorische Rahmen ist einfach – und sollte Ihre Prioritäten bestimmen. Regulierungsbehörden regulieren Daten, nicht Modelle. Die HIPAA Security Rule verlangt beispielsweise von betroffenen Unternehmen und Geschäftspartnern, eine eindeutige Identifikation für Anwender zu vergeben und Audit-Kontrollen zu implementieren, die Aktivitäten in Systemen mit elektronischen Gesundheitsdaten aufzeichnen und prüfen. Die Regel kennt keine KI-Ausnahme. Nach meiner Auffassung muss ein Agent, der Patientendaten liest, genauso identifizierbar und nachvollziehbar sein wie eine Pflegekraft. Ein HIPAA-Compliance-Programm, das Agent-Zugriffe nicht zuordnen kann, hat eine Evidenzlücke, bevor die erste Beschwerde eingeht. Der Praxistest steht in you cannot govern what you cannot attribute.
Zugangsdaten sind der stille Schwachpunkt
Agents authentifizieren sich mit Zugangsdaten, und die Umfrage legt nahe, dass diese so gehandhabt werden, wie ein überlastetes Team alles behandelt, was nicht für Skalierung geplant war. 86 Prozent aller Befragten berichten von Problemen mit Zugangsdaten bei nicht-menschlichen Identitäten, 27 Prozent von Sicherheitsvorfällen oder Datenschutzverstößen durch überprivilegierte nicht-menschliche Identitäten.
Der Entwickler-Blick ist noch deutlicher: Von den 500 Entwicklern geben 40 Prozent an, Agents dauerhaften Zugriff auf Systeme oder Zugangsdaten zu gewähren, 24 Prozent hinterlegen Zugangsdaten im Code, und 20 Prozent teilen Zugangsdaten über Slack oder E-Mail. 43 Prozent nutzen keinen dedizierten Secrets Manager oder Vault.
Gerade dieser letzte Punkt ist kritisch, denn er zeigt die Schwäche von Richtlinien ohne Durchsetzung. Viele Teams haben einen Vault – viele aber auch einen Shortcut. Wenn ein Agent ein dauerhaftes Passwort verwendet, das jemand vor Monaten in eine Nachricht kopiert hat, weichen die Zugriffskontrolle auf dem Papier und die tatsächliche Zugriffskontrolle voneinander ab – und nur eine davon taucht im Audit-Trail auf. Das ist die gleiche Lücke, die in permissions do not determine what AI should be allowed to use beschrieben wird: Was ein Agent darf und was er können sollte, sind unterschiedliche Fragen.
Compliance-Verantwortliche sollten das aus einem bestimmten Grund beachten: Eine überprivilegierte nicht-menschliche Identität kann Datenminimierung unterlaufen, sobald sie mehr liest als für die Aufgabe nötig – und das geschieht still, ohne dass ein Anwender es meldet.
Unabhängige Forschung bestätigt das Muster
Eine einzelne Anbieterumfrage beweist wenig. Drei weitere Quellen weisen jedoch in die gleiche Richtung, auch wenn zwei davon Anbieterforschung sind.
Beginnen wir mit der CISO-Perspektive: Die Vorlon-Umfrage unter CISOs, berichtet von IT Brief UK, befragte 500 US-CISOs aus Unternehmen mit mindestens 500 Mitarbeitern zum Kalenderjahr 2025. 30,8 Prozent berichteten von unautorisiertem Datenabfluss durch SaaS-AI-Integrationen. 86,8 Prozent gaben an, dass die Transparenz darüber, welche Daten AI-Tools mit SaaS-Anwendungen austauschen, eine Schwachstelle ihrer aktuellen Tools ist. Vorlon verkauft eine Ecosystem-Security-Plattform – bewerten Sie die Zahlen also als Anbieterforschung. Die Transparenzzahl ist die relevante.
Diese Transparenz-Feststellung deckt sich mit den 1Password-Daten – nur aus einer anderen Perspektive im Unternehmen. CISOs berichten von begrenzter Transparenz beim Datenaustausch zwischen AI-Tools und SaaS-Anwendungen, während 1Password-Befragte von verteilter Verantwortlichkeit für Agents sprechen. Beide zeigen strukturelle Lücken, auch wenn sie unterschiedliche Aspekte messen.
Nun zur Praxisperspektive aus Kiteworks-Forschung: Der Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report sammelte im zweiten Quartal 2026 Antworten von 459 Security-, Compliance- und Technologie-Profis – alle Angaben sind selbstberichtete Werte. 65 Prozent entdeckten, dass Mitarbeiter nicht genehmigte AI-Tools mit Unternehmensdaten nutzen. Nur 30 Prozent hatten einen formalen AI-Kill-Switch oder eine Agent-Terminationsfunktion implementiert. Schatten-AI und unkontrollierte Agents sind zwei Seiten des gleichen Problems: Zugelassene und nicht zugelassene Tools greifen auf Daten zu, die niemand dokumentiert hat.
Abschließend die Regierungsansicht: Am 20. August 2026 veröffentlichte das britische National Cyber Security Centre einen Blogbeitrag, Managing the cyber risk of agentic AI. Die Empfehlungen: Jeder Agent sollte eine eigene Identität haben, Zugangsdaten sollten möglichst kurzlebig sein, benannte Personen oder Gruppen sollten für Agentic-AI-Aktivitäten verantwortlich sein, bei denen unbeabsichtigte Aktionen schwerwiegende Folgen hätten. Unternehmen sollen definieren, wann ein Agent stoppen und menschliche Freigabe einholen muss, und Logs sollten möglichst unveränderbar sein. Außerdem sollten Unternehmen jederzeit Agent-Aktivitäten sofort stoppen können. Diese Liste ist eine Evidenz-Checkliste – jeder Punkt entspricht einer möglichen Regulatorenfrage.
Warum Identität allein keinen Nachweis liefert
Identität beantwortet eine Frage zuverlässig: Wer oder was fragt an? Auditoren und Regulierungsbehörden stellen aber vier Fragen: Wer hat delegiert, auf welche Daten wurde zugegriffen, nach welcher Richtlinie – und können Sie das beweisen? Die erste ist eine Identitätsfrage. Die anderen drei sind Fragen auf Datenebene. Das ist der Punkt aus identity knows who, data knows what – und deshalb kann ein Unternehmen ein sauberes IAM-Programm haben und trotzdem bei einer Evidenzanfrage scheitern.
Die Wunschliste der Umfrage bestätigt diese Lücke: Gefragt, was sie für den Ausbau des Agent-Einsatzes benötigen, wünschen sich 53 Prozent klare Verantwortlichkeit für Agent-Aktionen, 52 Prozent eine zentrale Übersicht über Zugriffe von Menschen und Agents, und 51 Prozent einen vollständigen Audit-Trail. Nur 5 Prozent sagen, sie brauchen nichts. Allen drei Wünschen ist gemeinsam: Es geht nicht um ein besseres Modell, sondern um Evidenz- und Attributionskontrollen.
Das ist das Architekturargument für Governance auf Datenebene. Kiteworks Compliant AI steuert Agent-Interaktionen mit regulierten Daten auf Datenebene, nicht auf Modellebene. Die Durchsetzung hängt also nicht von Prompts, Safety-Filtern oder bestimmten Agent-Frameworks ab. Jede Interaktion durchläuft vier Prüfungen: Der Agent wird via OAuth 2.0 authentifiziert und mit dem menschlichen Autorisierer verknüpft. Der Zugriff wird anhand von Agent-Identität, Datenklassifikation und Kontext geprüft. Die Daten werden mit FIPS 140-3 validierter Verschlüsselung während der Übertragung und im ruhenden Zustand geschützt. Und jede Interaktion landet mit voller Attribution in einem manipulationssicheren Audit-Trail, der in Echtzeit an das SIEM gestreamt wird.
Der Kiteworks Secure MCP Server wendet dieses Muster auf KI-Clients wie Claude und Copilot an. Jede Anfrage wird anhand von rollen- und attributbasierten Kontrollen geprüft, sodass ein KI-Client nur die Daten erhält, die die Richtlinie erlaubt. Jeder Datei- und Ordnerzugriff sowie jede Datenabfrage ist autorisiert, durchgesetzt und protokolliert. Durch OAuth 2.0-Authentifizierung übernimmt jede KI-Operation die bestehenden Berechtigungen des Anwenders – Mensch und Agent, der für diesen Menschen arbeitet, unterliegen einer Richtlinie und einem Audit-Trail. Die Data Policy Engine macht diese einheitliche Richtlinie kanalübergreifend durchsetzbar, und die Audit-Logs machen sie für Regulatoren nachvollziehbar.
Das Designprinzip ist Parität: Governance, die Menschen abdeckt, aber Agents nicht, lässt eine schnell wachsende Gruppe von Datenkonsumenten außerhalb der Nachweiskette. Governance, die Agents abdeckt, aber die delegierenden Menschen ignoriert, unterbricht die Verantwortlichkeitskette. Beides fällt im Audit durch.
Was Sie vor der nächsten Audit-Anfrage ändern sollten
Für all das braucht es keine neue Tool-Kategorie, sondern zuerst eine Entscheidung. Beginnen Sie mit den Entscheidungen, denn Technologie setzt nur um, was jemand festgelegt hat.
Bestimmen Sie einen Verantwortlichen für jeden Agent. Die 65 Prozent, die sagen, jemand anderes sollte zuständig sein, zeigen: Die Zuweisung wurde nie getroffen – also holen Sie das nach. Der Verantwortliche kann eine Rolle statt einer Person sein, aber es muss eine benannte Rolle sein, die ein Regulator ansprechen kann. Hier beginnt auch zero trust für generative KI: Kein Agent ist standardmäßig vertrauenswürdig, und jeder Agent ist an einen Menschen gebunden, der die Verantwortung trägt.
Zählen Sie, was Sie haben. Wenn ein Drittel Ihrer IT- und Security-Mitarbeiter nicht sagen kann, wie viele Agents und nicht-menschliche Identitäten es gibt, ist ein Inventar der erste Schritt. Dokumentieren Sie auch, welche Zugangsdaten jeder Agent besitzt und wo diese gespeichert sind.
Führen Sie Agents unter dieselbe Identity- und Access-Management-Governance wie Menschen, mit kurzlebigen Zugangsdaten und ohne dauerhafte Geheimnisse in Chat-Tools. Ergänzen Sie dann Richtlinien auf Datenebene, sodass Identität den Zugang steuert und Richtlinien den Abfluss regeln.
Testen Sie den Kill Switch. Nur 30 Prozent der Befragten in der Kiteworks-Studie haben einen implementiert. Eine Kontrolle, die nie getestet wurde, ist nur eine Hypothese. Führen Sie eine Übung durch, bei der ein Agent gestoppt wird, und messen Sie, wie lange es dauert, exakt zu zeigen, auf welche Daten er zugegriffen hat.
Üben Sie schließlich die Evidenzanfrage: Wählen Sie einen Agent, eine Woche und eine typische Regulatorenfrage – und liefern Sie den Nachweis. Dauert das Wochen, haben Sie die Lücke vor dem Prüfer gefunden.
Das Muster aus Umfrage, CISO-Forschung und NCSC-Empfehlungen ist eindeutig: Zugriff kommt zuerst, Verantwortlichkeit hinkt hinterher. Die Unternehmen, die diese Lücke schließen, behandeln Agent-Zugriffe von Anfang an als gesteuerte, zuordenbare und nachweisbare Aktivität.
Erfahren Sie mehr über die Steuerung von KI-Agent-Datenzugriffen in regulierten Umgebungen – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
In der Regel nicht. Regulierungsbehörden knüpfen Verpflichtungen an die Daten und das Unternehmen, das sie hält – unabhängig davon, ob eine Person oder ein Agent auf die Daten zugreift. Die Anforderungen der HIPAA Security Rule an eindeutige Benutzeridentifikation und Audit-Kontrollen enthalten keine Ausnahme für KI. Ein Agent, der auf elektronische Gesundheitsdaten zugreift, muss also nachvollziehbar sein. Behandeln Sie Agents als zweite Identitätsklasse im selben Governance-Modell und ordnen Sie ihre Aktivitäten den gleichen GRC-Nachweisen zu, die Sie bereits für menschliche Anwender erzeugen.
Die Umfrage zeigt, dass Unternehmen dies noch nicht eindeutig geregelt haben. Die Befragten nannten Teamleitung (24 Prozent), Anwender (19 Prozent), Unternehmensleitung (17 Prozent) und Security-Team (13 Prozent). 65 Prozent sagten, jemand anderes sollte verantwortlich sein. Der nachvollziehbare Ansatz ist, jedem Agent vor dem Einsatz einen benannten Verantwortlichen zuzuweisen und den Agent mit dem Menschen zu verknüpfen, der seinen Workflow delegiert hat. Kiteworks Compliant AI verknüpft jeden Agent mit dem autorisierenden Menschen und protokolliert alle Interaktionen mit vollständiger Attribution im Audit-Trail – so ist der Verantwortliche sichtbar und muss nicht nachträglich rekonstruiert werden.
Nutzen Sie sie als Orientierung, nicht als Beweis. Die 1Password-Umfrage ist selbstberichtete US-Stichprobe und stammt von einem Anbieter für Identity- und Secrets-Management. Ihr Wert liegt darin, dass andere Quellen – etwa Vorlons CISO-Studie und der NCSC-Blog zur Agentic AI – in die gleiche Richtung weisen. Bauen Sie Ihr Programm auf dem eigenen Inventar und Evidenztests auf und nutzen Sie die Umfrage, um deren Durchführung zu begründen. Ein zero trust data exchange-Ansatz basiert auf Verifikation statt Zusicherung – das gilt für Forschung wie für Zugriffe.
Teilweise. Nur 35 Prozent der Befragten verwalten Agents im Rahmen bestehender IAM-Prozesse. Identität beantwortet, wer anfragt – aber nicht, auf welche Daten ein Agent zu welchem Zweck zugreifen darf. Erweitern Sie die Identity-Governance auf Agents und ergänzen Sie Richtlinien, die bei jeder Anfrage anhand von Datenklassifikation und Kontext geprüft werden, damit ein Agent nur die minimal notwendigen Daten erhält. Die HIPAA Minimum Necessary Rule ist ein gutes Modell für dieses Prinzip. Der Kiteworks Secure MCP Server zeigt, wie eine Durchsetzung pro Anfrage vor KI-Clients platziert werden kann.
Sie sollten nachweisen können, welcher Mensch den Agent delegiert hat, auf welche Daten er zugegriffen hat, welche Richtlinie dies erlaubt hat, ob die Daten verschlüsselt waren und einen manipulationssicheren Log aller Aktionen vorlegen. Üben Sie die Erstellung dieses Nachweispakets und messen Sie die Zeit. In der Umfrage gaben 51 Prozent an, dass ein vollständiger Audit-Trail für die Ausweitung des Agent-Einsatzes wichtig ist – das ist ein sinnvoller Standard. Prüfen Sie zunächst, ob Ihre Audit-Logs Agent-Aktivitäten mit derselben Attribution wie menschliche Aktivitäten erfassen, und üben Sie dann die Nachweisanfrage.
Weitere Ressourcen
- Blog Post
Zero‑Trust-Strategien für kosteneffizienten KI-Datenschutz - Blog Post
Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blog Post
Für Ihre Daten gibt es kein „–dangerously-skip-permissions“ - Blog Post
Regulierungsbehörden fragen nicht mehr nach einer KI-Policy. Sie wollen den Nachweis, dass sie funktioniert.