WASViking AI Guardian

AI exposure monitoring on employee endpoints. Detects sensitive data sent to public AI tools, enforces organization policy at paste time, and reports activity per user, device, and AI application.

WASViking^® AI Guardian is an AI exposure intelligence layer for the endpoint. It observes how employees interact with public AI tools (ChatGPT, Claude, Gemini, Copilot, Perplexity, and others), classifies the content they are about to send, and enforces the policies your security team configures in the portal.

It is not a DLP proxy, a man in the middle, an SSL inspector, or a keylogger. The browser sensor reads the composer text only at submit or paste time and the agent processes it in memory.

Coverage maps to insider risk, data minimization (GDPR, LGPD), PCI DSS masking, and HIPAA confidentiality of PHI.

What it detects

The agent classifies content with a deterministic engine that combines high precision detectors with a context layer. The catalog covers Brazilian and global identifiers, protected health information, financial data, special category data under LGPD and GDPR, cloud credentials, names and addresses, and structural signals.

Personal data (PII)

• Brazilian identifiers: CPF, CNPJ, RG (São Paulo state checksum unlabeled, every state when labeled), CNH (Denatran dual mod-11 check digits), PIS, PASEP, NIS, NIT, passport, and PIX keys in all four shapes (CPF, CNPJ, email, phone, and the random UUID form).
• Global identifiers: email, phone, SSN, credit card validated by Luhn, and full names introduced by an honorific (Sr., Dr., Mr., Mrs., Prof., including the Portuguese connectives da, de, dos) or a labeled field (Name:, Patient:, Cliente:).
• Postal addresses: Brazilian forms anchored by Rua, Av., Travessa, Praça, Rodovia, and English forms anchored by Street, Avenue, Boulevard, Highway.
• Dates of birth in labeled contexts (DOB:, Date of birth:, Nascimento:, Data de nascimento:). Evidence is masked to year only (••/••/1985) so the age stays recoverable while the exact birthday does not leave the endpoint.

Re-identification risk (quasi-identifier cluster)

Even when no single field is PII, three or more quasi-identifiers in the same prompt re-identify a person with high probability (Sweeney 2000). The agent fires a quasi_identifier_cluster classification when three or more of the following co-occur in a single prompt: gender, age, US ZIP, Brazilian CEP, city or state, marital status, occupation, employer, nationality, or an inline date of birth. The evidence row shows the matched categories rather than the raw values, so the analyst sees why the cluster fired without any single quasi-identifier leaving the host.

Protected health information (PHI)

Clinical vocabulary in English and Portuguese, ICD-10 codes, common medication and laboratory test names (RxNorm and LOINC subsets), Brazilian professional registries (CRM, CRO, COREN), and health insurance carriers (Unimed, Amil, Bradesco Saúde, Hapvida, and others). These are treated as health topics on their own and only escalate to a real PHI finding when a patient identifier (MRN, CNS) is present, or when a personal identifier sits in the same prompt. A general question like "explain hypertension" stays informational; the same text with a CPF becomes a PHI incident.

Special category data (LGPD Art. 5 II and GDPR Art. 9)

Racial origin, religion, political opinion, union membership, sexual orientation, biometric data, and genetic data. Each category is detected with a bilingual vocabulary and treated the same way as PHI: a topic on its own, a real finding only when a personal identifier corroborates the subject. So "explain Catholic doctrine" stays a topic; the same content next to a CPF becomes an Art. 5 II or Art. 9 incident.

Financial data

Credit card validated by Luhn, IBAN validated by the mod-97 check across a country-length table of 80 IBAN-issuing countries, SWIFT and BIC codes in labeled context, and Brazilian agency-and-account pairs.

Credentials and cloud tokens

AWS access keys, JWTs, private keys (RSA, EC, OpenSSH, DSA, PGP), Anthropic API keys (sk-ant-), OpenAI project-scoped keys (sk-proj-), Google API keys (AIza...), Stripe live keys (sk_live_, rk_live_, pk_live_; the test variants are deliberately ignored), Slack webhooks, GitHub fine-grained PATs and OAuth and refresh and server-to-server tokens, Azure SAS tokens and storage AccountKey=, GCP service account JSON, SendGrid, Mailgun, Twilio, database connection strings with embedded credentials (entropy-gated to skip documentation snippets), and kubeconfig YAML.

Provider tokens that lack a dedicated detector are still caught by the generic key = value assignment rule with an entropy gate that rejects placeholders like change-me, process.env.X, or os.getenv(...).

Source code, SQL objects, and internal context

Structural signals (fences, imports, function definitions, SELECT, INSERT, CREATE TABLE, mysqldump, pg_dump), RFC1918 ranges, .internal, .corp, .local, .lan, plus your own organization names and internal domains as configured in policy.

Production and confidentiality markers

Mentions of production, prod, confidential, NDA, proprietary amplify the risk of any adjacent finding. The classifier emits a co-occurrence boost when an amplifier sits next to real sensitive data, so "improve this PRODUCTION code for banco XPTO" carries more risk than "improve this code".

Bypass resistance

Two adversarial shapes are defeated without configuration:

• Unicode look-alike substitution. Fullwidth digits and homograph characters are normalized (NFKC) before the classifier sees the prompt, so CPF １１１.４４４.７７７-３５ and password=раssword123 are treated as CPF 111.444.777-35 and password=password123.
• Encoded envelopes. Content wrapped in base64, URL-encoding, JSON escape sequences, or hex is decoded in memory (up to three passes deep) and the classifier runs again on each decoded chunk. Findings recovered this way carry a via base64 or via base64>url badge in the portal.

Evidence masking

Every classification carries a masked evidence sample so a reviewer can audit a true positive without the raw value ever leaving the endpoint. Examples:

What it does not capture

The privacy contract is the product. The agent never persists raw prompts, raw file contents, or screen captures. Persistent storage holds only metadata: a short SHA-256 fingerprint, character and token counts, classification labels, the masked evidence samples above, and a pseudonymized user reference. The cleartext OS user name and primary egress IPv4 are recorded for organization attribution, an intentional posture choice for insider risk investigations.

Uploads (DOCX, XLSX, ZIP, PDF, plain text) are inspected in memory and the bytes are discarded. Only metadata, the SHA-256 of the file, and the resulting classifications are stored.

How the organization API key is stored on the endpoint

The organization API key is held in the operating system's native encrypted credential store: macOS Keychain, Windows Credential Manager, or Linux Secret Service. An additional application-layer envelope binds the credential to the originating host, so a keystore entry copied to another machine decrypts to garbage. Nothing sensitive is written to a plain file on the endpoint.

What this gives you:

• Backup-safe. Time Machine, iCloud, and corporate backup tools do not sweep the credential store, so a routine restore does not resurrect the key on a different machine.
• Support-safe. When an operator pastes the agent's configuration for a support ticket, no credential goes with it.
• Compliance-ready. Auditors covering SOC 2 CC6.6, ISO 27001 A.10.1, and HIPAA Technical Safeguards ask whether host credentials are encrypted at rest. The answer is yes, by the OS-native credential store with an application-layer envelope on top.

Honest scope: the keystore does not defeat an attacker who already has the user's interactive session and can read the running agent's process memory, or who can redirect the API endpoint to capture the outbound Authorization header. Those residual insider-threat risks are addressed by complementary controls: short-lived credentials, anomaly detection at the API side, and revocation workflows. They are out of scope of this page.

Operators verify the on-host credential state with wasviking-sentinel ai-browser key-status. The command reports the storage source and never prints the key.

Regulatory mapping

Every classification carries a stable list of compliance tags that map the finding to the regulatory frameworks it implicates. The mapping is deterministic at the detector level, so the same prompt produces the same tag set on every host.

The dashboard surfaces these as colored chips. The event row in the table carries a deduplicated rollup of every framework the event implicates; the detail drawer shows the per-classification chip set so you can see whether a single finding maps to PCI DSS, HIPAA, GDPR, LGPD, or several of them at the same time.

Advanced detection

Three configuration knobs let you tighten or extend the classifier per tenant. All three live in the agent policy file.

Per-tenant custom detectors

Add proprietary patterns the built-in detectors do not cover, for example an internal employee ID, a project code, or a customer reference. Each entry carries its own label, category, regex (RE2 syntax), confidence, mask, and compliance tags. The agent refuses to start if a pattern fails to compile, so a typo never silently disarms detection. Up to 64 custom detectors per tenant.

Confidence calibration per label

A per-label multiplier in the [0, 1] range damps a noisy detector for your tenant without disabling it. The multiplier only lowers confidence, never raises it. The same engine surfaces both regex and custom-detector findings, so calibration covers both.

LLM-assisted classification (opt in)

For prompts where the deterministic engine returns low confidence or a high score and you want a second opinion, the agent can call an LLM provider directly with your API key to add semantic classifications. The customer-direct posture is intentional: the prompt content goes from the endpoint to the LLM provider over public TLS and never transits WASViking infrastructure. Results are cached on disk by SHA-256 of the prompt, so identical prompts are never re-classified. A daily budget guard stops calls when the cap is reached. LLM findings appear in the dashboard with the llm_ prefix so they are distinguishable from regex hits.

This layer is most useful for paraphrased PII, contract text, M&A context, and proprietary IP that pattern matching cannot describe.

The configuration shape for all three knobs is documented in Set up WASViking AI Guardian.

Policy enforcement at the endpoint

You define rules under Portal > AI Guardian Policies. Each rule combines:

• Event: prompt submit, paste, file upload, or any.
• Conditions (ANDed): website category (generative AI, unsanctioned, sanctioned), data class (PII, PHI, secret, source code, internal), minimum severity, AI platform, browser.
• Targets: all users, specific OS user names (include and exclude), or directory groups synced from your identity provider. Group targets are resolved to confirmed users when the policy is served, so a rule can read "Finance" instead of a list of logins (see Identity and directory).
• Action: Block, Warn, Audit, or Allow. Stronger actions win across overlapping rules.

When a user pastes a credit card into a chat with an unsanctioned AI tool and a Block rule matches, the agent stops the paste and displays a branded "Paste blocked" card with the rule name and the message you configured. The page receives no content. Block decisions and policy metadata are written to the local audit trail and forwarded to your tenant.

Identity and directory

Agents observe an operating-system user name on each device. On its own that string is hard to govern at scale: the same person can have different logins on different machines, and a login like jsilva means nothing to an auditor. The Identity page under Cyber Risk > AI Guardian > Identity maps those OS user names to corporate identities from your directory, which unlocks group-based policy targeting, real names in the dashboards, and erasure requests that cover every device a person uses.

• Directory sync (SCIM 2.0). Point your identity provider's provisioning at the SCIM endpoint shown on the page and paste the bearer token generated there. Supported today: Microsoft Entra ID (the directory behind Microsoft 365 / Office 365, so there is no separate integration to configure if you already use Microsoft 365) and Okta. Users and groups sync automatically. Rotating the token invalidates the previous one immediately. The token is shown once at generation time and stored only as a hash.
• Google Workspace directory sync. Google Workspace does not push SCIM to an app you create yourself, so WASViking pulls your directory instead, on a schedule, using a read-only Google service account (Admin SDK Directory API). This brings in your users and their groups, which a plain Google user export leaves out. The setup guide has the one-time Google steps.
• CSV import. For organizations without an identity provider, import identities from a CSV with user_name, display_name, department, and groups (separated by ";"). Re-imports update existing rows.
• Alias mapping. A scan reads the distinct OS user names seen in your event stream over the last 31 days and proposes matches against your identities using deterministic heuristics (exact login, email local part, display name). Every suggestion is reviewed by a person: only confirmed aliases ever affect enforcement, dashboards, or erasure. A suggestion never blocks or attributes anything on its own, so the system cannot act on the wrong person. Confirmations and rejections are written to the audit log.
• Group policy targeting. Once aliases are confirmed, an enforcement rule can target a directory group. When the policy is served to agents the group is expanded to the confirmed user names behind it, so the agent enforces exactly the same way it always has; the directory layer changes who a rule covers, not how the endpoint behaves.
• Erasure by person. A right-to-be-forgotten request can name a corporate identity instead of a single login. The request expands to every confirmed alias of that person and removes their events across all of their devices in one operation, which is what LGPD Art. 16 and GDPR Art. 17 expect when an employee uses more than one machine.

Confirmed mappings resolve to real names in the dashboards; events whose user name has no confirmed identity keep the raw login and are shown as unverified, so the console never implies an attribution it cannot stand behind.

Dashboards in the portal

Four pages under Cyber Risk read the same per-tenant event store, each designed for a different audience:

• Executive Summary (/portal/cyber-risk/ai-guardian/executive/): C-level and compliance rollup. AI Security Score (0 to 100 composite of four pillars: vendor governance, data minimization, enforcement coverage, user concentration), four headline KPIs (unapproved apps, sensitive uploads, high-risk users, block decisions), vendor posture buckets (Approved / Review / Blocked), sensitive data sent to AI by category, and top users by risk. The score formula is published in the same page so an auditor can challenge the math.
• AI Guardian (/portal/cyber-risk/ai-guardian/): SOC drill-down. KPI tiles (events, critical and high, monitored devices, top AI platform), time series, severity, vendor posture, policy, OS and browser donuts, top users, and a paginated events table with masked evidence in the detail drawer. The Type column carries a decoded pill when a match came from an encoded envelope; the drawer opens with a Compliance row that lists every regulatory framework the event implicates.
• AI Applications (/portal/cyber-risk/ai-guardian/applications/): IT and compliance view. Per-AI-app rollup with users, alerts, uploads, sanctioned posture, severity mix, and trend pills against the previous window.
• AI Guardian Policies (/portal/cyber-risk/ai-guardian/policies/): security engineering. Row builder for the rules described above.

Updates and release governance

The agent updates itself in place through a verified flow. Each apply recomputes sha256 on the downloaded binary, validates the operating system code signature, takes a single-flight lock, backs up the running binary, atomically renames the new one in place, restarts the service, and checks /healthz for the expected new version. If any step fails, the previous binary is restored automatically. The host never sits in a half-applied state.

Per-organization governance lives under **Settings > System Settings

AI Guardian. Administrators choose the release channel (stable, beta, or canary) and may set a pinned version to homologate one build at a time. The same tab carries the Vendor governance** card with three states per vendor: Approved (sanctioned in the dashboard), Blocked (explicitly forbidden, recorded as blocked in the dashboard) and Review (the default, treated as Shadow AI). The portal controls win over what an endpoint requests on the wire.

Where to go next

Follow the setup guide: Set up WASViking AI Guardian.