AI apps in the browser expose third-party risk gaps

At a glance

What this is: This is a third-party risk analysis focused on AI apps, browser activity, and OAuth-based access paths, with the key finding that shadow AI is widespread and largely invisible to conventional controls.

Why it matters: It matters because IAM, SaaS security, and identity governance teams must account for browser-mediated AI use, unmanaged integrations, and third-party access that can bypass normal approval and review processes.

By the numbers:

• The average organisation has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use.
• The average organisation has 17 AI OAuth integrations in use.
• The average organisation has 17 AI browser extensions in use.

👉 Read Push Security's analysis of shadow AI and browser-mediated third-party risk

Context

Shadow AI is now a browser and SaaS governance problem as much as it is an application problem. When employees can adopt AI tools through the browser, connect them to work accounts, and grant OAuth access without central review, identity teams lose visibility into who or what can reach corporate data.

For third-party risk programmes, the challenge is no longer simply vendor due diligence. It is understanding the full chain of delegated access that starts with employee self-sign-up, passes through browser-based consent, and ends in tenant-level exposure or uncontrolled data flow.

Key questions

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

A: Security teams should govern Shadow AI by enforcing controls where users actually interact with AI tools, not only at the network edge. That means browser-level inspection, content classification, and policy enforcement for paste, upload, and prompt actions. If users can move sensitive data into an AI tool without a control decision, the governance model is incomplete.

Q: Why do browser extensions create identity governance risk?

A: Extensions can broaden the browser trust boundary by accessing content, modifying pages, or interacting with data that identity teams assume is protected by the browser session. That makes them relevant to both human identity and broader NHI governance, because they can create hidden paths for data access or credential exposure.

Q: What breaks when OAuth consent is used for shadow AI without review?

A: The organisation loses control over delegated access. A user may authorise an AI app to reach mail, files, or other SaaS resources, and that access can persist even after the original business need has changed. Without review, the consent itself becomes a standing risk surface.

Q: Who should own offboarding for third-party AI integrations?

A: Identity, SaaS, and third-party risk teams should share ownership, with a clear revocation step tied to user lifecycle events. If an AI tool is connected to a corporate tenant through OAuth or an extension, offboarding must remove that link as deliberately as any other access grant.

Technical breakdown

Browser-mediated AI adoption creates unmanaged identity pathways

Modern AI use often starts in the browser, where users sign up, log in, and connect tools to work identities without a separate procurement or security checkpoint. That means the control point is not only the app itself, but the browser session, consent flow, and tenant connection that establish access. Once an AI app is connected through OAuth or a browser extension, the real risk becomes scope creep: access can persist beyond the original intent, and security teams may only see the resulting traffic or token grants after the fact.

Practical implication: Map AI app use back to browser-originated identity events, not just application inventories.

OAuth consent turns shadow AI into delegated access risk

OAuth is convenient because it lets a user authorize an app to act on their behalf without sharing a password, but that same delegation model can expose mailboxes, files, chats, and other tenant resources if scopes are excessive. In third-party risk terms, the danger is not only the app name, but the effective privilege it inherits through consent. If the business cannot distinguish harmless AI assistance from broad delegated access, it cannot govern the resulting blast radius.

Practical implication: Review OAuth scopes as access grants, and treat overbroad consent as a governance finding.

Browser telemetry is the missing control plane for shadow AI

Browser security controls can expose the AI tools, extensions, and integrations that never appear in sanctioned inventory systems. That makes telemetry valuable as a discovery layer, but only if it is tied to identity context such as user, tenant, consent, and session. Without that correlation, teams may detect the presence of AI use while still missing what data was accessed, which account authorised it, and whether the access should be revoked.

Practical implication: Correlate browser telemetry with identity and SaaS records before deciding what to block or allow.

Threat narrative

Attacker objective: The attacker wants to inherit legitimate browser-mediated access and use delegated permissions to reach corporate data without triggering traditional perimeter controls.

1. Entry occurs when an employee signs up for an AI app or installs a browser extension in the course of normal work, often using a corporate identity.
2. Escalation occurs when the user grants OAuth consent or extension permissions that extend the tool's effective access into tenant data and connected services.
3. Impact occurs when the third-party app or integration can read, process, or exfiltrate corporate information through the permissions already granted.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-level visibility is now a third-party risk control, not just a user-experience layer. AI adoption is increasingly occurring through the browser, which means the browser has become the practical enforcement point for SaaS and delegated access governance. Organisations that treat browser activity as a secondary telemetry source will miss the actual identity events that matter, including consent, extension installation, and shadow AI use. The implication is that third-party risk programmes must move upstream into the browser session.

Delegated access is the core governance problem behind shadow AI. The issue is not whether an AI app exists, but what permissions it inherits once a user connects it to work systems. OAuth consent, extension scopes, and tenant bindings can turn a lightweight tool into a durable access path. Security teams should therefore evaluate AI apps as identity-bearing third parties rather than as isolated software purchases.

Shadow AI is an NHI problem because the tool often acts with non-human identity-like privileges. Once an AI app is connected to an organisation's tenant, it behaves like a non-human actor consuming access on behalf of the user and possibly beyond the user's original intent. That makes lifecycle questions central: who approved it, what scopes were granted, when should access be revoked, and how is usage recertified? Governance that stops at app discovery will not contain delegated access.

Identity governance must account for consent drift, not just credential theft. Traditional controls assume the danger begins when a secret or password is stolen, but browser-based AI adoption shows that risk can also be created by legitimate, user-approved delegation. The named concept here is consent drift: access that grows or persists beyond the business context in which it was first granted. Practitioners should treat that as a first-class governance issue rather than a convenience trade-off.

Third-party risk management will increasingly depend on tenant-level revocation discipline. If the organisation cannot quickly identify AI apps, browser extensions, and OAuth links tied to a user or tenant, it cannot enforce offboarding or limit exposure after a compromise. This is where SaaS governance, NHI lifecycle controls, and identity reviews converge. The practical conclusion is straightforward: access granted in the browser must be revocable with the same discipline as any other privileged connection.

From our research:

• The average organisation has 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations in use, according to the 2026 Infrastructure Identity Survey.
• The average organisation already has 17 AI browser extensions in use, which means browser-level discovery is now a governance requirement, not an optional control.
• That scale makes the NHI Lifecycle Management Guide relevant for revocation, review, and offboarding discipline across AI-linked access paths.

What this signals

Shadow AI is becoming a lifecycle problem inside the browser. When employees self-adopt AI tools, the real control failure is not just discovery but the inability to recertify and revoke delegated access before it becomes part of day-to-day work. Teams that already manage SaaS and NHI lifecycle controls should extend those processes to browser-originated AI connections, using the NHI Lifecycle Management Guide as the operational baseline.

With 16 AI apps, 17 AI browser extensions, and 17 AI OAuth integrations already present in the average organisation, the governance gap is structural rather than exceptional. Browser telemetry should feed the same identity and access review processes used for SaaS and other non-human access paths, and the OWASP Non-Human Identity Top 10 is a useful lens for evaluating delegated risk.

For practitioners

• Inventory browser-originated AI access paths Build a live inventory of AI apps, browser extensions, and OAuth integrations that originate in employee browsers, then map each item to the user, tenant, and scopes it can reach. Do not rely on procurement records alone.
• Review OAuth scopes as delegated privilege Classify every AI-related OAuth grant by effective access, not by app name. Flag broad mailbox, file, and chat scopes as higher-risk delegated privileges that require recertification or removal.
• Tie offboarding to consent revocation When a user leaves, changes role, or no longer needs a tool, revoke browser-based AI consent and extension access as part of the standard offboarding workflow. Include third-party integrations in the access review queue.
• Use browser telemetry for shadow AI detection Correlate browser telemetry with SaaS tenant logs to identify unsanctioned AI tools that never pass through standard app governance. Use that evidence to decide whether the problem is discovery, policy, or revocation.

Key takeaways

• Shadow AI is creating browser-mediated access paths that identity teams often cannot see or review in time.
• The exposure is already measurable at scale, with multiple AI apps, extensions, and OAuth integrations present in the average organisation.
• Governance has to shift from app discovery to delegated-access control, lifecycle revocation, and browser-based telemetry correlation.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Consent drift: The condition where an action remains technically permitted even though the user’s original consent no longer clearly covers what the agent is doing. It is a governance failure, not just a logging gap, because the workflow can expand beyond its approved boundary while still passing policy checks.
• Browser-mediated identity: Browser-mediated identity is access that is established, maintained, or abused through the web session rather than only through a traditional login boundary. It matters because cookies, tokens, and session state can become attack assets, especially when unmanaged devices and SaaS applications are involved.

What's in the full article

Push Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Telemetry-driven discovery workflow for AI apps, extensions, and OAuth integrations in the browser
• Practical examples of how Push maps browser activity to shadow AI exposure
• The article's broader third-party risk framing across SaaS, extensions, and identity controls
• Implementation-oriented guidance for teams assessing browser-based AI governance

👉 Push Security's full post covers the browser telemetry, AI app inventory, and OAuth exposure details behind this analysis.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security across human and non-human access, it is worth exploring.