For the team clearing a rollout: what the software talks to, how traffic is secured, how a device authenticates, and where captured data goes. Install steps are in Deploying the desktop agent with Microsoft Intune and Rolling out the browser extension; the full privacy posture is in the Discovery trust addendum.
Outbound destinations to allow
If outbound traffic from the fleet is filtered by destination, allow these hosts. All are standard HTTPS on port 443, and none pin certificates, so a TLS-inspecting proxy can decrypt them without special handling.
| Destination | Purpose |
|---|---|
app.flowscope.com | Capture event ingestion, device pairing and sign-in, and agent auto-update |
stflowscopeextrel.blob.core.windows.net | Browser extension update manifest and package download |
stflowscopeagentrel.blob.core.windows.net | Desktop agent installer and auto-update bundles, reached via a short-lived signed link minted by app.flowscope.com |
The desktop agent host is reached through a redirect from app.flowscope.com, so without it on the allowlist the agent install and self-update will fail behind a destination filter.
As a plain list for a firewall ruleset:
app.flowscope.com
stflowscopeextrel.blob.core.windows.net
stflowscopeagentrel.blob.core.windows.net
There are no inbound connections; the device only reaches out.
How traffic is secured
All traffic to app.flowscope.com is HTTPS, terminated at Azure Front Door with managed certificates, over TLS 1.3. The agent's network calls, including its auto-update check, go through a native HTTPS client rather than an embedded browser, so they are not affected by any in-app content policy.
How a device is authorized
A capture surface cannot send anything until it is paired to your organization. Pairing is a browser handshake in which the participant signs in with their work account and confirms; it provisions a credential unique to that device. Every subsequent request carries that credential, and the server resolves the specific device before accepting anything.
- The credential is per device. No shared key is baked into the software, so nothing in a distributed build is valid for another customer or machine.
- It is revocable. An admin can revoke a device from the dashboard at any time; its requests are then rejected immediately and it must pair again to return.
Administrators sign in to the dashboard through your own identity provider (Google Workspace or Microsoft Entra ID for customer staff), not a flowscope-managed password.
The path captured data takes
Captured activity is minimized in layers before it comes to rest:
- On the device, before anything is sent: capture is confined to the customer's allowlist, the denylist categories are excluded entirely, password fields and token-bearing URL parameters are dropped, and format-checkable personal data (payment-card numbers, bank-account identifiers, and government-issued identification numbers) is masked.
- In transit: over the TLS channel above, authenticated by the device credential.
- On the server, before storage: an always-on layer (Microsoft Azure AI Language) masks a broader set of personal data, such as names and addresses.
- At rest: a managed PostgreSQL database on Microsoft Azure, encrypted at rest, tagged only with a pseudonym. Once the setup window closes, flowscope cannot map that pseudonym back to a person.
flowscope captures no audio, video, or webcam input; the model is accessibility-tree events. Captured data is never used to train any model. Subprocessors are listed on the subprocessors page; retention terms are in the Discovery trust addendum.
Endpoint execution controls
Both the browser extension and the desktop agent install normally under standard endpoint execution-control policies.