Okta a récemment lancé les vérifications de posture avancées dans le client Okta Verify pour macOS et Windows. Cette fonctionnalité s’appuie sur osquery, un agent sur terminal léger, capable d’exécuter une requête SQL au moment de la connexion afin de détecter des données essentielles de l’appareil : services launchd, chemins de fichiers, processus en cours d’exécution, gestionnaires de paquets, ports à l’écoute, applications installées et artefacts de conteneur, qui fournissent ensemble un signal de vérification des appareils au moment de la connexion. Avec les vérifications de posture avancées, si un appareil ne respecte pas le standard d’hygiène attendu, cet utilisateur n’obtient pas l’accès.
Ensuite, nous avons montré comment vous pouvez utiliser cette fonctionnalité pour détecter si des applications de sécurité qui devraient être en cours d’exécution sont désactivées ou ne fonctionnent pas. Notre équipe a publié une détection de surveillance des outils de sécurité qui attribue un score à un terminal en fonction des outils de sécurité attendus devant être actifs, de la gestion des terminaux mobiles (MDM) aux outils de prévention des fuites de données (DLP) en passant par les logiciels de sécurité DNS.
L’un des grands atouts d’osquery est sa capacité à s’adapter à un environnement de menaces en constante évolution. La véritable valeur ne réside pas dans la détection d’une seule menace, mais dans l’obtention d’une visibilité étendue sur tout ce qui s’exécute sur un appareil, y compris les agents d’IA, les assistants de codage et les environnements d’exécution de modèles locaux qui se sont discrètement intégrés à l’environnement de développement de chacune et chacun.
Pour faciliter cette démarche dès le premier jour, nous avons publié un large ensemble d’exemples de vérifications dans le dépôt public customer-detections d’Okta, couvrant 24 outils d’IA différents sur macOS et Windows.
Outils d’IA non autorisés
Les équipes sécurité ont passé les deux dernières années à élaborer des politiques pour l’utilisation des interfaces de chat IA SaaS, mais le travail n’est pas terminé. Le prochain défi concerne la deuxième vague d’outils qui apparaît en parallèle :
Les assistants de codage agentiques lisent et écrivent des fichiers, exécutent des commandes shell et appellent des services externes avec peu ou pas de validation à chaque action — Cursor, Goose, Aider, Cline, Windsurf, OpenAI Codex CLI, Gemini CLI, et bien d’autres.
Les environnements d’exécution LLM locaux comme Ollama, LM Studio, GPT4All et llama.cpp exécutent les modèles directement sur le terminal et, dans plusieurs configurations par défaut, exposent une API REST non authentifiée sur le réseau local.
Les applications de bureau connectées au cloud et les extensions d’IDE transmettent, par conception, le code, les fichiers et l’historique des conversations en dehors de l’appareil. Cela inclut ChatGPT Desktop, GitHub Copilot, Microsoft Copilot, Sourcegraph Cody, Tabnine et Supermaven.
Les agents disposant d’identifiants d’entreprise, tels que Kiro (le successeur d’Amazon Q), héritent des sessions AWS IAM Identity Center et peuvent disposer des mêmes autorisations que l’utilisateur connecté, y compris l’accès à l’infrastructure de production.
Ces applications agentiques se répartissent en deux catégories. Une catégorie d’agents s’authentifie, par exemple lorsqu’une session Claude Code s’authentifie via l’authentification unique (SSO). Mais la plupart relèvent d’une autre catégorie : un développeur qui installe Ollama ou connecte Cursor à un référentiel privé sans enregistrer l’agent auprès d’un fournisseur d’identité. Il s’agit de la « Shadow AI », l’un des retours les plus fréquents qu’Okta reçoit lors des échanges autour de l’IA. La majorité des entreprises déclarent que des agents d’IA sont en production sans gouvernance formelle ni attribution claire de la responsabilité. Cela expose chaque entreprise à un risque.
Du code source sensible et des secrets peuvent quitter l’entreprise via un canal agentique qu’aucun outil DLP n’a jamais été conçu pour inspecter. Un agent autonome disposant d’un accès shell, fonctionnant sans surveillance sur un appareil, peut s’authentifier dans une application sensible, laissant les administrateurs se demander par la suite quel outil a supprimé la base de données avec la commande rm -rf. Les administrateurs ne peuvent pas arrêter un agent dont l’équipe sécurité ignore l’existence.
Il existe un moyen d’apporter de la visibilité et de la clarté. La détection au niveau des terminaux permet de transformer une supposition (« nous pensons que les ingénieurs utilisent des outils d’IA locaux ») en ressources pouvant être gérées et intégrées à une politique de vérification des appareils.
Même pour les outils qui disposent réellement d’une gestion de l’identité (une session IAM Identity Center AWS de Kiro ou une autorisation OAuth pour l’autorisation OAuth GitHub de Copilot), la posture de l’appareil reste un signal distinct et indispensable. Savoir qu’un agent s’est authentifié correctement ne signifie pas pour autant que l’appareil sur lequel il s’exécute doit être considéré comme fiable. C’est précisément la faille que ces vérifications visent à combler, et elles sont complémentaires des contrôles au niveau de l’identité. Les vérifications de posture avancées vous permettent de transformer la posture d’un outil en condition d’accès.
Répertoire d’outils multiplateforme
Le dossier sample_osquery_checks est organisé par plateforme :
sample_osquery_checks/
├── Cross/ # vérifications applicables à tout système d’exploitation (supply-chain / campagnes de malware)
├── macOS/ # tables osquery spécifiques à macOS
└── Windows/ # Tables osquery spécifiques à Windows
Chaque vérification est un fichier YAML au même format :
title: <Nom lisible par un humain>
id : <Unique identifier>
description : <Ce que la vérification détecte et pourquoi c’est important> <What the check detects and why it matters>
références :
- <Liens vers la documentation du vendeur ou renseignements sur les menaces>
auteur :
- <E-mail de l'auteur><Author email>
plateforme :
- macOS | Windows | Linux
requête : |
<osquery SQL query><requête SQL osquery>
Dans cet exemple, « query » correspond à une requête SQL standard exécutée sur les tables virtuelles d’osquery. Elle doit renvoyer un résultat non vide lorsque la condition est détectée, et un résultat vide sur un appareil sain. Ce résultat alimente directement l’évaluation de la politique Device Assurance dans Okta Verify.
Parmi les 24 outils répertoriés dans le référentiel, 23 disposent à la fois de variantes macOS et Windows (adaptées au schéma osquery de chaque plateforme — applications et launchd sur macOS, contre programmes et services sur Windows) ; Microsoft Copilot est uniquement disponible sur Windows, pour des raisons évidentes.
Catégorie | Outils |
Interfaces en ligne de commande pour codage agentique / agents IDE | Aider, Cline/Roo, Continue.dev, Cursor, Goose, Kimi Code, OpenCode, Sourcegraph Cody, Supermaven, Tabnine, Windsurf/Codeium |
Assistants de codage dans le cloud | GitHub Copilot, Microsoft Copilot, OpenAI Codex CLI, Gemini CLI, Claude (Desktop + Code), Kiro (Amazon Q) |
Environnements d’exécution LLM locaux | Ollama, LM Studio, GPT4All, llama.cpp, Jan, AnythingLLM |
Clients de messagerie de bureau | ChatGPT Desktop |
Quatre types de risques
Chaque vérification suit la même structure que celle présentée dans la publication d’origine : un ensemble de Common Table Expressions (CTE) indépendantes, chacune vérifiant un type d’artefact, additionnées pour obtenir un score, puis comparées à un seuil. Au moins deux indicateurs positifs indépendants (score > 1) sont nécessaires avant le déclenchement d’un contrôle. Il s’agit d’un contrôle des faux positifs délibéré. Un fichier résiduel laissé après une désinstallation ou un nom de processus correspondant partiellement ne suffit pas, à lui seul, à déclencher une vérification. Un binaire, un fichier de configuration et un processus en cours d’exécution constituent ensemble des signaux de bien meilleure qualité. Il s’agit de la même logique de corrélation qui doit être appliquée à toute alerte bruyante provenant d’une source unique.
Voici l’exemple représentatif du contrôle macOS pour Cursor, le fork de VS Code conçu pour l’IA :
title : Détection de l’éditeur Cursor AI
id : e9b3f6d2a7c1450e8f3b9d6a2c5e7f1b
description: |
Détecte la présence de Cursor, un éditeur de code natif pour l’IA basé sur VS Code, sur les appareils macOS.
Cursor intègre l’assistance au codage par l’IA directement dans l’éditeur et envoie par défaut le contexte du code
— y compris les fichiers ouverts, la sortie du terminal et l’historique du dépôt — vers les serveurs de Cursor et
fournisseurs d’IA tiers (OpenAI, Anthropic, Google). Le mode Agent de l’éditeur peut, de manière autonome
exécuter du code, lancer des commandes de terminal et modifier des fichiers sans confirmation à chaque action. Le mode
confidentialité est disponible, mais nécessite une activation explicite.
plateforme : macOS
requête : |
WITH launchd_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
DE launchd
WHERE name LIKE '%cursor%'
),
file_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
À partir du fichier
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
DEPUIS les applications
WHERE (name LIKE '%cursor%' OR bundle_identifier LIKE '%cursor%')
AND bundle_identifier NOT LIKE 'com.apple.%'
),
final_score AS (
SÉLECTIONNER
launchd_cursor.total + file_cursor.total
+ process_cursor.total + apps_cursor.total
Score AS
FROM launchd_cursor, file_cursor, process_cursor, apps_cursor
)
SÉLECTIONNER
CASE WHEN score <= 1 THEN 0 ELSE 1 END AS cursor_detected
FROM final_score;
Abordons maintenant un autre outil : Ollama, un serveur LLM local. Ollama fonctionne entièrement sur l’appareil, ce qui signifie qu’un outil DLP qui analyse le trafic des API cloud n’est pas pertinent.
L’API REST d’Ollama est également liée par défaut à 0.0.0.0:11434 sans authentification, ce qui la rend accessible à tout autre élément du réseau local :
title : Détection du serveur LLM local Ollama
plateforme : macOS
requête : |
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;
Inclure la table listening_ports comme indicateur, en complément des vérifications des processus et des fichiers, permet à cette requête de signaler également une installation mal configurée (c’est-à-dire exposée sur le réseau) et pas seulement la présence du binaire.
Goose, l’agent d’ingénierie autonome open source de Block, illustre un troisième type de risque : un agent conçu pour exécuter de manière autonome des tâches en plusieurs étapes, comme lancer des suites de tests, modifier des pipelines de build et appeler des API externes. Il peut le faire à l’aide de configurations en texte clair qui peuvent contenir des clés API :
title : Détection des agents Goose AI
plateforme : macOS
requête : |
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;
Et Kiro (le successeur d’AWS pour Amazon Q Developer) présente un quatrième scénario de risque potentiel : l’héritage des identifiants. Kiro s’authentifie via AWS IAM Identity Center, de sorte qu’une session Kiro compromise peut inclure les autorisations AWS réelles de la personne connectée :
title : Détection de l’outil de développement d’IA Kiro (Amazon Q)
plateforme : macOS
requête : |
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'
-- residual Amazon Q artifacts from the Q-to-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;
Cette requête permettra d’identifier les installations d’Amazon Q Developer, car elle contient le chemin de configuration hérité (~/.amazonq/) inclus aux côtés des propres chemins de Kiro.
Nous vous recommandons d’ajuster le seuil pour chaque outil au fur et à mesure que vous collectez les données de votre parc. Le score par défaut supérieur à 1 dans ces exemples constitue un point de départ pertinent. Les outils qui intègrent moins d’artefacts détectables (par exemple, Goose comporte deux CTE tandis que Claude en compte huit) présentent des courbes de faux positifs et de faux négatifs différentes. De plus, les fichiers résiduels laissés par des outils désinstallés peuvent générer des signaux parasites qu’il est utile de surveiller avant de passer du mode surveillance au mode application.
Du score à la décision de connexion
Chacune de ces vérifications renvoie une seule colonne 0/1, ce qui correspond à ce qu’attend une condition de politique de vérification des appareils. À partir de là, il revient aux administrateurs de décider quelles mesures prendre, le cas échéant. Ces décisions peuvent dépendre du type d’utilisateurs ainsi que de leurs rôles. Il est possible que le même signal donne lieu à des réponses très différentes selon le public auquel il s’adresse. En pratique, cela signifie que vous pouvez aller bien au-delà d’une simple autorisation ou interdiction binaire par outil. Envisagez l’approche suivante :
Bloquer la connexion aux applications sensibles depuis des appareils utilisant des outils de codage agentique non autorisés, en particulier ceux disposant d’un accès au shell ou aux fichiers.
Avertir et notifier un administrateur lorsqu’un runtime LLM local est détecté avec un port exposé sur le réseau, afin que l’équipe IT puisse intervenir sur la configuration OLLAMA_HOST (ou équivalent) plutôt que de procéder à un blocage immédiat.
Autoriser sous conditions : par exemple, permettre l’utilisation de GitHub Copilot ou Cursor pour les équipes d’ingénierie, mais bloquer l’application agentique pour la finance ou le juridique.
Suivre l’adoption de manière passive, sans aucune contrainte, afin de comprendre l’utilisation de la Shadow AI sur l’ensemble du parc avant de définir une politique.
Chaque requête peut être exécutée de manière autonome via osqueryi (le shell interactif en ligne de commande d’osquery) sur une instance locale afin de valider les résultats avant de l’intégrer à une politique. Nous vous recommandons de surveiller ces détections avant de les appliquer de manière contraignante. Intégrez la vérification dans une politique en mode rapport uniquement dans un premier temps, puis examinez le taux de détection sur un échantillon représentatif du parc. Vérifiez que les détections positives correspondent bien à de réelles installations et non à des artefacts de désinstallation avant de passer en mode « blocage ». Cela évitera la formation d’une file d’attente au support pour des ingénieurs logiciel bloqués.
Comme chaque vérification suit le même modèle CTE et seuil, étendre la couverture à un nouvel outil consiste simplement à copier l’un de ces fichiers et à remplacer les chemins d’accès, les noms de processus et les ports propres à cet outil.
Combler la lacune de couverture
Ces requêtes constituent une étape vers la création d’un inventaire des outils d’IA déployés sur votre parc aujourd’hui. Les équipes sécurité n’auront plus à se poser de questions, ni à passer des nuits blanches à s’inquiéter des outils agentiques qui s’exécutent sur les appareils.
Si la rédaction de requêtes osquery n’est pas votre point fort, Identity Security Posture Management (ISPM) d’Okta peut effectuer toutes les actions décrites dans cet article de blog (et bien plus encore), avec une logique de détection gérée par Okta. Lorsqu’il est sous licence Okta for AI Agents, il peut détecter les autorisations OAuth non gérées liées aux outils d’IA et alerter les administrateurs et administratrices afin d’intégrer ces agents à la gestion.
L’ensemble des 24 requêtes est disponible sur le GitHub d’Okta ici. Les contributions sont les bienvenues. Si vous suivez un outil d’IA que nous n’avons pas encore mentionné, dupliquez le dépôt et soumettez une PR avec une nouvelle vérification au même format YAML. C’est le moyen le plus rapide de le présenter à toutes les autres équipes qui utilisent ce dépôt.
