FireAIs säkerhetsblogg

Av FireAI Security & Research Team · Publicerad

Varför slutpunktsdetektering kämpar med en AI-agent som blir oseriös

Varför slutpunktsdetektering kämpar med en AI-agent som blir oseriös

Endpoint Detection and Response har ägnat två decennier åt att svara på en fråga väl: gör den här processen något som skadlig kod skulle göra? Den kontrollerar signaturer, bevakar onormalt beteende och flaggar obehörig privilegieskalering. En AI-agent med verktygsåtkomst bryter premissen för den frågan, inte genom att vara skadlig kod, utan genom att vara ett pålitligt program som kan övertalas att missbruka sin egen, helt legitima, åtkomst.

Före-AI-versionen av detta problem har redan ett namn

Att använda ett legitimt, signerat program för att göra något skadligt är inte nytt. MITER ATT&CK katalogiserar det som System binär proxyexekvering (T1218): "binärfiler signerade med betrodda digitala certifikat kan vanligtvis köras på Windows-system som skyddas av digital signaturvalidering," vilket är exakt varför godkännandelistor och signaturkontroller kämpar när den betrodda binären i sig själv är den som fungerar. En AI-agent utökar samma svaghet till ett program som inte alls behöver förinstalleras med skadlig kod: det kan omdirigeras under körning, med text som det läser.

En kapad agent är en förvirrad ställföreträdare

Den tillämpliga termen här är förvirrat ställföreträdarproblem: "ett datorprogram som luras av ett annat program (med färre privilegier eller mindre rättigheter) att missbruka sin auktoritet." Ge en agent verkliga verktyg, låt den sedan läsa innehåll som du inte vet, och det kan instrueras av det innehållet. Detta är exakt mönstret OWASP:s inmatning för snabb injektion beskriver, och det har redan demonstrerats, inte bara teoretiserat: Invariant Labs Rapport 26 maj 2025 visade en kodningsagent som läste ett vanligt utseende GitHub-problem i ett offentligt arkiv, efter dolda instruktioner i det för att exponera privata arkivdata, med hjälp av verktyg som det var legitimt beviljat. Forskarnas egen slutsats: "det här är inte ett fel i själva GitHub MCP-serverkoden, utan snarare en grundläggande arkitektonisk fråga som måste åtgärdas på agentsystemnivå."

Illustrativt: hur en EDR-loggpost ser ut i båda riktningarna
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling

# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.

Det är den faktiska blinda fläcken: inte en lucka i någon produkt, men det faktum att loggposten för "agent gjorde sitt normala jobb" och "agent kapades för att missbruka sitt normala jobb" kan vara identisk på processnivå. Ingenting om binären förändrades. Ingenting om systemanropsmönstret är nytt. Endast avsikten bakom begäran ändrades, och avsikten är inte ett fält i en processlogg.

Vad minskar egentligen detta, och vad gör det inte

Det är värt att vara exakt om vad personen som namngav detta mönster faktiskt rekommenderar. Simon Willison, som beskrev "dödlig trifecta" med tillgång till privat data, exponering av otillförlitligt innehåll och extern kommunikation tillsammans i en agent, är tydlig att undvika den kombinationen är den verkliga lösningen, inte ett tilläggsräcke: "det enda sättet att förbli säker där är att undvika den dödliga trifecta-kombinationen helt." Han är öppet skeptisk till produkter som påstår sig fånga injicerade instruktioner på ett tillförlitligt sätt i efterhand, och noterar att "vi fortfarande inte vet hur vi till 100 procent på ett tillförlitligt sätt förhindrar att detta händer" och att en fångstgrad på 95 procent är "mycket underkänd" för en säkerhetskontroll.

  • Design först: ge en agent de smalaste verktygen och dataåtkomsten som dess uppgift behöver, så det finns mindre för en framgångsrik injektion att missbruka (den arkitektoniska korrigeringen både Willison och Invariant Labs pekar på).
  • Behandla allt innehåll som agenten läser som du inte har skrivit eller vet, problem, hämtade sidor, nedladdade filer, som otillförlitlig input, i princip varje gång.
  • Där design och granskning inte räcker, är det enda steget som ett dataexfiltreringsförsök inte kan hoppa över en nätverksanslutning. Att se eller begränsa det, per process, hindrar inte en agent från att luras, men det är ett verkligt, oberoende lager som inte är beroende av att känna igen den injicerade instruktionen i första hand.

Var FireAI och HisnLabs kommer in

No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.

FireAI är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.

Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.

Källor