WASViking AI Guardian

Monitoramento de exposição a IA nos endpoints dos colaboradores. Detecta dados sensíveis enviados a ferramentas públicas de IA, aplica a política da organização no momento da colagem e reporta a atividade por usuário, dispositivo e aplicação de IA.

O WASViking^® AI Guardian é uma camada de inteligência de exposição a IA para o endpoint. Ele observa como os colaboradores interagem com ferramentas públicas de IA (ChatGPT, Claude, Gemini, Copilot, Perplexity e outras), classifica o conteúdo que eles estão prestes a enviar e aplica as políticas que a sua equipe de segurança configura no portal.

Ele não é um proxy de DLP, um man in the middle, um inspetor de SSL nem um keylogger. O sensor do navegador lê o texto do campo de composição apenas no momento do envio ou da colagem, e o agente o processa em memória.

A cobertura se relaciona a risco interno, minimização de dados (GDPR, LGPD), mascaramento do PCI DSS e confidencialidade de PHI da HIPAA.

O que ele detecta

O agente classifica o conteúdo com um motor determinístico que combina detectores de alta precisão com uma camada de contexto. O catálogo cobre identificadores brasileiros e globais, informações de saúde protegidas, dados financeiros, dados de categoria especial sob a LGPD e o GDPR, credenciais de nuvem, nomes e endereços, e sinais estruturais.

Dados pessoais (PII)

• Identificadores brasileiros: CPF, CNPJ, RG (checksum do estado de São Paulo quando sem rótulo, todos os estados quando rotulado), CNH (dois dígitos verificadores mod-11 do Denatran), PIS, PASEP, NIS, NIT, passaporte e chaves PIX em todos os quatro formatos (CPF, CNPJ, e-mail, telefone e a forma aleatória em UUID).
• Identificadores globais: e-mail, telefone, SSN, cartão de crédito validado por Luhn e nomes completos introduzidos por um pronome de tratamento (Sr., Dr., Mr., Mrs., Prof., incluindo os conectivos do português da, de, dos) ou por um campo rotulado (Name:, Patient:, Cliente:).
• Endereços postais: formas brasileiras ancoradas por Rua, Av., Travessa, Praça, Rodovia, e formas em inglês ancoradas por Street, Avenue, Boulevard, Highway.
• Datas de nascimento em contextos rotulados (DOB:, Date of birth:, Nascimento:, Data de nascimento:). A evidência é mascarada para exibir apenas o ano (••/••/1985), de modo que a idade continua recuperável enquanto a data exata de aniversário não sai do endpoint.

Risco de reidentificação (cluster de quase-identificadores)

Mesmo quando nenhum campo isolado é PII, três ou mais quase-identificadores no mesmo prompt reidentificam uma pessoa com alta probabilidade (Sweeney 2000). O agente dispara uma classificação quasi_identifier_cluster quando três ou mais dos itens a seguir ocorrem juntos em um único prompt: gênero, idade, ZIP dos EUA, CEP brasileiro, cidade ou estado, estado civil, ocupação, empregador, nacionalidade ou uma data de nascimento no corpo do texto. A linha de evidência mostra as categorias que casaram, e não os valores brutos, então o analista vê por que o cluster disparou sem que nenhum quase-identificador isolado saia do host.

Informações de saúde protegidas (PHI)

Vocabulário clínico em inglês e português, códigos CID-10 (ICD-10), nomes comuns de medicamentos e de exames laboratoriais (subconjuntos de RxNorm e LOINC), registros profissionais brasileiros (CRM, CRO, COREN) e operadoras de planos de saúde (Unimed, Amil, Bradesco Saúde, Hapvida e outras). Esses itens são tratados, por si só, como temas de saúde e só escalam para um achado real de PHI quando há um identificador de paciente (MRN, CNS) presente, ou quando um identificador pessoal aparece no mesmo prompt. Uma pergunta geral como "explique hipertensão" permanece informativa; o mesmo texto com um CPF se torna um incidente de PHI.

Dados de categoria especial (LGPD Art. 5 II e GDPR Art. 9)

Origem racial, religião, opinião política, filiação sindical, orientação sexual, dados biométricos e dados genéticos. Cada categoria é detectada com um vocabulário bilíngue e tratada da mesma forma que PHI: por si só é um tema, e só é um achado real quando um identificador pessoal corrobora o titular. Assim, "explique a doutrina católica" permanece um tema; o mesmo conteúdo ao lado de um CPF se torna um incidente do Art. 5 II ou do Art. 9.

Dados financeiros

Cartão de crédito validado por Luhn, IBAN validado pela verificação mod-97 contra uma tabela de comprimento por país com 80 países emissores de IBAN, códigos SWIFT e BIC em contexto rotulado e pares brasileiros de agência e conta.

Credenciais e tokens de nuvem

Chaves de acesso da AWS, JWTs, chaves privadas (RSA, EC, OpenSSH, DSA, PGP), chaves de API da Anthropic (sk-ant-), chaves da OpenAI com escopo de projeto (sk-proj-), chaves de API do Google (AIza...), chaves live da Stripe (sk_live_, rk_live_, pk_live_; as variantes de teste são deliberadamente ignoradas), webhooks do Slack, PATs fine-grained do GitHub e tokens OAuth, de refresh e server-to-server, tokens SAS do Azure e AccountKey= de storage, JSON de service account do GCP, SendGrid, Mailgun, Twilio, strings de conexão de banco de dados com credenciais embutidas (com filtro de entropia para ignorar trechos de documentação) e YAML de kubeconfig.

Tokens de provedores que não têm um detector dedicado ainda são capturados pela regra genérica de atribuição key = value, com um filtro de entropia que rejeita placeholders como change-me, process.env.X ou os.getenv(...).

Código-fonte, objetos SQL e contexto interno

Sinais estruturais (fences de código, imports, definições de função, SELECT, INSERT, CREATE TABLE, mysqldump, pg_dump), faixas RFC1918, .internal, .corp, .local, .lan, além dos nomes da sua própria organização e dos domínios internos configurados na política.

Marcadores de produção e de confidencialidade

Menções a production, prod, confidential, NDA, proprietary amplificam o risco de qualquer achado adjacente. O classificador emite um reforço por coocorrência quando um amplificador aparece ao lado de dados sensíveis reais, então "melhore este código de PRODUCTION do banco XPTO" carrega mais risco do que "melhore este código".

Resistência a bypass

Duas formas adversariais são neutralizadas sem nenhuma configuração:

• Substituição por caracteres Unicode semelhantes. Dígitos de largura total (fullwidth) e caracteres homógrafos são normalizados (NFKC) antes de o classificador ver o prompt, então CPF １１１.４４４.７７７-３５ e password=раssword123 são tratados como CPF 111.444.777-35 e password=password123.
• Envelopes codificados. Conteúdo embrulhado em base64, URL-encoding, sequências de escape JSON ou hexadecimal é decodificado em memória (até três passagens de profundidade), e o classificador roda de novo sobre cada trecho decodificado. Os achados recuperados dessa forma recebem um selo via base64 ou via base64>url no portal.

Mascaramento de evidências

Toda classificação carrega uma amostra de evidência mascarada, para que um revisor possa auditar um verdadeiro positivo sem que o valor bruto saia do endpoint em momento algum. Exemplos:

O que ele não captura

O contrato de privacidade é o produto. O agente nunca persiste prompts brutos, conteúdo bruto de arquivos nem capturas de tela. O armazenamento persistente guarda apenas metadados: um fingerprint SHA-256 curto, contagens de caracteres e de tokens, rótulos de classificação, as amostras de evidência mascarada acima e uma referência pseudonimizada do usuário. O nome de usuário do sistema operacional em texto claro e o IPv4 principal de saída são registrados para atribuição dentro da organização, uma escolha de postura intencional para investigações de risco interno.

Uploads (DOCX, XLSX, ZIP, PDF, texto puro) são inspecionados em memória e os bytes são descartados. Apenas os metadados, o SHA-256 do arquivo e as classificações resultantes são armazenados.

Como a chave de API da organização é armazenada no endpoint

A chave de API da organização fica no repositório de credenciais criptografado nativo do sistema operacional: macOS Keychain, Windows Credential Manager ou Linux Secret Service. Um envelope adicional na camada de aplicação vincula a credencial ao host de origem, de modo que uma entrada do keystore copiada para outra máquina é descriptografada como lixo. Nada sensível é gravado em arquivo simples no endpoint.

O que isso oferece a você:

• Seguro em backups. Time Machine, iCloud e ferramentas corporativas de backup não varrem o repositório de credenciais, então uma restauração de rotina não ressuscita a chave em outra máquina.
• Seguro no suporte. Quando um operador cola a configuração do agente em um chamado de suporte, nenhuma credencial vai junto.
• Pronto para conformidade. Auditores que cobrem SOC 2 CC6.6, ISO 27001 A.10.1 e as Technical Safeguards da HIPAA perguntam se as credenciais do host são criptografadas em repouso. A resposta é sim, pelo repositório de credenciais nativo do sistema operacional, com um envelope na camada de aplicação por cima.

Escopo honesto: o keystore não derrota um atacante que já tenha a sessão interativa do usuário e consiga ler a memória do processo do agente em execução, ou que consiga redirecionar o endpoint da API para capturar o header Authorization de saída. Esses riscos residuais de ameaça interna são tratados por controles complementares: credenciais de curta duração, detecção de anomalias no lado da API e fluxos de trabalho de revogação. Eles estão fora do escopo desta página.

Os operadores verificam o estado da credencial no host com wasviking-sentinel ai-browser key-status. O comando informa a origem do armazenamento e nunca imprime a chave.

Mapeamento regulatório

Toda classificação carrega uma lista estável de tags de conformidade que mapeiam o achado para os frameworks regulatórios que ele envolve. O mapeamento é determinístico no nível do detector, então o mesmo prompt produz o mesmo conjunto de tags em todos os hosts.

O dashboard exibe essas tags como chips coloridos. A linha do evento na tabela carrega uma consolidação deduplicada de todos os frameworks que o evento envolve; o drawer de detalhes mostra o conjunto de chips por classificação, para que você veja se um único achado se relaciona a PCI DSS, HIPAA, GDPR, LGPD ou a vários deles ao mesmo tempo.

Detecção avançada

Três ajustes de configuração permitem apertar ou estender o classificador por tenant. Os três ficam no arquivo de política do agente.

Detectores personalizados por tenant

Adicione padrões proprietários que os detectores nativos não cobrem, por exemplo um ID interno de colaborador, um código de projeto ou uma referência de cliente. Cada entrada carrega o seu próprio rótulo, categoria, regex (sintaxe RE2), confiança, máscara e tags de conformidade. O agente se recusa a iniciar se um padrão não compilar, então um erro de digitação nunca desarma a detecção em silêncio. Até 64 detectores personalizados por tenant.

Calibração de confiança por rótulo

Um multiplicador por rótulo no intervalo [0, 1] atenua um detector ruidoso para o seu tenant sem desativá-lo. O multiplicador só reduz a confiança, nunca a aumenta. O mesmo motor apresenta tanto os achados de regex quanto os de detectores personalizados, então a calibração cobre os dois.

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

Para prompts em que o motor determinístico retorna baixa confiança ou uma pontuação alta e você quer uma segunda opinião, o agente pode chamar um provedor de LLM diretamente, com a sua chave de API, para adicionar classificações semânticas. A postura de conexão direta do cliente é intencional: o conteúdo do prompt vai do endpoint ao provedor de LLM por TLS público e nunca transita pela infraestrutura da WASViking. Os resultados ficam em cache em disco, indexados pelo SHA-256 do prompt, então prompts idênticos nunca são reclassificados. Uma proteção de orçamento diário interrompe as chamadas quando o teto é atingido. Os achados de LLM aparecem no dashboard com o prefixo llm_, para que se distingam dos acertos de 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.

O formato de configuração dos três ajustes está documentado em Configurar o WASViking AI Guardian.

Aplicação de políticas no endpoint

Você define as regras em Portal > AI Guardian Policies. Cada regra combina:

• Evento: envio de prompt, colagem, upload de arquivo ou qualquer um.
• Condições (combinadas com AND): categoria do site (IA generativa, não autorizado, autorizado), classe de dado (PII, PHI, secret, código-fonte, interno), severidade mínima, plataforma de IA, navegador.
• Alvos: todos os usuários, nomes de usuário específicos do sistema operacional (inclusão e exclusão) ou grupos de diretório sincronizados a partir do seu provedor de identidade. Os alvos do tipo grupo são resolvidos para usuários confirmados no momento em que a política é servida, então uma regra pode dizer "Financeiro" em vez de uma lista de logins (veja Identidade e diretório).
• Ação: Block, Warn, Audit ou Allow (bloquear, avisar, auditar ou permitir). Entre regras sobrepostas, a ação mais forte prevalece.

Quando um usuário cola um cartão de crédito em um chat com uma ferramenta de IA não autorizada e uma regra Block casa, o agente interrompe a colagem e exibe um card com a identidade da marca, "Paste blocked" (colagem bloqueada), com o nome da regra e a mensagem que você configurou. A página não recebe nenhum conteúdo. As decisões de bloqueio e os metadados da política são gravados na trilha de auditoria local e encaminhados ao seu tenant.

Identidade e diretório

Os agentes observam um nome de usuário do sistema operacional em cada dispositivo. Sozinha, essa string é difícil de governar em escala: a mesma pessoa pode ter logins diferentes em máquinas diferentes, e um login como jsilva não diz nada a um auditor. A página Identity, em Cyber Risk > AI Guardian > Identity, mapeia esses nomes de usuário do sistema operacional para identidades corporativas do seu diretório, o que habilita o direcionamento de políticas por grupo, nomes reais nos dashboards e solicitações de eliminação que cobrem todos os dispositivos que uma pessoa usa.

• Sincronização de diretório (SCIM 2.0). Aponte o provisionamento do seu provedor de identidade para o endpoint SCIM exibido na página e cole o bearer token gerado ali. Suportados hoje: Microsoft Entra ID (o diretório por trás do Microsoft 365 / Office 365, então não há integração separada a configurar se você já usa o Microsoft 365) e Okta. Usuários e grupos são sincronizados automaticamente. Rotacionar o token invalida o anterior imediatamente. O token é exibido uma única vez, no momento da geração, e armazenado apenas como hash.
• Sincronização de diretório do Google Workspace. O Google Workspace não envia SCIM para um app que você mesmo cria, então a WASViking busca o seu diretório, de forma agendada, usando uma service account do Google somente leitura (Admin SDK Directory API). Isso traz os seus usuários e os grupos deles, algo que uma exportação simples de usuários do Google deixa de fora. O guia de configuração traz os passos no Google, feitos uma única vez.
• Importação por CSV. Para organizações sem um provedor de identidade, importe as identidades a partir de um CSV com user_name, display_name, department e groups (separados por ";"). Reimportações atualizam as linhas existentes.
• Mapeamento de aliases. Uma varredura 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 usando heurísticas determinísticas (login exato, parte local do e-mail, nome de exibição). Toda sugestão é revisada por uma pessoa: somente aliases confirmados afetam a aplicação de políticas, os dashboards ou a eliminação. Uma sugestão nunca bloqueia nem atribui nada por conta própria, então o sistema não tem como agir sobre a pessoa errada. Confirmações e rejeições são gravadas na trilha de auditoria.
• Direcionamento de políticas por grupo. Depois que os aliases são confirmados, uma regra de aplicação pode ter como alvo um grupo de diretório. Quando a política é servida aos agentes, o grupo é expandido para os nomes de usuário confirmados por trás dele, então o agente aplica a política exatamente da mesma forma de sempre; a camada de diretório muda quem uma regra cobre, não como o endpoint se comporta.
• Eliminação por pessoa. Uma solicitação de direito ao esquecimento pode indicar uma identidade corporativa em vez de um único login. A solicitação se expande para todos os aliases confirmados daquela pessoa e remove os eventos dela em todos os seus dispositivos em uma única operação, que é o que o Art. 16 da LGPD e o Art. 17 do GDPR esperam quando um colaborador usa mais de uma máquina.

Os mapeamentos confirmados são resolvidos para nomes reais nos dashboards; os eventos cujo nome de usuário não tem identidade confirmada mantêm o login bruto e são exibidos como não verificados, então o console nunca sugere uma atribuição que não possa sustentar.

Dashboards no portal

Quatro páginas em Cyber Risk leem o mesmo repositório de eventos por tenant, cada uma desenhada para um público diferente:

• Executive Summary (/portal/cyber-risk/ai-guardian/executive/): consolidação para C-level e conformidade. AI Security Score (índice composto de 0 a 100 com quatro pilares: governança de fornecedores, minimização de dados, cobertura de aplicação de políticas, concentração de usuários), quatro KPIs de destaque (apps não aprovados, uploads sensíveis, usuários de alto risco, decisões de bloqueio), grupos de postura de fornecedores (Approved / Review / Blocked), dados sensíveis enviados a IA por categoria e os principais usuários por risco. A fórmula da pontuação é publicada na mesma página, para que um auditor possa contestar a conta.
• AI Guardian (/portal/cyber-risk/ai-guardian/): drill-down para o SOC. Blocos de KPI (eventos, Critical e High, dispositivos monitorados, principal plataforma de IA), série temporal, gráficos de rosca de severidade, postura de fornecedores, política, sistema operacional e navegador, principais usuários e uma tabela paginada de eventos com evidência mascarada no drawer de detalhes. A coluna Type traz uma etiqueta decoded quando uma correspondência veio de um envelope codificado; o drawer abre com uma linha Compliance que lista todos os frameworks regulatórios que o evento envolve.
• AI Applications (/portal/cyber-risk/ai-guardian/applications/): visão para TI e conformidade. Consolidação por aplicação de IA com usuários, alertas, uploads, postura de autorização, distribuição de severidade e indicadores de tendência em relação à janela anterior.
• AI Guardian Policies (/portal/cyber-risk/ai-guardian/policies/): engenharia de segurança. Construtor de linhas para as regras descritas acima.

Atualizações e governança de releases

O agente se atualiza no próprio lugar por meio de um fluxo verificado. Cada aplicação de atualização recalcula o sha256 do binário baixado, valida a assinatura de código do sistema operacional, obtém um lock de execução única (single-flight), faz backup do binário em execução, renomeia atomicamente o novo binário para o lugar dele, reinicia o serviço e consulta /healthz esperando a nova versão. Se qualquer etapa falhar, o binário anterior é restaurado automaticamente. O host nunca fica em um estado de atualização aplicada pela metade.

A governança por organização fica em Settings > System Settings > AI Guardian. Os administradores escolhem o canal de release (stable, beta ou canary) e podem definir uma versão fixada (pinned version) para homologar um build por vez. A mesma aba traz o card Vendor governance, com três estados por fornecedor: Approved (autorizado no dashboard), Blocked (explicitamente proibido, registrado como bloqueado no dashboard) e Review (o padrão, tratado como Shadow AI). Os controles do portal prevalecem sobre o que um endpoint solicita pela rede.

Próximos passos

Siga o guia de configuração: Configurar o WASViking AI Guardian.