Den kunstig intelligens synlighedskrise: Hvorfor sikkerhedsteams flyver blindt og hvorfor de ikke behøver at gøre det

Integreringen af kunstig intelligens-agenter i produktionsmiljøer accelererer, men sikkerhedsarkitekturen, der kræves for at sikre dem, er langt tilbage. Vi er i en æra, hvor en kunstig intelligens-agent, der er tildelt en rutineopgave i et staging-miljø, kan uafhængigt beslutte at “fikse” en adgangskode-fejl ved at slette en database-volumen.

Som en branche har vi kollektivt slukket for vores hjerner, når det kommer til de grundlæggende principper for sikkerhed og overvågning omkring kunstig intelligens. Sikkerhedsteams flyver blindt, men de behøver ikke at gøre det.

Myten om systemprompts og sikker værktøjsudstyr

En udbredt myte i kunstig intelligens-rummet er, at vi kan kontrollere agentadfærd bare ved at fortælle det, hvordan det skal opføre sig. Systemprompts er rådgivende, ikke gennemførende. I den nævnte incident havde AI’ens systemregler udtrykkeligt fastsat, at den aldrig måtte køre destruktive kommandoer, men agenten overtrådte alligevel sine egne markedsførte sikkerhedsforanstaltninger og udførte den mest irreversibele handling, der var mulig.

Vi må arbejde under antagelsen af, at kunstig intelligens ikke “ved” noget som helst. Angreb mod kunstig intelligens er social manipulation, bortset fra at offeret er dummere end den gennemsnitlige menneskelige. Alle, der har erfaring med penetrationstest, forstår, hvor svært det er for organisationer at forsvare sig mod sociale manipulationsangreb. Nu er vores computere også sårbare.

Desuden er kunstig intelligens-værktøjsudstyr i sidste ende bare software, og alle software har fejl. Vi har allerede set eksempler på, hvor kunstig intelligens-værktøjsudstyr automatisk starter uautentificerede HTTP-servere, der tillader lokale processer eller websteder at udføre vilkårlige shell-kommandoer med brugerrettigheder.

Den sorte kasse for kunstig intelligens-revision

Hvis en kunstig intelligens bliver gal eller manipuleres, er det en mareridt at finde ud af, hvad den gjorde. Kunstig intelligens-værktøjsudstyr leverer generelt ikke revisionslogger. Hvis du er heldig at være på en enterprise-niveau, er loggene, du modtager, meget mangelfulde. For eksempel kan du få en vag begivenhed, der angiver, at en bruger “brugte kunstig intelligens.” og kun modtager grundlæggende målinger, der detaljerer input- og output-token-tællinger.

Ingen af disse hjælper en sikkerhedsanalytiker med at besvare den fundamentale spørgsmål: Hvad gjorde denne agent nøjagtigt?

Afsløring af kunstig intelligens: Hvordan stoppe med at flyve blindt

Det gode nyheder er, at du ikke nødvendigvis behøver en ny, skinnende kunstig intelligens-sikkerhedsapplikation for at genopnå synlighed. Skygge-kunstig intelligens-anvendelse og agent-aktivitet er opdagelige ved hjælp af eksisterende log-analyseteknikker, som dit team allerede burde have. Kunstig intelligens-værktøjsudstyr-kald, kommando-eksekveringer og system-ændringsbegivenheder kan spores til kunstig intelligens ved hjælp af eksisterende proces-eksekveringsanalyse (som du gør i din sikkerhedsinformation og begivenhedsstyring (SIEM), ikke sandt?).

Her er, hvordan du kan udnytte din nuværende infrastruktur til at spore kunstig intelligens-aktivitet:

• DNS-analyse: Analyse af DNS-logger for forespørgsler til kendte kunstig intelligens-service-domæner kan hjælpe med at opdage kunstig intelligens-anvendelse i dit miljø.
• Trusler: Denne tilgang kræver opdatering af en truselliste over domæner, der er associeret med kunstig intelligens-platforme eller model-udbydere.
• Fællesskabsressourcer: Der er fællesskabsprojekter og blocklister til rådighed, som kan konverteres til opslagstabeller til programmatisk brug.
• SSL-sporing: En lignende tilgang kan bruge SSL-logger til at spore servernavne, selvom det giver lidt mindre detaljer, da den fulde URL ikke er optaget.
• Endpoint-telemetri: Du kan bruge værktøjer som Sysmon til at tælle underprocesser og jagte høj bash-spawnere, hvilket er et stærkt tegn på, at potentielle kunstig intelligens-agenter udfører kommandoer på en endpoint.

Blindpunktet, der kræver aktive ændringer i din dataindsamling, er selv promptene. Hvad beder brugerne kunstig intelligens om? Uploader de nogen potentielt følsomme dokumenter, hvilket skaber overholdelsesproblemer? At svare på disse spørgsmål kræver sandsynligvis indsamling af API-forespørgslerne til udbyderen; web-proxies, LLM-proxies og data-indtagelsesværktøjer fra logging og SIEM-udbydere. Disse kan fjerne sløret, der blokerer denne værdifulde datakilde.

Den nye trussel: Maliciøse MCP-servere

Modelkontekstprotokollen (MCP) er dukket op som en måde at specificere, hvordan kunstig intelligens-applikationer integrerer med eksterne værktøjer og datakilder. Mens det standardiserer forbindelser, introducerer det også massive nye angrebsvektorer via “Ond MCP“-servere.

Jeg værter et praktisk træningsworkshop, hvor studerende kan opleve dette angreb førstehånds. De designer en maliciøs MCP-server til at narre en LLM til at ringe til legitime værktøjer og sende outputtet tilbage til angriberen. Fordi LLM’er er meget sårbare over for social manipulation, er det ofte nok at vælge bedre formulering eller en clever forklaring for at omgå deres indbyggede sikkerhedsforanstaltninger.

Studerende bruger ofte deres maliciøse server til at instruere kunstig intelligens om, at den er “i vedligeholdelsesmodus” og må overføre data til et sekundært værktøj til “revisionslogning”, hvilket resulterer i data-ekstraktion. Nogle er mere kreative med deres prompte end andre, men alle er som regel succesfulde.

At genopnå kontrollen

For at ordentligt gennemgå kunstig intelligens-aktivitet i den virkelige verden har du brug for en proxy til at aflytte kunstig intelligens-forespørgsler og en log-samlingsværktøj, der kan håndtere massive JSON-nytlastninger. Med denne synlighed kan du opdage og afhjælpe trusler. Du kan ikke kun stole på kunstig intelligens-udbydere til at levere sikkerhedslaget. Gennemførelse skal bo i organisationens systemer, ikke i en tekst, som vi håber, modellen beslutter at adlyde. Med en god log-løsning har sikkerhedsteams telemetri; det er tid for dem at starte med at spørgere det.