Notifications
Clear all
Topic starter
19/08/2026 3:46 pm
TL;DR: AI use is already creating browser-level identity risk because real login pages, session tokens, and unmanaged access paths can be captured in-browser before traditional controls see the activity, according to Push Security. That makes browser telemetry, detection, and guardrails central to securing AI apps and shadow SaaS, not an optional layer.
NHIMG editorial — based on content published by Push Security: AiTM phishing and browser-based identity attacks
Questions worth separating out
Q: How should security teams reduce the risk of MFA bypass through AiTM phishing?
A: Treat MFA as one control in a broader session-security chain.
Q: Why do MFA and SSO not fully cover browser-based identity attacks?
A: MFA and SSO reduce risk at authentication, but many attacks succeed after authentication has already occurred.
Q: What breaks when organisations treat the browser as a low-risk interface?
A: They miss the point where identity, session, and access actually converge.
Practitioner guidance
- Deploy browser-level session detection Instrument browser activity so cloned login pages, token capture, and suspicious session reuse are visible during the authentication flow, not only after compromise is reported.
- Prioritise token-aware phishing controls Tune detections for AiTM behaviour, including real-time credential relay, MFA interception, and session token theft, because these patterns bypass static URL and signature filtering.
- Extend IAM monitoring to AI app sessions Classify AI apps and shadow SaaS as identity-sensitive browser targets, then monitor sign-in context, session reuse, and access timing for anomalies.
What's in the full article
Push Security's full post covers the operational detail this post intentionally leaves for the source:
- How the browser telemetry works for cloned login page detection and session activity analysis
- Examples of adversary-in-the-middle phishing kits and the behaviour patterns they expose
- Operational guidance for blocking browser-based attacks before session takeover occurs
- The product and detection workflow details behind secure AI app and shadow SaaS monitoring
👉 Read Push Security's analysis of AiTM phishing and browser-based identity attacks →
AI in the workforce: are browser controls keeping up?
Explore further
19/08/2026 4:23 pm
Browser control is now an identity control, not a UI layer. When authentication, session reuse, and app access all happen in the browser, the browser becomes part of the identity enforcement surface. That is especially true for AI apps and shadow SaaS, where users may authenticate through unmanaged paths that never touch traditional device trust logic. Practitioners should treat browser visibility as core IAM telemetry, not a niche detection feed.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to the 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.
A question worth separating out:
Q: How should security teams govern local AI apps that bypass browser-based controls?
A: Security teams should treat local AI apps as endpoint-governed software, not as browser extensions of SaaS. That means requiring installation review, user attribution, allowed-use policy, and inventory coverage that includes the device itself. If the tool executes locally, browser logs alone are insufficient for audit, compliance, or incident response.
👉 Read our full editorial: AI in the workforce is creating browser identity risk
