WASViking AI Guardian

Roll out the WASViking AI Guardian on employee laptops and desktops. Enable it in the portal, install the agent and the managed browser extension, validate detection and the first policy block, then operate it day to day (updates, identity mapping, advanced detection).

The WASViking^® AI Guardian gives you visibility and control over how employees use generative-AI tools on their work devices. A lightweight Sentinel agent runs on each host and pairs with a managed browser extension (Chrome, Edge, or Firefox). Together they classify AI exposure (which vendors are visited, what kind of content is involved, a risk score, and masked evidence) and forward that telemetry to WASViking over the secure mTLS tunnel.

Privacy is built in: the agent forwards classifications, scores and masked evidence only, never raw prompts, pasted content, or files. The local audit log stays on the device; cloud forwarding and storage are governed by the master toggle in the portal.

The setup has two halves, and the order matters: configure the WASViking portal first (enable AI Guardian, set the governance policy, and mint an API Key scoped to ai_guardian:install), then run a one-line install command on each device. You do not need to create a Sentinel Agent token for AI Guardian.

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

What this deployment does

• Discovers and classifies AI usage per device: which AI vendors (OpenAI, Anthropic, Google, Microsoft, Perplexity, and more) are used, and how.
• Forwards privacy-preserving telemetry: classifications, risk scores, and masked evidence. Raw prompts, pasted content, and files never leave the device.
• Enforces vendor governance: classify each AI vendor as approved (sanctioned), blocked (flagged red), or leave it for review (the default: every known vendor is treated as Shadow AI).
• Force-installs and pins the managed browser extension via the OS managed-policy channel so it cannot be removed by the user.
• Protects the deployment with a master password required to uninstall the agent or lift the force-installed browser policy.
• Governs agent self-updates with a release channel and an optional pinned version for homologated builds.
• Surfaces everything in the portal under AI Guardian (Executive Summary, AI Applications, dashboard) and routes alerts through your notification channels.

How it works

1. You enable AI Guardian and set the governance policy in the portal.
2. You mint an API Key scoped to ai_guardian:install. Creating the key shows a one-time install command that embeds a short-lived bootstrap.
3. On each device, the install command downloads the agent, registers it (mTLS identity) using the bootstrap, and stores the org API key in the OS secret store (Keychain / Credential Manager / Secret Service).
4. The installer registers the native messaging host and force-installs the published browser extension via managed policy.
5. The agent runs as a per-user service and the extension pairs with it over loopback. AI exposure is classified locally and forwarded to WASViking over the mTLS tunnel.
6. The portal correlates the telemetry against your vendor governance and raises alerts on blocked or Shadow-AI usage.

Access posture

• The agent forwards classifications, scores, and masked evidence only. Raw prompts, pasted content, and files never leave the device.
• The local audit log (JSONL) stays on the device; the master toggle in the portal controls cloud forwarding and storage. Disabling it stops forwarding immediately; the browser sensor never holds this control.
• Forwarding uses the secure mTLS tunnel, not a plain bearer call.
• The master password is stored as a one-way hash and is never shown again; it gates uninstall and policy removal on managed hosts.
• Revoke access at any time by toggling AI Guardian off, revoking the API Key, or uninstalling the agent with the master password.

Pre-requisites

Step 1: Enable AI Guardian (portal)

In the portal, go to Settings → System Settings → AI Guardian and turn on the WASViking AI Guardian master toggle. The status reads Enabled once active.

This toggle governs cloud forwarding and storage of AI-exposure telemetry. When it is off, registered agents stop forwarding to WASViking; the local audit log on each device is unaffected. The browser sensor cannot override this control.

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 tab, the feature is not yet active on your plan; contact [email protected] to have it activated.

Settings → System Settings → AI Guardian → master toggle.

Step 2: Set a master password (recommended)

In the same tab, under Master password, set a password of at least 12 characters and click Save. It is stored as a one-way hash and never shown again.

This password is required to uninstall the agent or lift the force-installed browser policy on a managed host. Without it, a user cannot remove the agent or disable the extension. Use Remove master password to clear it (and the uninstall protection).

Keep the passphrase in your secrets manager. The portal stores only a one-way hash and the endpoint never sees the cleartext. If you lose it, set a new one in the portal before any agent can be uninstalled.

Master password: gates uninstall and policy removal.

Step 3: Configure agent updates (optional)

Under Agent updates, choose how devices self-update:

Both empty means the agent follows the default stable channel. Click Save. A pinned version that does not exist in the release catalog is treated as "no update available" rather than an error.

Agent updates: release channel and optional pinned version.

Step 4: Configure vendor governance

Under Vendor governance, classify each AI vendor:

Tick the built-in vendors (OpenAI, Anthropic, Google, Microsoft, Perplexity, Quora, DeepSeek, xAI, OpenRouter, HuggingFace, Mistral, Lovable) in either column, and add any others in the Custom vendors textareas (one per line). Click Save.

The agent picks up both lists on the next monitor restart (which includes any self-update). Events reclassify immediately on the next event after the restart.

Blocking a vendor here does not by itself stop an event; it classifies and flags it. To actively enforce on the endpoint, create an AI Guardian Policy rule (portal → AI Guardian → AI Guardian Policies). Note that rule event matching is strict: an event:paste rule does not cover prompt submissions or file uploads; use Any for full coverage.

Vendor governance: approved, blocked, and custom vendors.

Step 5: Create an API Key scoped to ai_guardian:install (portal)

This key authorizes installing the AI Guardian endpoint on a device.

Go to Settings → System Settings → API Keys and click + New Key.

Click Create Key. The portal shows the raw key once, together with the install command for Linux, macOS, and Windows (switch with the OS tabs). A short-lived bootstrap is minted when the install script is fetched, so copy the command now: it is shown only on this screen.

You can reuse the same key to install on as many machines as you need while the key is active. The key is bootstrap only: once an agent is registered, it identifies itself by its mTLS client certificate, not by the API key, so you can rotate or revoke the install key without disconnecting endpoints that are already running.

Adding ai_guardian:install to an existing key later (via Edit) does not reveal a new install command; the bootstrap is minted at creation. To get a fresh command, create a new key.

API Key scope picker with ai_guardian:install selected.

The one-time install command, shown only at key creation.

Step 6: Install the agent on each device

Run the command from Step 5 on the device. It downloads the agent, registers it over mTLS using the bootstrap, stores the API key in the OS secret store, installs the native messaging host, and force-installs the browser extension via managed policy.

Linux / macOS

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

The agent runs as a per-user service (systemd --user on Linux, a LaunchAgent on macOS). No root or sudo is required for the standard install. On Linux, to keep it running after logout: sudo loginctl enable-linger "$USER".

Verify the agent:

# Linux
systemctl --user status wasviking-sentinel

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

The Windows agent ships in two install vehicles. They differ in scope (per-user vs. per-machine), in boot mechanism (Scheduled Task vs. Windows Service), and in privilege requirements. Pick the vehicle that matches your operating model.

Option A: Single user, single machine (install.ps1)

Run from a PowerShell session as the user who will be monitored. The script registers the AI Guardian Scheduled Task in that user's session and stores the organization API key in Windows Credential Manager. The force-install of the browser policy prompts for UAC elevation.

iex (irm -Headers @{Authorization='ApiKey wv_live_xxx'} `
  https://api.wasviking.com/api/v1/sentinel/ai-guardian/install.ps1)

Verify:

Get-ScheduledTask "WASViking AI Guardian"
Get-ChildItem "$env:LOCALAPPDATA\WASViking\Guardian\"
wasviking-sentinel ai-browser key-status

The key-status command reports the credential storage backend and never prints the key.

Option B: Fleet deploy, per-machine (MSI)

Prerequisites:

Steps:

1. Sign in to the portal and go to Sentinel Agents > Get Agent > AI Guardian MSI (x64) to download the installer.
2. Stage the .msi on your distribution share or in your MDM artifact store.
3. Push the install with msiexec and the properties from the table below. The MSI self-enrolls the endpoint during install, so no post-install scripting is required.

msiexec /i <PATH>\wasviking-ai-guardian_<VERSION>_amd64.msi /qn `
  /l*v "%TEMP%\guardian-install.log" `
  WASV_API_KEY="<WASV_API_KEY>" `
  WASV_API="<WASV_API>"

MSI properties:

Intune. Package the MSI as a Win32 LOB app. Set the install command to the msiexec line above. Set the uninstall command to msiexec /x {<PRODUCT_CODE>} /qn. Retrieve <PRODUCT_CODE> from any installed machine with:

Get-WmiObject Win32_Product -Filter "Name='WASViking AI Guardian'" |
  Select-Object IdentifyingNumber

The ProductCode regenerates on every MSI build to enable MajorUpgrade. The UpgradeCode is stable and is what Intune, SCCM, and Group Policy use for upgrade detection.

SCCM. Create an Application of type Windows Installer (.msi). On the Programs tab, use the msiexec line above as the install command. Set the detection method to "Windows Installer" with the ProductCode field empty so SCCM detects upgrades by UpgradeCode.

Group Policy software installation. Publish or assign the .msi under Computer Configuration > Software Installation. Pass WASV_API_KEY and WASV_API through a transform (.mst) generated with Orca, or wrap the install in a startup script that sets the properties.

What the MSI installs:

Verify the MSI install:

sc.exe query WASVikingGuardian
Get-ChildItem 'C:\Program Files\WASViking\Guardian\' -Recurse
Get-ChildItem 'C:\ProgramData\WASViking\Guardian\' -Recurse

Expected:

Mass deployment

All three vehicles are idempotent and safe to re-run. The same install API key works across the entire fleet. Bootstrap is per-machine, so rotating the install API key has no effect on already-enrolled endpoints.

Replace wv_live_xxx with your real key; the portal pre-fills the full command for you on the key-creation screen. The bootstrap embedded in the rendered script expires a few minutes after the script is fetched, so run it promptly.

What the installer does

1. Installs the agent binary to a per-user directory.
2. Registers the agent (mTLS identity) via the one-time bootstrap.
3. Stores the org API key in the OS secret store: Keychain (macOS), Credential Manager / DPAPI (Windows), or Secret Service (Linux).
4. Installs the native messaging host manifest and allowlists the published extension IDs.
5. Force-installs the browser extension via managed policy (HKLM ExtensionInstallForcelist on Windows, managed-policy JSON on Linux, MDM staging on macOS).
6. Starts the per-user service/task that monitors AI exposure.

The browser extension

The managed extension is what observes AI usage in the browser; the agent is the native messaging host it pairs with over loopback. The agent must be installed and running: without it the extension shows "Not paired with the local WASViking agent." The installer in Step 6 force-installs the published extension automatically, but users can also install it manually from the official stores:

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.

The force-install uses the standard managed-policy mechanisms the browsers already support; the policy keys are documented by the browser vendors and remain the authoritative reference:

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

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.

A manually installed extension still needs the agent. If the popup stays "not paired", confirm the agent service is running and that the native messaging host manifest was installed for that browser.

Step 7: 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 Portal > 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

This section applies to the install.sh (Linux, macOS) and install.ps1 (Windows) vehicles. The Enterprise MSI on Windows consumes the bootstrap during install and does not persist the organization API key on the endpoint; identity is the mTLS client certificate from that point on.

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.

Uninstalling the agent

Removal is gated by the master password set in Step 2. On the device, run:

wasviking-sentinel ai-browser uninstall \
  --master-password "your-master-password" \
  --remove-key

The command authenticates the master password online against your tenant, then lifts the force-installed browser policy, removes the native messaging host manifest, stops and removes the per-user service (LaunchAgent / systemd --user unit / Scheduled Task), and, with --remove-key, deletes the persisted org API key and API base from the OS secret store. If no master password is configured for the organization, the --master-password flag can be omitted.

Preview first with --dry-run. Without --master-password on a protected host the command exits 77 ("master password rejected") and nothing is removed.

For a machine installed with the Enterprise MSI, uninstall through your management tool instead:

msiexec /x {<PRODUCT_CODE>} /qn

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.

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.

Updating the agent

The agent updates itself in place through a safe, verified flow. The operator can trigger it at any time and the host always ends in one of two states: the new binary running and healthy, or the previous binary running and healthy. There is no broken intermediate.

Governance lives in the Agent updates card from Step 3 (release channel and pinned version). On the endpoint, run from any account that can read the host's persisted api configuration:

# 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 flags are needed in the common case. The command auto-detects the binary the service manager supervises, reads the api base from the install configuration, and reads the org api key from the host keystore set at install time.

What the safety gate does. On --yes, the agent fetches the release manifest, downloads the binary, recomputes its sha256, verifies the operating system code signature, takes a single-flight lock, copies the current binary to a .bak, atomically renames the new binary in place, restarts the service, and waits for the local /healthz endpoint to report the expected new version. If any of these steps fails the agent restores the .bak, restarts the service, and exits non-zero with a clear message. Disk + service state never end up half-applied.

The exit codes are stable so they can be wired into a fleet manager:

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
• ai_guardian.update_policy_set
• ai_guardian.approved_vendors_set (single action covers approved + blocked changes)
• 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.

Identity and directory

Agents report an operating-system user name on each device. To target policies by group, show real names in the dashboards, and erase a person across every device they use, map those OS user names to corporate identities under Portal > AI Guardian > Identity. Only mappings you confirm affect enforcement; suggestions never act on their own.

Connect an identity provider (SCIM)

1. Open Portal > AI Guardian > Identity and, in the Identity provider (SCIM 2.0) card, click Generate token. Copy the token immediately: it is shown only once. Note the SCIM endpoint shown next to it (for example https://api.wasviking.com/api/scim/v2).
2. Configure your identity provider's provisioning to point at that endpoint using an OAuth bearer token with the token you copied. This covers Microsoft Entra ID and Okta, which both push to this SCIM endpoint. Google Workspace works differently and has its own section below.
3. Assign the users and groups you want WASViking to know about. They appear on the Identity page after the first sync. Rotating the token in the portal invalidates the previous one immediately; revoking it stops directory sync.

Microsoft Entra ID or Okta. Create an enterprise application with automatic user provisioning, set the Tenant URL (or equivalent) to the SCIM endpoint, set the Secret Token to the bearer token, test the connection, then enable provisioning and assign the users and groups to sync. If your organization already uses Microsoft 365 / Office 365, this is the same Entra ID directory those accounts already live in; there is nothing separate to set up for Office 365.

Sync Google Workspace (directory pull)

Google Workspace does not push SCIM to an app you create yourself, so the SCIM card above does not apply to it. Instead, WASViking reads your directory directly, on a schedule, using Google's read-only Admin SDK Directory API. You grant a read-only service account access once and paste it into the portal, and WASViking keeps your users and their groups in sync. This is the right path for any Google Workspace customer, and it also brings in your groups, which a plain Google user export leaves out.

In Google (one-time setup, by a Workspace or Cloud admin):

1. In the Google Cloud console, create a project or pick an existing one.
2. Go to APIs & Services > Library, search for Admin SDK API, and click Enable.
3. Go to IAM & Admin > Service Accounts and create a service account (for example, "workspace-directory-reader"). It needs no project roles.
4. Open the service account, go to Details > Advanced settings, and turn on Enable Google Workspace Domain-wide Delegation. Copy the Client ID it shows.
5. In the Google Admin console, go to Security > Access and data control > API controls > Domain-wide delegation and click Add new. Paste that Client ID, and in the OAuth scopes field add these three read-only scopes, comma separated:
   • 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

Then click Authorize. 6. Back on the service account in Google Cloud, go to Keys > Add key > Create new key, choose JSON, and click Create. Your browser downloads a JSON key file. Keep it private.

In the portal, under Portal > AI Guardian > Identity:

1. Find the Google Workspace directory sync card.
2. Upload the service-account JSON key you just downloaded.
3. Enter the admin email to impersonate: any Google Workspace admin address, such as [email protected]. WASViking reads the directory as this admin.
4. Leave Reconcile leavers and group changes on (recommended). With it on, people removed in Google are deactivated here and group membership stays in step with Google. Turn it off if you only want to add and update people, never remove them.
5. Leave the interval at its default and click Connect Google Workspace. The sync then runs on a schedule.
6. Click Sync now to run the first pull right away. Your users and groups appear in the lists below within a few seconds.

WASViking only manages the users and groups it pulls from Google. Anything you added by CSV or by hand, and every mapping you have already confirmed, stays exactly as it is. Leave the Customer id field as my_customer unless Google gave you a specific customer id that starts with C.

Import identities from a CSV

No identity provider yet? Use the CSV import card instead. Provide a file with columns user_name, display_name, department, and groups (group names separated by ";"). Re-importing updates existing rows. You can also add a single identity by hand from the same card. If you upload a raw Google Workspace user export, the portal tells you the columns do not match and points you to Google Workspace directory sync, which also pulls in the groups a user export leaves out.

Confirm which login belongs to whom

1. Click Scan devices for usernames. WASViking reads the distinct OS user names seen in your event stream over the last 31 days and proposes matches against your identities.
2. Review Pending suggestions: each row shows the OS user name, the suggested identity, and the heuristic that produced it (exact login, email local part, or display name). Click Confirm to activate a mapping or Reject to dismiss it.
3. Resolve Unmapped usernames (logins with no automatic match) by choosing an identity and clicking Map, which confirms the mapping in the same step.

Confirmations and rejections are recorded in the audit log (Settings > History). Only confirmed aliases feed group policies, dashboard name resolution, and erasure by person, so a wrong guess is never enforced.

Target a policy at a directory group

1. Open Portal > AI Guardian Policies and create or edit a rule.
2. Under Targets, choose Directory groups and select one or more groups. The builder shows how many confirmed users each group covers today, so you can see the real reach before saving.
3. Optionally list OS user names to exclude. Save the rule.

When the policy is served to agents, the group is expanded to the confirmed user names behind it. Enrolled endpoints pick up the change on their next policy refresh (about 15 seconds); no agent restart is needed. If you add people to the group in your identity provider later, confirm their aliases on the Identity page and they are covered automatically on the next refresh.

Erase a person across every device

A right-to-be-forgotten request can name a corporate identity instead of a single login. It expands to every confirmed alias of that person and removes their events across all of their devices in one operation. This is the reliable way to satisfy LGPD Art. 16 and GDPR Art. 17 when an employee has used more than one machine.

Troubleshooting

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

Where this fits in the platform

• AI exposure lives under AI Guardian: Executive Summary, AI Guardian dashboard, and AI Applications.
• Enforcement rules live under AI Guardian → AI Guardian Policies.
• Alert routing is documented under Notification Channels, Slack and Teams, and Webhooks.