AI Visibility and Control (AIVC) – Bitdefender TechZone

Hosted assistants are the path most organizations already worry about. The inventory shows which ones are in use, on which machines, and whether you have marked them as approved, so a filtering decision starts from what your users actually run rather than from a list of well-known domains.

Coding assistants run inside editors that already hold source repositories, and often credentials and configuration files in the same working directory. They are rarely covered by whatever you decided about chat assistants, because nobody classified them as the same kind of tool.

Local model runtimes, MCP servers, and agent frameworks execute on the machine itself. A control that governs which websites an endpoint may reach does not see them at all. The MCP server is the sharpest case: its entire purpose is to hand a model access to something else, and it usually arrives as a configuration entry rather than as an install.

Where an AI tool is configured to connect to a database, a code repository, an internal API, or a third-party model service, that connection is part of your attack surface. AI Visibility and Control records the configured scope of those connections, not the data moving across them.

A developer installs OpenClaw, an open-source framework for AI agents that act on the operating system rather than only answering questions. It arrives as a single-line install command, so it never appears in installed-programs reporting, and it runs with whatever the user granted during setup, often full disk and terminal access. It appears in AI Services under Tools and skills with a risk score, and the finding lists the hosts it was observed on.

What matters is not the framework but what it loads. OpenClaw extends itself with skills, code packages pulled from ClawHub, a public registry, and a malicious skill inherits the permissions the agent already holds. Bitdefender has documented skills that open reverse shells and exfiltrate the plain-text API keys OpenClaw stores in its own configuration file.

From the affected-host set you can confirm scope in Live Search. This is one of the cases where the inventory leads to removal rather than tuning: Bitdefender's guidance is not to run OpenClaw on company devices. Where it is still running, PHASR hardens the workstation by blocking at the level of individual actions rather than whole programs, so the agent can be stopped from decoding obfuscated commands, terminating processes, or making silent outbound transfers while it continues to run.

Filtering AI Services to the Coding category returns the assistants running inside editors across the development team, including the ones that were installed as extensions and never appeared in installed-programs reporting. Reviewing them against what your team has actually approved gives you a short list, and for the hosted ones you can block by domain in Content Control. For the ones you keep, the finding detail shows what each one is configured to reach.

The pattern in both cases is the same. The inventory tells you what exists and what about it is risky; the enforcement decision that follows is a separate, deliberate one.

A developer connects their assistant to the company's internal ticketing system with a Model Context Protocol (MCP) server, a small connector that gives a model access to another system. It is a few lines in a configuration file, so there is no installer, no entry in installed-programs reporting, and no traffic for a network control to inspect. It appears in AI Services with the assets it exposes listed alongside it.

The question the finding answers is not whether the connector exists but what it reaches. A connector pointed at a read-only reporting view is a different exposure from one holding write credentials to a production database, and that difference lives entirely in its configuration. The affected-host list usually settles a second question: whether this is one developer's shortcut or a pattern the whole team copied from the same internal wiki page.

Keeping prompts off a third-party server is a real benefit, and it is why people install local runtimes in the first place. What it changes is the shape of the exposure, not the degree of it. A hosted assistant leaves a record in your web filtering logs; a local runtime leaves nothing there at all because the traffic never crosses the gateway. Furthermore, local runtimes are ordinary software on the endpoint—carrying the same patching and configuration obligations as anything else, but often running without the review a purchased tool would have received.

The score orders your queue; it does not decide the outcome. Approved tools carry findings, and most findings describe how a tool is configured rather than whether it should exist. For example, a coding assistant that was formally approved by your development team but configured with access to every repository on the machine calls for a configuration review, not removal.

A score of 0 means AIVC found nothing risky in how a tool is configured, not that your organization approved it. The score cannot see what makes a tool unacceptable for your organization: an unapproved vendor, where data goes, or what your compliance rules allow. A well-configured assistant that nobody sanctioned is still shadow AI. The score describes the tool; approval is still your decision.

The agent records what AI software is present and how it is configured. It does not read prompts, chat history, or file content. The distinction is practical rather than legal: it is what lets you run the inventory across the estate, instead of waiting on a consultation process that would delay the answer past the point where it was useful.

A license tells you who is accountable for the agent. It does not vet what the agent loads or what it reads. Commercial agents extend themselves through marketplaces and skill registries on the same pattern as open-source ones, and an extension runs with the permissions the agent already holds rather than with permissions of its own.

The second half of the problem is instruction rather than code. An agent that reads a ticket, a web page, or a shared document is reading content someone else may have written, and an agent that acts on what it reads can be steered by it.

This is why the inventory tracks skills and configuration, not only the name of the product. The approved agent and the agent as actually extended on a given endpoint are two different objects.

Vendor review covers the AI you bought as AI. It does not cover the AI that arrived inside something you bought for another reason. A collaboration suite adds a meeting summarizer, a CRM adds a content generator, a ticketing system adds a reply assistant. Each one ships from a vendor already on the approved list, gets enabled by default or by a tenant administrator, and is re-reviewed by nobody — the procurement event that would have triggered a security review happened years earlier, for a product that did something else at the time.

This is a different blind spot from the unmanaged devices below, and the difference decides who fixes it. An unmanaged device is invisible because the agent is not on it. Embedded AI can be invisible on a fully managed endpoint, because the capability runs in the vendor's tenant rather than on the machine: there is no separate AI application installed, no distinct process to observe, and the domain was allowlisted long before the feature existed.

The inventory covers endpoints running the GravityZone agent. Personal phones, contractor laptops, and unmanaged machines are outside its scope—yet browser-reachable assistants are exactly the kind of tool used from those devices. Making unmanaged devices visible is the Network Sensor's job. Knowing which part of the estate the number describes is essential to reporting it accurately.