By NHI Mgmt Group Editorial TeamPublished 2026-06-02Domain: EventsSource: Push Security

TL;DR: AI regulations across the US, EU, and UK are converging on browser-level visibility into AI tool use, but most organisations still lack the control plane to prove it, according to Push Security. Browser mediation is becoming a governance issue for identity teams, not just a security telemetry problem.


At a glance

What this is: Push Security argues that AI regulation is pushing organisations toward browser visibility and control as the place where AI tool use can be observed and governed.

Why it matters: This matters because identity teams will be asked to evidence who or what accessed AI tools, which means browser-level controls may need to sit alongside IAM, NHI, and human access governance.

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.

👉 Read Push Security's analysis of AI regulation, browser visibility, and compliance


Context

AI governance is increasingly colliding with the browser, because that is where users, copilots, and external AI tools intersect before data leaves the organisation. For identity programmes, that shifts the control question from whether an application is approved to whether the access path is visible, attributable, and enforceable in real time.

Push Security's framing is that browser control is becoming a compliance and governance issue, not just a security feature. That is a familiar pattern in NHI and human IAM: once a new interaction layer becomes the easiest place to bypass policy, the identity team inherits the accountability gap.

The practical challenge is that most access governance models were built around managed endpoints, named applications, and policy checkpoints outside the browser. AI tool use breaks that assumption because activity can happen inside the session, across unmanaged services, and before traditional controls can classify the interaction.


Key questions

Q: How should security teams govern AI use in the browser?

A: Security teams should govern browser-based AI use by tying session visibility to identity policy. That means defining which tools are allowed, what data can be pasted or uploaded, and how those actions are logged for audit. Without browser-layer evidence, enforcement remains indirect and teams cannot prove whether policy was actually applied.

Q: Why do existing IAM controls struggle with browser-mediated AI activity?

A: Existing IAM controls struggle because they usually govern application access and authentication events, not the user actions that happen after login inside the browser. AI prompts, uploads, and tool handoffs can occur within a valid session, which means the identity was authenticated but the behaviour still bypassed meaningful oversight.

Q: What breaks when browser visibility is missing for AI governance?

A: When browser visibility is missing, teams lose the ability to attribute AI use, detect sensitive data movement, and prove that approved tools were used within policy. The result is a governance blind spot where the organisation may still have authentication records but lacks session evidence for compliance or investigation.

Q: Who is accountable when AI tool use happens through unmanaged browser sessions?

A: Accountability sits with the organisation that allowed the session path to exist without control, because the browser becomes the place where policy, identity, and data handling intersect. If no team owns that layer, neither IAM nor security can demonstrate who approved the interaction or who is responsible for the exposure.


Background and context

Browser-level visibility into AI tool use

Browser visibility means observing the session layer where users interact with web apps, SaaS tools, and AI services, rather than relying only on network or endpoint logs. In AI governance, that layer matters because prompt entry, copy-paste, file uploads, and token-mediated actions often happen there first. It is also where policy enforcement can become context-aware, such as detecting sensitive data flows or unauthorised tool use before content leaves the organisation. Without browser telemetry, identity teams are left inferring behaviour from downstream logs that arrive too late for meaningful control.

Practical implication: Practitioners should map which AI interactions are only visible in the browser and identify where current logging cannot support audit or containment.

Why EDR alone misses browser-based AI activity

Endpoint detection and response is designed to observe device behaviour, processes, and known malicious activity on the host. It does not fully capture what happens inside a browser session when a user moves data into an AI tool, authorises an integration, or performs an action through a web interface that looks legitimate at the endpoint level. That gap is structural, not a tuning problem. If the security model only sees the device and not the application session, it cannot reliably distinguish approved work from policy-bypassing AI use.

Practical implication: Treat EDR as one layer and define separate controls for browser-mediated AI interactions that need session-level context.

Browser control as a governance plane for AI regulation

As AI regulation develops, organisations will need evidence of who accessed what, under which conditions, and whether data handling stayed within approved boundaries. Browser control can provide that evidence when AI use occurs in SaaS and web-based interfaces. The important shift is that governance moves from static app approval to runtime oversight of the interaction itself. That aligns with identity assurance, auditability, and acceptable-use enforcement, especially where the AI tool is external and the data path is user-driven.

Practical implication: Build audit requirements around session evidence and policy enforcement at the browser layer, not only around application registration.


NHI Mgmt Group analysis

Browser visibility is becoming an identity control point, not a niche security add-on. Once AI tool use happens inside the browser, the control problem moves closer to the session than to the application. That shifts ownership toward identity and access teams, because attribution, policy enforcement, and auditability now depend on whether the browser activity can be tied to a governed identity. Practitioners should treat browser-mediated AI use as part of access governance, not as an adjacent tooling issue.

The compliance gap is not that organisations lack AI policies, but that they cannot prove policy enforcement at the point of use. Policies written for approved applications do not help if the user can reach external AI tools through a browser session that sits outside existing visibility. That is a control failure, not a documentation failure. The practical implication is that evidence collection must move to the interaction layer where the policy decision actually happens.

Ephemeral browser sessions create a runtime governance gap for both human and non-human identities. The same browser path that enables human users to reach AI tools can also carry delegated credentials, session tokens, or embedded automation. That makes the browser a shared enforcement surface across identity types. Practitioners should reassess whether their current controls can distinguish legitimate use from unmanaged data movement before the session closes.

AI regulation will reward organisations that can show session-level accountability, not just application inventory. The market is moving toward proof of control, and browser visibility is one of the few places where that proof can be anchored in real user behaviour. This does not replace IAM or NHI governance, but it exposes where they stop short. Teams should expect browser telemetry to become part of audit evidence for AI use cases.

From our research:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and a further 47% only partial visibility, according to The State of Non-Human Identity Security.
  • That visibility gap helps explain why only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
  • For a broader view of how these blind spots surface in real environments, see 52 NHI Breaches Analysis for repeated patterns of unmanaged access and delayed detection.

What this signals

Browser-mediated AI use will push identity teams toward evidence-based governance. The organisations that can tie session activity to identity, policy, and data handling will be better placed to answer regulators and auditors. The ones that cannot will keep discovering the gap only after data has already crossed the browser boundary.

Session-level accountability is emerging as a named control gap. Browser visibility is not just about detecting abuse, it is about proving that the right identity used the right tool in the right context. That is why browser telemetry will increasingly sit alongside IAM, NHI governance, and acceptable-use controls rather than beneath them.

As more AI interactions move through managed and unmanaged web sessions, practitioners should expect their governance model to become more dependent on runtime evidence than on static approval lists. For teams building that programme, the NHI Lifecycle Management Guide and the Top 10 NHI Issues are useful reference points for aligning access, oversight, and accountability.


For practitioners

  • Map AI use cases to browser-controlled access paths Identify which approved and shadow AI tools are reachable only through browser sessions and which of those paths bypass existing application or network controls. Prioritise the sessions where sensitive data, delegated credentials, or external copilots can be used without a durable audit trail.
  • Separate EDR telemetry from browser-session evidence Document where host telemetry ends and browser interaction evidence begins. Use that gap analysis to define what your audit, investigation, and policy-enforcement teams must capture from the browser itself, especially for SaaS-based AI use.
  • Define AI acceptable-use controls at the session layer Write controls that express where prompts, uploads, copy operations, and tool handoffs are allowed inside browser-mediated AI workflows. Then align those controls with identity ownership so security, IAM, and compliance teams can test them together.
  • Review delegated access paths for browser-mediated automation Check whether browser-based AI tools can inherit credentials, tokens, or session state that were not intended for that interaction. Where delegation exists, require explicit accountability for the identity that initiated the session and the data it can move.

Key takeaways

  • Browser visibility is becoming the place where AI governance, compliance evidence, and identity accountability meet.
  • Traditional IAM and EDR controls do not fully explain what happens inside a browser session once AI tools are in use.
  • Practitioners should move from application-only approval models to session-level evidence and enforcement for AI activity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Browser control affects how access is enforced during active sessions.
NIST Zero Trust (SP 800-207)SP 800-207Zero trust requires continuous verification at the session layer.
OWASP Agentic AI Top 10AI tool use in browsers overlaps with agentic access and prompt-driven data movement.

Assess browser-mediated AI use for tool misuse, prompt injection, and unauthorised data transfer.


Key terms

  • Browser-mediated ai use: Browser-mediated AI use is interaction with AI tools through a web session rather than a managed native application. It matters because prompts, uploads, and delegated actions can happen inside a valid session, leaving identity teams with limited visibility unless they instrument the browser layer directly.
  • Session-level evidence: Session-level evidence is the record of what happened during an authenticated browser session, not just that authentication occurred. It includes user actions, tool access, and data movement, which helps security and compliance teams prove whether policy was actually enforced at the point of use.
  • Browser visibility: Browser visibility is the ability to observe activity inside the user’s browser where applications, data entry, and AI interactions occur. It extends governance beyond login events and endpoint telemetry, giving practitioners a way to connect identity, policy, and behaviour in real time.

Deepen your knowledge

Browser-level AI governance is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is being asked to prove control over AI tool use, the course is a practical starting point.

This post draws on content published by Push Security: AI regulation is here, how browser visibility and control can achieve compliance. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org