Push expands browser detections and file download telemetry

At a glance

What this is: Push Security’s update expands browser telemetry and enforcement with custom detections, file download visibility, password-entry blocking, and a longer events window.

Why it matters: IAM and security teams get more control over browser-mediated identity behaviour, which matters when risky actions, unsafe downloads, and credential-entry mistakes happen before traditional controls can see them.

Context

Browser-side identity controls are becoming more operationally useful because the browser is where sign-in mistakes, risky web activity, and file transfer behaviour increasingly show up first. When those events are only visible after the fact, teams lose the chance to intervene at the point of action.

This update from Push Security extends that browser control surface in four ways: custom detections, file download telemetry, prevention of password entry into non-password fields, and a longer events retention window. The governance question is no longer whether browser telemetry exists, but whether it is usable for policy, triage, and response.

For identity programmes, this sits at the overlap of human IAM, browser security, and detection engineering. It is especially relevant where the browser has become the front door for authentication, SaaS access, and user-driven downloads that may never pass through a conventional network checkpoint.

Key questions

Q: How should security teams handle risky browser activity before it reaches the application layer?

A: Use browser detections to intervene at the point of interaction, not after logs are analysed. The key is to translate risky DOM states, requests, headers, and user behaviour into explicit warn or block rules that reflect local policy. That gives teams control over identity-adjacent activity while the user session is still active.

Q: What makes file download telemetry useful for identity and security teams?

A: It exposes file name, download URL, MIME type, and unsafe status, which helps teams connect downloads to identity sessions and response workflows. The important part is coverage of browser-constructed files, not just network downloads, because those can evade assumptions built around perimeter logging.

Q: What breaks when password entry is not blocked in non-password fields?

A: When password entry is not blocked in non-password fields, users can accidentally place secrets into application logs, support traces, or analytics fields that were never meant to hold credentials. That creates avoidable exposure, especially in high-value applications such as identity providers. The failure is not authentication itself, but secret leakage through everyday form behaviour.

Q: Should teams rely on browser event history instead of SIEM retention?

A: No. A browser console window is useful for quick triage, but it is not a substitute for central retention, correlation, and investigation. Security teams should treat browser events as a source feed and preserve longer history in SIEM so they can connect download, authentication, and user-behaviour signals.

How it works in practice

Custom browser detections from DOM, headers, and web traffic

Push’s custom detections let teams write rules against live browser activity rather than waiting for downstream logs. The detection surface includes page DOM elements, web requests and responses, and HTTP headers such as cookies. That means policy can react to user-visible behaviour, content changes, and session artefacts in the browser context. Rules are written in YAML and can trigger actions such as warn or block, with custom end-user messaging. The practical effect is to turn the browser into a controllable inspection point for identity-relevant behaviour, including risky workflows and policy violations.

Practical implication: define browser rules for the specific behaviours you already wish you could stop at the point of interaction.

File download telemetry and browser-constructed files

The file download feed reports metadata such as file name, download URL, MIME type, and whether the file was judged unsafe. Importantly, the telemetry is not limited to conventional network downloads. It also covers files created in the browser itself, including downloads built from blob or data URLs. That matters because browser-constructed files can bypass assumptions that only network-layer controls see transfer events. The feed can also be scoped by employee group, individual user, and profile type, which makes it usable for targeted monitoring and investigation rather than only broad logging.

Practical implication: route download telemetry into SIEM or SOAR and use it to spot risky file creation paths that never touch standard network download controls.

Blocking password entry into non-password fields

Password-entry blocking is a browser-side safeguard against a common human error: typing a password into a field that is not actually a password field, such as a username or email box. That mistake can expose credentials to application logs, form handlers, or other telemetry that was never intended to hold secrets. The control is especially relevant for sign-in flows tied to a primary identity provider, where the cost of accidental disclosure is higher. This is not about authenticating the user more strongly. It is about preventing secret spillage through the wrong form field.

Practical implication: treat credential entry protection as a browser control for secret leakage, not just a usability feature.

NHI Mgmt Group analysis

Browser telemetry is becoming an enforcement layer, not just an observation layer. The important shift in this update is that detections can now trigger warn or block actions directly in the browser. That changes the governance model for identity-relevant activity because the browser is no longer just a place to collect evidence after the fact. Practitioners should treat browser instrumentation as part of the access-control surface, especially where user behaviour is the control point.

File download telemetry closes a visibility gap that traditional logging often misses. Downloads created in the browser itself, including blob and data URL flows, are easy to overlook if teams think only in terms of network perimeter events. The named concept here is browser-originated download visibility: the ability to see and classify files that are assembled locally in the session before they become artefacts elsewhere. That matters for SaaS-heavy environments where the browser is the effective workstation.

Password-entry blocking addresses secret leakage at the moment of user error. The risk is not weak authentication policy, but accidental credential capture in fields that can expose secrets to logs or analytics. For identity programmes, this is a human control with machine consequences: one mistaken keystroke can create a downstream secret-handling problem. The practitioner implication is to move protection closer to the form interaction, not only to the back-end account.

Events retention only becomes useful when it feeds the broader detection stack. A 30-day console window helps short-cycle triage, but Push Security itself recommends longer-term ingestion into SIEM for querying and correlation. That reflects a wider identity security pattern: browser telemetry is valuable when it can be joined with authentication, endpoint, and SaaS signals. Teams should treat the console as a working view, not the system of record.

Custom detections give security teams a way to encode local policy into browser controls. The strongest use cases are not generic alerts but organisation-specific indicators, red-team test cases, and prohibited workflows such as unauthorized MCP connections. That makes browser detections useful for governance where policy cannot be expressed cleanly in the application itself. Practitioners should translate ambiguous browser risk into explicit rules that can warn, block, and surface evidence consistently.

What this signals

Browser-side enforcement is now part of identity governance. When detections can warn or block directly in the browser, teams are no longer limited to after-the-fact monitoring. That shifts browser telemetry from a visibility tool into a control surface for human IAM and SaaS access governance.

Browser-originated downloads create a visibility problem that network controls miss. Files built from blob or data URLs may never look like traditional downloads, yet they still carry business risk and investigative value. Security teams should expect browser-native file creation to become a normal part of triage and response.

Secret leakage often starts with a user interface mistake, not a compromise. Blocking password entry into non-password fields prevents credentials from being copied into places that generate logs, analytics, or support artefacts. That is a practical example of controlling identity risk at the point of human action.

For practitioners

• Define browser rules for high-risk workflows Map the DOM elements, web requests, responses, and cookie patterns that indicate risky user behaviour or policy violations, then decide whether each rule should warn or block.
• Ingest file download telemetry into your security stack Send file name, download URL, MIME type, and unsafe-download signals into SIEM or SOAR so investigators can correlate downloads with identity and session activity.
• Block password entry into non-password fields Apply the safeguard first to sign-in flows that matter most, especially the identity provider and other core applications where a leaked password would create broader exposure.
• Use the events window for rapid triage, not long-term retention Treat the 30-day events page as a short-horizon investigation view and keep authoritative history in your SIEM for correlation, search, and retention.
• Write custom detections for organisation-specific browser risk Create YAML rules for known IOCs, targeted TTPs, red-team test cases, and browser behaviours that should never occur in your environment.

Key takeaways

• Browser telemetry is moving closer to enforcement, with custom detections and block actions that operate inside the session rather than after the fact.
• File download visibility now includes browser-constructed files, which closes a gap that traditional network monitoring often misses.
• Preventing password entry into non-password fields reduces accidental secret leakage in the most sensitive authentication workflows.

Key terms

• Browser Enforcement: Browser enforcement is policy execution inside the browser or closely adjacent endpoint layer where the user interaction occurs. It is relevant when employees use AI tools through web interfaces, because sensitive text can be copied, pasted, or generated without ever passing through traditional network controls.
• File Download Telemetry: File download telemetry is event data about files retrieved through the browser, including metadata such as file name, source URL, MIME type, and safety status. It helps security teams identify potentially malicious or risky downloads and connect them to the session, user, or workload that initiated them.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Browser-originated Download: A browser-originated download is a file created or transferred within the browser session rather than through a traditional network download path. This includes files built from blob or data URLs, which can bypass assumptions that only network-layer events need to be monitored.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.