Okta introdujo recientemente comprobaciones de postura avanzadas en el cliente de Okta Verify para macOS y Windows. Esta función aprovecha osquery, un agente ligero de endpoint, que puede ejecutar una consulta SQL en el momento del inicio de sesión para detectar datos críticos del dispositivo —servicios launchd, rutas de archivos, procesos en ejecución, administradores de paquetes, puertos de escucha, aplicaciones instaladas y artefactos de contenedores— que, en conjunto, proporcionan una señal de Device Assurance en el momento del inicio de sesión. Con las comprobaciones de postura avanzadas, si un dispositivo no cumple con el estándar de higiene del dispositivo esperado, ese usuario no obtiene acceso.
A continuación, mostramos cómo se puede utilizar esta función para detectar si las aplicaciones de seguridad que deberían estar en ejecución están deshabilitadas o no se están ejecutando. Nuestro equipo publicó una detección de vigilancia de herramientas de seguridad que evalúa un dispositivo en función de las herramientas de seguridad que se espera que estén en funcionamiento, desde software de administración de dispositivos móviles (MDM) hasta herramientas de prevención de fugas de datos (DLP) y software de seguridad DNS.
Una de las grandes ventajas de osquery es su capacidad de adaptación a un entorno de amenazas en constante evolución. El verdadero valor no reside en detectar una sola amenaza, sino en obtener una visibilidad amplia de todo lo que se ejecuta en un dispositivo, incluidos los agentes de IA, los asistentes de codificación y los entornos de ejecución de modelos locales que se han convertido silenciosamente en parte del entorno de desarrollo de todos.
Para facilitar las cosas desde el primer día, hemos publicado un amplio conjunto de comprobaciones de muestra en el repositorio público customer-detections de Okta, que abarca 24 herramientas de IA distintas para macOS y Windows.
Herramientas de IA no autorizadas
Los equipos de seguridad han dedicado los últimos dos años a desarrollar políticas para el uso de interfaces de chat con IA basadas en SaaS, pero el trabajo aún no ha terminado. El siguiente desafío es la segunda oleada de herramientas que está apareciendo paralelamente:
Los asistentes de codificación basados en agentes leen y escriben archivos, ejecutan comandos de shell y llaman a servicios externos con poca o ninguna confirmación por acción: Cursor, Goose, Aider, Cline, Windsurf, OpenAI Codex CLI, Gemini CLI y más.
Los entornos de ejecución LLM locales, como Ollama, LM Studio, GPT4All y llama.cpp, ejecutan los modelos directamente en el extremo y, en varias configuraciones predeterminadas, exponen una API REST no autenticada en la red local.
Las aplicaciones de escritorio y las extensiones de IDE conectadas a la nube transmiten código, archivos e historial de conversaciones fuera del dispositivo por diseño. Entre ellos se incluyen ChatGPT Desktop, GitHub Copilot, Microsoft Copilot, Sourcegraph Cody, Tabnine y Supermaven.
Los agentes con credenciales empresariales, como Kiro (el sucesor de Amazon Q), heredan las sesiones de AWS IAM Identity Center y pueden tener los mismos permisos que el usuario que ha iniciado sesión, incluido el acceso a la infraestructura de producción.
Estas aplicaciones basadas en agentes se dividen en dos categorías. Un tipo de agente se autentica, como por ejemplo una sesión de Claude Code que se autentica mediante SSO. Pero la mayoría pertenecen a una categoría diferente: un Developer que instala Ollama o conecta Cursor a un repositorio privado sin registrar el agente con un proveedor de identidades. Esto es lo que se conoce como “IA en la sombra” y es uno de los comentarios más frecuentes que Okta recibe en las conversaciones relacionadas con la IA. La mayoría de las organizaciones informan que tienen agentes de IA en producción sin una gobernanza formal ni una responsabilidad definida. Esto supone un riesgo para todas las organizaciones.
El código fuente confidencial y los secretos pueden salir de la organización a través de un canal agéntico que las herramientas DLP nunca fueron diseñadas para inspeccionar. Un agente autónomo con acceso a la consola que se ejecuta sin supervisión en un dispositivo puede autenticarse en una aplicación sensible, y los administradores se preguntarán más tarde qué herramienta eliminó la base de datos con rm -rf. Los administradores no pueden desactivar un agente cuya existencia desconoce el sistema de seguridad.
Existe una manera de brindar visibilidad y claridad. La detección a nivel de extremo es lo que convierte una suposición —“asumimos que los ingenieros están utilizando herramientas de IA locales”— en activos que pueden gestionarse e incorporarse a una política de Device Assurance.
Incluso para las herramientas que sí cuentan con una verdadera historia de identidad —como la sesión de AWS IAM Identity Center de Kiro o una concesión de OAuth para la concesión de OAuth de GitHub de Copilot—, la postura del dispositivo sigue siendo una señal separada y necesaria. El hecho de saber que un agente se ha autenticado correctamente no significa que se deba confiar en el dispositivo en el que se ejecuta. Esa es la brecha que pretenden cubrir estas comprobaciones, y son complementarias a los controles de la capa de identidad. Las comprobaciones de postura avanzadas permiten convertir la postura de una herramienta en una condición de acceso.
Repositorio de herramientas multiplataforma
La carpeta sample_osquery_checks está organizada por plataforma:
sample_osquery_checks/
├── Cross/ # comprobaciones que se aplican a cualquier sistema operativo (cadena de suministro / campañas de malware)
├── macOS/ # Tablas osquery específicas de macOS
└── Windows/ # Tablas osquery específicas de Windows
Cada comprobación es un archivo YAML con el mismo estilo:
title: <Human-readable name>
id: <Identificador único> <Unique identifier>
Descripción: <Qué detecta la comprobación y por qué es importante> <What the check detects and why it matters>
Referencias:
- <Enlaces a documentos del proveedor o información sobre amenazas><Links to vendor docs or threat intel>
autor:
- <Correo electrónico del autor><Author email>
plataforma:
- macOS | Windows | Linux
consulta: |
<osquery SQL query>
En este ejemplo, “query” es una consulta SQL estándar sobre las tablas virtuales de osquery. Debe devolver un resultado no vacío cuando se detecte la condición, y un resultado vacío en un dispositivo limpio. Ese resultado se incorpora directamente a la evaluación de la política de Device Assurance en Okta Verify.
De las 24 herramientas incluidas en el repositorio, 23 tienen variantes para macOS y Windows (adaptadas al esquema osquery de cada plataforma: aplicaciones y launchd en macOS frente a programas y servicios en Windows); Microsoft Copilot solo está disponible para Windows, por razones obvias.
Categoría | Herramientas |
Agentes de CLI/IDE para codificación ágrica | Aider, Cline/Roo, Continue.dev, Cursor, Goose, Kimi Code, OpenCode, Sourcegraph Cody, Supermaven, Tabnine, Windsurf/Codeium |
Asistentes de codificación en la nube | GitHub Copilot, Microsoft Copilot, OpenAI Codex CLI, Gemini CLI, Claude (Desktop + Code), Kiro (Amazon Q) |
Entornos de ejecución de LLM locales | Ollama, LM Studio, GPT4All, llama.cpp, Jan, AnythingLLM |
Clientes de chat de escritorio | ChatGPT para escritorio |
Cuatro tipos de riesgo
Cada comprobación sigue la misma estructura que se presentó en la publicación original: un conjunto de expresiones de tabla comunes (CTE) independientes, cada una de las cuales comprueba un tipo de artefacto, se suman para obtener una puntuación y se les aplica un umbral. Se requieren dos o más indicadores positivos independientes (puntuación > 1) antes de que se active una comprobación. Se trata de un control deliberado de falsos positivos. Un archivo residual que quede después de una desinstalación o un nombre de proceso que coincida con una subcadena no es suficiente para activar una comprobación por sí solo. Un archivo binario, un archivo de configuración y un proceso en ejecución, en conjunto, constituyen señales de mucha mayor fidelidad. Es la misma lógica de correlación que debería aplicarse a cualquier alerta ruidosa de una sola fuente.
Aquí está la comprobación de macOS para Cursor, la bifurcación de VS Code nativa de IA, como ejemplo representativo:
Título: Detección del editor de IA Cursor
id: e9b3f6d2a7c1450e8f3b9d6a2c5e7f1b
Descripción: |
Detecta la presencia de Cursor, un editor de código nativo de IA basado en VS Code, en dispositivos macOS.
Cursor inserta la asistencia de codificación mediante IA directamente en el editor y, por defecto, envía el contexto del código
—incluyendo archivos abiertos, salida de terminal e historial del repositorio— a los servidores de Cursor y
proveedores de IA de terceros (OpenAI, Anthropic, Google). El modo Agente del editor puede de forma autónoma
ejecutar código, ejecutar comandos de terminal y modificar archivos sin confirmación previa a cada acción. Privacidad
el modo está disponible, pero requiere una activación explícita.
Plataforma: macOS
consulta: |
WITH launchd_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
DESDE launchd
WHERE name LIKE '%cursor%'
),
file_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
DESDE archivo
WHERE path LIKE '/Applications/Cursor.app'
OR path LIKE '/Users/%/.cursor/mcp.json'
OR path LIKE '/Users/%/.cursor/extensions/%'
OR path LIKE '/Users/%/Library/aplicación soporte/Cursor/usuario/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
DE las aplicaciones
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
Puntuación AS
FROM launchd_cursor, file_cursor, process_cursor, apps_cursor
)
Select
CASO CUANDO puntuación <= 1 ENTONCES 0 SINO 1 FIN COMO cursor_detected
FROM final_score;
Ahora vamos a hablar de otra herramienta: Ollama, un servidor LLM local. Ollama se ejecuta completamente en el dispositivo, lo que significa que una herramienta DLP que inspeccione el tráfico de la API en la nube no es aplicable.
La API REST de Ollama también se enlaza a 0.0.0.0:11434 sin autenticación por defecto, lo que la hace accesible desde cualquier otro dispositivo en la red local:
Título: Detección de servidores LLM locales de Ollama
Plataforma: macOS
consulta: |
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;
Incluir la tabla listening_ports como indicador junto con las comprobaciones de procesos y archivos es lo que permite que esta consulta también señale una instalación mal configurada (una que está expuesta en la red), en lugar de solo la presencia del binario.
Goose, el agente de ingeniería autónoma de código abierto de Block, ilustra un tercer tipo de riesgo: un agente diseñado para la ejecución de tareas desatendidas y en varios pasos, como la ejecución de conjuntos de pruebas, la modificación de pipelines de compilación y la llamada a API externas. Puede hacerlo con configuraciones de texto plano que pueden contener claves de API:
Título: Detección de agentes de IA Goose
Plataforma: macOS
consulta: |
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;
Y Kiro (el sucesor de Amazon Q Developer de AWS) presenta un posible cuarto escenario de riesgo: la herencia de credenciales. Kiro se autentica a través de AWS IAM Identity Center, por lo que una sesión de Kiro comprometida puede incluir los permisos reales de AWS del usuario que ha iniciado sesión:
Título: Detección de la herramienta de desarrollo de IA Kiro (Amazon Q)
Plataforma: macOS
consulta: |
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'
-- artefactos residuales de Amazon Q de la migración de Q a Kiro
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;
Esta consulta detectará las instalaciones de Amazon Q Developer, ya que contiene la ruta de configuración heredada (~/.amazonq/). y se incluye junto con las propias rutas de Kiro.
Recomendamos ajustar el umbral para cada herramienta a medida que recopila datos de la flota. La puntuación predeterminada > 1 en estas muestras es un punto de partida razonable. Las herramientas que generan menos artefactos detectables (por ejemplo, Goose tiene dos CTE, pero Claude tiene ocho) tendrán curvas de falsos positivos/falsos negativos diferentes. Además, los archivos residuales de las herramientas desinstaladas pueden ser una fuente de ruido que conviene observar antes de cambiar una comprobación del modo de supervisión al modo de aplicación.
Desde la puntuación hasta la decisión de inicio de sesión
Cada una de estas comprobaciones devuelve una única columna de 0/1, que es lo que espera una condición de la política de Device Assurance. A partir de ahí, corresponde a los administradores decidir qué medidas tomar, si es que deben tomar alguna. Estas decisiones pueden depender del tipo de usuarios y de sus roles. Es posible que la misma señal soporte respuestas muy diferentes según el público al que se aplique. En la práctica, eso significa que puede ir mucho más allá de permitir/bloquear binariamente por herramienta. Considere el siguiente enfoque:
Bloquear el inicio de sesión en aplicaciones confidenciales desde dispositivos que ejecutan herramientas de codificación basadas en agentes no autorizadas, en particular aquellas con acceso a la línea de comandos o a archivos.
Avise y notifique a un administrador cuando se detecte un entorno de ejecución LLM local con un puerto expuesto a la red, para que el departamento de TI pueda revisar la configuración de OLLAMA_HOST (o equivalente) en lugar de bloquearlo directamente.
Permitir con condiciones; por ejemplo, permitir GitHub Copilot o Cursor para grupos de ingeniería, pero bloquear la aplicación de agentes para finanzas o asuntos legales.
Dar seguimiento pasivo a la adopción, sin ningún tipo de imposición, para comprender el uso oculto de la IA en toda la flota antes de decidir las políticas.
Cada consulta se puede ejecutar de forma independiente a través de osqueryi (el intérprete de comandos interactivo de osquery) en una instancia local para validar los resultados antes de incorporarla a una política. Recomendamos supervisar estas detecciones antes de aplicar las medidas correspondientes. Primero, incorpore la verificación a una política en modo de solo informe y, a continuación, revise la tasa de aciertos en una muestra representativa de la flota. Asegúrese de que los elementos positivos sean instalaciones reales y no artefactos de desinstalación antes de pasar al modo “bloqueo”. Esto evitará que se forme una cola de espera en el servicio de asistencia técnica con ingenieros de software bloqueados.
Dado que cada comprobación sigue el mismo patrón de CTE y umbral, ampliar la cobertura a una nueva herramienta consiste simplemente en copiar uno de estos archivos e intercambiar las rutas, los nombres de los procesos y los puertos específicos de esa herramienta.
Cerrar la brecha de cobertura
Estas consultas representan una vía para crear un inventario de las herramientas de IA que se utilizan actualmente en su flota. Los equipos de seguridad no tendrán que adivinar —o, lo que es más probable, pasar noches en vela— preguntándose qué herramientas de agente se ejecutan en los dispositivos.
Si escribir código osquery no es lo tuyo, Identity Security Posture Management (ISPM) de Okta puede hacer todo lo que se describe en esta publicación de blog (y mucho más), con la lógica de detección gestionada por Okta. Cuando se licencia bajo Okta for AI Agents, puede detectar concesiones OAuth no administradas relacionadas con herramientas de IA y advertir a los administradores para que pongan esos agentes bajo administración.
El conjunto completo de 24 consultas está disponible en el GitHub de Okta aquí. Se aceptan contribuciones. Si realiza el seguimiento de una herramienta de IA que aún no hayamos cubierto, bifurque el repositorio y envíe una solicitud de extracción con una nueva verificación en el mismo formato YAML. Esta es la forma más rápida de que llegue a todos los demás equipos que usan este repositorio.
