Okta hat kürzlich erweiterte Statusprüfungen im Okta Verify-Client für macOS und Windows eingeführt. Diese Funktion nutzt osquery, einen ressourcenschonenden Endpoint-Agenten, der beim Anmelden eine SQL-Abfrage ausführen kann, um kritische Gerätedaten zu erfassen (z. B. launchd-Dienste, Dateipfade, laufende Prozesse, Paketmanager, Listening-Ports, installierte Apps und Container-Artefakte), die zusammen ein Device-Assurance-Signal zum Anmeldezeitpunkt liefern. Wenn diese erweiterten Statusprüfungen zeigen, dass ein Gerät den erwarteten Gerätehygiene-Standard nicht erfüllt, erhält der:die Benutzer:in keinen Zugriff.
Wir haben gezeigt, wie Sie mithilfe dieser Funktion erkennen können, ob vorgeschriebene Sicherheitsanwendungen deaktiviert sind oder nicht ausgeführt werden. Unser Team hat eine Watchdog-Erkennung für Sicherheitstools veröffentlicht, die ein Gerät basierend auf den Sicherheitstools bewertet, die ausgeführt werden sollten, z. B. MDM-Software (Mobilgerätemanagement), DLP-Tools (Datenverlustprävention) und DNS-Sicherheitssoftware.
Einer der großen Vorteile von osquery ist, dass es sich an eine dynamische Bedrohungslandschaft anpassen kann. Der wahre Wert liegt nicht darin, eine einzelne Bedrohung zu erkennen. Vielmehr erhalten Sie umfassende Transparenz darüber, was auf einem Gerät ausgeführt wird, einschließlich KI-Agenten, Programmierassistenten und lokaler Modelllaufzeiten, die unbemerkt Teil jeder Entwicklungsumgebung geworden sind.
Um dies vom ersten Tag an zu erleichtern, haben wir im öffentlichen customer-detections-Repository von Okta eine breite Palette von Beispielprüfungen veröffentlicht, die 24 verschiedene KI-Tools unter macOS und Windows abdecken.
Nicht autorisierte KI-Tools
Security-Teams haben in den letzten zwei Jahren Richtlinien für die Nutzung von SaaS-KI-Chat-Schnittstellen entwickelt, aber die Arbeit ist noch nicht abgeschlossen. Die nächste Herausforderung ist die damit einhergehende zweite Welle von Tools:
Agentenbasierte Programmierassistenten, die Dateien lesen und schreiben, Shell-Befehle ausführen und mit wenigen oder keinen erforderlichen Bestätigungen pro Aktion externe Dienste aufrufen – Cursor, Goose, Aider, Cline, Windsurf, OpenAI Codex CLI, Gemini CLI und weitere.
Lokale LLM-Laufzeitumgebungen wie Ollama, LM Studio, GPT4All und llama.cpp, die Modelle direkt auf dem Endpoint ausführen und in mehreren Standardkonfigurationen eine nicht authentifizierte REST-API im lokalen Netzwerk bereitstellen.
Mit der Cloud verbundene Desktop-Apps und IDE-Erweiterungen, die dafür ausgelegt sind, Code, Dateien und den Gesprächsverlauf vom Gerät zu übertragen. Dazu gehören ChatGPT Desktop, GitHub Copilot, Microsoft Copilot, Sourcegraph Cody, Tabnine und Supermaven.
Agenten mit Unternehmens-Anmeldedaten wie Kiro (der Nachfolger von Amazon Q), die AWS IAM Identity Center-Sessions erben und über dieselben Berechtigungen wie der:die angemeldete Benutzer:in (einschließlich Zugriff auf die Produktionsinfrastruktur) verfügen können.
Diese agentischen Anwendungen lassen sich in zwei Kategorien unterteilen. Während sich die einen authentifizieren (z. B. Claude Code-Sessions, die sich über SSO authentifizieren), fallen die meisten Anwendungen in eine andere Kategorie: Wenn Entwicklerinnen Ollama installieren oder Cursor mit einem privaten Repository verbinden, ohne den Agenten bei einem Identity-Anbieter zu registrieren, entsteht „Schatten-KI“. Das ist einer der häufigsten Feedback-Punkte bei KI-bezogenen Gesprächen mit Okta-Kundenunternehmen. Die meisten Unternehmen berichtet über KI-Agenten, die ohne formelle Governance und ohne durchgehend zugewiesene verantwortliche Person in ihren Produktionsumgebungen im Einsatz sind. Dies stellt für jedes Unternehmen ein Risiko dar.
Sensibler Quellcode und Geschäftsgeheimnisse können das Unternehmen über einen agentenbasierten Kanal verlassen, für dessen Überprüfung die vorhandenen DLP-Tools nie ausgelegt waren. Ein autonomer Agent mit Shell-Zugriff, der unbeaufsichtigt auf einem Gerät ausgeführt wird, kann sich bei einer sensiblen App authentifizieren, sodass sich Administrator:innen später fragen, welches Tool die Datenbank per „rm -rf“ gelöscht hat. Administrator:innen können keinen Agenten abschalten, dessen Existenz dem Security-Team nicht bekannt ist.
Es gibt eine Möglichkeit, für Transparenz und Klarheit zu sorgen: Mit Erkennung auf Endpunktebene müssen Sie keine Vermutung mehr anstellen („Wir gehen davon aus, dass Entwickler:innen lokale KI-Tools ausführen“), sondern haben Transparenz über die vorhandenen Assets, sodass Sie diese verwalten und in eine Device-Assurance-Richtlinie integrieren können.
Selbst bei den Tools, die über ein echtes Identity-Managementkonzept verfügen (z. B. die AWS IAM Identity Center-Sessions von Kiro oder OAuth-Grants für den GitHub-OAuth-Grant von Copilot), müssen Sie zunächst den Gerätestatus und damit ein separates, notwendiges Signal erfassen. Und selbst wenn sich ein Agent korrekt authentifiziert hat, bedeutet das nicht, dass dem Gerät, auf dem er ausgeführt wird, vertraut werden sollte. Die Statusprüfungen zielen auf genau diese Lücke ab und ergänzen die Kontrollen auf Identity-Ebene. Mit erweiterten Statusprüfungen können Sie den Sicherheitsstatus eines Tools als Zugriffsbedingung definieren.
Plattformübergreifendes Tool-Repository
Der Ordner „sample_osquery_checks“ ist nach Plattform organisiert:
sample_osquery_checks/
├── Cross/ # Prüfungen, die für jedes Betriebssystem gelten (Lieferkette/Malware-Kampagnen)
├── macOS/ # macOS-spezifische osquery-Tabellen
└── Windows/ # Windows-spezifische osquery-Tabellen
Jede Prüfung ist eine YAML-Datei im selben Stil:
title: <menschenlesbarer Name>
id: <eindeutiger Identifikator>
description: <Was die Prüfung erkennt und warum das wichtig ist>
references:
- <Links zu Dokumentation des Anbieters oder Bedrohungsdaten>
author:
- <E-Mail-Adresse der:des Autor:in>
platform:
- macOS | Windows | Linux
query: |
<osquery-SQL-Abfrage>
In diesem Beispiel ist „query“ eine Standard-SQL-Abfrage der virtuellen Tabellen von osquery. Es sollte ein nicht leeres Ergebnis zurückgeben, wenn die Bedingung erkannt wird, und ein leeres Ergebnis auf einem sauberen Gerät. Dieses Ergebnis fließt direkt in die Auswertung der Device Assurance-Richtlinie in Okta Verify ein.
Von den 24 im Repository enthaltenen Tools verfügen 23 sowohl über macOS- als auch über Windows-Varianten (angepasst an das osquery-Schema der jeweiligen Plattform – Apps und launchd unter macOS bzw. Programme und Dienste unter Windows); Microsoft Copilot ist aus offensichtlichen Gründen nur für Windows verfügbar.
Kategorie | Tools |
Agentenbasierte Coding-CLIs/ IDE-Agenten | Aider, Cline/Roo, Continue.dev, Cursor, Goose, Kimi Code, OpenCode, Sourcegraph Cody, Supermaven, Tabnine, Windsurf/Codeium |
Cloud-Programmierassistenten | GitHub Copilot, Microsoft Copilot, OpenAI Codex CLI, Gemini CLI, Claude (Desktop + Code), Kiro (Amazon Q) |
Lokale LLM-Laufzeitumgebungen | Ollama, LM Studio, GPT4All, llama.cpp, Jan, AnythingLLM |
Desktop-Chat-Clients | ChatGPT Desktop |
Vier Risikoarten
Jede Prüfung folgt der gleichen Struktur, die im ursprünglichen Beitrag vorgestellt wurde: eine Reihe unabhängiger Common Table Expressions (CTEs), die jeweils einen Artefakttyp prüfen, zu einer Punktzahl summiert und mit einem Schwellenwert abgeglichen werden. Zwei oder mehr unabhängige positive Indikatoren (Score >1) sind erforderlich, bevor eine Prüfung ausgelöst wird. Dies ist eine bewusste False-Positive-Kontrolle. Eine nach einer Deinstallation übrig gebliebene Datei oder ein Prozessname, der zufällig eine Teilzeichenfolgen-Übereinstimmung aufweist, reicht für sich allein nicht aus, um eine Prüfung auszulösen. Eine Binärdatei, eine Konfigurationsdatei und ein laufender Prozess sind zusammen deutlich aussagekräftigere Signale. Es ist dieselbe Korrelationslogik, die bei jedem Single-Source-Alert mit hohem Rauschen angewendet werden sollte.
Hier ist die macOS-Prüfung für Cursor, den KI-nativen VS Code-Fork, als repräsentatives Beispiel:
title: Cursor AI Editor-Erkennung
id: e9b3f6d2a7c1450e8f3b9d6a2c5e7f1b
description: |
Erkennt das Vorhandensein von Cursor, einem KI-nativen Code-Editor auf Basis von VS Code, auf macOS-Geräten.
Cursor integriert KI-gestützte Programmierhilfe direkt in den Editor und sendet standardmäßig Code-Kontext
(z. B. geöffnete Dateien, Terminalausgaben und Repository-Verlauf) an die Cursor-Server und
KI-Drittanbieter (OpenAI, Anthropic, Google). Der Agent-Modus des Editors kann autonom
Code ausführen, Terminalbefehle ausführen und Dateien ändern, ohne dass jede Aktion bestätigt werden muss.
Datenschutz-Modus ist verfügbar, erfordert jedoch ein explizites Opt-in.
platform: macOS
query: |
WITH launchd_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
FROM launchd
WHERE name LIKE '%cursor%'
),
file_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
FROM file
WHERE path LIKE '/Applications/Cursor.app'
OR path LIKE '/Users/%/.cursor/mcp.json'
OR path LIKE '/Users/%/.cursor/extensions/%'
OR path LIKE '/Users/%/Library/Application Support/Cursor/User/settings.json'
),
process_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name LIKE '%cursor%'
AND path NOT LIKE '/System/%'
AND path NOT LIKE '/Library/%'
),
apps_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
FROM apps
WHERE (name LIKE '%cursor%' OR bundle_identifier LIKE '%cursor%')
AND bundle_identifier NOT LIKE 'com.apple.%'
),
final_score AS (
SELECT
launchd_cursor.total + file_cursor.total
+ process_cursor.total + apps_cursor.total
AS score
FROM launchd_cursor, file_cursor, process_cursor, apps_cursor
)
SELECT
CASE WHEN score <= 1 THEN 0 ELSE 1 END AS cursor_detected
FROM final_score;
Wenden wir uns nun einem anderen Tool zu: Ollama, einem lokalen LLM-Server. Ollama läuft vollständig auf dem Gerät, sodass dieser Server von einem DLP-Tool, das den Cloud-API-Datenverkehr überprüft, nicht erkannt wird.
Die REST-API von Ollama bindet sich standardmäßig auch ohne Authentifizierung an 0.0.0.0:11434, wodurch sie für alle anderen Systeme im lokalen Netzwerk erreichbar ist:
title: Erkennung lokaler Ollama-LLM-Server
platform: macOS
query: |
WITH launchd_ollama AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM launchd WHERE name LIKE '%ollama%'
),
file_ollama AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM file
WHERE path LIKE '/Applications/Ollama.app'
OR path LIKE '/Users/%/.ollama/models/%'
OR path LIKE '/opt/homebrew/bin/ollama'
),
process_ollama AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM processes WHERE name LIKE '%ollama%'
),
netports_ollama AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM listening_ports
WHERE port = '11434' OR path LIKE '%ollama%'
),
final_score AS (
SELECT launchd_ollama.total + file_ollama.total
+ process_ollama.total + netports_ollama.total AS score
FROM launchd_ollama, file_ollama, process_ollama, netports_ollama
)
SELECT CASE WHEN score <= 1 THEN 0 ELSE 1 END AS ollama_detected
FROM final_score;
Die Einbeziehung der Tabelle „listening_ports“ als Indikator neben den Prozess- und Dateiüberprüfungen ermöglicht es dieser Abfrage, auch eine falsch konfigurierte (d. h. im Netzwerk exponierte) Installation zu melden, anstatt nur das Vorhandensein der Binärdatei.
Goose, der autonome Open-Source-Engineering-Agent von Block, veranschaulicht eine dritte Art von Risiko: einen Agenten, der für die unbeaufsichtigte, mehrstufige Aufgabenausführung konzipiert ist, z. B. für das Ausführen von Test-Suites, das Ändern von Build-Pipelines und das Aufrufen externer APIs. Dies kann mit Klartext-Konfigurationen geschehen, die API-Keys enthalten können:
title: Goose KI-Agent-Erkennung
platform: macOS
query: |
WITH file_goose AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM file
WHERE path LIKE '/opt/homebrew/bin/goose'
OR path LIKE '/Users/%/.config/goose/profiles.yaml'
OR path LIKE '/Users/%/.local/share/goose/sessions/%'
),
process_goose AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM processes
WHERE name = 'goose' OR cmdline LIKE '%block-goose%'
),
final_score AS (
SELECT file_goose.total + process_goose.total AS score
FROM file_goose, process_goose
)
SELECT CASE WHEN score <= 1 THEN 0 ELSE 1 END AS goose_detected
FROM final_score;
Und Kiro (der Nachfolger von AWS für Amazon Q Developer) stellt ein potenzielles viertes Risikoszenario dar: Vererbung von Anmeldedaten. Kiro authentifiziert sich über das AWS IAM Identity Center, sodass eine kompromittierte Kiro-Session die AWS-Berechtigungen des:der tatsächlich angemeldeten Benutzer:in enthalten kann:
title: Kiro (Amazon Q) Erkennung von KI-Entwicklertools
platform: macOS
query: |
WITH file_kiro AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM file
WHERE path LIKE '/Applications/Kiro.app'
OR path LIKE '/Users/%/.kiro/settings/mcp.json'
-- verbleibende Amazon Q-Artefakte aus der Q-zu-Kiro-Migration
OR path LIKE '/Users/%/.amazonq/scopes/scope.json'
OR path LIKE '/Users/%/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-%'
),
process_kiro AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM processes
WHERE name LIKE '%kiro%' OR name LIKE '%amazon-q%'
),
apps_kiro AS (
SELECT COALESCE(COUNT(*), 0) AS total FROM apps
WHERE name LIKE '%kiro%' OR bundle_identifier LIKE '%amazonq%'
),
final_score AS (
SELECT file_kiro.total + process_kiro.total + apps_kiro.total AS score
FROM file_kiro, process_kiro, apps_kiro
)
SELECT CASE WHEN score <= 1 THEN 0 ELSE 1 END AS kiro_detected
FROM final_score;
Diese Abfrage erfasst Installationen von Amazon Q Developer, da sie den veralteten Konfigurationspfad (~/.amazonq/) enthält und neben Kiros eigenen Pfaden enthalten ist.
Wir empfehlen, den Schwellenwert pro Tool anzupassen, während Sie Flottendaten erfassen. Der Standardwert von >1 in diesen Stichproben ist ein sinnvoller Ausgangspunkt. Tools, die weniger erkennbare Artefakte ausliefern (z. B. hat Goose zwei CTEs, Claude jedoch acht), weisen unterschiedliche False-Positive-/False-Negative-Kurven auf. Zudem können Restdateien von deinstallierten Tools eine Störquelle darstellen, die Sie beobachten sollten, bevor Sie bei einer Prüfung vom Überwachungsmodus zur Durchsetzung wechseln.
Vom Score zur Entscheidung über die Anmeldung
Jede dieser Prüfungen gibt (wie bei einer Device Assurance-Richtlinienbedingung erwartet) eine einzelne 0/1-Spalte zurück. Ausgehend von diesen Ausgaben können Administrator:innen entscheiden, ob und welche Maßnahmen ergriffen werden, wobei die Entscheidungen von der Art der Benutzer:innen und deren Rollen abhängen können. Möglicherweise stellen Sie fest, dass dasselbe Signal sehr unterschiedliche Reaktionen unterstützt – je nachdem, auf welche Zielgruppe es angewendet wird. In der Praxis bedeutet das, dass Sie weit über ein binäres Zulassen/Blockieren pro Tool hinausgehen können. Ziehen Sie den folgenden Ansatz in Betracht:
Anmeldung bei sensiblen Apps blockieren, wenn auf den Geräten nicht genehmigte agentenbasierte Programmiertools ausgeführt werden, insbesondere solche mit Shell- und/oder Dateizugriff.
Administrator:innen warnen und benachrichtigen, wenn eine lokale LLM-Laufzeitumgebung mit einem im Netzwerk freigegebenen Port erkannt wird, damit die IT-Abteilung die Konfiguration von OLLAMA_HOST (oder Ähnlichem) überprüfen kann, anstatt sie direkt zu blockieren.
Zulassen mit Bedingungen, sodass zum Beispiel GitHub Copilot oder Cursor für Entwicklungsgruppen zugelassen, für Finanz- oder Rechtsabteilungen aber blockiert werden.
Nutzung passiv und ohne jegliche Durchsetzungsmaßnahmen nachverfolgen, um den Einsatz von Schatten-KI in der gesamten Flotte zu verstehen, bevor Sie über eine Richtlinie entscheiden.
Jede Abfrage kann eigenständig über osqueryi (die interaktive Befehlszeilen-Shell von osquery) gegen eine lokale Instanz ausgeführt werden, um die Ergebnisse zu validieren, bevor sie in eine Richtlinie eingebunden wird. Wir empfehlen, diese Erkennungen zu überwachen, bevor Sie sie durchsetzen. Integrieren Sie die Prüfung zunächst im Nur-Protokollieren-Modus in eine Richtlinie und überprüfen Sie dann die Trefferquote bei einem repräsentativen Teil der Flotte. Stellen Sie sicher, dass es sich bei den positiven Ergebnissen um tatsächliche Installationen und nicht um Deinstallationsartefakte handelt, bevor Sie in den Blockieren-Modus wechseln. Dies verhindert eine Helpdesk-Warteschlange von ausgesperrten Softwareentwickler:innen.
Da jede Prüfung demselben CTE-und-Schwellenwert-Muster folgt, besteht die Ausweitung der Abdeckung auf ein neues Tool lediglich darin, eine dieser Dateien zu kopieren und die für dieses Tool spezifischen Pfade, Prozessnamen und Ports auszutauschen.
Schließen der Abdeckungslücke
Diese Abfragen bieten eine Möglichkeit, ein Inventar der KI-Tools zu erstellen, die heute in Ihrer gesamten Flotte ausgeführt werden. Dadurch müssen Security-Teams bei der Frage, welche agentenbasierten Tools auf Geräten ausgeführt werden, nicht mehr rätseln – oder gar in Schweiß ausbrechen.
Wenn das Schreiben von osquery nicht zu Ihren bevorzugten Aufgaben gehört, können Sie all das, was in diesem Blog-Beitrag beschrieben wird (und noch vieles mehr), mit Identity Security Posture Management (ISPM) von Okta umsetzen, wobei die Erkennungslogik von Okta verwaltet wird. Wenn ISPM über Okta for AI Agents lizenziert ist, werden zudem nicht verwaltete OAuth-Grants von KI-Tools erkannt und Administrator:innen darauf hingewiesen, diese Agenten in die Verwaltung aufzunehmen.
Alle 24 Abfragen sind hier auf dem GitHub von Okta verfügbar. Beiträge sind willkommen. Wenn Sie ein KI-Tool verfolgen, das wir noch nicht behandelt haben, forken Sie das Repository und reichen Sie einen PR mit einer neuen Prüfung im selben YAML-Format ein. Dies ist die schnellste Möglichkeit, diese Prüfung für jedes andere Team zugänglich zu machen, das dieses Repository nutzt.
