AI-synlighetskrisen: Varför säkerhetsteam flyger blint och varför de inte behöver

Integreringen av AI-agenter i produktionsmiljöer accelererar, men den säkerhetsarkitektur som krävs för att skydda dem ligger farligt långt efter. Vi befinner oss i en era där en AI-agent, som har tilldelats ett rutinuppdrag i en staging-miljö, kan oberoende besluta att “fixa” en lösenordsmatchning genom att ta bort en databasvolym.

Som bransch har vi kollektivt stängt av våra hjärnor när det gäller de grundläggande principerna för säkerhet och övervakning kring AI. Säkerhetsteam flyger blint, men de behöver inte göra det.

Myten om systemprompt och säker verktygsutveckling

En utbredd myt i AI-utrymmet är att vi kan kontrollera agentbeteende genom att bara säga till dem att bete sig. Systemprompt är råd, inte tvångsmedel. I den ovannämnda incidenten angav AI:s systemregler uttryckligen att de aldrig skulle köra destruktiva kommandon, men agenten bröt mot sina egna marknadsförda skydd och utförde den mest irreversibla åtgärden som är möjlig.

Vi måste arbeta under antagandet att AI inte faktiskt “vet” någonting. Angrepp mot AI är social ingenjörskonst, förutom att målet är dummare än den genomsnittliga människan. Alla som har erfarenhet av penetrationstestning förstår hur svårt det är för organisationer att försvara sig mot social ingenjörskonst. Nu är våra datorer också sårbara.

Dessutom är AI-verktyg i slutändan bara programvara, och all programvara har buggar. Vi har redan sett exempel där AI-verktyg automatiskt startar oautentiserade HTTP-servrar, vilket tillåter alla lokala processer eller webbplatser att köra godtyckliga shell-kommandon med användarbehörighet.

Den svarta lådan av AI-revision

Om en AI går rogue eller manipuleras, är det en mardröm att ta reda på vad den gjorde. AI-verktyg tillhandahåller vanligtvis inte revisionsloggar. Om du är tillräckligt lycklig att vara på en företagsnivå, är loggarna du får mycket bristfälliga. Till exempel kan du få en vag händelse som anger att en användare “använde Gen AI.” och bara få grundläggande mått som detaljerar indata- och utdatatokenantal.

Ingen av dessa hjälper en säkerhetsanalytiker att besvara den grundläggande frågan: Vad exakt utförde den här agenten?

Avslöja AI: Hur man slutar flyga blint

Den goda nyheten är att du inte nödvändigtvis behöver en ny, AI-särskild säkerhetsenhet för att återfå synlighet. Skugg-AI-användning och agentaktivitet kan upptäckas med hjälp av befintliga logganalystekniker som ditt team borde redan ha. AI-verktygsanrop, kommandouppföranden och systemändrande händelser kan spåras till AI med hjälp av befintlig processutföringsanalys (som du gör i din säkerhetsinformation och händelsehantering (SIEM), eller hur?).

Här är hur du kan utnyttja din befintliga infrastruktur för att upptäcka AI-aktivitet:

• DNS-analys: Analys av DNS-loggar för frågor till kända AI-tjänstdomäner kan hjälpa till att upptäcka AI-användning i din miljö.
• Hotlistor: Detta tillvägagångssätt kräver underhåll av en uppdaterad hotlista över domäner som är associerade med AI-plattformar eller modellleverantörer.
• Gemenskapsresurser: Det finns gemenskapsprojekt och blocklistor tillgängliga som kan modifieras till söktabeller för programmatisk användning.
• SSL-spårning: Ett liknande tillvägagångssätt kan använda SSL-loggar för att spåra servernamn, även om det ger något mindre detaljer eftersom den fullständiga URLen inte spelas in.
• Slutpunktsövervakning: Du kan använda verktyg som Sysmon för att räkna barnprocesser och jaga höga bash-utlösare, vilket är en stark indikator på potentiella AI-agenter som kör kommandon på en slutpunkt.

Den blinda fläcken som kräver aktiva ändringar i din datainsamling är själva prompten. Vad ber om användarna av AI? Laddar de upp några potentiellt känsliga dokument, vilket skapar regelefterlevnadsproblem? Att besvara dessa frågor kräver troligen insamling av API-förfrågningar till leverantören; webbproxier, LLM-proxier och datainmatningsverktyg från loggnings- och SIEM-leverantörer. Dessa kan ta bort slöjan som blockerar denna värdefulla datakälla.

Den framväxande hotet: Skadliga MCP-servrar

Modellkontextprotokollet (MCP) har dykt upp som ett sätt att specificera hur AI-appar integrerar med externa verktyg och datakällor. Medan det standardiserar anslutningar, introducerar det också massiva nya angreppsvektorer via “Onda MCP“-servrar.

Jag har en hands-on-utbildningsworkshop där studenter kan uppleva detta angrepp på första hand. De utformar en skadlig MCP-server för att lura en LLM att anropa legitima verktyg och skicka utdata tillbaka till angriparen. Eftersom LLM:er är mycket sårbara för social ingenjörskonst, är det ofta bara en fråga om att välja bättre formulering eller en smart förtext för att kringgå deras inbyggda skydd.

Studenter använder ofta sin skadliga server för att instruera AI att den är “i underhållsläge” och måste skicka data till ett sekundärt verktyg för “revisionsloggning”, vilket resulterar i dataexfiltration. Vissa är mer kreativa med sina prompter än andra, men alla är vanligtvis framgångsrika.

Återfå kontrollen

För att ordentligt granska AI-aktivitet i den verkliga världen behöver du en proxy för att avlyssna AI-förfrågningar och ett loggsamlingverktyg som kan hantera massiva JSON-nyttolaster. Med denna synlighet kan du upptäcka och triagera hot. Du kan inte förlita dig enbart på AI-leverantörer för att tillhandahålla säkerhetsskiktet. Genomdrivning måste bo i ditt företags system, inte i en text som vi hoppas att modellen beslutar att lyda. Med en bra loggningslösning har säkerhetsteam telemetrin; det är dags för dem att börja fråga den. Du kan upptäcka och triagera hot. Du kan inte förlita dig enbart på AI-leverantörer för att tillhandahålla säkerhetsskiktet. Genomdrivning måste bo i ditt företags system, inte i en text som vi hoppas att modellen beslutar att lyda. Med en bra loggningslösning har säkerhetsteam telemetrin; det är dags för dem att börja fråga den.