TL;DR: AI visibility and control increasingly depend on the browser because many AI interactions, sessions, and data movements now happen there rather than in endpoint tools, making browser telemetry a practical control surface for identity and data protection, according to Push Security. That shifts the problem from simple app blocking to governing unmanaged identities, session-level access, and browser-native activity that conventional controls often miss.
NHIMG editorial — based on content published by Push Security: browser-based AI control and identity risk
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern employee use of public AI tools in the browser?
A: They should treat browser AI use as an identity and data-control problem, not just an acceptable-use issue.
Q: Why do AI tools create new identity governance risks for IAM teams?
A: AI tools create new identity governance risks because they combine fast adoption with broad access paths and subordinate permission objects.
Q: What breaks when organisations rely on endpoint controls alone for AI use?
A: Endpoint-only control misses the in-session behaviour that determines whether AI use is safe or compliant.
Practitioner guidance
- Map browser-accessed AI services Inventory which AI tools are accessed through browsers, who is using them, and which identities, tokens, or connected apps are involved.
- Add session controls for AI uploads Use browser-native controls to detect and restrict risky prompt, paste, upload, and file-sharing behaviour when sensitive data may leave the organisation through AI tools.
- Correlate identity telemetry with browser events Join identity logs, SaaS audit trails, and browser telemetry so security teams can see whether a human login, delegated token, or compromised session is driving AI activity.
What's in the full article
Push Security's full post covers the operational detail this post intentionally leaves for the source:
- Specific browser-side detection patterns for account takeover, token misuse, and suspicious AI app activity
- Product and telemetry examples showing how browser visibility is used to investigate AI-related identity events
- Implementation detail on how browser controls are applied to unmanaged identities and shadow SaaS usage
- Threat-research context behind the Push team's view of browser-native AI exposure
👉 Read Push Security's analysis of browser-based AI control and identity risk →
Secure AI in the browser: what identity teams need to know?
Explore further
Browser-based AI use is now an identity governance problem, not just an application governance problem. Once prompts, uploads, and connected accounts move through the browser, the security boundary shifts from installed software to live session behaviour. That makes traditional approval lists insufficient on their own, because the identity risk lives in what the browser session can do right now. Practitioners should treat browser-mediated AI activity as a first-class governance domain.
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, according to the same report.
A question worth separating out:
Q: How can teams decide whether to block or allow browser-based AI usage?
A: Base the decision on data sensitivity, identity assurance, and the browser context of the session. If the user is signing in from an unmanaged device, using an external AI service, or moving regulated data, the safer choice is to block or heavily constrain the session rather than rely on policy alone.
👉 Read our full editorial: Browser-based AI control is becoming an identity problem