Skip to main content

Browser Protection

The Browser Protection gives workspace security teams one place to review browser-native activity across:

  • browser extension activity
  • observed third-party extension inventory and policy state
  • browser activity signals
  • Web Access Protection decisions
  • shadow SaaS pressure
  • SaaS response controls

Route:

  • https://dralvia.tech/#/browser-security

What it shows​

  • Unified Browser Activity: normalized browser events such as navigation, redirects, uploads, clipboard events, and Web Access Protection decisions.
  • Workspace Security Operations hero: the Browser Protection now opens with a route-level operations hero, current feed count, and stable shortcuts into extension rollout, browser activity signals, and Web Access Protection.
  • Observed Extension Inventory: installed-extension observations from managed browsers that granted the optional inventory permission, including risk score, host access, publisher trust, linked-domain intel from Dralvia scans, trusted-brand-backed publisher verification, update-source-aware publisher reputation, workspace policy state, and an inline responsive detail inspector.
  • Wide-screen responsive layout: the #/browser-security route now uses a wider shell and defers the two-column activity/governance split until ultra-wide breakpoints so the event feed, posture cards, and extension governance widgets can use the full available workspace instead of collapsing too early.
  • Overflow-safe governance tiles: extension-governance summary tiles now wrap long labels and explanatory text inside the card boundaries instead of clipping or spilling out on mid-sized displays.
  • Extension enforcement outcomes: recent disable/remove attempts reported by managed browsers, including success vs permission gaps or browser-side failures, surfaced directly in the console summary and event stream.
  • Managed rollout bundle: Chrome and Edge ExtensionSettings payloads exported from Dralvia extension policy state so risky extensions can be blocked or removed through browser enterprise policy.
  • Release provenance: the Browser Extension Downloads workspace now also exposes release manifest and optional detached signature artifacts so rollout teams can verify the current ZIP before manual distribution.
  • Force-install readiness: when a stable Dralvia extension ID and update URL are configured, the downloads workspace also exposes Chrome/Edge ExtensionInstallForcelist payloads for the Dralvia extension itself.
  • Extension Detail Drawer: click an extension row to inspect permissions, host patterns, provenance, operator notes, and risk rationale without leaving the console.
  • Extension Risk Telemetry: a rolling summary of the managed-browser extension feed. The panel shows total extension state events, distinct extensions reporting in the window, how many events were high/critical risk, how many enforcement attempts failed (failed, permission_missing, error), and a top list of the riskiest extensions with their latest risk level, policy action, enforcement outcome, install type, permission scope, host access level, publisher trust, and last seen timestamp.
  • Account Posture Violations: a corporate-account violation dashboard that aggregates events where personal or mixed posture was observed on a workspace-bound or SSO-required sanctioned app, where approved account-domain or workspace binding was missing or wrong, or where the runtime recorded a known governance violation reason. The panel shows blocked vs warned vs monitored counts, account-domain and workspace mismatch totals, the top governance reason codes, and the top violating apps with their identity, workspace-bound/SSO flags, per-status counts, and top reason.
  • Extension risk and posture-violation sparklines: the Extension Risk Telemetry and Account Posture Violations panels now also render a daily sparkline of the last 14 days under each panel header. The extension sparkline stacks high/critical share on top of the total bar; the violation sparkline stacks blocked share on top of warned/monitored.
  • Shadow SaaS Adoption Trend: a daily sparkline of net-new SaaS apps discovered for the workspace, with totals broken down by sanctioned status (sanctioned / controlled / unsanctioned / unknown) and a shadow-AI count. The panel also lists the most recent net-new apps with their identity, category, vendor, and first-seen timestamp. The data is sourced from a GET /swg/saas/adoption/trend endpoint that buckets lifecycle_discovered SaaS history entries per UTC day and deduplicates re-discoveries to one entry per app.
  • Lifecycle resolution alongside adoption inflow (added 2026-05-16): the same Shadow SaaS Adoption Trend panel now also shows how the discovered apps actually resolved during the same window. A Lifecycle resolution section reports counts per terminal state (reviewing, sanctioned, deprecated, retired) plus the five most recent transitions (app, from-state, to-state, time, actor). Operators see both the SaaS inflow (new app discovery) and the resolution outflow (how the funnel was closed) in one panel.
  • Account Posture Pressure: aggregates personal, corporate, mixed, and unknown SaaS account posture across the current feed and highlights the apps with the most personal or mixed usage evidence.
  • Posture governance context: each account-posture card now carries backend-resolved app identity, vendor, category, sanctioned state, active control state, pressure level, and a recommended next step so operators can rank posture drift without manually cross-referencing SWG catalog data.
  • Governance owner context: account-posture cards now also surface SaaS governance owner, review status, and review note when that metadata already exists for the app.
  • Binding hardening context: account-posture cards now also show whether workspace SSO is required, whether the app should remain workspace-bound, and any operator rollback note that explains how exceptions should be handled.
  • Why this happened for SaaS response flows: account-posture cards now also derive a Why this happened panel with Reason, Risk, Safer path, and Next step, so posture-driven monitor or block decisions use the same plain-language rationale as the browser DLP evidence views.
  • Posture history drill-in: each account-posture card can now fetch the recent normalized browser-event history for that app so operators can review personal vs corporate usage before changing SaaS controls.
  • Governance timeline drill-in: account-posture cards can also open the recent SaaS control and governance change timeline for the same app, including actor, change type, and note.
  • Posture-driven response actions: operators can now create or remove monitor and block SaaS controls for the highest-pressure personal or mixed apps directly from the Browser Protection.
  • Data Movement Controls: the console now includes a workspace-managed browser DLP policy surface for uploads, downloads, clipboard, print, and text submission. Operators can set rollout mode (observe, warn, block), destination scope, sensitive-data classifiers, per-action overrides, adaptive access controls for unmanaged/BYOD/contractor contexts, destination-risk scoring for SaaS governance signals, evidence capture preferences, and user-facing intervention copy.
  • Data-movement pressure summary: the same Data Movement section now highlights the dominant DLP trigger and top Risk cluster from the backend summary.data_movement contract, alongside the existing scope/coverage pressure counters, so operators can see the hottest browser-time leak pattern without expanding each event.
  • Retention And Redaction Controls: the same console now exposes the browser-event privacy policy directly, including retention days, summary truncation length, actor/device/url redaction toggles, and metadata keys that should be removed from operator-visible event metadata.
  • Intervention preview + analyst evidence: the same Data Movement section previews the warn/block copy that the browser-native enforcement layer will use and shows the most recent warned, monitored, or blocked data-movement events from the normalized browser event feed.
  • Incident export and escalation: browser event cards and DLP analyst-evidence cards now expose Download EvidencePack and Escalate to TicketBridge so operators can hand off a browser-native incident without leaving the Browser Protection.
  • Decision trail download (added 2026-05-16): browser event cards and DLP analyst-evidence cards now also expose Download decision trail. The download is a normalized JSON record of every policy stage that contributed to the decision (destination_scope, destination_risk, adaptive, scan, classifier, governance) alongside destination context, runtime posture, why this happened, and an audit record (actor, device, source, extension version, enforcement outcome). The trail also carries an evidence_quality block that self-assesses each decision: an overall completeness of strong, partial, or weak, how many policy stages matched, whether content-classifier evidence is present, and whether the actor and device are attributed. SIEM and ticketing pipelines can use it to triage which DLP decisions are backed by full content evidence versus thinner scope-only signals. Downstream SIEM and ticketing pipelines can consume the same trail_schema_version-pinned shape through the Browser Security API.
  • Runtime scope visibility: analyst evidence now also shows whether each browser-time DLP event was in scope, out of scope, or limited by runtime blind spots, plus the target label, destination sanctioned status, and common scope-limitation reasons.
  • Scan-aware intervention evidence: analyst evidence now also shows when a page scan elevated the decision, including scan verdict, impersonated brand, top scan signals, and whether the intervention was driven by destination scope, scan pressure, or both.
  • Runtime account-posture evidence: analyst evidence now also shows the inferred runtime account posture, confidence, source, and matched domains/signals used to close personal_or_unsanctioned blind spots.
  • Approved corporate alias handling: when SaaS governance defines approved_account_domains, the browser runtime now treats those domains as corporate identity evidence for that sanctioned app so workspace-approved alias domains are less likely to trigger false personal-account pressure.
  • Unresolved account-binding enforcement: when SaaS governance defines approved_account_domains but the current browser page exposes neither a visible approved account domain nor any inferable workspace, Dralvia now emits approved_account_domain_unresolved_runtime. That path warns by default, and blocks when the sanctioned app is workspace-bound and already configured for blocking workspace control.
  • Unresolved binding evidence: analyst evidence now shows unresolved for sanctioned account-domain or workspace binding when the browser had no proof either way, instead of presenting that state as a confirmed mismatch.
  • Explicit binding states: browser-runtime governance evidence now carries explicit state values for sanctioned account-domain and workspace binding (matched, mismatch, unresolved), so downstream analytics and operator views do not have to derive that state from reason codes alone.
  • Approved workspace binding: when SaaS governance defines approved_workspace_ids, the browser runtime now compares the inferred Slack workspace (including modern app.slack.com/client/<team-id> routes), Zoom workspace subdomain, Google Workspace account index across supported *.google.com apps, Google Admin customer domain from admin.google.com/<customer_domain>/..., Atlassian Administration org id from admin.atlassian.com/o/<org-id>/..., GitHub organization slug from github.com/orgs/<org>/... / github.com/organizations/<org>/... or normal GitHub repository-owner routes like github.com/<owner>/<repo>/..., or wildcard subdomain workspace against that approved list before allowing sanctioned-app activity to continue.
  • Unresolved workspace enforcement: if SaaS governance defines approved_workspace_ids but the current browser URL does not expose any inferable workspace, Dralvia now emits approved_workspace_unresolved_runtime instead of quietly treating that session as benign. That path warns by default, and blocks when the sanctioned app is workspace-bound and already configured for blocking workspace control.
  • Workspace binding evidence: account-posture cards and browser DLP analyst-evidence rows now show the approved workspace list plus the inferred workspace id/source and whether the runtime matched or mismatched the sanctioned workspace policy.
  • Workspace-as-corporate fallback: when no visible account email is present, an approved workspace match now counts as medium-confidence corporate posture evidence instead of leaving the runtime posture at unknown.
  • Cross-surface "Why" decision chip: each event in the Recent Browser Security Events list now also renders a single plain-English "Why" pill that summarises the dominant decision flag. Governance binding, destination app risk, adaptive device posture, page-scan signal, or destination scope. So analysts can spot what drove a block without expanding the analyst evidence card. Severity follows the underlying flag (governance/destination risk/adaptive → warn or bad, scan elevation → bad with verdict + impersonated brand, scope match → neutral).
  • Why this happened summary: Recent Browser Security Events now also render Risk and Safer path guidance inline, and the Data Movement analyst-evidence cards add an Why this happened panel with Reason, Risk, Safer path, and Next step. Browser DLP runtime events now persist that coaching in normalized event metadata, so the console reuses one canonical trigger and action summary instead of recomputing the text client-side.
  • Destination-risk scoring: browser-runtime DLP now uses SaaS governance control_action, destination sanctioned_status, and workspace risk_note as a separate scoring overlay. Workspace admins can tune scores, warn/block thresholds, and whether unknown or unsanctioned apps require a risk note before warning or blocking browser data movement.
  • Adaptive device/session evidence: analyst evidence now also shows device trust, ownership, workforce type, and adaptive enforcement reason when managed browser posture or paired device telemetry elevated the decision.
  • Runtime content-classifier evidence: browser DLP events for clipboard paste plaintext, typed form submission values, and print-page text now carry redacted content_classifier_hits plus derived classifier categories (secrets, credentials, source_code, regulated_data) when workspace policy enables those detectors. The Browser Protection analyst-evidence card now renders both the detected class list and the redacted per-hit details (label, pattern_id, redacted_sample).
  • Workspace custom classifier patterns: the Data Movement Controls surface now lets workspace admins define up to 12 workspace-specific regex detectors (id, label, category, pattern, optional flags) that the managed browser runtime applies with the same redaction contract as built-in classifiers.
  • Upload text extraction: when a managed user selects readable text-like files in a browser upload flow, the runtime now performs a bounded local read (up to 3 files, 80k characters per file, 200k total) and feeds that plaintext into the same redacted classifier path before the upload event is emitted.
  • Office upload extraction: that same bounded upload path now also reads XML text from archive-based office formats (.docx, .docm, .xlsx, .xlsm, .pptx, .pptm, .odt, .ods, .odp) before classification.
  • PDF / legacy office upload recovery: for deeper binary uploads such as .pdf, .doc, .xls, and .ppt, the runtime now performs bounded PDF literal/hex text recovery plus printable-string recovery before classification. This improves coverage, but it is still not equivalent to full PDF layout parsing, OCR, or full document parsing.
  • Download body sampling: for explicit http(s) download clicks, the managed runtime can now fetch a bounded response sample when browser fetch/CORS allows it, pass that sample through the same text/office/binary extractor path, and emit redacted classifier evidence plus download_inspection_* metadata before recording the download DLP event.
  • Governance binding evidence: analyst evidence now also shows when tenant_bound or sso_required SaaS governance metadata elevated a browser-time decision for a personal or mixed runtime posture, including rollback context.
  • Browser-time guardrails: the managed extension can now consume that same policy and trigger browser-time warnings or hard blocks for upload, explicit download clicks, clipboard, print, and text_submission actions when the current destination scope evaluates as in-policy.
  • SWG deep links: the console can now open the Web Access Protection with the SaaS app pre-filtered to speed up follow-on policy work.
  • Shadow SaaS Pressure: the most active shadow apps currently seen by SWG.
  • SaaS Response Controls: active allow, monitor, or block controls for SaaS apps.
  • Quick Actions: direct links into Browser Extension Downloads, Browser Activity Signals, and Web Access Protection. These actions sit under the Workspace Security Operations command panel so the tab behaves like a first-stop triage surface instead of a raw event table.
  • Workspace identity badge: each event in the Recent Browser Security Events list now shows the inferred SaaS workspace beside the app id (for example slack.com @acme for acme.slack.com, slack.com @T12345 for app.slack.com/client/T12345/..., docs.google.com @account #5 for a Google Workspace account-index path, admin.google.com @contoso.com for admin.google.com/contoso.com/..., or atlassian.net @ABCDEF12-3456-7890-abcd-ef1234567890 for admin.atlassian.com/o/...). Workspace identity is inferred from the event URL plus the resolved app_id; events whose URL does not match a known SaaS shape simply omit the badge.
  • Recent events pagination: the Recent Browser Security Events list now paginates 3 events per page so the surface stays readable on common laptop widths. The page count, current range, and Previous/Next controls appear under the list whenever the filtered feed has more than three events. Filters and search reset the view to page 1.
  • SaaS lifecycle pill: each Account Posture Pressure card now renders a coloured lifecycle pill next to Owner and Review. The five states are discovered → reviewing → sanctioned (revertible to reviewing or moved to deprecated) → deprecated → retired. Hovering the pill shows when the state last changed and which actor changed it. New apps are auto-created in discovered the first time a normalized app_id arrives in a browser security event for the workspace; lifecycle is a parallel state machine to the existing freeform review_status field, not a replacement.
  • Lifecycle transition API: POST /swg/saas/governance/<app_id>/lifecycle with {"lifecycle_state": "<state>"} moves a governance record forward or back. The endpoint validates allowed transitions and returns 409 transition_not_allowed (with from and to fields) when an operator tries to skip a step. Each successful transition writes a history entry on the SaaS governance timeline.
  • Lifecycle action buttons: each Account Posture Pressure card now exposes a Lifecycle: action row that only renders the transitions allowed from the current state (discovered → reviewing, reviewing → sanctioned | deprecated, sanctioned → reviewing | deprecated, deprecated → reviewing | retired). Clicking a button POSTs to the lifecycle endpoint above and refreshes the console once the backend confirms. Apps in the terminal retired state instead show a Lifecycle locked notice in place of the button row.
  • Lifecycle filter: the Account Posture Pressure section now has a Lifecycle filter: dropdown that narrows the visible cards to one lifecycle state at a time and shows the per-state count next to each option. Selecting all restores the full list.
  • Bulk lifecycle moves: each Account Posture Pressure card has a checkbox. When at least one card is selected the section shows a bulk action bar with the count and a button per shared next state. Clicking a button POSTs once to /swg/saas/governance/lifecycle/bulk with the selection and target state. Successful moves and per-app failures are summarised inline (Bulk move to <state>: applied N, failed M.); per-app failures are also reported in the page error banner with the failing app_id and detail. The bulk endpoint enforces the same allowed-transition map as the per-card endpoint, so disallowed jumps are rejected per-app instead of failing the batch.
  • Lifecycle role gating: SaaS lifecycle moves (per-card and bulk) require tenant_admin or tenant_owner. tenant_analyst, tenant_member, and tenant_billing are observe-only and receive 403 lifecycle_admin_required from the API. The lifecycle action row and bulk action bar still render so analysts can see what an admin would do; the rejected request surfaces in the console error banner.
  • Lifecycle KPI strip: a Governance Lifecycle Distribution panel now sits directly above the Account Posture Pressure section. Five tiles (one per lifecycle state) report how many SaaS governance records currently sit in each state for the workspace, and a Recent transitions list under the tiles shows the latest from → to lifecycle moves with timestamp and actor. The data comes from the new GET /swg/saas/governance/lifecycle/distribution endpoint and is observe-only.
  • Lifecycle history CSV export: the KPI strip header now has an "Export history CSV" button that downloads every recorded lifecycle transition for the current workspace as a CSV with header tenant_id,app_id,from_state,to_state,change_type,actor,source,created_at. The export reuses the SaaS history feed and is suitable for evidence-grade audit pulls; an X-Lifecycle-History-Rows response header reports the exact row count.
  • Lifecycle activity sparkline: the KPI strip now also renders a daily sparkline of the last 30 days of lifecycle transitions. Each bar is one UTC day; bars are stacked by lifecycle state (discovered, reviewing, sanctioned, deprecated, retired) using distinct colours so operators can see at a glance which transitions drove a busy day. Hovering shows the date and transition count plus a per-state breakdown. The peak day is called out next to the window label, and the start/end dates of the window are printed under the sparkline.
  • Stuck-in-lifecycle review callout: an amber callout in the KPI strip now lists SaaS apps that have sat in discovered or reviewing past the configured threshold (default 14 days). The callout shows the count split between the two monitored states and the worst-stale apps with their state, days-in-state, and owner.
  • Stuck-in-lifecycle webhook alerts: workspaces on the Pro tier can subscribe to the saas.lifecycle.stuck event via Pro Tier Integrations. Run POST /swg/saas/governance/lifecycle/sweep-stuck (or schedule it on your side) to fire one webhook per newly stale app. Per-workspace SLA thresholds come from GET|POST /swg/saas/governance/lifecycle/policy; the dispatcher de-duplicates so a stuck app pages once per (app_id, lifecycle_state) until it transitions.
  • Lifecycle SLA editor: a Lifecycle SLA thresholds card in the KPI strip lets tenant_admin or tenant_owner users set distinct day thresholds for discovered → reviewing and reviewing → sanctioned directly from the console. Values clamp to the API's [1, 365] window. Saving the form refreshes the Stuck-in-lifecycle review callout and updates the policy that drives saas.lifecycle.stuck webhooks. The same card also exposes an "Auto-escalate to TicketBridge after N sweeps" field (default 3, 0 disables) so a stuck app can automatically open a TicketBridge ticket once the sweeper has observed it that many times in a row.

Who can use it​

  • Workspace users with an authenticated session can view their workspace-scoped browser-security activity.
  • Dralvia support can assist with workspace-scoped troubleshooting when requested.

Why this page exists​

Before this console, browser-native workflows were split across multiple surfaces. The Browser Protection is the shared first-stop page for browser-time review before you move deeper into rollout, raw evidence, or policy actions.

How to use it​

  1. Open #/browser-security.
  2. Review the top summary cards.
  3. Filter the event feed by source or action type.
  4. Review risky extensions and set workspace policy state with notes when operator coaching or block planning is needed.
  5. Review the account-posture panel and open posture history for an app when you need to confirm whether the current pressure is isolated or part of a broader corporate/personal usage mix.
  6. Open the governance timeline for the same app when you need to confirm who changed SaaS controls or review status before making another policy change.
  7. Use the recommended next step plus sanctioned-state context to decide whether to monitor, block, or remove an existing control for apps showing personal or mixed usage.
  8. Tune the Data Movement policy when you want browser-native warnings or blocks for selected actions, destinations, device/session contexts, or destination-risk scores.
  9. Tune the Retention And Redaction Controls when browser evidence should stay visible but PII needs to be pseudonymized or trimmed for routine operators.
  10. Open one of the quick actions when you need deeper evidence or controls.
  11. Use Download EvidencePack when a browser-native incident needs a signed chain-of-custody export, or Escalate to TicketBridge when the case should move into the incident queue.

Current scope​

This is a Phase 1 console, not the final browser-control plane.

Live today:

  • normalized browser activity feed
  • observed extension inventory with risk scoring + linked-domain intel from Dralvia scans
  • extension governance policy state: allow, warn, monitor, block, prevent install, remove
  • policy sync + enforcement outcome reporting (best-effort)
  • Browser Protection visibility for extension enforcement outcomes and recent failure details
  • Browser Protection account-posture summary for personal vs corporate SaaS usage in the current event window
  • Backend-enriched account-posture pressure entries with vendor/category identity, sanctioned state, active control state, and recommended next-step guidance
  • Governance owner and review-state context on account-posture cards
  • Governance binding metadata on account-posture cards (sso_required, tenant_bound, rollback_note)
  • App-scoped posture history drill-in powered by filtered browser-security events
  • App-scoped SaaS governance/control timeline drill-in powered by /swg/saas/history
  • Workspace-scoped browser DLP policy control plane with rollout mode, destination scope, sensitive-data classifiers, per-action overrides, adaptive access controls, destination-risk scoring, evidence-capture preferences, and intervention-copy preview
  • Workspace-scoped browser-event privacy policy editor with retention, redaction, metadata-key stripping, and summary truncation controls
  • Browser Protection analyst evidence panel for warned/monitored/blocked data-movement events already present in the normalized feed
  • Browser Protection inline operator-coaching summaries in the recent feed plus Why this happened panels in DLP analyst evidence cards
  • Browser Protection backend-driven data-movement pressure summary with dominant trigger, dominant data-at-risk cluster, runtime posture mix, and scope/coverage pressure
  • Browser Protection Why this happened panels on SaaS account-posture cards, plus coaching-backed default notes when operators create posture-driven monitor or block SaaS controls
  • Browser Protection runtime DLP coverage summary for scope-matched events, out-of-scope events, and the most common browser-time blind spots
  • Browser Protection scan-aware evidence for DLP events, including scan-driven escalation, impersonation-linked events, and the strongest page-scan reasons behind the intervention
  • Browser Protection runtime account-posture evidence for DLP events, including inferred posture, confidence, and matched-domain signals
  • Browser Protection adaptive device/session posture evidence for DLP events, including device trust, ownership, workforce type, and adaptive reason
  • Browser Protection destination-risk evidence for DLP events, including SaaS workspace control action, destination-risk reason, score, and matched policy rule
  • Browser Protection governance-binding evidence for DLP events, including runtime workspace-binding / SSO reason and rollback note
  • Browser event EvidencePack (Dralvia's exportable evidence report) export and TicketBridge escalation directly from the console activity feed and DLP evidence cards
  • Browser extension runtime support for browser-time warn/block on high-signal data-movement actions using workspace DLP policy + destination scope context, including explicit download links
  • Responsive wide-shell Browser Protection layout with overflow-safe extension governance summary cards
  • SWG summary integration
  • shadow SaaS summary
  • SaaS controls summary

Not live yet:

  • guaranteed full-body browser-side classification for non-fetchable download targets, OCR/font-aware PDF parsing, plus stronger and less heuristic personal-vs-corporate account posture enforcement at runtime when no approved corporate-domain evidence is available
  • one persisted cross-surface coaching contract shared by Browser Protection, extension warning surfaces, SWG decision views, and SaaS-governance API response surfaces
  • corporate-vs-personal SaaS account enforcement
  • guaranteed install prevention / removal enforcement for third-party extensions
  • deeper replay-pack workflows from this page

Evidence handling note​

The routine recent-event feed can apply workspace privacy redaction for normal operator views. The signed browser-event EvidencePack export preserves the stored incident payload and metadata for audit and TicketBridge handoff.

Who this is for​

  • Workspace owners and workspace admins who manage browser controls and SaaS governance.
  • Security analysts who triage browser-native incidents and escalation evidence.
  • Dralvia support teams assisting with a workspace-specific browser security investigation.

Role-based start here​

  • Workspace Owner: start with Before you start, then review Step-by-step and Next best actions.
  • Workspace Admin: start with Step-by-step, then use What each button does and API and automation.
  • Security Analyst: start with Day-2 operations, then use Self-check playbook and Troubleshooting.

Before you start​

  1. Confirm you are in the correct workspace.
  2. Confirm browser events, extension observations, or SWG telemetry are actually flowing for this workspace.
  3. Confirm you have the role needed to change policy, lifecycle state, or escalation settings.

Step-by-step​

  1. Open #/browser-security.
  2. Review the summary cards and current event feed volume.
  3. Filter the feed to the app, action type, or policy surface you need.
  4. Inspect the relevant event, extension, or posture card.
  5. Apply governance, lifecycle, DLP, or escalation actions only after reviewing the evidence panel.

Day-2 operations​

  1. Review recent browser-native events daily for new risky extensions, posture drift, or blocked data movement.
  2. Review lifecycle transitions and governance notes weekly.
  3. Export EvidencePacks or escalate to TicketBridge after any browser-native incident that needs a formal record.

Self-check playbook​

  1. Confirm telemetry freshness before assuming the console is empty.
  2. Confirm filters are not hiding the event, app, or lifecycle state you expect.
  3. Confirm the workspace has browser extension, activity-signal, or SWG sources enabled for the workflow you are checking.
  4. Confirm the action you want is allowed for your current role.

What each button does​

  • Refresh: reloads the latest browser security, governance, and evidence data.
  • Download EvidencePack: exports the current incident evidence bundle.
  • Escalate to TicketBridge: creates or updates an incident handoff.
  • Lifecycle action buttons: move a SaaS governance record to an allowed next state.
  • Bulk lifecycle actions: move multiple selected SaaS records to the same allowed next state.

Troubleshooting​

  1. If the feed looks empty, first confirm upstream browser, beacon, or SWG telemetry is arriving for the workspace.
  2. If lifecycle actions fail, confirm your role is tenant_admin or tenant_owner.
  3. If escalation fails, capture the exact error banner and the affected event or app id before retrying.

API and automation​

  • Browser security route: #/browser-security
  • SaaS lifecycle transition: POST /swg/saas/governance/<app_id>/lifecycle
  • SaaS lifecycle bulk transition: POST /swg/saas/governance/lifecycle/bulk
  • Lifecycle distribution: GET /swg/saas/governance/lifecycle/distribution

API error quick reference​

  • 401 Unauthorized: your session or API key is missing, expired, or not valid for this workspace.
  • 403 Forbidden: your role can read the page but cannot perform the requested governance or lifecycle mutation.
  • 404 Not Found: the target event, app, lifecycle record, or export artifact does not exist for this workspace scope.
  • 429 Too Many Requests: the workspace hit a rate or cooldown limit; wait and retry.
  • 500 Internal Server Error: the backend failed while loading browser evidence, governance context, or export output; retry once and capture the error if it persists.

Next best actions​

Related guides:

  • Browser Extension

  • Web Access Protection

  • EvidencePack verification

  • If you see risky extension activity, review the Browser Extension guide next.

  • If you see app posture drift, review Web Access Protection and SaaS governance history next.

  • If you see data-movement incidents, export EvidencePack or escalate to TicketBridge next.

FAQ​

Why is the Browser Protection empty?​

The console only shows what upstream browser extension, beacon, and SWG sources have actually sent for the workspace.

Why can I see lifecycle buttons but still get a 403?​

The UI leaves the action visible for context, but the backend only allows lifecycle changes for elevated roles.

Next steps​

  1. Tune browser DLP and retention settings for your workspace.
  2. Review Browser Extension, Browser Beacons, and Web Access Protection pages for deeper controls.
  3. Export evidence or open an incident handoff for any event that needs follow-up.

Known limits and rate limits​

  • Plan quotas apply: scan, render, report, repository, and API-key limits follow your plan tier. See Pricing & Plans for the enforced defaults.
  • API requests are rate limited per workspace. A 429 Too Many Requests response means a rate or quota window was exceeded; wait for the reset window, then retry once and reduce burst volume.
  • Free Evaluation has the tightest limits and is subject to anti-abuse controls. Paid plans raise the limits; Enterprise sets custom limits by contract.