Validate the Installation

The extension needs both components running: the WebExtension in the browser and the native messaging agent on the device. All three checks must pass for events to reach the Quilr console.

Console-side validation — the fastest check

If the device successfully phoned home, it will show up in the Quilr Console within seconds of install. Open Settings → Browser Extension in your tenant Console and switch to the Deployment Status tab. Type the test user’s email / name in the search box.

Get-Process | Where-Object Name -like '*quilr*'

pgrep -lf 'quilr-native-messaging-agent'

3

Popup status is green — persona active

Click the Quilr icon in the browser toolbar. The popup should display “Persona Active & Extension Enabled” with a green indicator, confirming:

• Both the WebExtension and native agent are running
• The user’s persona has resolved (the popup shows Registered to: <user>@<tenant>)
• Version numbers appear in the footer for both Extension and Agent

Pass / fail criteria

• ✓
  Extension visible and enabled in browser settings
• ✓
  Native agent process running in system tools
• ✓
  Popup shows green status with version strings for both components

Functional test

Two quick visual checks against a real AI site — the first confirms the extension injected its UI into the page; the second confirms the native agent is actually relaying events to the backend.

Test 1 — Quilr icon visible in the prompt box

Open any of the popular AI websites below in the browser the user typically uses. When the page finishes loading and the prompt input is rendered, the Quilr icon — a small atom-style mark with a cyan/pink orbital ring — appears inside the prompt-input row, parked between the typing area and the right-side controls (e.g. mic / send buttons). That icon is injected by the WebExtension — if it’s there, the extension is loaded, has page-script permission, and matched the host’s content-script rule.

Test 2 — Prompt round-trips to the Quilr console

With the icon visible, type a real prompt (e.g. “Summarise this paragraph in one line.”) into the prompt box on https://claude.ai and hit send. The event should appear in the Quilr console within ~2 seconds, proving the WebExtension → native messaging agent → backplane pipe is complete.

Test 3 — DLP control fires on a sensitive prompt

Tests 1 and 2 confirmed the extension renders and the pipe to the console is open. Test 3 confirms the policy half of the chain — a control configured in the console actually reaches the extension, the DLP engine matches a sensitive payload, and the Quilr popup blocks the user before the prompt leaves the device.

3.1 — Enable the “Prevent leakage” control in Action mode

1. In the Quilr Console, open Controls and switch to the AI Risks tab.
2. Search for preven and find the row “Preventing The Leakage Of Sensitive Data Via An AI App”.
3. Toggle Status on (green).
4. In the Mode dropdown, pick Action (not Monitor). Monitor only logs; Action shows the block popup to the user.

3.2 — Paste the synthetic-PII payload into an AI site

Open any monitored AI site (Claude / ChatGPT / Gemini / Copilot …) and paste the block below into the prompt input. Do not use real personal data — the block below is publicly-circulated synthetic test data (commonly-known fake SSNs / DOBs used in DLP smoke tests) included specifically so this validation never accidentally leaks real PII.

First and Last Name    SSN            Date of Birth
Robert Aragon          489-36-8350    6/7/1981
Ashley Borden          514-14-8905    7/8/1981
Thomas Conley          690-05-5315    8/9/1981
Susan Davis            421-37-1396    9/10/1981
Christopher Diaz       458-02-6124    1/10/1975
Rick Edwards           612-20-6833    2/11/1975
Victor Faulkner        300-62-3266    3/12/1975
Lisa Garrison          660-03-8360    4/13/1975
Marjorie Green         213-46-8915    5/14/1975
Mark Hall              449-48-3135    6/14/1975
James Heard            559-81-1301    7/16/1975
Albert Iorio           322-84-2281    8/17/1975
Charles Jackson        646-44-9061    9/18/1975
Teresa Kaminski        465-73-5022    10/19/1975
Tim Lowe               044-34-6954    1/20/1991
Monte Mceachern        477-12-8344    2/21/1991

Click Send. Do not type quickly — the extension matches on the rendered prompt body, so it’s fine if the paste lands instantly.

3.3 — What you should see

3.4 — Confirm a Finding was generated in the Console

The popup only proves the block happened locally. The finding row proves the event was uploaded to the backplane and attributed to the right user, app, and control. Open Findings in the Console, switch to the Browser Extension Findings tab, then the AI Risks sub-tab. Filter Finding Type to A user shares sensitive data with an AI application.

Test 4 — Multi-channel DLP coverage (copy · upload · paste)

Test 3 covered the prompt channel — sensitive data typed / pasted into an AI site’s prompt input. Three other controls cover the remaining user-action channels. Enabling all four together confirms the DLP engine intercepts on every supported user signal, not just one.

4.1 — Enable the three additional controls (all Action mode)

In Controls → AI Risks, enable each row below and set Mode = Action. Same propagation rule as Test 3 — wait ~90 seconds after the last toggle before testing.

4.2 — Trigger each channel with the synthetic-PII payload

Use the same synthetic-PII block from Test 3.2 as the source content. After enabling all three controls + waiting 90 s, perform each action below in turn on a monitored AI site (Claude / ChatGPT / Gemini …). Each one should produce its own popup + finding.

4.3 — Confirm 3 distinct findings in the Console

Back in Findings → Browser Extension Findings → AI Risks, you should now have three new finding rows — one per channel — in addition to the one from Test 3. Filter Finding Type in the right-side panel to confirm each fired:

• A user is copying sensitive data
• A user is uploading sensitive data
• A user is pasting sensitive data