Was ist Schatten-KI: Die verborgene Bedrohung, die Unternehmen 670.000 $ pro Datenleck kostet

Shadow AI bezeichnet die nicht genehmigte Nutzung von KI-Tools, Modellen und Agenten durch Mitarbeiter ohne Wissen oder Genehmigung der IT-Abteilung. Diese Praxis ist weit verbreitet und für Sicherheitsteams weitgehend unsichtbar — genau das macht sie so kostspielig.

Laut dem IBM-Bericht 2025 zahlen Organisationen mit hohem Shadow-AI-Anteil 670.000 $ mehr pro Datenpanne als solche mit geringem oder keinem Shadow-AI-Anteil. Das ergibt eine erwartete Gesamtsumme von 4,63 Mio. $. Diese Differenz spiegelt unkontrollierte Datenflüsse, ungesteuerten Modellzugriff und Zugangsdaten wider, die außerhalb jedes Sicherheitsperimeters an KI-Dienste Dritter übermittelt werden.

Das Ausmaß lässt sich schwerer abtun, als die meisten Sicherheitsteams erwarten. Entwickler, Finanzabteilungen, HR und der operative Bereich setzen KI-Tools nach eigenem Ermessen ein. Dieser Artikel erläutert, wie Shadow AI in Unternehmensumgebungen tatsächlich aussieht, warum es zu Sicherheits- und Compliance-Risiken führt und was IT-Teams tun können, um dem zuvorzukommen.

Was ist Shadow AI?

Shadow AI umfasst jedes KI-Tool, Modell, Plugin oder jeden Agenten, der innerhalb einer Organisation ohne ausdrückliche IT- oder Sicherheitsgenehmigung verwendet wird. Es befindet sich an der Schnittstelle zwischen Shadow IT und generativer KI und erbt die Governance-Blindstellen des ersteren, während es die Datenverarbeitungsrisiken der letzteren hinzufügt. Laut Varonis-Daten haben 98 % der Organisationen Mitarbeiter, die nicht genehmigte Apps nutzen, einschließlich Shadow AI.

Der Umfang ist größer, als die meisten Sicherheitsteams annehmen.

KI-Agenten stellen eine qualitative Verschiebung des Risikos dar. Eine Tabelle, die in einem nicht genehmigten Cloud-Speicher liegt, ist ein Datenexpositionsproblem. Ein KI-Agent mit delegiertem Zugriff auf E-Mail, Kalender und Dateisystem ist ein Access-Governance-Problem.

Shadow IT vs. Shadow AI: Den Risikomultiplikator verstehen

Shadow IT und Shadow AI haben gemeinsam, dass Mitarbeiter Tools außerhalb der Sichtbarkeit der IT nutzen. Das Risikoprofil ist jedoch grundlegend unterschiedlich.

Shadow IT (nicht genehmigte SaaS, privater Cloud-Speicher, nicht verwaltete Geräte) verursacht primär Datenhaltungs- und Compliance-Probleme. Daten liegen irgendwo, wo die IT keine Kontrolle hat. Die Exposition ist größtenteils statisch.

Shadow AI verarbeitet Daten. Es analysiert sie, fasst sie zusammen, generiert Ausgaben daraus und handelt im Fall von agentenbasierten Systemen autonom danach. Die Exposition ist dynamisch und oft irreversibel.

Das SaaS-Wildwuchs-Problem verstärkt dies. Mitarbeiter nutzen über 665 KI-Tools in einer typischen Unternehmensumgebung, laut der Analyse von Harmonic Security von 22 Millionen KI-Prompts in Unternehmen (2025). Sechs Anwendungen sind für 92,6 % der Exposition sensibler Daten verantwortlich, aber die verbleibenden 659 zu blockieren ist operativ zwecklos und zerstört die Produktivität. Die Governance-Herausforderung liegt in Sichtbarkeit, Klassifizierung und kontrolliertem Zugriff.

Die finanziellen Auswirkungen: Warum Shadow AI Unternehmen 670.000 $ pro Datenpanne kostet

Laut dem IBM-Bericht „Cost of a Data Breach" 2025 erhöhen Datenpannen mit hohem Shadow-AI-Anteil die durchschnittlichen Kosten um 670.000 $ im Vergleich zu solchen mit geringem oder keinem Shadow-AI-Anteil — ein Anstieg von 16 %, der die erwartete Gesamtsumme auf 4,63 Mio. $ pro Vorfall bringt.

Zwei zugrunde liegende Statistiken erklären den Mechanismus:

• 97 % der Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlebten, hatten keine angemessenen KI-Zugriffskontrollen.
• 63 % der betroffenen Organisationen hatten keine Governance-Richtlinien für die Verwaltung von KI oder die Erkennung nicht autorisierter Nutzung.

Die Kausalkette ist direkt. Mitarbeiter führen KI-Tools schneller ein, als Sicherheitsteams sie bewerten können. Ohne Zugriffskontrollen fließen sensible Daten in Modelle, die die IT nie genehmigt hat und nicht auditieren kann. Wenn eine Datenpanne auftritt, verlängert das Fehlen von Logging und Governance die Erkennungs- und Eindämmungszeit — und in der Ökonomie von Datenpannen ist Zeit der primäre Kostentreiber.

Für CFOs ist die Rechnung eindeutig: Die erwarteten Kosten einer Shadow-AI-bezogenen Datenpanne betragen 4,63 Mio. $. Die Kosten eines KI-Governance-Programms für Unternehmen — Zugriffskontrollen, CASB-Bereitstellung, Lizenzierung genehmigter Tools, Credential-Management — sind nur ein Bruchteil davon. Das risikobereinigte Argument für Governance-Investitionen ist nicht mehrdeutig.

Sicherheitsteams haben auch eine DLP-Blindstelle (Data Loss Prevention): Die meisten DLP-Tools prüfen strukturierte Datenübertragungen. Konversationelle KI-Prompts sind unstrukturierter Text. Ein Mitarbeiter, der einen Datenbank-Verbindungsstring in einen Free-Tier-LLM-Account eingibt, löst keinen DLP-Alarm aus. Die Daten verlassen die Organisation unbemerkt.

Die versteckte Bedrohung: Credential-Exposition und KI-Agenten

Das direkteste und am wenigsten berichtete Shadow-AI-Risiko ist die Credential-Exposition. Mitarbeiter fügen ständig Secrets in öffentliche LLMs ein, weil es der schnellste Weg ist, Hilfe zu bekommen.

Ein Entwickler, der ein Produktionsproblem debuggt, fügt einen Datenbank-Verbindungsstring zusammen mit dem Fehlerprotokoll in ChatGPT ein. Ein DevOps-Ingenieur teilt eine Kubernetes-Konfigurationsdatei, einschließlich eingebetteter API-Keys, mit einem KI-Assistenten, um nach einem Deployment-Fehler zu fragen. Ein Finanzanalyst lädt eine Q3-Prognosetabelle in ein nicht genehmigtes KI-Zusammenfassungs-Tool hoch, um sich auf eine Vorstandssitzung vorzubereiten.

Laut der Analyse von Harmonic Security von 22,4 Millionen KI-Prompts in Unternehmen (2025) machen Code, juristische Dokumente und Finanzdaten 74,5 % der an KI-Tools exponierten sensiblen Daten aus. Quellcode allein enthält eingebettete Secrets (fest codierte API-Keys, Zugriffstokens und Dienstkonto-Credentials), die die meisten Entwickler als Konfigurationsdetails und nicht als sicherheitskritisches Material behandeln.

Die agentenbasierte Risikoebene fügt eine zweite Angriffsfläche hinzu. KI-Agenten — Systeme, die delegierte OAuth-Berechtigungen zum Lesen von Dateien, Senden von E-Mails, Abfragen von Datenbanken und Aufrufen externer APIs verwenden — arbeiten mit breiten Zugriffserteilungen, die nie für autonome Nutzung konzipiert wurden. Wenn ein Mitarbeiter einen Produktivitäts-KI-Agenten autorisiert, auf seine Unternehmens-E-Mails und seinen Dateispeicher zuzugreifen, hat dieser Agent möglicherweise breitere effektive Berechtigungen, als es die Rolle des Mitarbeiters rechtfertigen würde.

Die meisten Organisationen haben kein Inventar darüber, welche Agenten welche OAuth-Erteilungen halten, und keinen Prozess, um sie zu widerrufen, wenn ein Mitarbeiter ausscheidet.

16,9 % aller Expositionen sensibler Daten im Datensatz von Harmonic flossen durch private Free-Tier-Accounts — wo die IT keine Sichtbarkeit, keinen Audit-Trail hat und Daten zum Training öffentlicher Modelle verwendet werden können (Harmonic Security, 2025).

Die Kombination aus Credential-Exposition und agentenbasiertem Zugriff erzeugt ein kumulierendes Risiko: Ein kompromittierter KI-Agent mit Zugriff auf einen Tresor nicht verwalteter Secrets kann weit mehr exfiltrieren als ein einzelner geleakter API-Key.

Reale Datenpannen im Zusammenhang mit Shadow AI

Diese drei Vorfälle haben einen gemeinsamen Nenner: In jedem Fall griff eine KI-Komponente, die innerhalb einer vertrauenswürdigen Umgebung operierte, auf weit mehr Daten zu, als irgendjemand ausdrücklich autorisiert hatte.

Microsoft AI Research: 38 TB interner Daten exponiert

Was geschah. Ein Microsoft-KI-Forschungsteam veröffentlichte einen offenen Datensatz auf GitHub zum Training von Bilderkennungsmodellen. Um die Dateien zu teilen, verwendeten sie einen Azure-SAS-Token — konfigurierten ihn aber mit vollem Zugriff auf das gesamte Storage-Konto anstatt nur auf den Zielordner. Jeder, der dem Repository-Link folgte, erhielt uneingeschränkten Zugriff auf 38 TB privater Unternehmensdaten.

Was geleakt wurde. Workstation-Backups von zwei Mitarbeitern, über 30.000 interne Microsoft-Teams-Nachrichten von 359 Mitarbeitern, private Schlüssel, Dienstpasswörter und geheime Tokens. Der Token hatte „Vollzugriff"-Berechtigungen und war auf ein Ablaufdatum im Jahr 2051 eingestellt.

Warum dies ein Shadow-AI-Vorfall ist. Die Datenpanne geschah direkt im Rahmen der KI-Datensatzarbeit. Forscher, die schnell KI-Modelle ausliefern wollten, umgingen standardmäßige Zugriffsprüfungsverfahren. Wiz Research, das die Exposition entdeckte, beschrieb es als „eine neue Risikoklasse, der Organisationen bei beschleunigter KI-Einführung gegenüberstehen". Da der Token Schreibzugriff gewährte, hätte ein Angreifer bösartigen Code in KI-Modelle einschleusen können, die andere Entwickler aktiv herunterluden.

Reaktion. Wiz machte den Vorfall im September 2023 öffentlich. Microsoft widerrief den Token und schloss den Zugriff. Der Fall wurde zu einem Referenzbeispiel im IBM-Bericht „Cost of a Data Breach" 2025.

Slack AI: Datenexfiltration aus privaten Kanälen via Prompt Injection

Was geschah. Forscher bei PromptArmor fanden eine kritische Schwachstelle in Slack AI — dem integrierten Assistenten, der es Mitarbeitern ermöglicht, ihre gesamte Slack-Historie in natürlicher Sprache abzufragen. Die Angriffsklasse war indirekte Prompt Injection: Ein Bedrohungsakteur postet eine Nachricht in einem öffentlichen Kanal, die versteckte Anweisungen für das LLM enthält. Wenn ein Ziel Slack AI verwendet, um nach Informationen zu suchen, behandelt das Modell die bösartigen Anweisungen als legitim und führt sie aus.

Was gefährdet war. API-Keys und andere Secrets, die in privaten Kanälen gespeichert waren, auf die der Angreifer keinen direkten Zugriff hatte. Slack AI aggregierte Daten sowohl aus öffentlichen als auch aus privaten Kanälen bei der Beantwortung von Benutzeranfragen — dieser kanalübergreifende Zugriff war der Angriffsvektor. Ein zweites Szenario ermöglichte es Slack AI, einen Phishing-Link zu rendern, um Credentials abzufangen.

Warum dies ein Shadow-AI-Vorfall ist. Slack AI ist ein Lehrbuchfall für eingebettete Shadow AI: eine KI-Funktion, die innerhalb eines bereits genehmigten Unternehmenstools aktiviert wird, ohne separate Sicherheitsprüfung ihrer KI-Komponente. IT-Teams hatten keine Sichtbarkeit darüber, dass der Assistent auf private Kanäle zugreifen und als Exfiltrationsvektor dienen konnte. Am 14. August 2024 (am selben Tag, an dem die Schwachstelle offengelegt wurde) erweiterte Slack die Fähigkeiten des Assistenten, um hochgeladene Dokumente und Google-Drive-Dateien zu indexieren, was die Angriffsfläche weiter vergrößerte.

Reaktion. Slack klassifizierte das Verhalten zunächst als „beabsichtigt", veröffentlichte dann aber einen Patch. Das Unternehmen erklärte, es gebe „keine Hinweise auf unbefugten Zugriff auf Kundendaten". Der Vorfall wurde weithin als erster dokumentierter Fall von Datenexfiltration via Prompt Injection in einem produktiven Enterprise-SaaS-Produkt behandelt.

Microsoft 365 Copilot: EchoLeak, Zero-Click-Datenexfiltration

Was geschah. Forscher bei Aim Security veröffentlichten CVE-2025-32711 (CVSS 9.3 — Kritisch) in Microsoft 365 Copilot, genannt EchoLeak. Es ist die erste dokumentierte Zero-Click-Prompt-Injection mit bestätigter Datenexfiltration in einem produktiven KI-System. Der Angriff erforderte keine Aktion des Opfers.

Wie es funktionierte. Ein Angreifer sendete dem Ziel eine E-Mail mit versteckten Anweisungen, die als Markdown-Links im Referenzstil getarnt waren. Als Copilot die E-Mail verarbeitete, umging es den eingebauten XPIA-Klassifikator (Prompt-Injection-Schutz) und den Link-Schwärzungsmechanismus. Copilot griff dann automatisch auf die Dateien des Opfers in OneDrive, SharePoint und Teams zu, konstruierte eine URL über die Microsoft Teams Proxy API — die auf Copilots Whitelist steht — und sendete die Daten an den Server des Angreifers. Keine Klicks erforderlich.

Was gefährdet war. Jede Datei oder Konversation, auf die der Benutzer innerhalb von Microsoft 365 zugreifen konnte: OneDrive-Dokumente, SharePoint-Dateien, Teams-Nachrichten. Bis Mitte 2024 betrieben laut Netrix Global bereits mehr als 10.000 Unternehmen Microsoft 365 Copilot.

Warum dies ein Shadow-AI-Vorfall ist. EchoLeak repräsentiert die nächste Generation des Shadow-AI-Risikos: ein KI-Agent mit breitem Zugriff auf Unternehmensdaten, der innerhalb eines genehmigten Tools operiert, ohne angemessene Sicherheitsprüfung seiner KI-Komponente. Der Angriff hinterließ keine Spuren in Standard-Überwachungssystemen — der gesamte Datenverkehr lief über vertrauenswürdige Microsoft-Domains.

Reaktion. Microsoft veröffentlichte im Juni 2025 einen Notfall-Patch. Der Fall veränderte grundlegend, wie die Branche das Risiko für KI-Agenten mit breiten Zugriffsberechtigungen bewertet.

Shadow AI im Unternehmen erkennen und verhindern

Erkennung und Prävention erfordern einen strukturierten Ansatz. KI vollständig zu verbieten funktioniert nicht — die Daten von Harmonic zeigen, dass Mitarbeiter KI-Tools unabhängig von Richtlinien nutzen, oft über private Geräte und Accounts, die Unternehmenskontrollen vollständig umgehen. Das Ziel ist Governance, nicht Verbot.

Das 5-Schritte-Framework für Shadow-AI-Governance

1. KI-Exposition ermitteln. Setzen Sie Netzwerküberwachung ein, um ausgehenden Datenverkehr zu bekannten KI-Domains zu identifizieren. Verwenden Sie einen Cloud Access Security Broker (CASB), um Einblick in die SaaS-Nutzung auf verwalteten Geräten zu erhalten. Prüfen Sie Browser-Erweiterungen auf Unternehmens-Endpunkten — viele KI-Tools operieren als Erweiterungen mit breitem Zugriff auf Seiteninhalte. Erstellen Sie ein Inventar dessen, was tatsächlich verwendet wird, bevor Sie Richtlinien schreiben.
2. Richtlinien für akzeptable Nutzung definieren. Klassifizieren Sie KI-Tools in drei Stufen: genehmigt (Enterprise-lizenziert, Datenverarbeitungsvereinbarungen vorhanden), bedingt (nur für nicht sensible Aufgaben erlaubt) und verboten (keine Datensouveränitätskontrollen, öffentliches Modelltraining). Veröffentlichen Sie die Richtlinie.
3. RBAC für KI-Tools implementieren. Rollenbasierte Zugangskontrolle (RBAC) gilt für den Zugriff auf KI-Tools genauso wie für jedes andere System. Entwickler sollten keinen Zugriff auf Finanz-KI-Tools haben. Finanzteams sollten keinen Zugriff auf Code-Repositories haben, die in KI-Pipelines eingespeist werden. Beschränken Sie Zugriffserteilungen auf das für jede Rolle erforderliche Minimum. Prüfen Sie vierteljährlich.
4. Genehmigte Alternativen bereitstellen. Mitarbeiter setzen Shadow AI ein, weil genehmigte Tools zu langsam zu beschaffen oder für die Aufgabe unzureichend sind. Stellen Sie für jede verbotene Tool-Kategorie eine genehmigte Alternative mit gleichwertiger Funktionalität bereit. Wenn Entwickler einen KI-Coding-Assistenten benötigen, geben Sie ihnen einen mit Enterprise-Datenkontrollen. Governance ohne Befähigung erzeugt Unmut und Workarounds.
5. Die zugrunde liegenden Credentials sichern. Dies ist der Schritt, den die meisten Governance-Frameworks überspringen. Selbst mit Richtlinien und CASB können Mitarbeiter, die direkten Zugriff auf rohe API-Keys, Datenbankpasswörter und Dienstkonto-Credentials haben, diese in jedes Tool einfügen. Die Zentralisierung des Secrets-Managements — sodass Credentials gespeichert, injiziert und programmatisch rotiert werden, anstatt manuell kopiert zu werden — entfernt den direktesten Pfad von Shadow AI zur Credential-Kompromittierung.

Wie Passwork die Grundlage gegen Shadow-AI-Risiken sichert

Sie können einen Mitarbeiter nicht physisch daran hindern, einen Browser-Tab zu öffnen und in ein öffentliches LLM zu tippen. Was Sie kontrollieren können, ist, worauf er Zugriff zum Einfügen hat.

Das Kernprinzip: Klartext aus der Gleichung entfernen

Wenn API-Keys, Datenbank-Credentials, Produktions-Secrets und Dienstkonto-Passwörter in einem zentralisierten verschlüsselten Tresor liegen — auf den programmatisch zugegriffen wird anstatt manuell zu kopieren — sinkt das Credential-Expositionsrisiko durch Shadow AI erheblich. Der Entwickler, der ein Produktionsproblem mit einem KI-Assistenten debuggen möchte, kann den Datenbank-Verbindungsstring nicht einfügen, weil er ihn nie im Klartext hatte.

Was Passwork bietet

Passwork ist sowohl als Self-Hosted-Deployment als auch als Cloud-gehostete Lösung verfügbar. Beide teilen dieselbe Kernarchitektur: AES-256-Verschlüsselung unter einem Zero-Knowledge-Modell, bei dem Credentials clientseitig verschlüsselt werden, bevor sie das Gerät verlassen.

Vier Kontrollen sind im Shadow-AI-Kontext am wichtigsten:

• Rollenbasierte Zugangskontrolle. Administratoren beschränken den Tresorzugriff auf bestimmte Teams und Rollen. Ein Entwickler erhält Zugriff auf Entwicklungsumgebungs-Secrets, nicht auf Produktion. Der Zugriff wird nach Funktion gewährt, nicht nach Seniorität oder Bequemlichkeit.
• Audit-Logs. Jedes Zugriffsereignis wird aufgezeichnet: wer welches Credential abgerufen hat, wann und von welchem System. Wenn ein Credential an einem unerwarteten Ort auftaucht, haben Sie einen Nachweis.
• Dienstkonto-Management. Das Shadow-AI-Risiko beschränkt sich nicht auf Menschen, die Secrets in Chat-Fenster einfügen. KI-Agenten und automatisierte Pipelines laufen unter Dienstkonten — und diese Konten sammeln im Laufe der Zeit Berechtigungen an, ohne dass jemand sie aktiv überprüft. Passwork ermöglicht es, Dienstkonto-Credentials genauso zu speichern, zu rotieren und zu beschränken wie menschlichen Zugriff: mit expliziten Rollen, Ablaufrichtlinien und einer vollständigen Zugriffshistorie.
• API-first Credential-Bereitstellung. Die REST API von Passwork ermöglicht es Pipelines und Anwendungen, Secrets programmatisch zur Laufzeit abzurufen, anstatt sie aus Umgebungsdateien oder Konfigurations-Repositories zu lesen. Das Credential berührt nie die Zwischenablage eines Entwicklers. Es geht direkt vom Tresor zum Prozess, der es benötigt — und der Abruf wird protokolliert.

Self-Hosted vs. Cloud

Die Self-Hosted-Option hält alle Daten innerhalb der eigenen Infrastruktur der Organisation — die richtige Wahl für Teams mit strengen Datenstandortanforderungen oder regulierten Umgebungen. Die Cloud-Option entfernt den operativen Aufwand des Betriebs einer eigenen Instanz bei gleichzeitiger Beibehaltung derselben Verschlüsselungsgarantien und Zugriffskontrollen. Keine der Optionen sendet Klartext-Credentials an Passwork-Server.

Wie Passwork Shadow-AI-Risiken adressiert

Fazit

Die Mehrkosten von 670.000 $ pro Datenpanne durch Shadow AI sind die Kosten der KI-Nutzung ohne Governance. Die Organisationen, die diese Mehrkosten zahlen, sind keine Ausreißer. Es sind die 63 %, die keine KI-Governance-Richtlinien hatten, und die 97 %, denen es bei einem Vorfall an angemessenen Zugriffskontrollen mangelte.

Governance beginnt auf der Credential-Ebene. Ein Mitarbeiter, der keinen Zugriff auf rohe Produktions-Secrets hat, kann diese nicht versehentlich exponieren — unabhängig davon, welches KI-Tool er öffnet. Das ist der Kontrollpunkt, den die meisten Shadow-AI-Frameworks übersehen, und derjenige, der die unmittelbarste Risikoreduktion liefert.

Prüfen Sie noch heute, auf welche Credentials Ihre Teams im Klartext zugreifen können. Diese Liste ist Ihre Shadow-AI-Expositionsfläche.

FAQ: Shadow AI im Unternehmen

Wie erkennt man Shadow AI?

Organisationen können Shadow AI erkennen, indem sie Netzwerkprotokolle auf ungewöhnlichen ausgehenden Datenverkehr zu KI-Domains überwachen, einen Cloud Access Security Broker (CASB) einsetzen, um die SaaS-Nutzung auf verwalteten Geräten zu prüfen, und Browser-Erweiterungen auf Unternehmens-Endpunkten überprüfen. Endpoint-DLP-Tools können große Textübertragungen zu bekannten KI-Diensten markieren, obwohl private Free-Tier-Accounts eine hartnäckige Blindstelle bleiben.

Was ist ein Beispiel für Shadow AI?

Ein häufiges Beispiel ist ein Entwickler, der proprietären Quellcode in einen privaten ChatGPT-Account einfügt, um ein Produktionsproblem zu debuggen — dabei werden fest codierte API-Keys und interne Architektur exponiert. Ein weiteres ist ein Marketingteam, das vertrauliche Kundendaten in ein nicht genehmigtes KI-Zusammenfassungs-Tool hochlädt, oder ein Finanzanalyst, der Q3-Prognosen mit einem Free-Tier-KI-Assistenten teilt, um Vorstandsmaterialien vorzubereiten.

Warum ist Shadow AI gefährlicher als Shadow IT?

Shadow IT verursacht Datenstandortprobleme — Daten liegen irgendwo, wo die IT keine Kontrolle hat. Shadow AI verarbeitet Daten: Es analysiert sie, generiert Outputs daraus und handelt bei agentenbasierten Deployments autonom danach. Die Exposition durch Shadow AI ist oft irreversibel, besonders wenn Daten durch Free-Tier-Accounts fließen, wo sie zum Training öffentlicher Modelle verwendet werden können.

Welche Credentials sind am meisten durch Shadow AI gefährdet?

API-Keys, Datenbank-Verbindungsstrings, OAuth-Tokens und Dienstkonto-Passwörter sind die am höchsten gefährdeten Credentials. Dies sind die Secrets, die Entwickler und DevOps-Ingenieure am wahrscheinlichsten in KI-Prompts einfügen, wenn sie debuggen oder um Konfigurationshilfe bitten. Fest codierte Secrets im Quellcode sind besonders exponiert, da Code die größte Einzelkategorie sensibler Daten ist, die mit KI-Tools geteilt werden (Harmonic Security, 2025).

Verhindert das Verbot von KI-Tools Shadow AI?

Nein. Die Analyse von Harmonic Security von 22,4 Millionen Enterprise-Prompts ergab, dass Mitarbeiter in über 90 % der Organisationen aktiv KI-Tools nutzen, meist über private Accounts, die die IT nie genehmigt hat. Pauschale Verbote verlagern die Nutzung auf private Geräte und Accounts mit noch weniger Sichtbarkeit. Effektive Governance kombiniert genehmigte Alternativen, klare Richtlinien für akzeptable Nutzung und technische Kontrollen auf der Zugriffsebene.

Passwortverwaltung für Teams: Die Lösung, die jedes KMU braucht

Das Speichern von Passwörtern in Slack und Browsern setzt Ihr Unternehmen Datenpannen aus. Erfahren Sie, warum persönliche Tools für Teams versagen, wie Sie ausscheidende Mitarbeiter mit einem Klick sicher offboarden und warum die neuesten NIST-Richtlinien von erzwungener Passwortrotation abraten.

Passwork BlogAlex Muntyan

VaultJacking: Wie eine PIN einen Google Password Manager-Tresor exponieren kann

VaultJacking zielt auf die Google Password Manager-PIN ab, um Ihren gesamten Tresor zu entsperren. Eine abgefangene PIN exponiert jedes gespeicherte Passwort und jeden Passkey. Erfahren Sie, wie der Angriff funktioniert, wer gefährdet ist und was zu tun ist, wenn Sie gephisht wurden.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Accounts widerruft keinen Zugriff. API-Keys, KI-Agent-Credentials und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan