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 in the portal under Cyber Risk > 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, or include/exclude specific OS user names.
• 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.

Dashboards in the portal

Three pages under Cyber Risk read the same per-tenant event store:

• AI Guardian (/portal/cyber-risk/ai-guardian/): 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/): 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/): row builder for the rules described above.

Where to go next

Follow the setup guide: Set up WASViking AI Guardian.