WASViking AI Guardian

Implante o WASViking AI Guardian em notebooks e desktops de colaboradores. Ative-o no portal, instale o agente e a extensão de navegador gerenciada, valide a detecção e o primeiro bloqueio por política e depois opere no dia a dia (atualizações, mapeamento de identidades, detecção avançada).

O WASViking^® AI Guardian dá a você visibilidade e controle sobre como os colaboradores usam ferramentas de IA generativa nos dispositivos de trabalho. Um agente Sentinel leve roda em cada host e se pareia com uma extensão de navegador gerenciada (Chrome, Edge ou Firefox). Juntos, eles classificam a exposição a IA (quais fornecedores são visitados, que tipo de conteúdo está envolvido, uma pontuação de risco e evidências mascaradas) e encaminham essa telemetria à WASViking pelo túnel mTLS seguro.

A privacidade faz parte do design: o agente encaminha somente classificações, pontuações e evidências mascaradas, nunca prompts brutos, conteúdo colado ou arquivos. A trilha de auditoria local permanece no dispositivo; o encaminhamento e o armazenamento na nuvem são governados pelo controle principal no portal.

A configuração tem duas metades, e a ordem importa: configure primeiro o portal da WASViking (ative o AI Guardian, defina a política de governança e gere uma chave de API com o escopo ai_guardian:install) e depois execute um comando de instalação de uma linha em cada dispositivo. Você não precisa criar um token de Sentinel Agent para o AI Guardian.

Para entender o que o AI Guardian detecta e como o mecanismo de políticas funciona, veja WASViking AI Guardian.

O que esta implantação faz

• Descobre e classifica o uso de IA por dispositivo: quais fornecedores de IA (OpenAI, Anthropic, Google, Microsoft, Perplexity e outros) são usados, e como.
• Encaminha telemetria que preserva a privacidade: classificações, pontuações de risco e evidências mascaradas. Prompts brutos, conteúdo colado e arquivos nunca saem do dispositivo.
• Aplica a governança de fornecedores: classifique cada fornecedor de IA como aprovado (sancionado), bloqueado (sinalizado em vermelho) ou deixe-o para revisão (o padrão: todo fornecedor conhecido é tratado como Shadow AI).
• Força a instalação e a fixação da extensão de navegador gerenciada pelo canal de políticas gerenciadas do sistema operacional, para que o usuário não possa removê-la.
• Protege a implantação com uma senha mestra, exigida para desinstalar o agente ou retirar a política de instalação forçada do navegador.
• Governa as autoatualizações do agente com um canal de release e uma versão fixada opcional para builds homologados.
• Exibe tudo no portal em AI Guardian (Executive Summary, AI Applications, dashboard) e encaminha os alertas pelos seus canais de notificação.

Como funciona

1. Você ativa o AI Guardian e define a política de governança no portal.
2. Você gera uma chave de API com o escopo ai_guardian:install. A criação da chave exibe um comando de instalação de uso único que embute um bootstrap de curta duração.
3. Em cada dispositivo, o comando de instalação baixa o agente, registra-o (identidade mTLS) usando o bootstrap e armazena a chave de API da organização no cofre de segredos do sistema operacional (Keychain / Credential Manager / Secret Service).
4. O instalador registra o native messaging host e faz a instalação forçada da extensão de navegador publicada por meio de política gerenciada.
5. O agente roda como um serviço por usuário, e a extensão se pareia com ele via loopback. A exposição a IA é classificada localmente e encaminhada à WASViking pelo túnel mTLS.
6. O portal correlaciona a telemetria com a sua governança de fornecedores e gera alertas sobre uso bloqueado ou de Shadow AI.

Postura de acesso

• O agente encaminha somente classificações, pontuações e evidências mascaradas. Prompts brutos, conteúdo colado e arquivos nunca saem do dispositivo.
• A trilha de auditoria local (JSONL) permanece no dispositivo; o controle principal no portal controla o encaminhamento e o armazenamento na nuvem. Desativá-lo interrompe o encaminhamento imediatamente; o sensor do navegador nunca detém esse controle.
• O encaminhamento usa o túnel mTLS seguro, e não uma chamada bearer simples.
• A senha mestra é armazenada como um hash unidirecional e nunca mais é exibida; ela é exigida para a desinstalação e para a remoção da política em hosts gerenciados.
• Revogue o acesso a qualquer momento desativando o AI Guardian, revogando a chave de API ou desinstalando o agente com a senha mestra.

Pré-requisitos

Passo 1: Ative o AI Guardian (portal)

No portal, vá em Settings → System Settings → AI Guardian e ligue o controle principal WASViking AI Guardian. O status passa a mostrar Enabled quando ativo.

Esse controle governa o encaminhamento e o armazenamento na nuvem da telemetria de exposição a IA. Quando ele está desligado, os agentes registrados param de encaminhar dados à WASViking; a trilha de auditoria local em cada dispositivo não é afetada. O sensor do navegador não pode se sobrepor a esse controle.

A mudança entra em vigor em poucos minutos em todos os endpoints registrados e é gravada na trilha de auditoria como ai_guardian.toggle. Se você não vê a aba AI Guardian, o recurso ainda não está ativo no seu plano; entre em contato com [email protected] para que ele seja ativado.

Settings → System Settings → AI Guardian → controle principal.

Passo 2: Defina uma senha mestra (recomendado)

Na mesma aba, em Master password, defina uma senha de pelo menos 12 caracteres e clique em Save. Ela é armazenada como um hash unidirecional e nunca mais é exibida.

Essa senha é exigida para desinstalar o agente ou retirar a política de instalação forçada do navegador em um host gerenciado. Sem ela, um usuário não consegue remover o agente nem desativar a extensão. Use Remove master password (remover a senha mestra) para limpá-la (e, com ela, a proteção contra desinstalação).

Guarde a passphrase no seu gerenciador de segredos. O portal armazena apenas um hash unidirecional, e o endpoint nunca vê o texto em claro. Se você a perder, defina uma nova no portal antes que qualquer agente possa ser desinstalado.

Master password: protege a desinstalação e a remoção da política.

Passo 3: Configure as atualizações do agente (opcional)

Em Agent updates, escolha como os dispositivos se autoatualizam:

Os dois campos vazios significam que o agente segue o canal estável padrão. Clique em Save. Uma versão fixada que não existe no catálogo de releases é tratada como "nenhuma atualização disponível", e não como um erro.

Agent updates: canal de release e versão fixada opcional.

Passo 4: Configure a governança de fornecedores

Em Vendor governance, classifique cada fornecedor de IA:

Marque os fornecedores já incluídos (OpenAI, Anthropic, Google, Microsoft, Perplexity, Quora, DeepSeek, xAI, OpenRouter, HuggingFace, Mistral, Lovable) em uma das colunas e adicione quaisquer outros nas áreas de texto Custom vendors (um por linha). Clique em Save.

O agente carrega as duas listas na próxima reinicialização do monitor (o que inclui qualquer autoatualização). Os eventos são reclassificados imediatamente, a partir do próximo evento após a reinicialização.

Bloquear um fornecedor aqui não interrompe, por si só, um evento; isso apenas o classifica e sinaliza. Para aplicar o bloqueio ativamente no endpoint, crie uma regra de AI Guardian Policy (portal → AI Guardian → AI Guardian Policies). Observe que a correspondência de eventos das regras é estrita: uma regra event:paste não cobre envios de prompt nem uploads de arquivo; use Any (qualquer evento) para cobertura completa.

Vendor governance: fornecedores aprovados, bloqueados e personalizados.

Passo 5: Crie uma chave de API com o escopo ai_guardian:install (portal)

Essa chave autoriza a instalação do endpoint do AI Guardian em um dispositivo.

Vá em Settings → System Settings → API Keys e clique em + New Key.

Clique em Create Key. O portal mostra a chave bruta uma única vez, junto com o comando de instalação para Linux, macOS e Windows (alterne pelas abas de sistema operacional). Um bootstrap de curta duração é gerado quando o script de instalação é baixado, então copie o comando agora: ele só é exibido nesta tela.

Você pode reutilizar a mesma chave para instalar em quantas máquinas precisar enquanto a chave estiver ativa. A chave serve apenas para o bootstrap: depois que um agente é registrado, ele se identifica pelo certificado de cliente mTLS, e não pela chave de API, então você pode rotacionar ou revogar a chave de instalação sem desconectar os endpoints que já estão em execução.

Adicionar ai_guardian:install a uma chave existente mais tarde (via Edit) não revela um novo comando de instalação; o bootstrap é gerado na criação. Para obter um comando novo, crie uma nova chave.

Seletor de escopos da API Key com ai_guardian:install selecionado.

O comando de instalação de uso único, exibido somente na criação da chave.

Passo 6: Instale o agente em cada dispositivo

Execute no dispositivo o comando do Passo 5. Ele baixa o agente, registra-o via mTLS usando o bootstrap, armazena a chave de API no cofre de segredos do sistema operacional, instala o native messaging host e faz a instalação forçada da extensão de navegador por meio de política gerenciada.

Linux / macOS

curl -fsSL -H "Authorization: ApiKey wv_live_xxx" \
  https://api.wasviking.com/api/v1/sentinel/ai-guardian/install.sh | sh

O agente roda como um serviço por usuário (systemd --user no Linux, um LaunchAgent no macOS). A instalação padrão não exige root nem sudo. No Linux, para mantê-lo em execução após o logout: sudo loginctl enable-linger "$USER".

Verifique o agente:

# Linux
systemctl --user status wasviking-sentinel

# macOS
launchctl list | grep wasviking

Na primeira execução, o macOS pode pedir que você autorize a extensão de navegador e o native messaging host. Aprove os dois.

Windows

O agente para Windows é distribuído em dois veículos de instalação. Eles diferem no escopo (por usuário vs. por máquina), no mecanismo de inicialização (Scheduled Task vs. Windows Service) e nos requisitos de privilégio. Escolha o veículo que corresponde ao seu modelo operacional.

Opção A: Um usuário, uma máquina (install.ps1)

Execute a partir de uma sessão do PowerShell como o usuário que será monitorado. O script registra a Scheduled Task do AI Guardian na sessão desse usuário e armazena a chave de API da organização no Windows Credential Manager. A instalação forçada da política de navegador solicita elevação via UAC.

iex (irm -Headers @{Authorization='ApiKey wv_live_xxx'} `
  https://api.wasviking.com/api/v1/sentinel/ai-guardian/install.ps1)

Verifique:

Get-ScheduledTask "WASViking AI Guardian"
Get-ChildItem "$env:LOCALAPPDATA\WASViking\Guardian\"
wasviking-sentinel ai-browser key-status

O comando key-status informa o backend de armazenamento da credencial e nunca imprime a chave.

Opção B: Implantação no parque, por máquina (MSI)

Pré-requisitos:

Passos:

1. Faça login no portal e vá em Sentinel Agents > Get Agent > AI Guardian MSI (x64) para baixar o instalador.
2. Disponibilize o .msi no seu compartilhamento de distribuição ou no repositório de artefatos do seu MDM.
3. Distribua a instalação com msiexec e as propriedades da tabela abaixo. O MSI registra o endpoint por conta própria durante a instalação, então nenhum script de pós-instalação é necessário.

msiexec /i <PATH>\wasviking-ai-guardian_<VERSION>_amd64.msi /qn `
  /l*v "%TEMP%\guardian-install.log" `
  WASV_API_KEY="<WASV_API_KEY>" `
  WASV_API="<WASV_API>"

Propriedades do MSI:

Intune. Empacote o MSI como um app Win32 LOB. Defina o comando de instalação como a linha msiexec acima. Defina o comando de desinstalação como msiexec /x {<PRODUCT_CODE>} /qn. Obtenha o <PRODUCT_CODE> em qualquer máquina instalada com:

Get-WmiObject Win32_Product -Filter "Name='WASViking AI Guardian'" |
  Select-Object IdentifyingNumber

O ProductCode é regenerado a cada build do MSI para permitir o MajorUpgrade. O UpgradeCode é estável e é o que o Intune, o SCCM e o Group Policy usam para detectar upgrades.

SCCM. Crie uma Application do tipo Windows Installer (.msi). Na aba Programs, use a linha msiexec acima como comando de instalação. Defina o método de detecção como "Windows Installer" com o campo ProductCode vazio, para que o SCCM detecte upgrades pelo UpgradeCode.

Instalação de software por Group Policy. Publique ou atribua o .msi em Computer Configuration > Software Installation. Passe WASV_API_KEY e WASV_API por meio de um transform (.mst) gerado com o Orca, ou encapsule a instalação em um script de inicialização que defina as propriedades.

O que o MSI instala:

Verifique a instalação do MSI:

sc.exe query WASVikingGuardian
Get-ChildItem 'C:\Program Files\WASViking\Guardian\' -Recurse
Get-ChildItem 'C:\ProgramData\WASViking\Guardian\' -Recurse

Esperado:

Implantação em massa

Os três veículos são idempotentes e podem ser reexecutados com segurança. A mesma chave de API de instalação funciona em todo o parque. O bootstrap é por máquina, então rotacionar a chave de API de instalação não tem efeito sobre os endpoints já registrados.

Substitua wv_live_xxx pela sua chave real; o portal já preenche o comando completo para você na tela de criação da chave. O bootstrap embutido no script renderizado expira alguns minutos depois que o script é baixado, então execute-o sem demora.

O que o instalador faz

1. Instala o binário do agente em um diretório por usuário.
2. Registra o agente (identidade mTLS) por meio do bootstrap de uso único.
3. Armazena a chave de API da organização no cofre de segredos do sistema operacional: Keychain (macOS), Credential Manager / DPAPI (Windows) ou Secret Service (Linux).
4. Instala o manifesto do native messaging host e inclui na allowlist os IDs da extensão publicada.
5. Faz a instalação forçada da extensão de navegador por meio de política gerenciada (ExtensionInstallForcelist em HKLM no Windows, JSON de política gerenciada no Linux, preparação via MDM no macOS).
6. Inicia o serviço/tarefa por usuário que monitora a exposição a IA.

A extensão de navegador

A extensão gerenciada é o que observa o uso de IA no navegador; o agente é o native messaging host com o qual ela se pareia via loopback. O agente precisa estar instalado e em execução: sem ele, a extensão mostra "Not paired with the local WASViking agent." (não pareada com o agente local da WASViking). O instalador do Passo 6 faz automaticamente a instalação forçada da extensão publicada, mas os usuários também podem instalá-la manualmente pelas lojas oficiais:

Na próxima abertura do navegador, a extensão se instala e se fixa na barra de ferramentas. O popup mostra Paired with the local WASViking agent (pareada com o agente local da WASViking) quando a ponte com o monitor local está saudável.

A instalação forçada usa os mecanismos padrão de política gerenciada que os navegadores já suportam; as chaves de política são documentadas pelos fornecedores dos navegadores e continuam sendo a referência oficial:

• Chrome Enterprise: gerenciamento de extensões do Chrome
• Microsoft Edge: política ExtensionInstallForcelist

Operadores que implantam via MDM (Intune, Jamf, Workspace ONE) podem aplicar os mesmos valores de política gerenciada pelos canais que já usam, em vez de depender do agente para gravá-los.

Uma extensão instalada manualmente ainda precisa do agente. Se o popup continuar em "not paired", confirme que o serviço do agente está em execução e que o manifesto do native messaging host foi instalado para aquele navegador.

Passo 7: Valide a detecção e a aplicação de políticas

Confirme que o dispositivo aparece no portal

Em poucos minutos após a instalação, abra Cyber Risk > AI Guardian no portal. O endpoint aparece em Monitored devices assim que processa o seu primeiro evento.

Gere um evento de teste

Abra o Chrome ou o Edge no endpoint. Acesse chat.openai.com (ou qualquer ferramenta de IA listada no dashboard) e cole conteúdo sensível no campo de mensagem. O classificador vem com um catálogo amplo, que inclui:

• Identificadores brasileiros e globais: CPF, CNPJ, RG, CNH, PIS, passaporte, chaves PIX (incluindo o formato UUID aleatório), IBAN, SWIFT ou BIC, SSN, cartão de crédito.
• Nomes, endereços postais e datas de nascimento quando introduzidos por um pronome de tratamento ou por um campo rotulado (por exemplo Patient: Jane Doe, Date of birth: 12/03/1985, Rua das Flores, 123, São Paulo).
• Dados de categoria especial segundo a LGPD Art. 5 II e o GDPR Art. 9: origem racial, religião, opinião política, filiação sindical, orientação sexual, dados biométricos e genéticos. O classificador trata esses itens, isoladamente, como indicadores e só os escala quando há um identificador pessoal no mesmo prompt.
• Informações de saúde protegidas: vocabulário clínico em inglês e português, códigos ICD-10 (CID-10), números de prontuário (MRN, CNS), registros profissionais brasileiros (CRM, CRO, COREN), operadoras de planos de saúde.
• Credenciais e tokens de nuvem: chaves de acesso da AWS, chaves da Anthropic, chaves de projeto da OpenAI, chaves de API do Google, chaves live do Stripe, webhooks do Slack, tokens fine-grained e OAuth do GitHub, chaves SAS e de storage do Azure, JSON de service account do GCP, strings de conexão de banco de dados, kubeconfig e outros.
• Código-fonte, URLs internas, objetos SQL e o léxico da sua própria organização, quando você fornece um por meio de política.

A camada de detecção também neutraliza, sem nenhuma configuração, dois formatos comuns de bypass:

• Substituição por caracteres Unicode semelhantes. Dígitos fullwidth e caracteres homógrafos são normalizados antes de o classificador ver o prompt, então CPF １１１.４４４.７７７-３５ é detectado da mesma forma que o formato ASCII.
• Envelopes codificados. Conteúdo encapsulado em base64, URL-encoding, sequências de escape JSON ou hex é decodificado em memória, e o classificador roda novamente sobre cada trecho decodificado. Os achados recuperados dessa forma trazem um badge via base64 (ou via base64>url) no dashboard, para que um analista reconheça a codificação adversarial.

Resultados da colagem:

• Se nenhuma política corresponder, o agente registra um evento classificado, com severidade e evidências mascaradas. O evento aparece na tabela do dashboard em até um minuto.
• Se uma política Block corresponder, o agente interrompe a colagem e o navegador mostra o card Paste blocked (colagem bloqueada) com o nome da regra e a mensagem que você configurou. O evento bloqueado é registrado com policy.action = block.

O que você verá no portal

Quando o evento de teste chega a Portal > AI Guardian, os metadados do classificador seguem até o dashboard:

• A linha do evento traz uma pequena etiqueta decoded (decodificado) na coluna Type sempre que pelo menos uma correspondência veio de um envelope codificado (base64, URL-encode, escape JSON, hex). É o seu sinal imediato de que o prompt continha exfiltração codificada, e não texto literal.
• O painel de detalhes abre com uma linha Compliance que lista, como chips coloridos, todos os frameworks regulatórios que o evento envolve. O classificador marca cada achado com strings estáveis de framework: LGPD.Art.5.I, LGPD.Art.5.II, GDPR.Art.4.1, GDPR.Art.9, HIPAA.PHI, HIPAA.Privacy, PCI.DSS, PCI.CHD, SOC2.CC6.1, SOC2.CC6.6, ISO27001.A.5.13, ISO27001.A.8.10, NIST.800-53.SC-28, NIST.800-53.SC-12, NIST.AI.RMF.MAP-4.1, NIST.AI.RMF.GOVERN-3, CPRA, PIPEDA.
• Cada linha de classificação no painel de detalhes traz o seu próprio conjunto de chips, para que você veja se um determinado achado mapeia para PCI, HIPAA, GDPR, LGPD ou vários deles ao mesmo tempo.
• As evidências mascaradas ao lado de cada classificação mostram o suficiente da correspondência para confirmar um verdadeiro positivo (•••.•••.•••-35 para um CPF, AKIA••••••MPLE para uma chave da AWS, J••• da S•••• para um nome, ••/••/1985 para uma data de nascimento) sem nunca armazenar o valor bruto.

Esses são os mesmos dados que o mecanismo de políticas enxerga, então um chip no painel de detalhes significa que a política poderia ter correspondido a compliance:LGPD.Art.9, se você quisesse. Filtros e widgets de conformidade por tenant estão no roadmap.

Crie uma primeira política Block

Para comprovar que o caminho de bloqueio funciona em um endpoint real, vá em Cyber Risk > AI Guardian Policies > New policy e configure:

• Name: Block PII into unsanctioned AI.
• Event: Paste.
• Conditions: Data class igual a pii AND website category igual a unsanctioned.
• Targets: All users.
• Action: Block.
• Message: Pasting sensitive PII data into an unsanctioned AI tool is not allowed by your organization policy.

Salve a regra. O agente busca a nova política no próximo ciclo de atualização. Repita a colagem do passo anterior e confirme o bloqueio.

Onde a chave de API fica após a instalação

Esta seção se aplica aos veículos install.sh (Linux, macOS) e install.ps1 (Windows). O Enterprise MSI no Windows consome o bootstrap durante a instalação e não persiste a chave de API da organização no endpoint; a partir daí, a identidade é o certificado de cliente mTLS.

O comando de instalação armazena a chave de API da organização no cofre de credenciais criptografado nativo do sistema operacional e nunca grava a chave em arquivo. No macOS, a entrada fica no Keychain (serviço wasviking-ai-guardian, conta = usuário do sistema operacional). No Windows, fica no Credential Manager. No Linux, fica no Secret Service via D-Bus (GNOME Keyring, KWallet ou o provedor em execução).

O valor colocado no keystore é um envelope AES-256-GCM protegido com uma chave derivada dos identificadores de máquina do host. Uma cópia da entrada levada para outro host é descriptografada como lixo.

O arquivo de ambiente em ~/.config/wasviking/ai-guardian.env contém apenas a URL base da API (WASV_API=<url>). Ele não carrega a chave.

Para verificar de onde a chave está sendo resolvida no momento, sem imprimir o valor:

wasviking-sentinel ai-browser key-status

Saída típica em uma instalação saudável:

OS keystore backend: macOS Keychain (available=true)
keystore: present (last 4 chars: ••••0123)
legacy file: absent
kit env file: WASV_API_KEY absent
Effective source: OS keystore (secure).

Se Effective source indicar qualquer coisa diferente do keystore do sistema operacional, reinicie o serviço do AI Guardian para que o agente releia o estado da credencial na próxima inicialização. O agente se reconcilia com o keystore do sistema operacional sem ação do operador.

Desinstalando o agente

A remoção é condicionada à senha mestra definida no Passo 2. No dispositivo, execute:

wasviking-sentinel ai-browser uninstall \
  --master-password "your-master-password" \
  --remove-key

O comando autentica a senha mestra online no seu tenant e, em seguida, retira a política de instalação forçada do navegador, remove o manifesto do native messaging host, interrompe e remove o serviço por usuário (LaunchAgent / unit systemd --user / Scheduled Task) e, com --remove-key, apaga a chave de API da organização e a base da API persistidas no cofre de segredos do sistema operacional. Se nenhuma senha mestra estiver configurada para a organização, a flag --master-password pode ser omitida.

Faça primeiro uma prévia com --dry-run. Sem --master-password em um host protegido, o comando sai com 77 ("master password rejected", senha mestra rejeitada) e nada é removido.

Para uma máquina instalada com o Enterprise MSI, desinstale pela sua ferramenta de gerenciamento:

msiexec /x {<PRODUCT_CODE>} /qn

Operação no dia a dia

Desativando o monitoramento temporariamente

Desligue o controle Status no card do AI Guardian. O gate de ingestão autoritativo, do lado da WASViking, deixa de persistir novos eventos da sua organização em até cinco minutos. Os endpoints em si continuam rodando e a trilha de auditoria local continua registrando, então você pode reativar sem reimplantar.

Rotacionando a chave de API de instalação

Revogue a chave existente em Settings > System Settings > API Keys e crie uma nova com o escopo ai_guardian:install. Os endpoints já registrados não são afetados, porque não dependem mais da chave.

Atualizando o agente

O agente se atualiza in place, por meio de um fluxo seguro e verificado. O operador pode dispará-lo a qualquer momento, e o host sempre termina em um de dois estados: o novo binário em execução e saudável, ou o binário anterior em execução e saudável. Não existe estado intermediário quebrado.

A governança fica no card Agent updates do Passo 3 (canal de release e versão fixada). No endpoint, execute a partir de qualquer conta que consiga ler a configuração de api persistida no host:

# What would happen, without changing anything (exit 10 if an update is available, 0 if not)
wasviking-sentinel ai-browser update --check

# Apply the update non-interactively
wasviking-sentinel ai-browser update --yes

# Restore the previous binary if you need to revert manually
wasviking-sentinel ai-browser update --rollback

No caso comum, nenhuma flag é necessária. O comando detecta automaticamente o binário que o gerenciador de serviços supervisiona, lê a base da api na configuração de instalação e lê a chave de api da organização no keystore do host, definida no momento da instalação.

O que o gate de segurança faz. Com --yes, o agente busca o manifesto da release, baixa o binário, recalcula o sha256, verifica a assinatura de código do sistema operacional, obtém um lock single-flight, copia o binário atual para um .bak, renomeia atomicamente o novo binário para o lugar do atual, reinicia o serviço e espera o endpoint local /healthz reportar a nova versão esperada. Se qualquer um desses passos falhar, o agente restaura o .bak, reinicia o serviço e sai com código diferente de zero e uma mensagem clara. O estado de disco + serviço nunca fica aplicado pela metade.

Os exit codes são estáveis, para que possam ser integrados a uma ferramenta de gerenciamento do parque:

Auditando mudanças

Toda ação deste fluxo é registrada na trilha de auditoria voltada ao cliente (Settings > History):

• ai_guardian.toggle
• ai_guardian.master_password_set / .clear
• ai_guardian.update_policy_set
• ai_guardian.approved_vendors_set (uma única ação cobre as mudanças em aprovados + bloqueados)
• apikey.create / apikey.revoke
• ai_guardian.policy.create / .update / .delete

Configuração avançada

Os padrões são ajustados para dar um sinal saudável já no primeiro dia, sem configuração. Três ajustes permitem tornar o classificador mais rigoroso ou estendê-lo por tenant. Os três ficam no arquivo de política do agente em cada endpoint (/etc/wasviking/ai-guardian-policy.json no Linux, em ~/Library/Application Support/WASViking/ no macOS, %ProgramData%\WASViking\ no Windows). Uma interface no portal para gerenciá-los de forma centralizada está no roadmap. Até lá, distribua o arquivo pela sua ferramenta de gerenciamento de endpoints.

Detectores personalizados por tenant

Adicione padrões proprietários que os detectores nativos não cobrem, por exemplo um código de projeto interno, um identificador de funcionário ou uma referência de cliente. Cada entrada é compilada no mesmo pipeline dos detectores nativos, e o agente se recusa a iniciar se um padrão estiver malformado, então um erro de digitação nunca desarma a detecção silenciosamente.

{
  "custom_detectors": [
    {
      "label": "internal_employee_id",
      "category": "pii",
      "regex": "\\bEMP\\d{6}\\b",
      "confidence": "high",
      "mask": "digits",
      "mask_keep": 2,
      "compliance_tags": ["LGPD.Art.5.I", "GDPR.Art.4.1"],
      "description": "Internal employee ID format"
    },
    {
      "label": "internal_project_code",
      "category": "internal",
      "regex": "\\bPROJ-\\d{4}\\b",
      "confidence": "high",
      "compliance_tags": ["ISO27001.A.5.13"]
    }
  ]
}

As categorias válidas são pii, secret, phi, sensitive, internal e source_code. As opções de máscara são digits, token, middle ou none. Você pode adicionar até 64 detectores personalizados por tenant.

Calibração de confiança por label

Atenue um detector ruidoso para o seu tenant sem desativá-lo. O multiplicador fica no intervalo [0, 1] e apenas reduz a confiança, nunca a aumenta.

{
  "label_thresholds": {
    "phone": 0.7,
    "br_bank_account": 0.4
  }
}

Um valor de 0.4 rebaixa um achado high para low naquele label, então as regras de política condicionadas a min_severity deixam de escalá-lo. Essa é a alavanca manual disponível hoje. Um ciclo de feedback automatizado, acionado por um botão "Mark false positive" (marcar como falso positivo) no portal, está no roadmap.

Classificação assistida por LLM (opt-in)

Para os casos em que o mecanismo determinístico retorna baixa confiança ou uma pontuação alta e você quer uma segunda opinião, o agente pode chamar diretamente um provedor de LLM para adicionar classificações semânticas. Você usa a sua própria chave de API. O conteúdo do prompt vai do endpoint ao provedor de LLM por TLS público e nunca transita pela infraestrutura da WASViking.

{
  "llm_assist": {
    "enabled": true,
    "provider": "anthropic",
    "model": "claude-haiku-4-5",
    "api_key": "sk-ant-api03-...",
    "min_trigger_score": 40,
    "min_trigger_confidence": "low",
    "max_content_chars": 8000,
    "cache_ttl_hours": 720,
    "budget_per_day_usd": 5.0,
    "timeout_ms": 6000
  }
}

O agente armazena os resultados em cache no disco, indexados pelo SHA-256 do prompt, então o mesmo conteúdo nunca é classificado duas vezes. A proteção de orçamento diário interrompe as chamadas ao LLM quando o teto configurado é atingido. Os achados produzidos pela camada de LLM aparecem no painel de detalhes com o prefixo llm_, para que sejam distinguíveis das correspondências por regex.

Essa camada é mais útil para PII parafraseada, texto de contratos, contexto de M&A e propriedade intelectual proprietária que a correspondência de padrões não consegue descrever.

Identidade e diretório

Os agentes reportam um nome de usuário do sistema operacional em cada dispositivo. Para direcionar políticas por grupo, mostrar nomes reais nos dashboards e apagar os dados de uma pessoa em todos os dispositivos que ela usa, mapeie esses nomes de usuário do sistema operacional para identidades corporativas em Portal > AI Guardian > Identity. Somente os mapeamentos que você confirma afetam a aplicação de políticas; sugestões nunca agem por conta própria.

Conecte um provedor de identidade (SCIM)

1. Abra Portal > AI Guardian > Identity e, no card Identity provider (SCIM 2.0), clique em Generate token. Copie o token imediatamente: ele é exibido uma única vez. Anote o endpoint SCIM mostrado ao lado dele (por exemplo https://api.wasviking.com/api/scim/v2).
2. Configure o provisionamento do seu provedor de identidade para apontar para esse endpoint usando um OAuth bearer token com o token que você copiou. Isso cobre o Microsoft Entra ID e o Okta, que enviam (push) para esse endpoint SCIM. O Google Workspace funciona de outra forma e tem a sua própria seção abaixo.
3. Atribua os usuários e grupos que você quer que a WASViking conheça. Eles aparecem na página Identity após a primeira sincronização. Rotacionar o token no portal invalida o anterior imediatamente; revogá-lo interrompe a sincronização do diretório.

Microsoft Entra ID ou Okta. Crie uma aplicação empresarial com provisionamento automático de usuários, defina o Tenant URL (ou equivalente) como o endpoint SCIM, defina o Secret Token como o bearer token, teste a conexão e então ative o provisionamento e atribua os usuários e grupos a sincronizar. Se a sua organização já usa Microsoft 365 / Office 365, este é o mesmo diretório Entra ID em que essas contas já estão; não há nada separado a configurar para o Office 365.

Sincronize o Google Workspace (leitura do diretório)

O Google Workspace não envia SCIM para um app criado por você, então o card de SCIM acima não se aplica a ele. Em vez disso, a WASViking lê o seu diretório diretamente, de forma agendada, usando a Admin SDK Directory API do Google, somente leitura. Você concede acesso uma única vez a uma service account somente leitura e a cola no portal, e a WASViking mantém os seus usuários e os respectivos grupos sincronizados. Esse é o caminho certo para qualquer cliente Google Workspace, e ele também traz os seus grupos, que uma simples exportação de usuários do Google deixa de fora.

No Google (configuração única, feita por um administrador do Workspace ou do Cloud):

1. No console do Google Cloud, crie um projeto ou escolha um existente.
2. Vá em APIs & Services > Library, procure por Admin SDK API e clique em Enable.
3. Vá em IAM & Admin > Service Accounts e crie uma service account (por exemplo, "workspace-directory-reader"). Ela não precisa de papéis no projeto.
4. Abra a service account, vá em Details > Advanced settings e ligue Enable Google Workspace Domain-wide Delegation. Copie o Client ID exibido.
5. No Google Admin console, vá em Security > Access and data control > API controls > Domain-wide delegation e clique em Add new. Cole esse Client ID e, no campo OAuth scopes, adicione estes três escopos somente leitura, separados por vírgula:
   • https://www.googleapis.com/auth/admin.directory.user.readonly
   • https://www.googleapis.com/auth/admin.directory.group.readonly
   • https://www.googleapis.com/auth/admin.directory.group.member.readonly

Depois clique em Authorize. 6. De volta à service account no Google Cloud, vá em Keys > Add key > Create new key, escolha JSON e clique em Create. O seu navegador baixa um arquivo de chave JSON. Mantenha-o privado.

No portal, em Portal > AI Guardian > Identity:

1. Localize o card Google Workspace directory sync.
2. Faça o upload da service-account JSON key (a chave JSON da service account) que você acabou de baixar.
3. Informe o admin email to impersonate (e-mail de administrador a personificar): qualquer endereço de administrador do Google Workspace, como [email protected]. A WASViking lê o diretório como esse administrador.
4. Deixe Reconcile leavers and group changes (reconciliar desligamentos e mudanças de grupo) ligado (recomendado). Com ele ligado, as pessoas removidas no Google são desativadas aqui e a participação em grupos acompanha o Google. Desligue se você quiser apenas adicionar e atualizar pessoas, nunca removê-las.
5. Deixe o intervalo no valor padrão e clique em Connect Google Workspace. A sincronização passa então a rodar de forma agendada.
6. Clique em Sync now para executar a primeira leitura imediatamente. Os seus usuários e grupos aparecem nas listas abaixo em poucos segundos.

A WASViking gerencia apenas os usuários e grupos que ela lê do Google. Tudo o que você adicionou por CSV ou manualmente, e todo mapeamento que você já confirmou, permanece exatamente como está. Deixe o campo Customer id como my_customer, a menos que o Google tenha fornecido um customer id específico que começa com C.

Importe identidades de um CSV

Ainda não tem um provedor de identidade? Use o card CSV import. Forneça um arquivo com as colunas user_name, display_name, department e groups (nomes de grupos separados por ";"). Reimportar atualiza as linhas existentes. Você também pode adicionar uma única identidade manualmente pelo mesmo card. Se você fizer o upload de uma exportação bruta de usuários do Google Workspace, o portal avisa que as colunas não correspondem e indica a sincronização de diretório do Google Workspace, que também traz os grupos que uma exportação de usuários deixa de fora.

Confirme qual login pertence a quem

1. Clique em Scan devices for usernames (procurar nomes de usuário nos dispositivos). A WASViking lê os nomes de usuário distintos do sistema operacional vistos no seu fluxo de eventos nos últimos 31 dias e propõe correspondências com as suas identidades.
2. Revise Pending suggestions: cada linha mostra o nome de usuário do sistema operacional, a identidade sugerida e a heurística que a produziu (login exato, parte local do e-mail ou nome de exibição). Clique em Confirm para ativar um mapeamento ou em Reject para descartá-lo.
3. Resolva Unmapped usernames (logins sem correspondência automática) escolhendo uma identidade e clicando em Map, que confirma o mapeamento no mesmo passo.

Confirmações e rejeições são registradas na trilha de auditoria (Settings > History). Somente aliases confirmados alimentam as políticas por grupo, a resolução de nomes nos dashboards e o apagamento por pessoa, então um palpite errado nunca é aplicado.

Direcione uma política a um grupo do diretório

1. Abra Portal > AI Guardian Policies e crie ou edite uma regra.
2. Em Targets, escolha Directory groups e selecione um ou mais grupos. O construtor de regras mostra quantos usuários confirmados cada grupo cobre hoje, para que você veja o alcance real antes de salvar.
3. Opcionalmente, liste nomes de usuário do sistema operacional a excluir. Salve a regra.

Quando a política é servida aos agentes, o grupo é expandido para os nomes de usuário confirmados por trás dele. Os endpoints registrados recebem a mudança na próxima atualização de política (cerca de 15 segundos); não é preciso reiniciar o agente. Se você adicionar pessoas ao grupo no seu provedor de identidade mais tarde, confirme os aliases delas na página Identity e elas passam a ser cobertas automaticamente na próxima atualização.

Apague os dados de uma pessoa em todos os dispositivos

Uma solicitação de direito ao esquecimento pode indicar uma identidade corporativa em vez de um único login. Ela se expande para todos os aliases confirmados daquela pessoa e remove os eventos dela em todos os seus dispositivos em uma única operação. Essa é a forma confiável de atender à LGPD Art. 16 e ao GDPR Art. 17 quando um colaborador usou mais de uma máquina.

Solução de problemas

Para qualquer coisa não coberta aqui, entre em contato com [email protected].

Onde isto se encaixa na plataforma

• A exposição a IA fica em AI Guardian: Executive Summary, dashboard do AI Guardian e AI Applications.
• As regras de aplicação de políticas ficam em AI Guardian → AI Guardian Policies.
• O encaminhamento de alertas está documentado em Notification Channels, Slack e Teams e Webhooks.