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 por uma conexão criptografada e com autenticação mútua.

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.
3. Em cada dispositivo, o comando de instalação instala o agente, registra o dispositivo na sua organização e faz a instalação forçada da extensão de navegador por meio de política gerenciada.
4. O agente e a extensão trabalham juntos no dispositivo. A exposição a IA é classificada localmente e encaminhada à WASViking por uma conexão criptografada.
5. O portal avalia a telemetria em relação à 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 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 uma conexão criptografada e com autenticação mútua.
• As credenciais de instalação são guardadas no armazenamento protegido de credenciais do sistema operacional e nunca ficam gravadas em texto claro.
• 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 Admin → System Settings → AI Guardian e ligue o controle principal WASViking AI Guardian. O status passa a mostrar Enabled quando ativo.

O controle só liga quando a sua organização tem uma franquia de dispositivos contratada. Sem ela, o portal recusa a mudança com esta mensagem: "WASViking AI Guardian is not active in your contract. Ask your WASViking contact or your partner to activate it." Desligar o controle é sempre permitido.

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. Se você não vê a aba AI Guardian, o AI Guardian ainda não está ativo no seu contrato; peça ao seu parceiro ou à equipe comercial da WASViking para ativá-lo.

Cada dispositivo registrado conta na franquia contratada. Quando a franquia acaba, um dispositivo novo é recusado até a franquia ser aumentada, e os dispositivos já contados continuam funcionando.

Admin → 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.

Os agentes não se atualizam sozinhos. Em Devices, abra as ações rápidas de um dispositivo e clique em Update agent, ou marque vários dispositivos (a caixa do cabeçalho seleciona todos os da página) e clique em Update selected. O botão mostra a versão que a sua organização resolve, e os dispositivos que já estão nela, desativados, com uma atualização pendente ou que nunca fizeram check-in para ações remotas são ignorados e contados no aviso.

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 vez que reiniciar (o que inclui qualquer autoatualização). A partir daí, os novos eventos são classificados com as listas atualizadas.

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 Admin → 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). 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 é usada apenas na instalação: um dispositivo que já está registrado deixa de depender dela, então você pode rotacionar ou revogar a chave de instalação sem desconectar os dispositivos 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. 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 instala o agente, registra o dispositivo na sua organização 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 a conexão dela com o agente da WASViking. Aprove as duas.

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. 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\"

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 dispositivo 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>"

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 por meio de um transform (.mst) gerado com o Orca, ou encapsule a instalação em um script de inicialização que defina a propriedade.

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, e rotacioná-la não tem efeito sobre os dispositivos 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 comando de instalação expira alguns minutos depois de ser baixado, então execute-o sem demora.

A extensão de navegador

A extensão gerenciada é o que observa o uso de IA no navegador, e ela trabalha em conjunto com o agente no mesmo dispositivo. 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 extensão e o agente estão conectados.

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 agente foi instalado com aquele navegador selecionado.

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 lista completa está em WASViking AI Guardian.

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 AI Guard > Visibility > AI Activity, os metadados do classificador seguem até o dashboard:

• A linha do evento traz uma pequena etiqueta decoded (decodificado) na coluna Type quando o conteúdo sensível foi encontrado em forma codificada, e não como 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 (LGPD, GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001, NIST e outros).
• 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 de conformidade no painel de detalhes é algo em que uma política pode se basear para corresponder.

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.

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 valida a senha mestra com a WASViking, retira a política de instalação forçada do navegador e remove o agente e o seu serviço. Com --remove-key, ele também apaga a chave de instalação armazenada. 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. A WASViking deixa de armazenar 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 Admin > System Settings > API Keys e crie uma nova com o escopo ai_guardian:install. Os dispositivos que já estão registrados não são afetados.

Atualizando o agente

O agente se atualiza in place, e você pode disparar uma atualização a qualquer momento. As atualizações são verificadas criptograficamente antes da instalação. Uma atualização que falha volta automaticamente para a versão anterior que estava funcionando.

A governança fica no card Agent updates do Passo 3 (canal de release e versão fixada). No dispositivo, execute:

# 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.

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

Se uma atualização sair com 75, execute wasviking-sentinel ai-browser key-status no dispositivo. Ele confirma se a credencial de instalação está presente sem nunca exibi-la. Se ela estiver ausente ou tiver sido revogada, reinstale com uma chave de instalação válida.

Apps de IA de desktop instalados nos dispositivos

A partir do agente 1.28.0 cada dispositivo também informa os aplicativos de IA de desktop que carrega: assistentes de chat, navegadores com IA, ferramentas de código com IA e de linha de comando, runtimes locais de modelos e assistentes de reunião do catálogo da WASViking. Cada aplicativo é identificado pela assinatura de código do fabricante, não só pelo nome, e o relatório diz quem o tem, se ele roda e em quais dias, as portas em que um runtime local escuta e se a configuração "apenas conta da organização" do próprio fabricante está aplicada. Nenhum caminho de arquivo, conversa, documento ou credencial sai do dispositivo.

Abra AI Guard > Visibility > AI Discovery > Desktop AI apps e decida cada aplicativo:

A WASViking não altera nada no dispositivo a partir desta tela. Os controles são arquivos para as ferramentas em que a sua organização já confia:

• Pacote de trava (por aplicativo e plataforma): a configuração do próprio fabricante que restringe o login à sua organização, como perfil de configuração para o seu MDM no macOS, script para Intune ou GPO no Windows e shell script no Linux. No macOS o perfil precisa vir do MDM; um perfil instalado à mão não é obrigatório.
• Regras de bloqueio para os aplicativos proibidos: uma política do AppLocker (apenas auditoria, com as regras padrão de permissão), uma lista de negação do gerenciamento declarativo para macOS 27 ou mais recente e um conjunto de regras do Santa. Carregue na sua ferramenta de controle de aplicativos primeiro em modo de auditoria.
• Guia de rede: o cabeçalho que cada fabricante aceita do seu proxy para recusar contas pessoais na web e no app de desktop, com os identificadores da organização que você decidiu, e o que os dispositivos veem no caminho até cada fabricante (direto ou por um proxy de inspeção). O cabeçalho exige inspeção TLS no proxy; um dos apps de desktop usa certificate pinning e precisa da CA do seu proxy na lista de pins pelo procedimento do próprio fabricante.

Como conferir: em até dez minutos depois de uma mudança o dispositivo envia um novo relatório e a coluna Organization lock passa a Set; os achados são resolvidos na próxima execução do discovery (a cada seis horas, ou Run discovery now). Em um dispositivo, rode wasviking-sentinel ai-browser desktop-apps para ver exatamente o que ele informa. A linha de um aplicativo desaparece no relatório seguinte à remoção.

Bloqueio no Windows a partir do portal. Para os aplicativos que você decidiu como Prohibited, o cartão "Block prohibited applications on Windows devices" da aba permite que o agente grave regras do AppLocker do Windows sobre a assinatura do fabricante (só apps empacotados, sempre mantendo todos os outros apps assinados permitidos). É um controle em dois passos: Start in audit mode faz o Windows registrar o que bloquearia enquanto os apps ainda abrem (evento 8023 no log do AppLocker); Enforce é oferecido quando todos os dispositivos Windows que reportam confirmam a auditoria, e então o Windows recusa iniciar os apps com a mensagem dele. A coluna de dispositivos mostra o modo que o agente leu de volta da política efetiva, não o modo que você pediu. Um dispositivo cujas regras de apps empacotados vêm do seu próprio GPO é reportado como conflito e deixado como está: aplique as regras exportadas lá. Exige o agente 1.29.0 ou mais recente no dispositivo; macOS e Linux continuam com as regras exportadas.

Alertas: assine um destino de alertas em AI Guardian Desktop AI App para receber uma mensagem quando o discovery abrir um achado sobre um aplicativo não aprovado e instalado, um runtime local de modelos exposto na rede ou um aplicativo cuja assinatura não é a do fabricante.

Auditando mudanças

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

• 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. Os detectores personalizados funcionam junto com os 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
  }
}

Os resultados ficam em cache no dispositivo, 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 AI Guard > Governance > 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 AI Guard > Governance > 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 AI Guard > Governance > 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 (Governance > Audit Log). 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 AI Guard > Protection > 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 Guard → Protection → AI Guardian Policies.
• O encaminhamento de alertas está documentado em Notification Channels, Slack e Teams e Webhooks.