DeepSeek V4 Pro-agenters sikkerhet avhenger av rammeverket – ikke bare modellen

Organisasjoner som tar i bruk agenter basert på DeepSeek V4 Pro, bør vurdere hele konfigurasjonen av modell, agentrammeverk, oppgave og kjøremiljø – ikke modellen isolert.

At modellen er tilgjengelig via web, mobilapp, API, OpenAI Responses API eller Codex-integrasjon, kan vise at et grensesnitt er kompatibelt. Det beviser ikke at instruksjoner, verktøy, tillatelser, minne, gjentakelser eller bivirkninger fungerer på samme måte i alle miljøer.

Den praktiske hovedregelen er enkel: Godkjenn bare en konkret, fastlåst konfigurasjon etter at akkurat denne konfigurasjonen har bestått sin egen sikkerhetstest.

Agenten er mer enn språkmodellen

Et agentrammeverk – altså laget som kobler modellen til verktøy, data og eksterne systemer – bestemmer mye av agentens faktiske handlingsrom. Det påvirker blant annet hvordan modellen mottar instruksjoner, velger verktøy, håndterer feil og kan endre systemer utenfor seg selv.

Viktige forskjeller kan ligge i:

• systemmeldinger og adaptere;
• definisjoner og implementasjoner av verktøy;
• tillatelsesnivåer og krav om godkjenning;
• tilgang til filsystem og nettverk;
• kilder til identitet og påloggingsinformasjon;
• kjøring av underprosesser og generert kode;
• regler for nye forsøk, tidsavbrudd og samtidighet;
• økttilstand, sammendrag, hurtigbuffere og varig minne.

Den samme DeepSeek V4 Pro-modellen kan derfor få en annen risikoprofil når den kjøres gjennom et annet rammeverk eller i et annet miljø. Et felles API-format er en egenskap ved integrasjonen – ikke en sikkerhetssertifisering.

Hva AgentS4D-undersøkelsen viser

AgentS4D evaluerte komplette kjøretidskonfigurasjoner, ikke bare isolerte modellsvar. Testen omfattet 328 tilfeller med bevisst innførte risikoer, fire agentrammeverk og fem modellbakdeler. Til sammen ga dette 6 560 kjøringer i en sandkasse. 4 461 kjøringer, eller 68,0 prosent, ble klassifisert som utrygge. I 4 344 kjøringer, tilsvarende 66,22 prosent, ble oppgaven både vurdert som fullført og kjøringen som utrygg. 13

Det sentrale funnet er at en oppgave kan bli fullført samtidig som agenten utfører noe utrygt. Agenten kan for eksempel levere riktig resultat, men samtidig gjøre en forbudt endring, behandle sensitive data feil, omgå en kontroll eller skape en annen skadelig bivirkning.

Tallene må ikke fremstilles som DeepSeek V4 Pros hendelsesrate i produksjon. Testen brukte bevisst risikobelastede tilfeller i en kontrollert sandkasse og slo sammen resultater fra flere kombinasjoner av modell og rammeverk. Produksjonssystemer vil ha andre oppgaver, kontroller, angrepsflater, data og definisjoner av skade. Benchmarken viser at sikkerhet i kjøretiden må måles direkte – den er ikke en prognose for hva alle distribusjoner vil oppleve. 135

Begrens konsekvensene når noe går galt

Sikkerhetskontroller bør redusere skadeomfanget også når modellen eller et verktøy oppfører seg uventet.

Bruk egne identiteter med minst mulige privilegier

Opprett separate identiteter for agenter, miljøer og leietakere. Unngå å gi agenten ansattes påloggingsinformasjon, administratoradgang til produksjon eller hemmeligheter som kan brukes bredt. Hver identitet bør bare ha tilgang til ressursene og operasjonene som kreves for den aktuelle jobben.

Begrens filsystem og nettverk

• Monter bare en dedikert arbeidsmappe.
• Gjør uvedkommende filstier utilgjengelige, ikke bare skjulte.
• Tillat bare godkjente nettverksmål, metoder og porter – og ved behov også en grense for utgående datamengde.
• Skill mellom lese-, kladde-, staging- og produksjonsskrivetilgang.
• Oppbevar hemmeligheter i en sikker meglingstjeneste eller bruk kortvarige token.
• Legg aldri langvarige hemmeligheter i ledetekster, arbeidsfiler, miljøvariabler eller verktøyresultater.

Handlinger med stor konsekvens – som sletting, publisering, betalinger, endring av tilgang, utrulling eller ekstern kommunikasjon – bør stanses av en policykontroll i kjøringslaget eller kreve uttrykkelig godkjenning.

Sikre hele kjeden

Førstepartsverktøy er bare én del av angrepsflaten. Underprosesser, skallkommandoer, generert kode, installasjon av pakker, eksterne verktøytjenere, programtillegg og såkalt skill-kode kan også skape bivirkninger.

De samme reglene må gjelde for alle disse veiene. Sørg særlig for at skallkommandoer eller generert kode ikke kan omgå kontrollene for filsystem, nettverk, autorisasjon, logging eller godkjenning.

Verktøy må håndheve reglene utenfor modellen

Et verktøykall generert av modellen må behandles som en forespørsel uten tillit. Det er verktøytjenesten – ikke modellen – som må håndheve autorisasjon og sikkerhetsregler.

Bruk smale skjemaer med kontroller som:

• avgrensede enum-verdier og lengdegrenser;
• normaliserte filstier og eksplisitte ressurs-ID-er;
• lister over godkjente nettverksmål;
• grenser for paginering og resultatstørrelse;
• validering av argumenter utenfor modellen;
• autorisasjon på serversiden for den konkrete innringeren, leietakeren, målressursen og operasjonen.

Skill planleggings- og forhåndsvisningsverktøy fra verktøy som faktisk gjør endringer. For destruktive eller vanskelige å reversere operasjoner bør dere:

• kreve forhåndsvisning og bekreftelse eller et godkjenningstoken;
• foretrekke myk sletting, karantene eller andre reversible prosesser;
• kreve idempotensnøkler;
• definere hva som skjer når samme forespørsel prøves på nytt;
• returnere varige kvitteringer slik at nye forsøk ikke gjentar effekten.

Et JSON-kall som ser gyldig ut, kan fortsatt inneholde et mål uten tillatelse, en farlig filsti, for omfattende tilgang eller en operasjon som burde kreve menneskelig vurdering.

Avklar tilstand og minne før lansering

Tilstand kan føre risiko videre mellom meldinger, oppgaver, brukere og miljøer. Organisasjoner bør dokumentere og håndheve regler for livsløpet til meldinger, opplastede filer, arbeidsfiler, sammendrag, verktøyresultater, hurtigbuffere og varig minne.

Som et minimum bør dere spesifisere:

• Isolasjon: Skill tilstand etter bruker, leietaker, oppgave og miljø. Ikke tillat implisitt deling mellom økter.
• Lagring: Definer levetid, kryptering, tilgangskontroll og sletting.
• Tilbakestilling: Ha en dokumentert metode for å tømme kontekst, minne, arbeidsområde, påloggingsinformasjon og hurtigbuffere mellom kjøringer.
• Nye forsøk og tidsavbrudd: Sett grenser for antall forsøk og ressursbudsjett. Nye forsøk må bevare idempotens og ikke i det skjulte utvide privilegier.
• Samtidighet: Definer låsing og konflikthåndtering for delte filer, godkjenninger og eksterne operasjoner.

Behandle tilbakestilling av tilstand som en del av sikkerhetsgrensen. Hvis gamle instruksjoner, hemmeligheter eller verktøyresultater uventet kan dukke opp i en ny oppgave, kan en modelloppgradering eller endring i systemmeldingen endre risikoen på en måte tester av bare modellsvar ikke fanger opp.

Alt som kan bære risiko, må behandles som upålitelig input

Prompt-injeksjon trenger ikke komme i brukerens direkte melding. Risikable instruksjoner kan være gjemt i:

• opplastede dokumenter og filer i kodearkiv;
• nettsider som hentes inn;
• eksterne skills og programtillegg;
• svar fra verktøytjenester;
• lagret minne;
• sammendrag og hurtigbufret kontekst;
• tekst brukeren selv legger inn.

Parser, merk og siter slikt innhold som data. Det skal ikke kunne endre agentens myndighet, policy, verktøyvalg, bruk av hemmeligheter eller krav om godkjenning. Denne separasjonen må håndheves av kjøretidsmiljøet, ikke bare overlates til modellen.

En sjekkliste for hver konkret konfigurasjon

Før en distribusjon godkjennes, bør den nøyaktige konfigurasjonen låses og dokumenteres:

1. Modell og ruting: Modell-ID og versjon, leverandørrute, inferensinnstillinger eller innsatsnivå og eventuelle kompatibilitetsadaptere.
2. Rammeverkets oppførsel: Versjon, systemmelding, øktlogikk, regler for nye forsøk og tidsavbrudd, policy for underprosesser og minneimplementasjon.
3. Verktøy og policyer: Versjoner av verktøy og policyer, terskler for godkjenning, autorisasjonslogikk og tillitsgrenser mot verktøytjenere.
4. Tillatelser: Identiteter, omfang, filsystemrøtter, nettverksmål, kilder til hemmeligheter og veier som kan skrive til produksjon.
5. Tilstandsregler: Isolasjon, lagring, tilbakestilling, hurtigbuffer, samtidighet og grenser mellom økter.
6. Adversarial testing: Prompt-injeksjon via alle risikobærere, forvirret stedfortreder-angrep, eksponering av hemmeligheter, sti-traversering, SSRF eller misbruk av utgående trafikk, ondsinnede verktøysvar, dupliserte forsøk, forgiftning av minne og omgåelse av godkjenning.
7. Bevis: Versjoner av ledetekster og policyer, verktøykall og resultater, godkjenninger, policyavgjørelser, endringer i arbeidsområdet, utgående forespørsler, brukt identitet, sluttartefakter og resultat for både fullføring og sikkerhet – alt under en stabil kjørings-ID.

Mål fullføring og sikkerhet separat. Et korrekt sluttresultat skal ikke veie opp for en utrygg bivirkning – det er hovedlærdommen fra AgentS4D. 12

Test på nytt når konfigurasjonen endres

Det som skal godkjennes, er den fastlåste konfigurasjonen – ikke en permanent merkelapp som «DeepSeek V4 Pro-agent».

Kjør den konfigurasjonsspesifikke testpakken på nytt etter alle vesentlige endringer i:

• modell eller leverandørrute;
• inferensinnstillinger eller innsatsnivå;
• systemmelding eller adapter;
• rammeverk eller øktlogikk;
• verktøy eller eksterne verktøytjenere;
• tillatelses- og godkjenningspolicyer;
• ruting av hemmeligheter;
• minne-, retry-, tidsavbrudds- eller samtidighetslogikk;
• nettverks- eller filsystemgrenser.

Slik blir sikkerhet i kjøretiden en målbar beslutning knyttet til det nøyaktige miljøet som kan skape virkninger i den virkelige verden – i stedet for en bred antakelse om modellens kvalitet.