AI inzetten in je organisatie klinkt eenvoudig: iemand opent een chatassistent, developers voegen een coding assistant toe aan hun editor en soms draait er zelfs een lokaal model op de werkplek. Alleen… wat je niet ziet, kun je ook niet beheren. Dat is precies waar AI visibility en controle helpt: het geeft security teams een bruikbare inventaris van AI-software en de risico-informatie die je nodig hebt om beleid en handhaving te onderbouwen.
In dit artikel leggen we uit wat er in de praktijk zichtbaar wordt, waarom traditionele software-inventaris dit vaak mist, en hoe je de resultaten koppelt aan bestaande beveiligingsmaatregelen.
Waarom je software-inventaris AI vaak niet ziet
Veel teams hebben inmiddels een lijst van geïnstalleerde applicaties of gestructureerde tooling die onder endpoint- en assetmanagement valt. Maar AI-gebruik ontsnapt daar regelmatig aan. Niet omdat AI ‘onzichtbaar’ is, maar omdat de routes anders zijn dan je bestaande inventarispatronen.
Denk aan vier veelvoorkomende vormen van AI-gebruik:
- AI via de browser: hosted assistenten lopen over webdiensten en komen niet altijd terug in dezelfde categorie als gewone desktopsoftware.
- AI binnen de ontwikkelomgeving: coding assistants zitten als editor-extension en lijken daardoor niet op “een programma” in je lijst.
- Lokaal draaiende AI: local model runtimes, agent frameworks of vergelijkbare componenten draaien direct op het endpoint, vaak met als gevolg dat webfilters niets betekenen.
- AI met verbindingen naar andere systemen: zodra een tool is geconfigureerd om bijvoorbeeld naar een database, repository, interne API of externe modelservice te koppelen, wordt de configuratie onderdeel van je aanvalsvlak.
Het probleem is dus niet alleen “welke tool staat op een pc?”, maar ook hoe die tool is geconfigureerd en welke impact dat kan hebben.
Wat AI visibility en controle concreet ontdekt
Bij Bitdefender GravityZone AI Visibility and Control (AIVC) start de ontdekking tijdens de risicoscan. De aanpak is gericht op metadata: het doel is een inventory van AI-software en een risicoinschatting op basis van configuratie, niet het analyseren van gesprekken of bestanden.
Belangrijke punten:
- Geen inspectie van prompts of chatgeschiedenis. AIVC focust op wat er aanwezig is en hoe het is ingesteld.
- Geen analyse van modelweights of volledige bestandsinhoud. Je krijgt dus geen “content deep dive”, maar wel een inventaris en een risicoperspectief.
- Meer dan alleen agents: AIVC herkent niet alleen AI-agents, maar ook de bijbehorende uitbreidingen (skills). Door skills mee te nemen ontstaat een completer beeld van exposure.
De broninformatie geeft aan dat AIVC meer dan 50 AI-agents en meer dan 70.000 skills kan herkennen. Elke gevonden service wordt bovendien gekoppeld aan een functionele categorie op basis van het primaire doel, met in totaal 17 categorieën. Dat maakt het makkelijker om resultaten te vertalen naar beleid en reviewroutes.
Twee weergaven die aansluiten op je dagelijkse workflow
AI visibility en controle wordt zichtbaar in de GravityZone Console via twee perspectieven. Die sluiten aan op verschillende vragen die teams in de praktijk hebben.
1) AI Services: het volledige beeld
De AI Services-weergave beantwoordt: “Welke AI draait er in mijn omgeving?” Het resultaat is een inventaris met per service details en een risicoscore. Denk hierbij aan informatie zoals categorie, afhankelijkheden en waar de service op is aangetroffen.
Een essentieel nuancepunt: een score van 0 betekent niet automatisch dat je organisatie de tool heeft goedgekeurd. Het betekent alleen dat AIVC niets risicovol heeft gezien in de configuratie. Daarom is het belangrijk om AI Services te vergelijken met je eigen lijst van gesanctioneerde tools, niet alleen naar risicovindingen te kijken.
2) AI Findings: waar je eerst naar moet kijken
De AI Findings-weergave antwoordt: “Welke punten moet ik prioriteren?” Findings worden geordend met een risicoscore en bevatten praktische context zoals de gerelateerde service, getroffen resources en een link naar mitigatieadvies.
Ook handig: een finding vertelt je waarom het op één machine wel en op een andere machine niet is opgepikt. Dat helpt bij besluitvorming, zeker als je te maken hebt met verschillende teams, setupverschillen of uitgerolde configuraties.
In de broncontext wordt benadrukt dat veel beheerders dagelijks met AI Findings werken, en pas later naar AI Services schakelen voor het volledige plaatje van een specifieke tool.
Waarom connectors je beleid kunnen omzeilen (en toch zichtbaar worden)
Een van de meest verrassende valkuilen voor security is dat AI niet altijd als “nieuw programma” aankomt. Soms verschijnt het alleen als configuratiebestand of als een kleine connector die een model toegang geeft tot externe functies.
Een voorbeeld uit de bronbeschrijving: een developer verbindt een AI-assistent met een ticketingsysteem via een Model Context Protocol (MCP)-server. Zo’n connector hoeft meestal niet als geïnstalleerde applicatie in je “programmalijst” te verschijnen en netwerkblokkering op basis van websites kan daardoor ineffectief zijn.
AI visibility en controle brengt dat toch in beeld door de discovery te koppelen aan wat de connector bereikt en welke scope daarbij hoort. Het onderscheid tussen een connector met alleen leesrechten versus een connector die schrijft naar een productieomgeving is daarmee geen gok meer, maar onderdeel van de risicoschatting.
Door ook een lijst met getroffen hosts te tonen, kun je bovendien beoordelen of het om een geïsoleerde test gaat of om een patroon dat breder binnen een team of afdeling is doorgezet.
Van inventaris naar handhaving: risicoscore is geen automatisch besluit
AI visibility en controle levert geen “autopilot” die meteen verwijdert of blokkeert. De kern is dat AIVC een queue ordent met scores op basis van blootstelling en configuratie. Het besluit en de enforcement blijven gekoppeld aan bestaande beveiligingsmechanismen binnen GravityZone.
Concreet werkt dat volgens de broninformatie op drie manieren:
- Toegang blokkeren via webcontent filtering: omdat veel AI services via de browser lopen, kun je op basis van de geïdentificeerde services passende domeinfilters inzetten.
- Custom detection rules: voor specifieke tools kun je regels maken die een matchen op procesnaam en vervolgens acties triggeren zoals “kill process”. Dat kan op company-wide schaal of binnen een scope met endpoint-tags.
- Hardening en PHASR voor AI-agenten: waar het gaat om toestemming en rechten, helpt PHASR om het gedrag van een agent los te beoordelen van de persoon achter het endpoint. Daardoor krijgt de agent de tools die nodig zijn, terwijl de restricties aan de gebruikerrol blijven gekoppeld.
Belangrijk daarbij: schakelen naar AI Visibility and Control vraagt geen volledig migratieproject. In de broncontext staat dat AIVC draait op het bestaande Bitdefender Endpoint Security Tools agent en kan worden ingeschakeld door beleidsinstellingen te wijzigen. De resultaten verschijnen na de eerstvolgende risicoscan.
Waarom dit vooral waardevol is voor SOC en security teams
Veel inventarissystemen zijn sterk in “wat is er geïnstalleerd?”, maar zwakker in “wat kan het doen?”. AI visibility en controle focust daarom op configuratiecontext en het bereik van AI-componenten, inclusief lokaal actieve runtimes en connectoren die niet via de browser lopen.
Daarnaast maakt het SOC-bruikbare karakter van de findings het makkelijker om te pivotten van een finding naar relevante endpoints en om incidentanalyse te onderbouwen met endpoint-specifiek bewijs.
Als je breder kijkt naar AI-gerelateerde risico’s, dan zie je ook dat controle vaak verder gaat dan alleen detectie. Denk bijvoorbeeld aan het belang van afspraken en governance rond identiteiten en agentgedrag. Ter verdieping kun je ook lezen over Bring Your Own Agent en controle via identiteit, omdat dit laat zien hoe permissies en rollen de impact van agenten beïnvloeden.
Praktische instap: zo pak je AI visibility en controle aan
Wil je dit soort aanpak effectief inzetten? Dan helpt een logische volgorde:
- Begin met inventarisatie: kijk eerst naar AI Services om te begrijpen welke AI-tools in gebruik zijn, ook wanneer ze lokaal of via ontwikkelcomponenten binnenkomen.
- Prioriteer via AI Findings: gebruik de risicoscore om te bepalen waar je als securityteam het snelst waarde pakt.
- Vergelijk met je sanctielijst: een score van 0 is geen goedkeuring—check of een tool daadwerkelijk is toegestaan.
- Pas handhaving toe met je bestaande controls: webfilters, detectieregels en hardening/PHASR zijn de plekken waar enforcement thuishoort.
Zo maak je beleid minder afhankelijk van domeinlijsten of aannames en meer afhankelijk van wat je organisatie daadwerkelijk draait.
Conclusie
AI visibility en controle lost een herkenbaar probleem op: AI-software en AI-componenten blijven vaak buiten beeld van traditionele software-inventaris. Door niet alleen te kijken naar browserdiensten, maar ook naar editor-extensions, lokaal draaiende runtimes en connectoren die andere systemen benaderen, krijg je een inventaris én een risicobeeld dat je kunt omzetten naar actie.
De waarde zit daarbij niet alleen in detectie, maar in de vertaling naar governance en enforcement: de risicoscore stuurt prioriteit, terwijl handhaving plaatsvindt met bestaande controls. Daarmee wordt AI-beveiliging praktischer, onderbouwder en beter te verdedigen richting stakeholders.
Bron: https://thehackernews.com/2026/10/product-walkthrough-bitdefender-ai.html
