The Browser Extension screen under Integrations > Browser extension shows the Chrome Web Store channel and the paired browser profiles. Use it to approve short-lived pairing requests, inspect vault-grant counts, and revoke approved browser profiles.
Access, role, and license boundary
Integrations is available only to the Owner and needs the Integration license feature. Browser Extension is part of that feature; new licenses have no separate Extension feature. Customers whose older license covers only the extension keep Browser Extension access, but not External API or Active Directory. Admin, Auditor, and User do not reach this panel through the normal navigation.
A pairing request is started from the extension, not from the console, and can name an active Owner, Admin, or User. Auditors cannot pair. Each user sees and manages only their own devices. Seeing another user’s name elsewhere does not give you access to that user’s pairing request.
A writable license is required to start or approve pairing. Read-only mode still allows listing devices and revoking an approved device as a security action. It does not allow approving a pending request. At least one vault in the active profile must be unlocked before approval.
What you can do here
- Open the VaultPilot Browser Vault Extension listing in the Chrome Web Store.
- Refresh the latest extension sync and the approved and pending device summaries.
- Match a pending device name and last-four code hint with a separately confirmed user request.
- Enter the full popup code and give the extension access to the vaults currently unlocked in this profile.
- Review active devices separately from revoked or expired archive records.
- Revoke an approved browser profile that is lost, unused, unexpected, or no longer trusted.
This panel does not remotely install or remove an extension, push browser policy, force a Web Store update, operate another browser, or prove that autofill worked on a page. It manages pairing and vault access on the server. Autofill remains something the user triggers in the extension, subject to the site, the extension session, browser policy, and matching rules.
Chrome Web Store and managed installation
Open in Chrome Web Store opens the listing for extension ID hjkbedlaieikhkoplgpiohlaakgebobi. Normal installation and updates use that store channel. Store installs need no ZIP download, Developer Mode, or Load unpacked.
For a managed Chrome or Edge fleet, deploy the same extension ID through the organization’s browser policy. That work happens in your browser-management tool, not on this VaultPilot screen. Chrome checks for updates on its own; the extension’s About view can ask for a Web Store check, but the browser may delay it and applies an update only when one is ready.
The release ZIP is an emergency fallback, not the routine managed installation path. An unpacked build may also need to be allowed on the server; do not change the store extension ID or the server’s allowed extensions without an approved change.
Pairing lifecycle
1. Start in the extension popup
Enter the VaultPilot server address, VaultPilot username, a recognizable device name, and an extension PIN in the popup, then choose Start pairing. The PIN protects the extension’s pairing keys in that browser profile; it is not the VaultPilot master password.
The server links the request to an active user who is not an Auditor and returns a code in XXXX-XXXX form that expires after ten minutes. The full code is shown only in the extension popup; it cannot be recovered from the device row.
2. Review pending state and check status
The extension keeps the request and code locally and offers Check approval. A pending request cannot be used until it is approved. If its ten minutes run out, the check reports it as expired and the row moves to Archive.
On this screen, Active devices holds pending and approved rows. A pending row shows the device name the user typed, only the last four code characters, and the current vault-grant count. It does not show the full code, username, browser profile, request address, extension ID, keys, or device ID. The device name is typed by the user and does not prove which device it is.
3. Approve and grant vaults
Before approval, confirm the request owner and browser profile through an internal channel. Compare the full code in the popup with the expected request and the row’s last-four hint, then enter the full code.
Approval requires a writable license and at least one unlocked vault. VaultPilot gives the device access to all vaults currently unlocked in the approving profile; this screen has no per-vault picker. The row’s vault-grant count shows how many vaults were granted. Approval is recorded in the audit history, refreshes the device list, and clears the code field.
After approval, choose Check approval in the popup. The extension can then download an encrypted copy of its granted vaults and decrypt it locally. Pairing never shows the master password or vault records in the management list.
Device list, sync, and revocation
The list shows only your most recent devices. The sync time, the approved and pending counts, and the Active devices/Archive split cover only those rows, not the full device history. Use the Audit Log for older pairing, revocation, and sync activity. Refresh reloads the list; while this screen is open, it also refreshes every few seconds.
The console shows Revoke only on an approved row. The button acts immediately without a second confirmation: the device is revoked, its vault access is removed, the audit history records the revocation, and the row moves to Archive. After revocation, the extension can no longer download vault data. Revoking server access does not uninstall the extension or erase its browser profile; remove local pairing or the extension separately on that browser when appropriate.
Each successful sync updates last seen and is recorded in the audit history. View, copy, and fill actions in the extension are recorded separately, but this screen does not prove that a page was filled. Use the Audit Log for event review and keep device details private.
Archive, expiry, and errors
Archive holds revoked and expired records among your most recent devices. It is not full history; use the Audit Log for older events. An expired request cannot be approved; start a new request from the popup. Archived rows have no approve or revoke action. They help private investigation but do not prove that the extension was removed locally.
A failed approval shows a general message asking you to check the code and expiry. Also check the license, the current profile, at least one unlocked vault, who made the request, and whether the row is still pending. A failed revocation shows a general error; refresh before retrying so you do not act on an old view.
Placeholder rows appear while the device list loads. There is no separate error card, so a failed load can look like an empty list. Do not treat No pairing requests yet or an empty Archive as final until the session, server connection, and Refresh have been checked.
Recommended workflows
Approve a new managed browser profile
- Confirm the browser received the Web Store extension through the approved user or policy channel.
- In the popup, enter the correct HTTPS server address, username, device name, and a new extension PIN; start pairing.
- Confirm the requester and browser profile through an internal channel before reading or entering the code.
- On this screen, match the device name and last-four hint, and confirm the request is still pending.
- Unlock only the vaults that should be granted; every currently unlocked vault is included.
- Enter the full code and choose Approve once.
- In the popup, check approval and sync; then confirm the pairing and the first sync in the audit history.
Revoke a lost or untrusted browser profile
- Refresh Active devices and identify the approved row from your own device inventory, not the device name alone.
- Record the general reason and expected impact without copying codes, IDs, or vault details into shared notes.
- Choose Revoke once; there is no second confirmation.
- Confirm the row moved to Archive, its grant count is cleared, and the audit history shows the revocation.
- If the browser is available, remove local pairing or uninstall through the browser-management channel separately.
Screen states
| State | Operator response |
|---|---|
| Devices loading | Wait for the placeholder rows or use Refresh after checking the session. |
| No pairing requests yet | Start from the extension popup; a request cannot be created in the console. |
| Pending | Confirm requester, browser profile, device name, and code through separate channels before approval. |
| Pairing code invalid | Re-enter the full code from the popup; do not guess it from the last-four hint. |
| Pairing expired | Find the row in Archive and start a new ten-minute request from the popup. |
| No unlocked vault | Unlock the intended vaults before approval; all unlocked vaults will be granted. |
| Read-only license | Do not approve or start pairing; an approved device can still be revoked for security. |
| Paired | Check the grant count, expected sync, and audit history. |
| Revoked | Treat server access as removed; handle local extension removal separately. |
| Archive empty | Refresh and check the connection; only recent devices are listed, so check the Audit Log before concluding there is no older history. |
| Approval failed | Check ownership, pending state, exact code, expiry, writable license, and unlocked vaults. |
| Revocation failed | Refresh, confirm the approved row and session, then retry once. |
Before you act
- Confirm you are signed in as Owner and the license includes the Integration feature.
- Decide whether the task is Web Store deployment, pairing approval, sync investigation, or revocation; this screen does not do all four remotely.
- Use an internal request channel to confirm the user and browser profile; the device row cannot prove either.
- Before approval, lock any vault that must not be granted.
- Treat the full code, last-four hint, device name, and timing together as sensitive.
- Revoke has no second confirmation and does not uninstall the extension or clear the browser profile.
Safe evidence
- Safe to share: tab name, Chrome Web Store channel, general state such as pending, paired, revoked, or expired, approved and pending counts (recent devices only), broad time window, and the general error message.
- Keep private: full or partial pairing code, device name, device ID, pairing keys, server address, username, exact times, vault names, vault-grant count, and any secret or autofill-visible value.
- If a pairing code is exposed, stop sharing it. Let the request expire or revoke the approved device, then start a fresh pairing.
- Mask the whole device row when a screenshot could link its name, code hint, grant count, and time. Cropping one field is not enough.
When to stop and escalate
Stop if the request owner cannot be confirmed, the device name or last-four hint does not match, an unexpected vault count would be granted, the request keeps expiring, a revoked device still syncs, the list looks empty despite known devices, or audit events do not match the action. Email support@vaultpilot.io with the general state, broad time window, redacted error text, and last safe step, without pairing material or vault data.
Operator notes
Pairing approves one device and grants it vault access; it is not remote browser administration. Chrome Web Store delivery, organization policy, server-side access, local extension state, and page autofill are separate. Never claim that approval alone installed the extension, applied an update, removed local data, or guaranteed autofill.