Browser Extension

Generate the deployment configuration in Airia

1. Go to Discover → Connect and click the Browser Extension tile. The Deploy Browser Extension wizard opens, with four steps: Method, Generate, Upload, and Verify.
2. Method: pick how you deploy: Manual install, Kandji, Jamf Pro, Microsoft Intune (Mac or Windows), JumpCloud, ManageEngine Endpoint Central, or Windows GPO (rolling out; if it isn't listed, use the Group Policy steps in the MDM Deployment Guide). If Edge is available in the wizard's browser picker (Edge support is rolling out), choose it for a Mac method to get Edge's force-install and managed-preferences instructions instead of Chrome's. The Windows methods configure both Chrome and Edge; see the Windows note under Edge below for which Edge ID they use.
3. Generate: the wizard creates a scoped provisioning key and builds the managed configuration for your method. The provisioning key can only reach the endpoints the extension uses. Treat it as a secret. Manual install skips this step and the next one.
4. Upload: follow the checklist to force-install the extension and deliver the managed configuration in your MDM console or Group Policy Management Console, then assign both to the same device group (or, for Group Policy, link the GPO to the computers' OU).
5. Verify: your fleet picks up the extension on its next check-in. Where Edge support has rolled out, this step also shows an Edge checklist and, where install coverage is available, recent check-ins from Edge (extension version 1.0.39 or later). The Edge Add-ons build can trail the Chrome Web Store build by a few versions; edge://extensions shows the version installed.

Generating a provisioning key needs the Platform Admin, Admin, Project Admin, or Security Admin role.

Distribute it to users

The extension is on the Chrome Web Store, Microsoft Edge Add-ons, and Firefox Add-ons. Search for "Airia". The wizard shows the extension ID to force-install. For Chrome and Edge it's also the 32-character string at the end of the store listing's URL: hcjkecanahplkmniojegmmjjijopbdma on the Chrome Web Store and klfpgnohpoebgpjcihdlkbhmgnfbaphg on Edge Add-ons.

The recommended path is force-install plus the managed configuration through your management tool. Pick the route that matches it:

• Microsoft Intune (Windows or Mac), Jamf Pro, Kandji, JumpCloud, ManageEngine Endpoint Central, Windows GPO (rolling out): use the matching method in the wizard. It generates the configuration in the form that tool needs. For Intune on Windows that's a set of PowerShell scripts that write the configuration to the registry for Chrome and Edge. Intune's configuration profiles don't carry extension configuration, so use the scripts rather than a profile.
• Chrome through Google Admin Console: follow the worked example below.
• Group Policy on domain-joined Windows machines: the wizard's Windows GPO method generates two PowerShell scripts that you run as Group Policy scheduled tasks to write the configuration to the registry for Chrome and Edge. Where it isn't available yet, use the script-free Group Policy steps. Both are in Option B: On-Prem Group Policy (GPO).
• Manual install: share the store link and have users add it and sign in themselves. This works for a pilot group.

Edge. Force-install the Edge Add-ons build in Edge: klfpgnohpoebgpjcihdlkbhmgnfbaphg;https://edge.microsoft.com/extensionwebstorebase/v1/crx in Edge's ExtensionInstallForcelist, with its managed configuration keyed by the same ID.

• Windows: the managed configuration applies to both Chrome and Edge. Force-install Edge through the same device policy Chrome uses, so that ExtensionInstallForcelist shows Platform as its source on edge://policy. Where Edge support has rolled out in the wizard, its Generate and Upload steps show the Edge Add-ons forcelist entry. Until the wizard's Edge support reaches your tenant, its Windows instructions and scripts key Edge by the Chrome Web Store ID. Either keep the Chrome build in Edge, or force-install the Edge Add-ons build and set $EdgeExtensionId = 'klfpgnohpoebgpjcihdlkbhmgnfbaphg' in the script. Don't use the commented-out alternate ID.
• Mac: Edge takes its own profiles, under the com.microsoft.Edge and com.microsoft.Edge.extensions.klfpgnohpoebgpjcihdlkbhmgnfbaphg preference domains. Edge on macOS has historically not passed managed configuration to extensions reliably, so check a pilot Mac on edge://policy before a wide rollout; users can sign in themselves if the values don't arrive. See Microsoft Edge on macOS.
• Already force-installing the Chrome Web Store build into Edge? You can keep it on Windows devices joined to an Active Directory domain and on MDM-managed Macs. On Windows devices that are only Microsoft Entra joined or only Intune enrolled, Edge silently skips a force-installed Chrome Web Store build, so use the Edge Add-ons build there. To move to the Edge Add-ons build, replace Edge's forcelist entry and move its configuration to the Edge ID; don't add a second entry, or Edge installs two Airia extensions.

Worked example: Chrome via Google Admin Console

1. In Airia, run the wizard's Generate step with any MDM method to create a provisioning key.

2. In admin.google.com, go to Devices → Chrome → Apps & extensions → Users & browsers.

3. Select the organizational unit you want covered.

4. Click + → Add Chrome app or extension by ID, and paste the extension ID.

5. Set Installation policy to Force install (or Force install + pin).

6. In the extension's Policy for extensions field, paste the configuration below, then Save. The Admin Console expects each setting wrapped in a Value object:

   {
     "region": { "Value": "na" },
     "provisioningApiKey": { "Value": "<provisioning-key>" },
     "suppressLoginPromptOnInstall": { "Value": true },
     "lockConfiguration": { "Value": true }
   }

   Set region to your tenant's region (na, eu, au, mena, or sg). For an on-premises or custom-domain tenant, use "customAppUrl": { "Value": "https://<your-airia-host>" } instead of region.

The extension lands in every user's Chrome in that OU on the next policy sync, already connected to your tenant.

Per-tool steps are in the Browser Extension MDM Deployment Guide.

Attribute activity to each user

The provisioning key is shared across your organization, so it doesn't identify the person browsing. To attribute activity when nobody is signed in to the extension, also push managedUserEmail, each user's own email, through a user-scoped policy. See Per-user attribution for Shadow AI events.

A signed-in user's activity is always reported under that user. managedUserEmail is used only when the extension connects with the provisioning key. The same attribution applies to prompts the extension checks against your guardrails, so their violations in the DLP violations feed name the same person.

To see which machine each event came from, also push managedDeviceName, a per-device label such as the computer name. From extension version 1.0.39 it's also sent with the prompts the extension checks, so violations show the device too. It must differ per device, so the Admin Console can't deliver it; use a device-level MDM (the wizard's Intune or Windows GPO script, JAMF $COMPUTERNAME, a NinjaOne script writing the machine's DNS host name). Set it to the real computer name: Airia also uses it to match installs against your device lists. See Device name on Shadow AI events.

Open the Browser Extension policies

1. Go to Discover → Connect and click the Browser Extension tile. In the wizard, click Set Shadow AI policy (or Manage Shadow AI policy once a policy exists) to open the Browser Extension Policies page.
2. Policies are per-group. Each policy has a name, who it applies to, its domain rules, and a status. A Default policy applies to everyone unless a more specific policy matches.
3. Click Add policy, or open an existing one.

Set your Shadow AI policy

The policy editor has a few tabs. Work through them in order.

What each action does:

Verify it worked

The connection shows Connected. As people browse, the extension's reported events appear under Discover → Activity Feed → Browser events, with per-user detail.

Run an end-to-end test

Prove the data is flowing before you widen the rollout. From one machine with the extension installed and either signed in or configured with managedUserEmail:

1. Test discovery. Visit an AI site covered by a Monitor rule and load a page or send a throwaway prompt.
2. In Airia, open Discover → Activity Feed → Browser events and confirm the visit appears within a few minutes, attributed to that user.
3. Test enforcement. Add a Block rule for a low-stakes AI domain, wait one policy-refresh interval (the polling interval from General Settings), then visit that domain. You should see the block page or warning in the browser.
4. Back in Airia, confirm the block or warn event is logged against the same user.

Only after both the discovery event and the enforcement event show up in Airia should you assign the policy beyond the test group.