TL;DR: AI attacks now cut both ways, with attackers using AI to scale phishing and identity abuse while AI platforms themselves become part of the attack surface, according to Push Security. The practical problem for identity teams is not model performance but browser-level visibility, control, and guardrails across human, NHI, and shadow AI access paths.
NHIMG editorial — based on content published by Push Security: AI attacks and browser security research
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.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
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 browsers create new identity and access risk?
A: Because they turn the browser from a passive display layer into a system that can interpret content and execute actions.
Q: What do security teams get wrong about shadow AI governance?
A: They often treat shadow AI as a banned-app problem when it is usually an identity and accountability problem.
Practitioner guidance
- Instrument the browser as an identity control plane Collect browser telemetry for authentication events, session changes, token use, and AI app access so identity teams can see what happens after login.
- Inventory shadow AI as part of NHI governance Map which AI tools employees use through the browser, which accounts or tokens they connect, and whether those sessions can access corporate data.
- Separate managed AI access from unmanaged browser usage Define which AI tools require approved access paths, which can be blocked, and which need conditional controls such as device trust, session binding, or data loss prevention.
What's in the full article
Push Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific examples of how browser security controls detect AI-related identity abuse in real sessions
- Threat-research detail on the poisoned tenant technique and how it was used against Push employees
- Practical distinctions between browser visibility, shadow AI discovery, and response workflows
- Examples of how attackers use computer-using agents to automate identity attacks
👉 Read Push Security's analysis of AI attacks in the browser →
AI attacks in the browser: what identity teams need to know?
Explore further
Browser visibility is now an identity control requirement, not a telemetry luxury. When authentication, session activity, and AI usage all happen inside the browser, controls that only observe the IdP or endpoint miss the moment abuse becomes real. The governance gap is that identity policy now needs runtime context from the browser to remain enforceable. Practitioners should treat browser telemetry as part of access governance, not as a separate security discipline.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Our research also found that enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
A question worth separating out:
Q: When should organisations block an AI app instead of approving it?
A: Block an AI app when its access scope, data handling, or downstream integrations exceed the organisation's risk tolerance and cannot be constrained with policy. If the app touches sensitive systems, lacks credible security posture, or can widen access dynamically, approval should wait until controls can be enforced at runtime.
👉 Read our full editorial: AI attacks in the browser are redefining identity risk