Browser extensions are becoming a stealthy API key theft channel

At a glance

What this is: A malicious Chrome extension impersonated ChatGPT, stole OpenAI API keys, and used a secondary channel to exfiltrate them after installation.

Why it matters: IAM and NHI teams need to treat browser extensions as part of the enterprise attack surface because they can intercept secrets after users authenticate them.

By the numbers:

• In total, researchers were able to extract 459 unique API keys, which were provided to OpenAI.
• The extension was last updated June 25th, 2025, and has approximately 10,000 installations.
• In total, we found 25 extensions engaging in malicious or suspicious behavior.

👉 Read Obsidian Security's analysis of browser extensions stealing OpenAI API keys

Context

Browser extensions sit inside a trust gap that many IAM programs still underweight. Users install them inside a normal browser session, grant permissions quickly, and often feed them secrets or tokens without the same scrutiny applied to native software or SSO-integrated applications. That makes browser extensions a practical NHI governance problem, not just a desktop hygiene issue.

In this case, the extension behaved like a legitimate assistant long enough to collect an OpenAI API key, store it locally, and then send it out through a hard-coded Telegram path on a later interaction. That pattern is typical of modern secret theft: the user grants access first, then the compromise happens after trust has been established. The broader finding is that this is not an isolated anomaly but a repeatable abuse model.

The article is strongest when it broadens from one malicious extension to a wider category of prompt poaching and search hijacking. For security architects, the main lesson is that browser add-ons can become unmanaged NHI consumers and exfiltration points even when they look like productivity tools.

Key questions

Q: How should organisations govern browser extensions that handle API keys?

A: Treat them as third-party software with identity and data access. Approve only extensions with a clear business need, restrict installation through browser management, review permissions for storage and cloud access, and rotate any secrets that were entered into an untrusted extension. Browser controls should sit alongside vaulting, SSO, and endpoint policy.

Q: What is the difference between a browser extension risk and a normal SaaS integration risk?

A: A SaaS integration is usually reviewed as a formal connected application with defined scopes and lifecycle controls. A browser extension can be installed informally by a user, then collect secrets from local browser state or page content without the same approval path. That makes its risk harder to see and faster to spread.

Q: When should a security team assume an API key is compromised?

A: Assume compromise whenever a key has been entered into software that later behaves unexpectedly, requests broad permissions, or sends data to an unapproved external service. In practice, that means immediate revocation and rotation, plus a review of downstream automation that might still be using the same secret.

Q: Why do browser extensions create shadow AI risk?

A: Because they can mediate prompts, model access, and secrets outside approved governance channels. If an extension sends prompts to an external server or impersonates a legitimate AI assistant, it is effectively operating as unmanaged AI infrastructure. That is shadow AI whether or not the user intended it.

Technical breakdown

How malicious browser extensions steal API keys

A browser extension runs with the permissions the user grants at install time, which can include access to tabs, page content, storage, and sometimes cloud integrations. In this case, the extension asked for an OpenAI API key, validated it, saved it in local storage, and later retrieved it for exfiltration. The design matters more than the branding: once a secret is copied into extension-controlled storage, the browser boundary no longer protects it. The delayed trigger is also important because it reduces suspicion during first use and lets the extension behave normally before theft starts.

Practical implication: Treat extension permissions and storage access as part of secret handling policy, not just browser preference management.

Why prompt poaching creates NHI governance risk

Prompt poaching is a data handling problem disguised as a convenience feature. The extension forwards user prompts or related data to an external server while presenting itself as a legitimate AI helper, which breaks user expectations about where sensitive content is processed. For NHI governance, the issue is not only theft of credentials but also unauthorised delegation of machine-held context to unapproved endpoints. That makes browser extensions a form of shadow AI infrastructure when they mediate access to models, prompts, and API keys without clear disclosure or control.

Practical implication: Classify AI-facing extensions as data processors and review them with the same scrutiny used for other third-party integrations.

How broad permissions increase the blast radius

The Google Drive example shows how a benign-looking feature can coexist with risky privilege scope. An extension may create one specific folder or function while still holding access to all files and folders in a user’s Drive. That is a classic excess-permission problem: the intended workflow is narrow, but the granted access is broad. In identity terms, the user has effectively issued standing privilege to code that can change behavior after installation. This is why least privilege must be enforced at the permission layer, not inferred from the feature description.

Practical implication: Review browser extension scopes against actual task requirements and remove any extension whose permissions exceed its stated function.

Threat narrative

Attacker objective: The attacker aimed to capture reusable API keys that could be abused for unauthorized model access, data exposure, and downstream cost or policy violations.

1. Entry through a spoofed ChatGPT browser extension that convinced users to enter an OpenAI API key.
2. Credential harvest by storing the key locally and later sending it to a Telegram bot through hard-coded credentials.
3. Impact through unauthorized API usage, prompt and data exposure, and possible account abuse once the key was stolen.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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 extensions have become an NHI trust boundary, not a convenience layer. When an extension can collect, store, and forward API keys, it is acting as an identity-adjacent control point. That makes extension governance part of IAM and NHI management, especially in environments where users routinely copy secrets into browser-based workflows. Practitioners should stop treating extensions as peripheral software and start treating them as secret-handling systems.

Prompt poaching is a shadow AI pattern because it quietly redirects machine-held context. The risk is not limited to stolen keys. It also includes undisclosed transfer of prompts, conversations, and metadata to external servers that users did not approve. Security teams need policy coverage for AI-facing browser tools, because the browser has become a low-friction control plane for unmanaged AI access.

Ephemeral user trust does not equal ephemeral access. A one-time installation can create long-lived exposure if the extension can revisit local storage, reuse session context, or retain cloud permissions. That is a useful concept for the field: the identity blast radius of an extension is often larger than its visible function suggests. Practitioners should validate not just what the extension does today, but what it can still reach tomorrow.

Browser-side secret theft shows why NHI governance must move closer to the user edge. Existing controls often focus on server-side vaults, CI/CD, and service accounts, but this incident starts in the browser where developers and analysts paste keys, prompts, and tokens. The control gap is real: secret handling policy, browser allowlisting, and extension review now belong in the same governance conversation. Teams that ignore the edge will keep rediscovering the same compromise pattern.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader lens on secret exposure pathways, see Guide to the Secret Sprawl Challenge for remediation patterns that extend beyond browser-based theft.

What this signals

Browser-side theft is now part of the NHI lifecycle problem, which means security programmes need to shift some control points closer to the user edge. The lesson is not that vaults are obsolete. The lesson is that secrets can be captured after legitimate use begins, so the governance model must cover storage, browser permissions, and revocation together.

Identity blast radius: a single pasted API key can become a reusable credential for model access, data exposure, and operational abuse. When a browser extension can reuse that key later, the effective privilege persists beyond the user’s original action. Teams should map which browser tools can touch secrets and treat that scope as part of access review.

The pattern here aligns with broader secret sprawl trends, including 24,008 unique secrets exposed in MCP configuration files in 2025 alone in our research. That scale suggests browser compromise is not an edge case but another distribution channel for the same underlying problem. Practitioners should prepare for extension governance to join vaulting, code scanning, and endpoint policy as a standard control set.

For practitioners

• Inventory browser extensions with secret-handling privileges Build an inventory of approved extensions across managed endpoints, then flag any add-on that can read page content, access storage, or interact with cloud files. Prioritize tools used by developers, analysts, and support staff because they are most likely to handle API keys and prompts.
• Block unreviewed AI-facing extensions at the browser layer Use browser management and endpoint controls to restrict installation of extensions that impersonate AI tools or route prompts to external servers. Require review for any extension that interacts with chat windows, side panels, or model APIs before it can be deployed.
• Revoke and rotate exposed API keys immediately If a key is entered into an extension that cannot be fully trusted, assume exposure and rotate it before further use. Tie rotation to revocation of any related tokens and check whether the key was used in automation or shared across environments.
• Limit Google Drive and similar broad scopes Compare the extension’s stated function with the actual permissions requested, especially if it asks for all-files access when it only needs a narrow backup folder. Remove broad scopes that are not essential to the task and review them on a recurring schedule.

Key takeaways

• Browser extensions can function as identity-adjacent systems when they collect and forward API keys from user sessions.
• Prompt poaching expands the risk beyond credential theft because it can redirect prompts and data to external servers without clear disclosure.
• Security teams should govern AI-facing extensions like third-party integrations, with permission review, secret rotation, and browser allowlisting.

Key terms

• Prompt Poaching: Prompt poaching is the covert capture and forwarding of user prompts, conversations, or related context to an unapproved external system. In browser and AI tooling, it often hides behind a legitimate-looking interface, turning user trust into an unwitting data transfer path.
• Browser Extension Blast Radius: Browser extension blast radius is the amount of data, identity context, and connected services an extension can reach if it is compromised. It depends on permissions, stored tokens, and linked accounts, not just the extension’s advertised feature set.
• Shadow AI: Shadow AI is the use of AI-enabled tools, agents, or integrations outside approved governance and visibility. It becomes a security problem when those tools can access prompts, secrets, or enterprise data without review, logging, or revocation controls.
• Identity-adjacent Control Point: An identity-adjacent control point is a component that can handle secrets, tokens, or authentication context even if it is not a formal IAM system. Browser extensions, side panels, and add-ons fit this category because they can intercept or reuse credentials after the user authenticates.

Deepen your knowledge

Browser-side secret handling and extension governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring browser-originated NHI risk into scope, it is worth exploring.

This post draws on content published by Obsidian Security: Small Tools, Big Risk, When Browser Extensions Start Stealing API Keys. Read the original.