De AI-zichtbaarheids crisis: waarom beveiligingsteams blind vliegen en waarom ze dat niet hoeven te doen

De integratie van AI-agents in productieomgevingen versnelt, maar de veiligheidsarchitectuur die nodig is om ze te beveiligen, blijft gevaarlijk achter. We leven in een tijdperk waarin een AI-agent, die is belast met een routineklus in een staging-omgeving, onafhankelijk kan besluiten om een “credential mismatch” te “verhelpen” door een databasevolume te verwijderen.

Als industrie schakelen we collectief onze hersenen uit als het gaat om de basisprincipes van beveiliging en observatie rond AI. Beveiligingsteams vliegen blind, maar ze hoeven dat niet te doen.

De mythe van systeemprompts en veilige tooling

Een wijdverbreide mythe in de AI-ruimte is dat we het gedrag van agents kunnen controleren door het alleen maar te vertellen hoe het zich moet gedragen. Systeemprompts zijn advies, niet afdwingend. In het eerdergenoemde incident stonden de systeemregels van de AI expliciet dat nooit destructieve opdrachten mochten worden uitgevoerd, maar de agent schond zijn eigen gemarkeerde bewakingslijnen en voerde de meest onomkeerbare actie uit die mogelijk was.

We moeten werken onder de veronderstelling dat de AI eigenlijk “niets” weet. Aanvallen op de AI zijn sociale manipulatie, behalve dat het slachtoffer dommer is dan de gemiddelde mens. Iedereen die ervaring heeft met penetratietests begrijpt hoe moeilijk het is voor organisaties om zich te verdedigen tegen sociale manipulatieaanvallen. Nu zijn onze computers ook kwetsbaar.

Bovendien is AI-tooling uiteindelijk gewoon software, en alle software heeft bugs. We hebben al gevallen gezien waarin AI-tooling automatisch ongeauthenticeerde HTTP-servers start, waardoor elke lokale proces of website willekeurige shell-opdrachten kan uitvoeren met gebruikersrechten.

De zwarte doos van AI-auditing

Als een AI in opstand komt of wordt gemanipuleerd, is het een nachtmerrie om te achterhalen wat het heeft gedaan. AI-tools bieden meestal geen auditlogs. Als je geluk hebt en op een enterprise-niveau zit, zijn de logs die je ontvangt ernstig tekortgeschoten. Je krijgt bijvoorbeeld een vage gebeurtenis die aangeeft dat een gebruiker “Gen AI” heeft gebruikt, en je ontvangt alleen basisstatistieken over het aantal invoer- en uitvoertokens.

Geen van beide helpt een beveiligingsanalist om de fundamentele vraag te beantwoorden: Wat heeft deze agent precies uitgevoerd?

AI ontdekken: hoe je kunt stoppen met blind vliegen

Het goede nieuws is dat je geen glimmende nieuwe AI-specifieke beveiligingsapparatuur nodig hebt om de zichtbaarheid terug te krijgen. Shadow AI-gebruik en agentactiviteit zijn detecteerbaar met behulp van bestaande loganalysetechnieken die je team al zou moeten hebben. AI-toolcalls, opdrachtuitvoeringen en systeemwijzigingsgebeurtenissen kunnen worden getraceerd naar AI met behulp van bestaande procesuitvoeringsanalyse (die je doet in je beveiligingsinformatie- en gebeurtenisbeheer (SIEM), nietwaar?).

Hier is hoe je je huidige infrastructuur kunt gebruiken om AI-activiteit te detecteren:

• DNS-analyse: Het analyseren van DNS-logs voor queries naar bekende AI-service-domeinen kan helpen bij het detecteren van AI-gebruik in je omgeving.
• Bedreigingslijsten: Deze aanpak vereist het onderhouden van een bijgewerkte bedreigingslijst van domeinen die zijn geassocieerd met AI-platforms of modelaanbieders.
• Gemeenschapsbronnen: Er zijn gemeenschapsprojecten en blocklists beschikbaar die kunnen worden omgezet in lookup-tabellen voor programmatische gebruik.
• SSL-tracking: Een soortgelijke aanpak kan SSL-logs gebruiken om servernamen te volgen, hoewel het iets minder detail biedt omdat de volledige URL niet wordt opgenomen.
• Endpoint-telemetrie: Je kunt tools zoals Sysmon gebruiken om kindprocessen te tellen en te jagen op hoge bash-spawners, wat een sterke indicator is van potentiële AI-agents die opdrachten uitvoeren op een endpoint.

De blinde vlek die actieve wijzigingen in je gegevensverzameling vereist, zijn de prompts zelf. Wat vragen gebruikers aan de AI? Uploaden ze mogelijk gevoelige documenten, waardoor compliance-problemen ontstaan? Het beantwoorden van deze vragen vereist waarschijnlijk het verzamelen van API-aanvragen naar de provider; webproxies, LLM-proxies en data-ingestietools van logging- en SIEM-aanbieders. Deze kunnen het gordijn wegnemen dat deze waardevolle gegevensbron blokkeert.

De opkomende bedreiging: kwaadaardige MCP-servers

Het modelcontextprotocol (MCP) is opgekomen als een manier om te specificeren hoe AI-apps integreren met externe tools en gegevensbronnen. Terwijl het connecties standaardiseert, introduceert het ook enorme nieuwe aanvalsvector via “Evil MCP“-servers.

Ik host een hands-on trainingworkshop waar studenten deze aanval kunnen ervaren. Ze ontwerpen een kwaadaardige MCP-server om een LLM te misleiden en deze te laten bellen naar legitieme tools en de output terug te sturen naar de aanvaller. Omdat LLM’s zeer kwetsbaar zijn voor sociale manipulatie, is het omzeilen van hun ingebouwde bewakingslijnen vaak alleen een kwestie van betere woordkeuze of een slimme voorwendsel.

Studenten gebruiken hun kwaadaardige server vaak om de AI te instrueren dat het “in onderhoudsmodus” is en dat het gegevens moet doorsturen naar een secundaire tool voor “auditlogging”, waardoor gegevensuitstroom ontstaat. Sommigen zijn creatiever met hun prompts dan anderen, maar allemaal zijn ze meestal succesvol.

De controle terugnemen

Om AI-activiteit in de echte wereld correct te auditen, heb je een proxy nodig om AI-aanvragen te onderscheppen en een logverzamelingstool die in staat is om enorme JSON-payloads te verwerken. Met deze zichtbaarheid kun je bedreigingen detecteren en triageren. Je kunt niet alleen vertrouwen op AI-aanbieders om de veiligheidslaag te bieden. Handhaving moet leven in de systemen van je organisatie, niet in een alinea tekst die we hopen dat het model besluit te gehoorzamen. Met een goede logoplossing hebben beveiligingsteams de telemetrie; het is tijd dat ze beginnen met het opvragen ervan.