Set up WASViking AI Guardian

Enable AI Guardian for your organization, create the install API key, set the master password, install the endpoint agent on Linux, macOS, and Windows, and validate the first policy block.

This guide walks an administrator through enabling WASViking^® AI Guardian for an organization and rolling the agent out to employee endpoints. The flow has five stages:

1. Enable AI Guardian for the organization.
2. Set the AI Guardian master password.
3. Create an install API key.
4. Run the install command on each endpoint (Linux, macOS, Windows).
5. Validate detection and policy enforcement.

You need the Admin role on the organization to complete this flow. Manager, Analyst, and Read-Only roles can view the AI Guardian dashboards but cannot change settings, create API keys, or edit policies.

For background on what AI Guardian detects and how the policy engine works, see WASViking AI Guardian.

Step 1. Enable AI Guardian for the organization

Sign in to portal.wasviking.com and go to Settings > System Settings > API Keys.

At the top of the tab you will find the WASViking AI Guardian card. The card describes the privacy contract (classifications, scores and masked evidence only, never raw prompts or files).

Move the Status toggle to Enabled. The change takes effect within a few minutes on every registered endpoint and is logged in the audit trail as ai_guardian.toggle.

If you do not see the AI Guardian card on this tab, the feature is not yet active on your plan. Contact [email protected] to have it activated.

Step 2. Set the AI Guardian master password

Still on the AI Guardian card, fill in Master password and Confirm password, then click Save.

The master password gates two privileged operations on the endpoint:

• Uninstalling the agent (wasviking-sentinel ai-browser uninstall).
• Lifting the force-installed browser extension policy on a managed machine.

Choose a passphrase of at least 12 characters and keep it in your secrets manager. The portal stores only a one-way hash and the endpoint never sees the cleartext. Lose it and you will need to set a new one in the portal before any agent can be uninstalled.

Step 3. Create an install API key

Still under Settings > System Settings > API Keys, scroll to the API Keys card and click + New Key.

Fill the Create API Key form:

Click Create Key. The API Key Created modal opens.

The key is shown once. Copy it now and store it in your secrets manager. The portal stores only its prefix and a hash.

The same modal includes the Install on a new machine section with three OS tabs and the matching install command. The command is self-contained: it carries the API key in the Authorization header, downloads a verified install script, registers the endpoint, fetches its mTLS certificates, and starts the agent under the operating system service manager. You can reuse the same key to install on as many machines as you need while the key is active.

The endpoints that this key enables on each device are bootstrap only. Once an agent is registered, it identifies itself by its mTLS client certificate, not by the API key. You can rotate or revoke the install key without disconnecting endpoints that are already running.

Step 4. Install the agent on an endpoint

Pick the OS tab in the Install on a new machine card and copy the command. The shapes below are reference examples. Always use the exact command the portal generates for your tenant, since it carries your API key and points at your tenant API host.

Linux

Run the command in a terminal with sudo. The script installs under /opt/wasviking-sentinel/, writes a systemd unit named wasviking-sentinel, and starts the per-user monitor.

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

Verify the service:

sudo systemctl status wasviking-sentinel

macOS

Run the command in Terminal.app as the user who will be monitored. The script installs under ~/Library/Application Support/WASViking/ and registers a LaunchAgent that starts the monitor on login.

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

Verify the agent:

launchctl list | grep wasviking

On the first run, macOS may prompt for permission to allow the browser extension and the native messaging host. Approve both.

Windows

Open PowerShell as Administrator and paste the command from the Windows tab. The installer drops the binaries under %ProgramFiles%\WASViking\Sentinel\ and registers a scheduled task plus a per-user service that starts at sign-in.

$h = @{ Authorization = 'ApiKey wv_live_xxxxxxxxxxxxxxxx' }
iwr -UseBasicParsing -Headers $h `
  https://api.wasviking.com/api/v1/sentinel/ai-guardian/install.ps1 `
  | iex

Verify the service in Services.msc (look for WASViking Sentinel) or in PowerShell:

Get-Service wasviking-sentinel

Browser extension

The install command applies the WASViking AI Guardian browser extension through the standard managed-policy mechanisms that Chrome, Edge, and Brave already support across Linux, macOS, and Windows. The exact policy keys and paths are documented by the browser vendors themselves and remain the authoritative reference:

• Chrome Enterprise — Manage Chrome extensions
• Microsoft Edge — ExtensionInstallForcelist policy

At the next browser launch, the extension installs and pins itself to the toolbar. The popup shows Paired with the local WASViking agent when the bridge to the local monitor is healthy.

Operators that deploy through MDM (Intune, Jamf, Workspace ONE) can apply the same managed-policy values through their existing channels instead of relying on the agent to write them.

Mass deployment

For fleet rollout, distribute the install command through your endpoint management tool (Ansible, Puppet, Intune, Jamf, SCCM). The script is idempotent and supports re-runs on the same device. To script a silent rollout, store the API key in your secrets manager and inject it as the Authorization header at deploy time.

Step 5. Validate detection and policy enforcement

Confirm the device shows up in the portal

Within a couple of minutes of installation, open Cyber Risk > AI Guardian in the portal. The endpoint will appear under Monitored devices as soon as it processes its first event.

Generate a test event

Open Chrome or Edge on the endpoint. Visit chat.openai.com (or any AI tool listed in the dashboard) and paste sensitive content into the composer. The classifier ships with a wide catalog, including:

• Brazilian and global identifiers: CPF, CNPJ, RG, CNH, PIS, passport, PIX keys (including the random UUID form), IBAN, SWIFT or BIC, SSN, credit card.
• Names, postal addresses, and dates of birth when introduced by an honorific or a labeled field (for example Patient: Jane Doe, Date of birth: 12/03/1985, Rua das Flores, 123, São Paulo).
• Special category data under LGPD Art. 5 II and GDPR Art. 9: racial origin, religion, political opinion, union membership, sexual orientation, biometric and genetic data. The classifier treats these as indicators on their own and only escalates them when a personal identifier sits in the same prompt.
• Protected health information: clinical vocabulary in English and Portuguese, ICD-10 codes, medical record numbers (MRN, CNS), Brazilian professional registries (CRM, CRO, COREN), health insurance carriers.
• Credentials and cloud tokens: AWS access keys, Anthropic keys, OpenAI project keys, Google API keys, Stripe live keys, Slack webhooks, GitHub fine-grained and OAuth tokens, Azure SAS and storage keys, GCP service account JSON, database connection strings, kubeconfig, and more.
• Source code, internal URLs, SQL objects, and your own organization lexicon when you provide one through policy.

The detection layer also defeats two common bypass shapes without any configuration:

• Unicode look-alike substitution. Fullwidth digits and homograph characters are normalized before the classifier sees the prompt, so CPF １１１.４４４.７７７-３５ is detected the same way as the ASCII form.
• Encoded envelopes. Content wrapped in base64, URL-encoding, JSON escape sequences, or hex is decoded in memory and the classifier runs again on each decoded chunk. Findings recovered this way carry a via base64 (or via base64>url) badge in the dashboard so an analyst can recognize adversarial encoding.

Outcomes of the paste:

• If no policy matches, the agent records a classified event with severity and masked evidence. The event surfaces in the dashboard table within a minute.
• If a Block policy matches, the agent stops the paste and the browser shows the Paste blocked card with the rule name and the message you configured. The blocked event is recorded with policy.action = block.

What you will see in the portal

When the test event reaches Cyber Risk > AI Guardian, the classifier metadata flows through to the dashboard:

• The event row carries a small decoded pill on the Type column whenever at least one match came from an encoded envelope (base64, URL-encode, JSON escape, hex). This is your one-glance signal that the prompt contained encoded exfil rather than literal text.
• The detail drawer opens with a Compliance row that lists every regulatory framework the event implicates, as colored chips. The classifier stamps stable framework strings on every finding: 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.
• Each classification row in the drawer carries its own chip set, so you can see whether a given finding maps to PCI, HIPAA, GDPR, LGPD, or several of them at the same time.
• The masked evidence next to each classification shows enough of the match to confirm a true positive (•••.•••.•••-35 for a CPF, AKIA••••••MPLE for an AWS key, J••• da S•••• for a name, ••/••/1985 for a date of birth) without ever storing the raw value.

This is the same data the policy engine sees, so a chip on the drawer means the policy could have matched on compliance:LGPD.Art.9 if you wanted to. Filtering and per-tenant compliance widgets are on the roadmap.

Create a first Block policy

To prove the block path works on a real endpoint, go to Cyber Risk > AI Guardian Policies > New policy and configure:

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

Save the rule. The agent fetches the new policy on its next refresh cycle. Repeat the paste from the previous step and confirm the block.

Where the API key lives after install

The install command stores the organization API key in the OS-native encrypted credential store and never writes the key to a file. On macOS the entry lives in the Keychain (service wasviking-ai-guardian, account = OS user). On Windows it lives in Credential Manager. On Linux it lives in the Secret Service via D-Bus (GNOME Keyring, KWallet, or the running provider).

The value placed in the keystore is an AES-256-GCM envelope wrapped with a key derived from the host's machine identifiers. A snapshot of the entry copied to a different host decrypts to garbage.

The env file at ~/.config/wasviking/ai-guardian.env contains only the API base URL (WASV_API=<url>). It does not carry the key.

To check where the key is currently resolved from without printing the value:

wasviking-sentinel ai-browser key-status

Typical output on a healthy install:

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

If Effective source reports anything other than the OS keystore, restart the AI Guardian service so the agent re-reads the credential state on the next start. The agent reconciles to the OS keystore without operator action.

Day-2 operations

Disabling monitoring temporarily

Toggle the Status switch on the AI Guardian card off. The authoritative ingest gate on the WASViking side stops persisting new events for your organization within five minutes. The endpoints themselves keep running and the local audit trail keeps recording, so you can re-enable without redeploying.

Uninstalling from an endpoint

Run the uninstall command as the user who installed the agent and provide the master password from Step 2.

wasviking-sentinel ai-browser uninstall --master-password "<your-master-password>"

The command authenticates the master password online against your tenant, then removes the browser policy, the native messaging host manifests, and the local agent state. A wrong master password exits with code 77 and changes nothing.

Rotating the install API key

Revoke the existing key from Settings > System Settings > API Keys and create a new one with the ai_guardian:install scope. Already-registered endpoints are unaffected because they no longer depend on the key.

Auditing changes

Every action on this flow is logged in the customer-facing audit log (Settings > History):

• ai_guardian.toggle
• ai_guardian.master_password_set / .clear
• apikey.create / apikey.revoke
• ai_guardian.policy.create / .update / .delete

Advanced configuration

The defaults are tuned to give a healthy signal on the first day without configuration. Three knobs let you tighten or extend the classifier per tenant. All three live in the agent policy file on each endpoint (/etc/wasviking/ai-guardian-policy.json on Linux, under ~/Library/Application Support/WASViking/ on macOS, %ProgramData%\WASViking\ on Windows). Portal UI for managing these centrally is on the roadmap. Until then, distribute the file through your endpoint management tool.

Per-tenant custom detectors

Add proprietary patterns the built-in detectors do not cover, for example an internal project code, an employee identifier, or a customer reference. Each entry compiles into the same pipeline as the built-ins and the agent refuses to start if a pattern is malformed, so a typo never silently disarms detection.

{
  "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"]
    }
  ]
}

Valid categories are pii, secret, phi, sensitive, internal, and source_code. Mask options are digits, token, middle, or none. You can add up to 64 custom detectors per tenant.

Confidence calibration per label

Damp a noisy detector for your tenant without disabling it. The multiplier is in the [0, 1] range and only lowers confidence, never raises it.

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

A value of 0.4 collapses a high finding to low for that label, so policy rules conditioned on min_severity no longer escalate it. This is the manual lever today. An automated feedback loop driven from a "Mark false positive" button in the portal is on the roadmap.

LLM-assisted classification (opt in)

For cases 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 to add semantic classifications. You bring your own API key. The prompt content goes from the endpoint to the LLM provider over public TLS and never transits WASViking infrastructure.

{
  "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
  }
}

The agent caches results by SHA-256 of the prompt on disk, so the same content is never classified twice. The daily budget guard stops LLM calls when the configured cap is reached. Findings produced by the LLM layer appear in the drawer 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.

Troubleshooting

For anything not covered here, contact [email protected].