Shadow AI Hides Where Your Inventory Doesn't Look

Ask most IT teams which AI tools run on their endpoints and the honest answer is "the ones we blocked." The real footprint is bigger, and most of it never shows up in a software inventory. Bitdefender has added an AI Visibility and Control (AIVC) capability to GravityZone aimed squarely at that gap, and the problem it targets is worth understanding whatever tooling you use.

What happened

Bitdefender published a walkthrough of GravityZone AIVC, a discovery and risk layer for Windows endpoints. It runs as part of the existing risk scan on the GravityZone agent and answers three questions: which AI software is present, who is using it, and how risky its configuration is.

According to the vendor, AIVC:

• Recognizes 50+ AI agents and 70,000+ "skills" — the modular packages pulled from public registries that extend what an agent can do.
• Sorts each discovered service into one of 17 functional categories (LLMs, coding, agents, MCP, local models, and so on) so different reviewers can filter to what they care about.
• Collects configuration metadata only — not prompts, chat history, model weights, credentials or full file contents.
• Gives each service and finding a risk score, the affected endpoints, and mitigation guidance, across two console views: an inventory ("AI Services") and a prioritized risk queue ("AI Findings").

It does not block anything on its own. Enforcement stays with existing controls: web content filtering for browser-based services, custom detection rules (e.g. kill a process by name) for local binaries, and Bitdefender's PHASR hardening, which can profile an AI agent separately from the user running it.

Why it matters

AI reaches a managed laptop through four doors, and traditional controls cover each one only partially:

1. The browser. A chat assistant in a tab installs nothing — there's no program for inventory to find.
2. The IDE. Coding assistants arrive as editor extensions, which aren't "installed programs," yet they sit next to source code, config files and often credentials.
3. Local runtimes. Model runners, agent frameworks and MCP (Model Context Protocol) servers execute on the machine itself. Web filtering never sees them, because the traffic never reaches the gateway.
4. Configured connections. An MCP entry pointing at a database, repo or internal API is often just a few lines in a config file — no installer, no inspectable traffic — yet it is now part of your attack surface.

The MCP case is the sharpest. A connector with read access to a reporting view and one holding write credentials to production look identical from the outside; the difference lives entirely in configuration. The sample findings Bitdefender shows are telling: MCP servers with overly broad filesystem access, servers installed from unofficial sources, unpinned package versions, plaintext HTTP transports and credentials embedded in URLs.

Two points from the walkthrough are worth keeping regardless of vendor. First, a clean risk score is not an approval — a well-configured tool nobody sanctioned is still shadow AI. Second, blocking famous AI domains is not a policy; without knowing what actually runs, administrators end up enforcing against a guess.

What to do

• Inventory beyond installed programs. Include browser AI usage, IDE extensions, local model runtimes, agent frameworks and MCP configuration files in your asset discovery.
• Hunt for MCP configs. Review where developers have wired assistants into ticketing systems, repositories, databases or internal APIs. Check scope (read vs. write), where the server came from, whether its version is pinned, and whether secrets are embedded in config.
• Keep a sanctioned-tools list and compare discovered AI against it — don't rely on "no findings" as permission.
• Treat agent skills/plugins like dependencies. They come from public registries; apply the same supply-chain hygiene you use for npm or PyPI.
• Separate agent and user privileges where your EDR/hardening stack allows it, so an agent gets only what its task requires.
• Enforce with the controls you already have — web filtering, application/process rules, hardening policies — once you know what's actually there.
• Give the SOC the host list. A local runtime or MCP server is a process running outside the browser sandbox; affected-endpoint data is a starting point for hunting, not just a posture metric.

Shadow AI isn't a future problem. It's already on your endpoints — the question is whether you can see it.

Product details summarized from Bitdefender's walkthrough as published by The Hacker News (13.10.2026).