LayerX Report: AI Extensions - The Unmonitored Consumption Channel
Hey team,
Saw the LayerX report drop today regarding AI browser extensions acting as a silent consumption channel. We spend so much time blocking the ChatGPT UI at the proxy level that we've ignored the backdoor sitting right in the user's browser.
The report highlights that these extensions aren't just risky due to malicious code; they're risky by design. "Helper" extensions that summarize emails or web pages are scraping sensitive context and sending it to third-party LLM endpoints, completely bypassing our DLP controls. Since the traffic is browser-initiated to legitimate API domains (like OpenAI or Anthropic), standard egress filtering often misses it.
I've started auditing our fleet for extensions with overly broad permissions. Here's a quick PowerShell snippet to enumerate installed extensions for Chrome to cross-reference with your allow-list:
$extensi
if (Test-Path $extensionsPath) {
Get-ChildItem $extensionsPath -Directory | ForEach-Object {
$manifest = Join-Path $_.FullName "*\manifest."
if (Test-Path $manifest) {
$data = Get-Content $manifest | ConvertFrom-Json
[PSCustomObject]@{
Name = $data.name
Version = $data.version
Permissions = $data.permissions -join ', '
}
}
}
}
The scary part is that most of this traffic looks like standard API calls. How are you guys handling this? Are you straight-up blocking all extensions, or have you found a way to inspect the LLM-bound payloads?
We moved to a strict allow-list via Group Policy (ExtensionInstallAllowlist) last quarter. It was painful initially—lots of complaints about PDF converters and grammar checkers—but the risk of data exfil via "free" AI tools was too high. We allow about 15 whitelisted extensions corp-wide. Anything else requires a security review, which usually kills the request.
The proxy inspection route is tricky with TLS 1.3 and ECH. I've been looking at on-device behavioral analysis instead. If an extension starts reading DOM elements from specific internal apps (like our HRIS or Jira) and then makes outbound HTTP requests to non-corporate IPs, we trigger an alert in our EDR.
Solid analysis. While allow-listing is ideal, it often misses BYOD or contractor devices. We've pivoted to monitoring DNS for direct API calls. If a client resolves an LLM API domain without visiting the sanctioned UI, it’s a clear red flag for an active extension.
Here’s a quick KQL query we use to catch this behavior:
DnsEvents
| where Name contains "api.openai"
| summarize count() by SrcIp, Bin(TimeGenerated, 5m)
| join kind=inner (NetworkEvents | where RemoteUrl !contains "chatgpt.com") on SrcIp
It helps us pinpoint the compromised host immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access