Both. AI browsers sit between identity assurance and transaction execution, so the right control model combines device intelligence, behavioural checks, and step-up authentication. If either side is missing, attackers can exploit the gap between who the user is and what the browser is allowed to do.
Where AI Browsers Sit in the Control Stack
AI browsers are not just “smarter browsing” and they are not just a fraud widget. They sit in the middle of a transaction path, where the same session may carry both identity assurance and user intent. That means the control question is really about whether the browser is allowed to act, whether the user is still the one driving it, and whether the action is safe for the transaction it is about to complete.
In practice, that makes AI browsers closer to a delegated-authorization problem than a simple UI problem. If the browser can read pages, retain cookies, execute workflows, and move from one site to another, then the security model has to account for the browser and computer-use agent security model, not only the end user’s login status. The right question is what the browser can do with that session, and under what conditions it should be stopped, challenged, or narrowed.
This is why organisations should treat AI browsers as both a fraud-control surface and an identity surface. Fraud controls look for abnormal device, browser, and behavioural signals; identity controls decide whether the action still matches the authenticated user and the current assurance level. If one side is strong and the other is weak, attackers can exploit the gap between being signed in and being legitimately authorised to transact.
Why Fraud Controls Alone Miss the Identity Gap
Fraud tools are good at spotting abnormal device posture, automation, impossible travel, velocity spikes, and anomalous interaction patterns. That is essential, because AI browsers can turn a normal session into a high-speed transaction engine. But fraud signals alone do not tell you whether the action is properly bound to the authenticated person, especially if the browser is reusing a live session, a remembered device, or a delegated workflow.
That distinction matters when the browser is operating inside a real account. A clean device fingerprint does not prove that the transaction is still legitimate, and a low-friction session does not prove that the user meant to authorise the specific action. Organisations need to pair fraud detection with step-up authentication, action scoping, and session constraints, especially for sensitive changes, payouts, account recovery, credential changes, or beneficiary edits.
Device intelligence is still valuable, but it should be treated as one input to a broader control decision. For identity-heavy journeys, the useful comparison is not “human versus bot” alone, but “is this still the right actor, on the right device, performing the right action, under the right level of assurance?”
How to Decide What the Control Owner Should Prioritise
For high-risk consumer and customer journeys, start with the transaction itself. If the AI browser can move money, change recovery data, create recipients, or alter account settings, then identity assurance and step-up authentication should be the primary control gates. If the main concern is automated abuse at scale, such as scripted fraud, fake account use, or bot-assisted abuse, then device intelligence and behavioural analytics should carry more weight.
That is why the strongest operating model is layered. Fraud teams should own velocity, device reputation, anomaly scoring, and abuse pattern detection. Identity teams should own assurance level, session binding, reauthentication thresholds, and policy for when delegation ends and human confirmation is required. In a well-run model, an AI browser is never trusted solely because it is already signed in.
The control point should also reflect the action’s reversibility. Low-risk reads can usually tolerate more automation. High-impact writes should require stronger confirmation, tighter session controls, or an explicit human re-approval step before execution.
Risk and Threat Considerations
AI browsers create a blended risk: they can look like legitimate users to fraud systems while still behaving like delegated automation in a live session. That makes them attractive for session hijack, account takeover, and transaction abuse, especially when attackers can ride an existing login rather than defeat primary authentication outright.
Failure mechanism: The browser inherits trust from the authenticated session, but the organisation fails to re-evaluate that trust at the moment of action. Attackers can exploit long-lived sessions, weak reauthentication rules, overbroad browser permissions, or missing device binding to turn access into unauthorised execution.
Impact: The result can be fraudulent transfers, account changes, recovery-path takeover, or silent abuse inside otherwise valid sessions. For a deeper look at how identity misuse and delegated browser execution overlap, the identity fraud prevention model is a useful companion, and the top NHI issue patterns also map well to overprivilege, reuse, and session abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | AI browsers can execute actions inside live sessions, making excess privilege a direct control risk. |
| NHI-04 — Insecure Authentication | The question hinges on when browser actions need stronger authentication than a logged-in session alone. | |
| Recommendation — Constrain browser-driven actions to the minimum privileges needed for the transaction. Require step-up authentication before high-risk browser actions are executed. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI browsers can misuse delegated authority if identity and action binding are weak. |
| Recommendation — Bind delegated browser actions to explicit identity and privilege checks at runtime. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | AI browsers performing sensitive transactions need stronger assurance than basic login state. |
| Recommendation — Apply higher assurance requirements before permitting sensitive browser-mediated transactions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The issue includes whether authenticated users must reauthenticate before sensitive actions. |
| IA-5 — Authenticator Management | Session and authenticator handling affect whether browser actions remain trustworthy over time. | |
| Recommendation — Enforce reauthentication for high-risk actions that the browser can initiate. Set short-lived, well-managed authenticators for high-risk browser sessions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Browser-mediated abuse often succeeds through excessive or stale account access. |
| Recommendation — Review and tighten accounts that can complete sensitive browser-driven transactions. | ||
Practitioner Guidance
What to prioritise: Treat the highest-risk transaction paths first, not the broadest browser rollout. If the AI browser can initiate money movement, recovery changes, or privilege changes, require stronger proof of user intent before execution.
What to verify: Confirm that device signals, session age, and authentication strength are checked at the point of action, not only at login. If the control only evaluates entry to the site, it is too early to stop and too late to be safe.
Decision rule: If a transaction is both high impact and hard to reverse, require step-up authentication or explicit confirmation even when fraud scores look clean. If the action is low impact and read-only, allow more automation but keep behavioural monitoring in place.
What practitioners underestimate: The browser is often the trust bridge between identity and execution. Once that bridge is overly broad, the failure mode is not just fraud or just identity compromise, it is authenticated abuse at machine speed.
Practitioner takeaway: The right operating model is layered control, not a single label. AI browsers should be governed as delegated execution environments where fraud, identity, and transaction policy all have to agree before the action is allowed.
Related resources from NHI Mgmt Group
- What happens when organisations treat fraud as a one-time training problem instead of an ongoing control issue?
- Should organisations treat agentic AI as a workload identity problem or an AI problem?
- Should organisations treat sandbox AI, internal AI apps, and production AI as the same control problem?
- When should organisations treat asset discovery as an identity control problem?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org