A Okta introduziu recentemente verificações de postura avançadas no cliente Okta Verify para macOS e Windows. Este recurso utiliza o osquery, um agente de endpoint leve, que pode executar uma consulta SQL no momento do login para detectar dados críticos do dispositivo — serviços launchd, caminhos de arquivos, processos em execução, gerenciadores de pacotes, portas de escuta, aplicativos instalados e artefatos de contêiner — que, em conjunto, fornecem um sinal de Device Assurance no momento do login. Com verificações avançadas de postura, se um dispositivo não atender aos padrões de higiene esperados, o usuário não terá acesso.
Como complemento, mostramos como você pode usar esse recurso para detectar se os aplicativos de segurança que deveriam estar em execução estão desativados ou não estão em execução. Nossa equipe publicou uma ferramenta de detecção de monitoramento de segurança que avalia um dispositivo com base nas ferramentas de segurança esperadas em execução, desde software de gerenciamento de dispositivos móveis (MDM) até ferramentas de prevenção de vazamento de dados (DLP) e software de segurança de DNS.
Um dos grandes atrativos do osquery é sua capacidade de se adaptar a um ambiente de ameaças em constante evolução. O verdadeiro valor não está em detectar uma única ameaça, mas em obter uma visão ampla de tudo o que está sendo executado em um dispositivo, incluindo agentes de IA, assistentes de codificação e ambientes de execução de modelos locais que, discretamente, se tornaram parte do ambiente de desenvolvimento de todos.
Para facilitar o processo desde o primeiro dia, publicamos um amplo conjunto de exemplos de verificações no repositório público customer-detections da Okta, abrangendo 24 ferramentas de IA distintas para macOS e Windows.
Ferramentas de IA não autorizadas
As equipes de segurança passaram os últimos dois anos desenvolvendo políticas para o uso de interfaces de bate-papo com IA em SaaS, mas o trabalho ainda não está concluído. O próximo desafio é a segunda onda de ferramentas que está surgindo simultaneamente:
Assistentes de codificação agênticos leem e gravam arquivos, executam comandos do shell e chamam serviços externos com pouca ou nenhuma confirmação por ação — Cursor, Goose, Aider, Cline, Windsurf, OpenAI Codex CLI, Gemini CLI e muitos outros.
Os ambientes de execução LLM locais, como Ollama, LM Studio, GPT4All e llama.cpp, executam modelos diretamente no endpoint e, em diversas configurações padrão, expõem uma API REST não autenticada na rede local.
Apps de desktop e extensões de IDE conectados à nuvem transmitem código, arquivos e histórico de conversas para fora do dispositivo por padrão. Isso inclui ChatGPT Desktop, GitHub Copilot, Microsoft Copilot, Sourcegraph Cody, Tabnine e Supermaven.
Agentes com credenciais Enterprise, como o Kiro (sucessor do Amazon Q), herdam as sessões do AWS IAM Identity Center e podem ter as mesmas permissões que o usuário conectado, incluindo o acesso à infraestrutura de produção.
Essas aplicações de agentes se dividem em duas categorias. Uma classe de agente realiza a autenticação, como uma sessão do Claude Code que se autentica por meio de SSO. Mas a maioria pertence a uma categoria diferente — um desenvolvedor instalando o Ollama ou conectando o Cursor a um repositório privado sem registrar o agente com um provedor de identidade. Isso é “IA paralela” e é um dos pontos de feedback mais comuns que a Okta recebe em conversas relacionadas à IA. A maioria das organizações relata a presença de agentes de IA em produção sem governança formal e sem uma atribuição consistente de responsáveis. Isso representa um risco para todas as organizações.
Códigos-fonte sensíveis e segredos podem sair da organização por meio de um canal controlado por agentes, algo que as ferramentas de DLP nunca foram projetadas para inspecionar. Um agente autônomo com acesso ao shell, executado sem supervisão em um dispositivo, pode autenticar-se em um app sensível, deixando os administradores se perguntando posteriormente qual ferramenta usou o comando rm -rf para apagar o banco de dados. Os administradores não podem desativar um agente cuja existência o sistema de segurança desconhece.
Existe uma maneira de proporcionar visibilidade e clareza. A detecção em nível de endpoint é o que transforma uma suposição — “presumimos que os engenheiros estejam executando ferramentas de IA locais” — em recursos que podem ser gerenciados e incorporados a uma política de Device Assurance.
Mesmo para as ferramentas que possuem uma história de identidade real — como a sessão do AWS IAM Identity Center do Kiro ou uma concessão OAuth para o GitHub OAuth do Copilot — a postura do dispositivo ainda é um sinal separado e necessário. Saber que um agente foi autenticado corretamente não significa que o dispositivo em que ele está sendo executado seja confiável. É essa lacuna que essas verificações visam preencher, e elas complementam os controles da camada de identidade. As verificações avançadas de postura permitem transformar a postura de uma ferramenta em uma condição de acesso.
Repositório de ferramentas multiplataforma
A pasta sample_osquery_checks está organizada por plataforma:
sample_osquery_checks/
├── Cross/ # verificações que se aplicam a qualquer SO (cadeia de suprimentos / campanhas de malware)
├── macOS/ # Tabelas osquery específicas do macOS
└── Windows/ # Tabelas osquery específicas do Windows
Cada verificação é um arquivo YAML com o mesmo estilo:
título: <Nome legível por humanos> <Human-readable name>
id: <Identificador único> <Unique identifier>
Descrição: <O que a verificação detecta e por que isso é importante> <What the check detects and why it matters>
referências:
- <Links para documentação do fornecedor ou informações sobre ameaças><Links to vendor docs or threat intel>
autor:
- <Author email>
plataforma:
- macOS | Windows | Linux
consulta: |
<osquery SQL query>
Neste exemplo, “query” é uma consulta SQL padrão nas tabelas virtuais do osquery. Deve retornar um resultado não vazio quando a condição for detectada e um resultado vazio em um dispositivo limpo. Esse resultado alimenta diretamente a avaliação da política de garantia de dispositivo no Okta Verify.
Das 24 ferramentas incluídas no repositório, 23 possuem variantes para macOS e Windows (adaptadas ao esquema osquery de cada plataforma — apps e launchd no macOS versus programas e serviços no Windows); o Microsoft Copilot é exclusivo para Windows, por razões óbvias.
Categoria | Ferramentas |
Agentes de CLI/IDE para codificação agética | Aider, Cline/Roo, Continue.dev, Cursor, Goose, Kimi Code, OpenCode, Sourcegraph Cody, Supermaven, Tabnine, Windsurf/Codeium |
Assistentes de codificação na nuvem | GitHub Copilot, Microsoft Copilot, OpenAI Codex CLI, Gemini CLI, Claude (Desktop + Code), Kiro (Amazon Q) |
Tempos de execução locais do LLM | Ollama, LM Studio, GPT4All, llama.cpp, Jan, AnythingLLM |
Clientes de chat para desktop | ChatGPT Desktop |
Quatro tipos de risco
Cada verificação segue a mesma estrutura apresentada na postagem original: um conjunto de Expressões de Tabela Comum (CTEs) independentes, cada uma verificando um tipo de artefato, somadas para gerar uma pontuação e definidas por um limite. São necessários dois ou mais indicadores positivos independentes (pontuação > 1) para que uma verificação seja acionada. Este é um controle de falso positivo intencional. Um arquivo residual de uma desinstalação ou um nome de processo que por acaso corresponda a uma substring não é suficiente, por si só, para acionar uma verificação. Um arquivo binário, um arquivo de configuração e um processo em execução juntos constituem sinais de fidelidade muito maior. É a mesma lógica de correlação que deve ser aplicada a qualquer alerta ruidoso de fonte única.
Aqui está a verificação do macOS para o Cursor, o fork do VS Code com IA nativa, como um exemplo representativo:
Título: detecção do editor de IA Cursor
identificação: e9b3f6d2a7c1450e8f3b9d6a2c5e7f1b
descrição: |
Detecta a presença do Cursor, um editor de código nativo de IA baseado no VS Code, em dispositivos macOS.
O Cursor incorpora assistência de codificação por IA diretamente no editor e, por padrão, envia o contexto do código
— incluindo arquivos abertos, saída do terminal e histórico do repositório — para os servidores do Cursor e
provedores de IA de terceiros (OpenAI, Anthropic, Google). O modo Agente do editor pode, de forma autônoma,
executar código, executar comandos de terminal e modificar arquivos sem confirmação a cada ação. Privacidade
O modo está disponível, mas requer ativação explícita.
Plataforma: macOS
consulta: |
WITH launchd_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
DO launchd
WHERE name LIKE '%cursor%'
),
file_cursor AS (
SELECT COALESCE(COUNT(*), 0) AS total
DO arquivo
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
DE processos
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
ONDE (nome COMO '%cursor%' OU identificador_pacote COMO '%cursor%')
AND bundle_identifier NOT LIKE 'com.apple.%'
),
final_score AS (
Select
launchd_cursor.total + file_cursor.total
+ process_cursor.total + apps_cursor.total
Pontuação AS
FROM launchd_cursor, file_cursor, process_cursor, apps_cursor
)
Select
CASO QUANDO pontuação <= 1 ENTÃO 0 SENÃO 1 FIM COMO cursor_detectado
FROM final_score;
Agora vamos abordar uma ferramenta diferente: Ollama, um servidor LLM local. O Ollama funciona inteiramente no dispositivo, o que significa que uma ferramenta DLP que inspeciona o tráfego da API na nuvem não é aplicável.
A API REST do Ollama também se vincula ao endereço 0.0.0.0:11434 sem autenticação por padrão, o que a torna acessível por qualquer outro dispositivo na rede local:
Título: detecção de servidor LLM local 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;
A inclusão da tabela listening_ports como um indicador, juntamente com as verificações de processo e arquivo, é o que permite que esta consulta também sinalize uma instalação mal configurada — uma que esteja exposta na rede — em vez de apenas a presença do binário.
Goose, o agente de engenharia autônomo de código aberto da Block, ilustra um terceiro tipo de risco: um agente projetado para a execução não supervisionada de tarefas em várias etapas, como executar conjuntos de testes, modificar pipelines de compilação e chamar APIs externas. Isso pode ser feito com configurações em texto sem formatação que podem conter chaves de API:
Título: detecção de agentes de IA da Goose AI
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;
E o Kiro (sucessor do Amazon Q Developer da AWS) apresenta um quarto cenário de risco potencial: a herança de credenciais. O Kiro autentica-se através do AWS IAM Identity Center, portanto, uma sessão do Kiro comprometida pode incluir as permissões reais do usuário conectado na AWS:
Título: detecção da ferramenta de IA para Developer 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'
-- artefatos residuais do Amazon Q da migração do Q para o Kiro
OR path LIKE '/Users/%/.amazonq/scopes/scope.json'
OR path LIKE '/usuários/%/.vscode/extensões/amazonwebservices.aws-kit de ferramentas-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 irá capturar instalações do Amazon Q Developer, pois elas contêm o caminho de configuração legado (~/.amazonq/). e está incluído junto com os próprios caminhos de Kiro.
Recomendamos ajustar o limite para cada ferramenta à medida que você coleta dados da frota. A pontuação padrão > 1 nessas amostras é um ponto de partida razoável. Ferramentas que geram menos artefatos detectáveis (por exemplo, Goose tem dois CTEs, mas Claude tem oito) terão curvas de falsos positivos/falsos negativos diferentes. Além disso, arquivos residuais de ferramentas desinstaladas podem ser uma fonte de ruído que vale a pena observar antes de alterar uma verificação do modo de monitoramento para o modo de aplicação.
Da pontuação à decisão de login
Cada uma dessas verificações retorna uma única coluna 0/1, que é o que uma condição de política de Device Assurance espera. A partir daí, cabe aos administradores decidir que medidas, se houver, devem ser tomadas. Essas decisões podem depender do tipo de usuários e de suas funções. Você pode descobrir que o mesmo sinal permite respostas muito diferentes dependendo do público a que é aplicado. Na prática, isso significa que você pode ir muito além de um permitir/bloquear binário por ferramenta. Considere a seguinte abordagem:
Bloquear o login em apps confidenciais a partir de dispositivos que executam ferramentas de codificação de agentes não autorizadas, especialmente aquelas com acesso ao shell e/ou a arquivos.
Avisar e notificar um administrador quando um ambiente de execução LLM local for detectado com uma porta exposta na rede, para que a equipe de TI possa verificar a configuração OLLAMA_HOST (ou equivalente) em vez de bloquear completamente.
Permitir com condições — por exemplo, permitir o GitHub Copilot ou o Cursor para grupos de engenharia, mas bloquear o aplicativo agêntico para os setores financeiro ou jurídico.
Rastrear a adoção de forma passiva, sem qualquer imposição, para entender o uso de IA não autorizada em toda a frota antes de definir políticas.
Cada consulta pode ser executada de forma independente através do osqueryi (o shell de linha de comando interativo do osquery) em uma instância local para validar os resultados antes de integrá-la a uma política. Recomendamos monitorar essas detecções antes de aplicar as medidas. Incorpore a verificação em uma política inicialmente no modo somente relatório e, em seguida, analise a taxa de acerto em uma amostra representativa da frota. Certifique-se de que os itens positivos sejam instalações reais e não artefatos de desinstalação antes de passar para o modo "bloqueio". Isso evitará uma fila de espera no suporte técnico com engenheiros de software bloqueados.
Como cada verificação segue o mesmo padrão de CTE e limite, estender a cobertura para uma nova ferramenta é uma questão de copiar um desses arquivos e substituir os caminhos, nomes de processos e portas específicos dessa ferramenta.
Como eliminar a lacuna de cobertura
Essas consultas representam um caminho para criar um inventário das ferramentas de IA em operação em sua frota atualmente. As equipes de segurança não precisarão adivinhar — ou, mais provavelmente, suar frio à noite — se perguntando quais ferramentas agênticas estão sendo executadas nos dispositivos.
Se escrever scripts osquery não é a sua praia, o Identity Security Posture Management (ISPM) da Okta pode fazer tudo o que foi descrito neste artigo no blog (e muito mais), com a lógica de detecção gerenciada pela Okta. Quando licenciado sob o Okta for AI Agents, ele pode detectar concessões OAuth não gerenciadas relacionadas a ferramentas de IA e alertar os administradores para que coloquem esses agentes sob gerenciamento.
O conjunto completo de 24 consultas está disponível no GitHub da Okta aqui. Contribuições são bem-vindas. Se você estiver monitorando uma ferramenta de IA que ainda não abordamos, faça um fork do repositório e envie um PR com uma nova verificação no mesmo formato YAML. Esta é a maneira mais rápida de apresentá-lo a todas as outras equipes que usam este repositório.
