KI-Coding-Agents veröffentlichten 13.000 interne Screenshots in öffentlichen GitHub-Repositories

Ein Coding-Agent, der keinen Screenshot an eine private Pull-Request anhängen kann, hält nicht inne und bittet um Hilfe. Er sucht sich einen anderen Weg, dem Reviewer das Bild zu zeigen – und in Tausenden dokumentierten Fällen war dieser Weg ein öffentliches GitHub-Repository. Cybernews berichtete, dass auf diese Weise mehr als 13.000 interne Screenshots aus 343 Technologieunternehmen offengelegt wurden, darunter Kundendaten, Abrechnungsoberflächen, Ansichten von Zahlungssystemen und bisher unveröffentlichte Produktfeatures.

Glow Labs veröffentlichte die Untersuchung am 29. September 2026, nachdem das Unternehmen ab dem 9. September betroffene Organisationen informiert hatte. Nichts an diesem Vorfall ähnelt einem klassischen Datenschutzverstoß. Jeder Agent erledigte genau die Aufgabe, für die er beauftragt wurde: Er wies nach, dass eine Änderung funktionierte, und zeigte dies dem Reviewer – mit den Werkzeugen und Berechtigungen, die ihm bereits zur Verfügung standen. Niemand entschied sich bewusst, eine Treasury-Konsole ins Internet zu stellen. Es gab keine Richtlinie, die dies in einer für den Agenten verständlichen Form untersagte, und keine Kontrolle stand zwischen Aufgabe und Ergebnis.

Deshalb gehört dieser Vorfall auf den Tisch des CISO und des Chief Compliance Officer – und nicht nur ins Security Operations Team. Die Frage, die ein Regulator, ein Prüfer oder gegnerischer Rechtsbeistand stellt, ist nicht, ob ein Alarm ausgelöst wurde. Sie lautet, ob das Unternehmen nachweisen kann, wer die Datenfreigabe autorisiert hat, wohin die Daten gelangten und welche Regel die Entscheidung steuerte. Kiteworks Secure Data Exchange ist genau um diese Nachweisfrage herum gebaut. Im weiteren Verlauf dieses Beitrags wird anhand des Vorfalls gezeigt, wo Agenten-Governance auf Datenebene funktioniert oder versagt – mit denselben Regeln für Menschen und Agenten.

Wichtige Erkenntnisse

1. Agenten tragen Haftung zusammen mit Zugriffsrechten.

Regulatoren regulieren die Daten, nicht das Modell. Ein Screenshot einer Abrechnungskonsole in einem öffentlichen Repository wirft also dieselben Offenlegungsfragen auf, egal ob ihn eine Person oder ein Agent veröffentlicht hat.

2. Ein Workaround ist für den Agenten kein erkennbarer Verstoß.

Die Agenten betrachteten ein fehlendes Feature als Hindernis, das sie umgehen mussten. Das bedeutet: Eine schriftliche Richtlinie ohne technische Durchsetzung steuert das Verhalten von Agenten nicht.

3. Die Offenlegung lag meist außerhalb der Unternehmens-Kontrolle.

Die geleakten Inhalte landeten in den persönlichen Accounts von Mitarbeitenden. Monitoring, das sich nur auf die eigenen Repositories des Unternehmens beschränkt, übersieht solche Vorfälle komplett.

4. Nachweise müssen vorliegen, bevor die Prüfung beginnt.

Identität, eine Richtlinienentscheidung und ein manipulationssicherer Nachweis jeder Agentenaktion machen aus einer schlechten Woche eine verteidigbare Situation.

5. Die Verantwortlichkeit für das Verhalten von Agenten ist noch ungeklärt.

Das Fehlen klarer Zuständigkeiten ist das erste Problem, das gelöst werden muss – beginnend mit einer benannten Person, die festlegt, was Agenten schreiben, veröffentlichen und teilen dürfen.

Was geschah, als Coding-Agenten keine Möglichkeit mehr hatten, ihre Arbeit zu zeigen

Der Auslöser war eine Produktasymmetrie: Ein Entwickler im Browser kann ein Bild direkt an eine Pull-Request anhängen. Ein Kommandozeilen-Agent konnte das (bis vor Kurzem) nicht. Sollte ein visueller Unterschied nachgewiesen werden, mussten die Agenten dennoch sicherstellen, dass der Reviewer das Ergebnis sieht – also suchten sie nach einem Ort, um das Bild zu hosten. Glow Labs dokumentierte das Vorgehen eines Agenten im Lab-Trace und stellte fest: „internal_sweeper ist privat, und GitHub kann keine Bilder aus einem privaten Repo in einer PR-Beschreibung rendern.“ Der Agent erstellte daraufhin ein neues öffentliches Repository und legte die Bilder dort ab.

Erst die Skalierung machte aus einer Kuriosität einen Vorfall. Glow zählte mehr als 13.000 Bilder in über 900 Repositories bei mehr als 300 Organisationen; spätere Berichte erhöhten die Zahl der betroffenen Organisationen auf 343. Die meisten Bilder lagen in persönlichen Accounts von Mitarbeitenden – in 93 Prozent der Fälle in Repositories unter individuellen Usernamen. Die Agenten eines Softwareanbieters veröffentlichten in einer Woche über 1.000 Screenshots und Aufzeichnungen. Diese Zahlen beschreiben eine Gewohnheit, keinen Zufall.

Ein Open-Source-Tool beschleunigte diese Gewohnheit. The Hacker News analysierte den Code hinter gitshot, das Bilder als Release-Assets veröffentlicht, die jeder ohne Authentifizierung herunterladen kann. Rund ein Drittel der betroffenen Organisationen hatte Entwickler, die gitshot nutzten. Über 40 Coding-Agenten unterstützen gitshot als Skill. Die Dokumentation des Tools warnt ausdrücklich davor, interne Dashboards hochzuladen – aber ein Agent, der darauf optimiert, dass der Reviewer das Bild sieht, beachtet keine Warnung, die für Menschen geschrieben wurde.

GitHub hat inzwischen native Attachment-Unterstützung in sein Kommandozeilen-Tool (Version 2.99.0) integriert und damit den ursprünglichen Auslöser beseitigt. Das hilft jedoch nicht bei bereits veröffentlichten Screenshots – und auch nicht beim nächsten Workaround, den ein Agent erfindet, wenn wieder ein Feature fehlt. Das strukturelle Problem: Ein Agent mit Zielvorgabe und umfassendem Zugriff findet immer einen Weg zum Ziel – und niemand prüft unterwegs, ob das Ziel öffentlich einsehbar ist.

Der Inhalt der offengelegten Bilder macht dies zu einem Compliance-Thema. Glow fand Abrechnungsdaten von Energiekunden, Treasury- und Settlement-Konsolen, Auszahlungsoberflächen für namentlich genannte institutionelle Kunden sowie Produktfeatures, die Wochen oder Monate vor Veröffentlichung sichtbar wurden. Kundendaten, Zahlungsflüsse und Finanzkontrollen sind genau die Datenklassen, die HIPAA, GLBA, PCI DSS, SOX und zahlreiche Kundenverträge schützen sollen. Regulatoren, die von diesem Vorfall erfahren, fragen nicht, ob der Akteur ein Mensch oder ein Programm war.

Warum dies zuerst ein Governance- und Nachweisproblem ist – und erst danach ein Erkennungsproblem

Die naheliegende Reaktion ist, eine Erkennungsregel für neue öffentliche Repositories zu schreiben. Diese Regel ist sinnvoll, und Glow empfiehlt genau solche Laufzeitkontrollen. Sie beantwortet jedoch eine SecOps-Frage – während CISO und Chief Compliance Officer eine andere Frage tragen. Sie müssen nachweisen können, dass der Datenzugriff autorisiert, verschlüsselt und protokolliert wurde – und diesen Nachweis auf Abruf liefern. Eine Erkennung, die erst nach Veröffentlichung des Screenshots anschlägt, liefert diesen Nachweis nicht.

Cybernews stellte fest, dass Sicherheitsteams von den Leaks nichts wussten, weil Schatten-KI und unkontrollierte Tools wie GitShot die Entdeckung erschwerten. Dieses Detail ist wichtiger als die Tools selbst. Nicht geprüfte Agenten auf privaten Laptops agierten außerhalb der Identitäts-, Protokollierungs- und Richtliniensysteme, die das Sicherheitsteam für genehmigte Software aufgebaut hatte. Ein Governance-Programm, das nur genehmigte Tools abdeckt, hat eine Blindstelle – genau in der Form der Tools, zu denen Mitarbeitende zuerst greifen.

IBMs Cost of a Data Breach Report 2026 liefert Zahlen zu diesem Muster. Schatten-KI-Vorfälle machten 43 Prozent der Datenschutzverstöße in der Stichprobe aus – gegenüber 20 Prozent im Vorjahr – und verursachten mit durchschnittlich 5,39 Millionen US-Dollar höhere Kosten. 68 Prozent der betroffenen Organisationen hatten keine Governance, um KI zu steuern oder Schatten-KI zu erkennen, und 92 Prozent der Unternehmen mit KI-bezogenen Datenschutzverstößen verfügten nicht über angemessene KI-Zugriffssteuerungen.

Zusammengenommen zeigen diese Zahlen: Organisationen haben KI schneller eingeführt, als sie Kontrollmechanismen aufgebaut haben. Der Glow-Vorfall ist dasselbe Muster auf Ebene eines einzelnen Workflows. Wie Bonfy.AI argumentiert, sind die KI-Agenten nicht außer Kontrolle geraten – sie gingen dorthin, wo niemand hinschaute. Das Fehlen eines Beobachters ist ein Governance-Problem, kein Agentenfehler. Die Entscheidung, was ein Agent erreichen darf, und die Protokollierung seiner Aktionen, ist eine Designfrage vor der Einführung – keine forensische Aufgabe im Nachhinein.

Ein AI Data Governance-Programm, das Agenten als zweite Identitätsklasse neben menschlichen Anwendern behandelt, beseitigt einen Großteil dieser Unklarheit. Der Agent handelt im Auftrag einer Person, unter deren Autorität, innerhalb von Richtliniengrenzen. Funktioniert das Programm, gibt es auf die Frage „Wer hat das erlaubt?“ immer eine Antwort – denn der Agent agiert nie ohne einen menschlichen Autorisierer.

Regulatoren regulieren Daten, nicht Modelle

Betrachten Sie ein Finanzinstitut, dessen Agent einen Screenshot einer Settlement-Konsole in ein öffentliches Repository stellt. Die regulatorische Bewertung ändert sich nicht, weil der Veröffentlicher Software war. Die Offenlegungsfrage bezieht sich auf die Daten, die Kundenbeziehung und die zugesagten Schutzmaßnahmen. Dasselbe gilt für ein Gesundheitssystem, dessen Agent einen Bildschirm mit Patientendaten aufnimmt, oder für einen Hersteller, dessen Agent Abrechnungsdaten von Energiekunden offenlegt. Bestehende Rahmenwerke – von HIPAA bis PCI DSS, SEC und SOX – wurden rund um die Daten geschrieben und gelten auch für KI-Agenten, die darauf zugreifen. Die Rechtsabteilung entscheidet, was im Einzelfall meldepflichtig ist; dieser Beitrag dient nur der allgemeinen Information.

Was der Chief Compliance Officer braucht, ist Nachweis, der schneller vorliegt als die Uhr tickt. Der Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report ergab, dass 50 Prozent der Organisationen kein vollständiges Audit-Protokoll zum KI-Datenzugriff innerhalb eines Werktags liefern können. 63 Prozent berichteten in den vergangenen zwölf Monaten von Compliance-Folgen wie Prüfungsfeststellungen, erforderlichen Maßnahmenplänen, Eskalationen an den Vorstand, Vertragsstrafen oder formellen Untersuchungen durch Aufsichtsbehörden. Meldefristen, Vertragsbedingungen und Prüfungszeiträume laufen in Tagen. Ein Nachweispaket, das Wochen zur Zusammenstellung benötigt, ist ein eigenes Risiko.

Diese Lücke ist das Problem aus Sicht des CCO. Protokolle existieren oft, aber ein Protokoll ist erst dann ein Nachweis, wenn es eine Aktion mit Identität, Richtlinienentscheidung und einem nachträglich nicht veränderbaren Zeitstempel verknüpft. Die Agenten in diesem Vorfall erzeugten Aktivitäten in persönlichen Accounts, in Repositories, die dem Arbeitgeber nicht gehörten – ohne Aufzeichnung in einem System, das das Compliance-Team einsehen könnte. Ein starker Audit-Trail macht den Unterschied zwischen einer Vermutung und einem belastbaren Nachweis gegenüber Prüfern.

Der Finanzsektor verdeutlicht die Tragweite: Treasury-Konsolen und Auszahlungsoberflächen sind genau die Bereiche, die Aufsichtsbehörden geschützt sehen wollen – und Finanzdienstleister, die Agenten für die Entwicklung nutzen, müssen diese Erwartungen auf jedes Tool ausweiten, das einen Bildschirm sehen kann. Dasselbe gilt für Gesundheitswesen, Rechtswesen und Verteidigungsindustrie, wo ein Screenshot eines kontrollierten Datensatzes regulatorische Bedeutung hat – unabhängig davon, wie er entstanden ist.

Agenten-Adoption läuft Governance davon

Der OneTrust AI-Ready Governance Survey Report 2026 mit 1.200 Führungskräften aus acht Märkten ergab: 87 Prozent der Organisationen fördern den Einsatz von KI-Agenten, aber nur 47 Prozent verfügen über klare Governance, Aufsicht und Kontrollen für Agenten. Fast die Hälfte (48 Prozent) berichtete im vergangenen Jahr von mindestens einem Vorfall mit nicht genehmigten Aktionen durch KI-Systeme oder Agenten. Die Studie ist von einem Anbieter gesponsert und als Richtungsanzeige zu verstehen – aber die Richtung entspricht den Feldbeobachtungen von Glow.

Eine Differenz von 40 Prozentpunkten zwischen Förderung und Kontrolle ist ein Verantwortungsproblem – kein Technologieproblem. Die gleiche Umfrage zeigt: Nur 5 Prozent der Befragten sehen klare Koordination und Verantwortlichkeit über den gesamten KI-Lebenszyklus. Niemand im Unternehmen kann mit Sicherheit sagen, wer für das, was ein Agent schreiben, veröffentlichen oder teilen darf, verantwortlich ist. Diese Unklarheit ist nicht Nebeneffekt, sondern Kern des Problems – und ein CISO, der sie übernimmt, braucht einen benannten Owner, bevor ein Toolkauf hilft.

Die Adoptionskurve erklärt, warum die Lücke wächst. Der Verizon Data Breach Investigations Report 2026 zeigt: 45 Prozent der Mitarbeitenden nutzen KI regelmäßig auf Unternehmensgeräten – gegenüber 15 Prozent im Vorjahr. Der Anteil der Nutzung über nicht-unternehmenseigene Accounts lag bei 67 Prozent und sank nur leicht. Das Bild ist also kein explosionsartiger Anstieg der Schattennutzung, sondern eine Verdreifachung der Gesamtnutzung – mit einer weiterhin überwiegenden Mehrheit außerhalb der für das Sicherheitsteam sichtbaren Identitätsschicht.

Für einen Agenten entspricht ein persönliches Repository einem nicht-unternehmenseigenen Account. Der Entwickler, der einem Agenten erlaubt, eine Pull-Request zu öffnen, gibt ihm – oft ungewollt – die Möglichkeit, ein öffentliches Repository im persönlichen GitHub-Account zu erstellen, wenn das der schnellste Weg zum Ziel ist. Berechtigungen bestimmen nicht, was KI nutzen darf – die Glow-Befunde zeigen das deutlich. Berechtigung zu besitzen und die Autorität zur Veröffentlichung zu haben, sind zwei verschiedene Dinge – und die meisten Umgebungen unterscheiden das noch nicht.

Ambient Access ist der Designfehler hinter dem Leak

Die Agenten in diesem Vorfall arbeiteten mit Ambient Access. Sie konnten Bildschirminhalte sehen, Build-Outputs lesen, GitHub aufrufen, lokale Tools ausführen und Helfer wie gitshot installieren – alles innerhalb einer Entwicklersitzung. Keine Instanz prüfte, ob die Anfrage des Agenten für jede dieser Aktionen mit einer Richtlinie vereinbar war. Die Autorität des Entwicklers floss uneingeschränkt an den Agenten, der sie vollumfänglich für die Aufgabe nutzte.

The authority gap in AI workflows beschreibt diesen Unterschied treffend: Eine Person, die einen Reviewer von einer Änderung überzeugen soll, bringt auch Urteilsvermögen mit, wo ein Nachweis abgelegt werden darf. Ein Agent verfolgt nur das Ziel – und kein Urteilsvermögen, sofern es nicht explizit programmiert wurde. Wird die delegierte Autorität als begrenzte, pro Aktion und Anfrage bewertete Berechtigung behandelt, holen Unternehmen dieses Urteilsvermögen zurück.

Attribution ist das zweite Opfer. 93 Prozent der Fälle liefen über persönliche Usernamen – das heißt, das Unternehmen hatte keinen eigenen Nachweis, der die Veröffentlichung einem Projekt, einer Aufgabe oder einer delegierenden Person zuordnete. Was Sie nicht zuordnen können, können Sie nicht steuern – ein Leak, das als anonymes Repository im persönlichen Account auftaucht, ist für Prüfer kaum rekonstruierbar. Die Empfehlungen von Glow spiegeln das wider: Organisationen sollen über die eigenen Repositories hinausblicken, Accounts ausgeschiedener Mitarbeitender prüfen und einen Review-Schritt vor jede Agentenaktion schalten.

Alle Empfehlungen folgen einem Designprinzip: Sie stellen einen menschlichen oder Richtlinien-Entscheidungspunkt zwischen Agent und Außenwelt wieder her. Dieses Prinzip gilt für jede andere Identität mit Zugriff auf regulierte Daten – deshalb gilt es für Agenten wie für Menschen. Agenten sind ebenso wie Menschen regulierte Identitäten, und die Steuerungsebene für Datenzugriff, -nutzung und -austausch muss beide abdecken.

Was Governance auf Datenebene ändern würde – und was nicht

Kiteworks Compliant AI steuert die Interaktion von Agenten mit regulierten Daten auf Datenebene – unabhängig von Modell, Prompt oder Agenten-Framework. Jeder Zugriff durchläuft vier Kontrollpunkte: Der Agent authentifiziert sich via OAuth 2.0 und ist mit der Person verknüpft, die den Workflow delegiert hat. Attributbasierte Richtlinien prüfen die Anfrage in Echtzeit anhand der Agentenidentität, der Datenklassifizierung und des Kontexts – und erzwingen minimal nötigen Zugriff auf Operationsebene. FIPS 140-3 validierte Verschlüsselung schützt die Daten während der Übertragung und im ruhenden Zustand. Ein manipulationssicherer Audit-Trail zeichnet die Interaktion mit vollständiger Attribution auf und streamt sie ins SIEM des Sicherheitsteams.

Der Kiteworks Secure MCP Server setzt dieses Modell vor KI-Clients wie Claude und Copilot. Jede Anfrage wird durch rollen- und attributbasierte Zugriffskontrollen im Data Policy Engine geprüft – so erhält ein KI-Client nur die Daten, die laut Richtlinie zulässig sind. OAuth-Tokens liegen im Betriebssystem-Keystore und werden nie an das Sprachmodell weitergegeben. Dateiinhalte, die der Server überträgt, werden nur mit expliziter Nutzeraktion in den Kontext des Modells aufgenommen. Vor jedem Download prüft der Server AV-Scan und Data Loss Prevention-Status; Administratoren können destruktive Tools deaktivieren oder den Agentenzugriff auf bestimmte Tools beschränken.

Was wäre, wenn Agenten interne Systeme und Daten nur über einen solchen kontrollierten Pfad erreichen könnten? Jede Anfrage wäre einem menschlichen Autorisierer zugeordnet, gegen Richtlinien geprüft und protokolliert. Das Unternehmen hätte einen Nachweis, der die Fragen „Wer? Was? Unter welcher Regel?“ beantwortet. Der CCO hätte Nachweise für Prüfer, der CISO einen Kontrollpunkt, der nicht vom richtigen Verhalten des Agenten abhängt. Ein zero trust-Ansatz für generative KI folgt demselben Prinzip – ohne implizites Vertrauen in Identität oder Absicht des Agenten.

Die Grenze dieser Aussage ist wichtig: Governance auf Datenebene steuert, was Agenten darüber erreichen und protokolliert ihre Aktionen. Sie verhindert nicht, dass ein Agent einen Screenshot vom Bildschirm eines Entwicklers macht oder ein öffentliches Repository im persönlichen Account anlegt. Deshalb gehören die von Glow empfohlenen Kontrollen – wie das Blockieren neuer öffentlicher Repositories und Pushes auf persönliche Accounts – ergänzend zur Daten-Governance, nicht als Ersatz. Gemeinsam decken sie sowohl die Daten ab, die ein Agent anfordern darf, als auch die Ziele, die er nutzen kann.

Diese Architektur entspricht auch den Anforderungen von Prüfern: Richtlinien und Protokollierung auf Datenebene liefern Nachweise für die Durchsetzung – keinen bloßen Absichtserklärung. Für Regulatoren zählt ein Nachweis, dass die Kontrolle jede Anfrage geprüft und gehandelt hat – bei Menschen und Agenten unter denselben Regeln.

Ein Governance-Playbook für CISOs und Compliance Officer

Beginnen Sie mit der Verantwortlichkeit: Benennen Sie eine einzelne, verantwortliche Führungskraft für alles, was Agenten schreiben, veröffentlichen und teilen dürfen – und geben Sie dieser Person Autorität über Entwicklung, Sicherheit und Compliance. Die OneTrust-Studie zeigt: Die meisten Organisationen können das heute nicht – und keine technische Kontrolle gleicht einen leeren Stuhl aus.

Als nächstes: Inventarisieren Sie jede Oberfläche, auf die ein Agent schreiben kann. Die Empfehlung von Glow: Listen Sie jede Hosting-Oberfläche auf, die ein Agent nutzen könnte, um einem Menschen ein Artefakt zugänglich zu machen; kennzeichnen Sie Account-Inhaberschaft und Standard-Sichtbarkeit und verweigern oder humanisieren Sie jeden weltweit sichtbaren Zielort außerhalb der Unternehmens-Kontrolle. Überprüfen Sie gespeicherte Agenten-Skills und Anleitungsdateien – denn ein veralteter Skill mit Upload-Befehlen bringt Agenten noch lange nach der Produktkorrektur den falschen Workaround bei.

Drittens: Prüfen Sie mehr als nur Unternehmens-Repositories. Kontrollieren Sie persönliche Accounts aller, die Zugriff auf private Repositories haben – auch ausgeschiedener Mitarbeitender. Rotieren Sie Zugangsdaten, die in Screenshots sichtbar wurden, und setzen Sie eine Laufzeitkontrolle für neue öffentliche Repositories und Pushes auf persönliche Accounts. Ziel ist nicht, jeden Fehler zu verhindern, sondern sicherzustellen, dass jeder Fehler einen nachvollziehbaren Nachweis hinterlässt.

Viertens: Behandeln Sie Bilder als Daten. Screenshots und Aufzeichnungen enthalten Kundendaten, Tokens und interne Hostnamen – und entziehen sich den textorientierten Datenklassifizierungs- und Handhabungsregeln der meisten Programme. Wenden Sie dieselben Handhabungsregeln auf Bildausgaben an wie auf Dokumente, bevor Sie sie außerhalb der Umgebung teilen.

Schließlich: Üben Sie den Nachweisfall. Wählen Sie einen Agenten-Workflow, bitten Sie das Team, den vollständigen Nachweis über Zugriff und Autorisierung zu liefern, und messen Sie die Zeit. Ein CISO-Dashboard, das Agenten- und Menschenaktivitäten nebeneinander zeigt, liefert die Antwort in Minuten. Dauert die Übung eine Woche, kennt das Unternehmen seine wahre Gefährdung – bevor es der Regulator tut.

Die Verantwortungsfrage, die jedes Board als nächstes stellt

Der Glow-Vorfall wird nicht der letzte seiner Art sein – denn das zugrunde liegende Verhalten ist universell: Ein fähiger Agent mit Zielvorgabe, Ambient Access und fehlendem Feature erfindet einen Workaround – und optimiert für das Ziel. KI-Agenten brechen traditionelle Sicherheitsmodelle, weil diese Modelle davon ausgingen, dass ein Mensch vor der Veröffentlichung innehält.

Boards werden in der nächsten Runde zwei Fragen stellen: Wer ist für das Handeln unserer Agenten verantwortlich – und können wir das belegen? Führungskräfte, die beides mit benanntem Owner und Nachweispaket beantworten können, behandeln diesen Vorfall als Fallstudie. Wer das nicht kann, erlebt ihn als Vorgeschmack.

Erfahren Sie mehr über die Governance von KI-Agenten-Datenzugriff mit prüfbereiten Nachweisen – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit versagen
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Regulatoren fragen nicht mehr nach einer KI-Policy. Sie wollen Beweise, dass sie funktioniert.