Cisco slog en klar alarm ved VB Transform 2026: når angribere kan køre en samtale over flere ture, bryder store lukkede modeller langt oftere sammen, end de gør i enkeltskud. I studiet kørte Cisco 6.986 multi‑turn angreb mod 15 proprietære “flagship” modeller og så en maksimal succesrate på 88,3 % (VentureBeat; Cisco‑bloggen). Spændet lå fra 7,89 % til 88,3 % på tværs af modellerne (VentureBeat; Cisco‑bloggen). Og ja, alle testede modeller viste ikke‑triviel eksponering. Det er ikke en nichefejl, det er en frontaldør.
Single‑turn red teaming gav ovenikøbet en anden rangordning end multi‑turn, så et pænt enkelt‑svar siger meget lidt om, hvordan modellen holder til en rigtig modstander (VentureBeat; Cisco‑bloggen). Resultaterne gælder for de 15 testede modeller i den konfiguration Cisco kørte. De kan ikke bare kopieres til alle lukkede modeller eller alle måder at deploye dem på.
Lad os tage metodikken tidligt, så ingen leder efter nåle i høstakken senere. Offentlige kilder frigiver ikke fulde prompt‑sekvenser, temperaturer, sessionlængder, kontekstvinduer eller API‑versioner for hver model (VentureBeat; Cisco‑bloggen). Definitionen af “success” i angrebene er heller ikke fuldt udlagt i det offentlige materiale. Det skaber usikkerhed for reproduktion lokalt og gør fin gradering af risiko sværere. Men hovedretningen er solid, og kilderne stemmer.
Hvad Cisco faktisk målte
Ifølge VentureBeat blev fundene præsenteret af Amy Chang, Ciscos leder for AI‑trusselsintel og sikkerhedsforskning, med Nicholas Conley som medforfatter. Grundlaget var 30.090 single‑turn prompts og 6.986 multi‑turn angreb mod 15 lukkede modeller fra store udbydere (VentureBeat). Cisco beskriver det som en paired‑regime evaluering, hvor samme modeller måles i både enkelt‑ og fleromgangsregimer for at sammenligne sårbarhedsprofilen (Cisco‑bloggen).
De to kilder matcher på mængder og intervaller: single‑turn‑ASR 2,19 % til 64,91 %, multi‑turn 7,89 % til 88,30 % (VentureBeat; Cisco‑bloggen). Kernen i fundet: de to regimer giver ikke samme modelorden, fejlkort eller hale‑risiko. Man kan ikke udlede samtalesikkerhed af et enkelt svar. Punktum.
Hvorfor single‑turn fejler som proxy
I en samtale kan en angriber prøve, aflæse modeladfærden, omformulere og skubbe mod grænserne. Lang kontekst kan få guardrails til at glide en smule tur for tur; instruktionskollisioner kan ophobes. Det er små skub, ikke én hammer. Cisco peger netop på, at multi‑turn blotlægger en anden fejlprofil og hale‑risiko end single‑turn (Cisco‑bloggen).
Helt lavpraktisk ser det sådan ud i et anonymt, forsimplet forløb: 1) Angriber spørger høfligt efter et resumé med en lille, “uskyldig” ekstra detalje. 2) Modellen svarer, men lægger en brik, angriberen kan bygge videre på. 3) Angriber henviser til forrige svar og drejer spørgsmålet en tand mere konkret, måske med et citeret stykke fra modellen selv. 4) Tredje eller fjerde tur: modellen efterkommer en variant, der omgår policys. Det er ikke magi. Bare tålmodig iteration.
Ciscos angreb i praksis
Cisco beskriver et agentisk test‑rammeværk, hvor angriberen itererer over flere runder, evaluerer responsen og justerer næste prompt for at nå et mål (Cisco‑bloggen; VentureBeat). I praksis er målene typisk at få modellen til at dele information, afvige fra instruktioner eller omgå policies – med feedback fra hvert svar, som guider næste skridt. Det er netop den adaptive loop, single‑turn aldrig fanger.
Konsekvenser for implementering og drift
VentureBeats Pulse‑survey fra juni blandt 107 enterprise‑respondenter viser, at 54 % allerede har haft en agent‑sikkerhedshændelse eller et near‑miss (18 % bekræftet, 36 % near‑miss). Stikprøven er lille, men signalet er skarpt (VentureBeat). Samtidig siger kun 32 %, at hver agent har en afgrænset, administreret identitet; 30 % isolerer højrisiko‑agenter i sandboxes; og 82 % læner sig primært op ad provider‑native kontroller (VentureBeat). Det er opskriften på blinde vinkler.
Tre områder vælter først, når multi‑turn glider igennem. Identitet og privilegier: uden mindste privilegium kan et enkelt fejlskridt række vidt. Isolation: uden sandboxes spreder fejl sig hurtigere. Overvågning og respons: uden samtale‑telemetri ser SOC ikke, hvornår en angriber prøver igen på tur 6.
Forsvarslinjer der virker, og hvor de knirker
Start med adaptiv red teaming. Ikke bare én runde. Kør angrebsagenter mod jeres vigtigste use cases og gennemgå mønstre manuelt for at skelne fejl fra støj. Kør det i realistiske testmiljøer med hegn rundt om data og værktøjer.
I arkitekturen: indfør least‑privilege med scoped, managed identities pr. agent. Isolér højrisiko‑agenter i sandboxes med stram netværksadgang. Læg et input‑/output‑sanitiseringslag, der kan stoppe PII og nøglefraser, ikke kun simple regex. Og overvåg prompt‑ og responsmønstre løbende. Ikke kun ved go‑live.
Og så det svære: adversarial training kan hjælpe, men risikerer overpasning, så nye varianter glider igennem. Filtre skal balancere sikkerhed og nytte; hårdt skåret filtrering kvæler hjælperen. Løbende overvågning kræver logning af samtaler, og det rammer hurtigt compliance. Det her er drift, ikke en slide.
Markedets reaktion og hvad det betyder
VentureBeat peger på, at Palo Alto Networks lukkede sit 25 mia. dollar‑køb af CyberArk, CrowdStrike vil betale 740 mio. for SGNL, og Cisco har meldt hensigt om at købe Astrix Security for omkring 400 mio. dollar. Fællesnævneren er identitet, privilegier og forbindelser mellem tjenester (VentureBeat). For indkøb betyder det flere valg i identitetslaget – og skærpede krav.
Krav, der giver mening nu: bed leverandører dokumentere multi‑turn adversarial evaluering eller give adgang til evalueringssignaler. VentureBeat skriver, at Cisco publicerer adversarial signals for 105 modeller; den type data bør vægte i due diligence (VentureBeat).
Telemetri og SOC i praksis
Behandl en agent med værktøjsadgang som en tredjepartsintegration med egne nøgler og stram rækkevidde. Hvert værktøjskald skal kunne spores, rulles tilbage og trigge alarm ved misbrug.
Minimalt logningssæt: session_id, user_id eller caller_id, turn_index, prompt_hash, response_hash, tool_call (navn, parametre, returkode), detected_PII, policy_decision, model_version, latency. Eksempler på alarmer: gentagne grænsesøgninger over flere ture, eksfiltrationsmønstre i output, uventede værktøjssekvenser, store afvigelser i output‑entropi, værktøjskald mod bloklister.
Test og governance uden tjekliste‑træthed
Kør to spor. Et build‑time spor, der fanger fejl før release. Og et produktionsspor, der lærer af virkelige samtaler. AWS beskriver pipelines, hvor kvalitet måles lag for lag – værktøjsvalg, ræsonnement, output – pointen er disciplinen, ikke platformen (AWS‑bloggen). Mål før og efter go‑live, så justeringer sker på data, ikke mavefornemmelse.
Prioriter lige nu og om lidt
0‑30 dage: flyt red teaming til multi‑turn for jeres top‑3 use cases; tænd samtale‑ og værktøjslogning; sæt menneske‑i‑loop på destruktive handlinger; lav et kort register over hver agents API‑tilladelser og nøglers rotation.
30‑120 dage: udsted scoped identities pr. agent og skær tokens til mindste nødvendige. Rul et I/O‑sanitiseringslag ud mod PII og nøglefraser. Byg en eval‑suite med adaptive angrebsagenter og regressionstests ved hver release. Træn SOC i samtaletelemetri og opdater playbooks.
6‑12 måneder: konsolider styring af agentidentiteter, certificér sandboxes som standard, og gør multi‑turn evaluering til change‑krav. Opdatér indkøbsskabeloner med krav om adversarial eval‑signaler eller tredjepartsrapporter for modeller i kritiske flows. Mål hændelser og nærved‑hændelser – ikke kun svartider.
Rapporteringshuller, kort og ærligt
Både Cisco‑bloggen og VentureBeat er klare på retning og tal. Der mangler stadig offentlige detaljer om præcise prompts, temperatur, sessionlængde, kontekstvindue, API‑versioner og hvordan “success” scores. Det begrænser reproduktion og lokal finjustering, men ændrer ikke ved, at single‑turn ikke dækker den faktiske risiko ved agentiske systemer.
Tilbage til virkeligheden
Ciscos tal er tydelige, og VentureBeat sætter dem i kontekst. Multi‑turn er der, hvor det reelle pres ligger på tværs af de testede modeller. Man opdager forskellen, når en hændelse rammer – ikke i et pænt single‑turn regneark.
