DeepSeek V4 Pro-agenters sikkerhed afhænger af hele systemet – ikke kun modellen

Organisationer, der vil sætte agenter baseret på DeepSeek V4 Pro i drift, bør vurdere hele konfigurationen model–agentramme–opgave–miljø – ikke modellen isoleret. At modellen kan tilgås via flere grænseflader, viser højst, at en runtime kan kommunikere med den. Det beviser ikke, at prompts, værktøjer, tilladelser, hukommelse, gentagne forsøg eller afledte effekter fungerer ens på tværs af systemerne.

Den praktiske tommelfingerregel er enkel: Godkend kun en konkret, versionsfastlåst konfiguration, når netop den konfiguration har bestået sin egen sikkerhedsevaluering.

Agenten er mere end den underliggende model

En agent består ikke kun af en sprogmodel. Agentrammen – den software, der orkestrerer modellens arbejde – bestemmer blandt andet, hvordan modellen modtager instruktioner, vælger værktøjer, tilgår data, håndterer fejl og påvirker eksterne systemer.

Vigtige forskelle kan ligge i:

• systemprompts og adaptere;
• definitioner og implementationer af værktøjer;
• rettighedsomfang og godkendelseskrav;
• filsystemets rodmapper og netværksadgang;
• kilder til legitimationsoplysninger og identitet;
• underprocesser og adfærd ved genereret kode;
• logik for gentagne forsøg, timeouts og parallelitet;
• sessionsdata, opsummeringer, caches og permanent hukommelse.

Den samme DeepSeek V4 Pro-backend kan derfor have en anden risikoprofil, når den køres gennem en anden agentramme eller i et andet eksekveringsmiljø. En kompatibel API-standard er et integrationskendetegn – ikke et sikkerhedsstempel.

Hvad AgentS4D-resultaterne viser – og ikke viser

AgentS4D evaluerede komplette runtime-konfigurationer frem for isolerede modelsvar. Benchmarktesten omfattede 328 risikoinjicerede cases på tværs af fire agentrammer og fem modelbackends og resulterede i 6.560 sandbox-kørsler. Heraf blev 4.461 kørsler, svarende til 68,0 procent, klassificeret som usikre, mens 4.344 kørsler, svarende til 66,22 procent, både var usikre og blev vurderet som gennemførte. 13

Den centrale pointe er, at en vellykket gennemførelse kan finde sted samtidig med usikker adfærd. En agent kan levere det ønskede resultat og samtidig foretage en forbudt ændring, håndtere følsomme data forkert, omgå en kontrol eller skabe en anden skadelig sideeffekt.

Tallene bør ikke fremstilles som DeepSeek V4 Pros produktionsbaserede hændelsesrate. Evalueringen brugte bevidst risikoinjicerede cases i en kontrolleret sandbox og samlede resultater på tværs af flere model–agentramme-kombinationer. Produktionsopgaver, sikkerhedskontroller, eksponering for fjendtligt indhold, aktiver og definitioner af skade vil være anderledes. Benchmarktesten viser, at sikkerhed i runtime skal måles direkte – ikke hvad enhver implementering nødvendigvis vil opleve i produktion. 135

Begræns konsekvenserne, hvis agenten fejler

Sikkerhedskontroller bør sikre, at fejl bliver så lidt alvorlige som muligt, også hvis modellen eller et værktøj opfører sig uventet.

Brug separate identiteter med mindst mulige rettigheder

Opret særskilte identiteter for agenter, miljøer og lejere. Undgå medarbejderes almindelige legitimationsoplysninger, administratoradgang til produktion og hemmeligheder, der kan genbruges bredt. Begræns hver identitet til de ressourcer og handlinger, der er nødvendige for den konkrete opgave.

Afgræns filsystem og netværk

• Montér kun en dedikeret arbejdsmappe.
• Gør uvedkommende stier utilgængelige i stedet for blot at skjule dem.
• Tillad kun godkendte netværksdestinationer, metoder og porte – og om nødvendigt også en begrænset mængde udgående trafik.
• Adskil læseadgang, kladder, skrivning til staging og skrivning til produktion.
• Opbevar hemmeligheder i en broker eller et system med kortlivede tokens.
• Læg aldrig langlivede legitimationsoplysninger i prompts, arbejdsfiler, miljøvariabler eller værktøjsoutput.

Handlinger med stor konsekvens – eksempelvis sletning, publicering, betalinger, ændring af adgang, deployment eller ekstern kommunikation – bør passere et politikcheck i eksekveringslaget eller kræve en udtrykkelig godkendelse.

Gennemgå hele eksekveringskæden

Førstepartsværktøjer er kun én del af angrebsfladen. Underprocesser, shell-kommandoer, genereret kode, installation af pakker, eksterne værktøjsservere, plugins og såkaldt skill-kode kan også skabe sideeffekter.

Den samme politik skal gælde for alle disse veje. Sørg især for, at shell-kommandoer eller genereret kode ikke kan omgå kontroller for filsystem, netværk, autorisation, logning eller godkendelser.

Gør værktøjer håndhævelige uden for modellen

Et værktøjskald, der er genereret af en model, skal behandles som en ukontrolleret anmodning. Det er værktøjsserveren – ikke modellen – der skal håndhæve reglerne for autorisation og sikkerhed.

Brug snævre skemaer med kontroller som:

• begrænsede enum-værdier og længdegrænser;
• normaliserede stier og eksplicitte ressourceidentifikatorer;
• lister over tilladte destinationer;
• grænser for paginering og resultatstørrelse;
• validering af argumenter uden for modellen;
• serverbaseret autorisation for den konkrete bruger, lejer, destination og handling.

Adskil planlægnings- og preview-værktøjer fra værktøjer, der faktisk ændrer noget. Ved destruktive eller vanskeligt reversible handlinger bør systemet:

• kræve en forhåndsvisning og en bekræftelse eller godkendelsestoken;
• foretrække soft-delete, karantæne eller andre reversible arbejdsgange;
• kræve idempotensnøgler;
• definere, hvad der sker, når den samme anmodning gentages;
• returnere varige kvitteringer, så gentagne forsøg ikke udløser samme effekt flere gange.

Det er nødvendigt, fordi et JSON-værktøjskald, der ser korrekt ud, stadig kan indeholde en uautoriseret destination, en farlig sti, et for stort rettighedsomfang eller en handling, der burde kræve menneskelig kontrol.

Fastlæg reglerne for tilstand og hukommelse før lancering

Tilstand kan føre risiko med sig på tværs af samtaler, opgaver, brugere og miljøer. Organisationer bør dokumentere og håndhæve livscyklusregler for beskeder, uploadede filer, arbejdsfiler, opsummeringer, værktøjsresultater, caches og permanent hukommelse.

Som minimum bør man fastlægge:

• Isolation: Adskil tilstand efter bruger, lejer, opgave og miljø. Tillad ikke implicit deling på tværs af sessioner.
• Opbevaring: Definér levetid, kryptering, adgangskontrol og sletningsregler.
• Nulstilling: Sørg for en dokumenteret måde at rydde kontekst, hukommelse, arbejdsområde, legitimationsoplysninger og caches mellem kørsler.
• Gentagne forsøg og timeouts: Sæt faste grænser for antal forsøg og ressourcebudgetter. Gentagelser skal bevare idempotens og må ikke stille og roligt udvide rettigheder.
• Parallelitet: Fastlæg låsning og konfliktløsning for delte filer, godkendelser og eksterne handlinger.

Betragt nulstilling af tilstand som en del af sikkerhedsgrænsen. Hvis gamle instruktioner, legitimationsoplysninger eller værktøjsresultater uventet kan dukke op i en ny opgave, kan en modelopgradering eller promptændring ændre risikoniveauet på måder, som test af modelsvar alene ikke fanger.

Behandl alle risikobærere som utroværdigt input

Prompt injection behøver ikke komme direkte fra brugerens besked. Risikable instruktioner kan være indlejret i:

• uploadede dokumenter og filer i et repository;
• websider, der hentes ind;
• eksterne skills og plugins;
• svar fra værktøjsservices;
• permanent hukommelse;
• opsummeringer og cachet kontekst;
• tekst leveret af brugeren.

Parsellér, mærk og citer dette materiale som data. Det må ikke kunne ændre agentens autoritet, politik, valg af værktøjer, brug af legitimationsoplysninger eller krav om godkendelse. Runtime-miljøet skal håndhæve adskillelsen i stedet for udelukkende at stole på, at modellen selv genkender ondsindede instruktioner.

Tjekliste før godkendelse af en bestemt agent

Før deployment bør den præcise konfiguration fastfryses og registreres:

1. Model og routing: Modelidentifikator og version, leverandørrute, inferensindstillinger eller effektivitetsniveau samt kompatibilitetsadaptere.
2. Agentrammens adfærd: Version af agentrammen, systemprompt, sessionslogik, regler for gentagne forsøg og timeouts, politik for underprocesser samt implementering af hukommelse.
3. Værktøjer og politikker: Versioner af værktøjsdefinitioner og politikker, godkendelsestærskler, autorisationslogik og tillidsgrænser for værktøjsservere.
4. Rettigheder: Identiteter, rettighedsomfang, filsystemets rodmapper, netværksdestinationer, kilder til legitimationsoplysninger og veje til skrivning i produktion.
5. Tilstand: Isolation, opbevaring, nulstilling, cacheadfærd, parallelitet og grænser mellem sessioner.
6. Fjendtlig testdækning: Prompt injection gennem alle risikobærere, confused-deputy-forsøg, eksponering af legitimationsoplysninger, path traversal, SSRF eller misbrug af udgående trafik, ondsindede værktøjssvar, dubletter ved gentagne forsøg, forgiftning af hukommelse og omgåelse af godkendelser.
7. Dokumentation: Prompts og politikversioner, værktøjskald og resultater, godkendelser, politikafgørelser, ændringer i arbejdsområdet, udgående forespørgsler, anvendt identitet, endelige artefakter samt resultatet for både gennemførelse og sikkerhed under et stabilt kørsels-ID.

Bedøm gennemførelse og sikkerhed separat. Et korrekt slutprodukt må ikke opveje en usikker sideeffekt – det er den centrale lære af AgentS4D-resultaterne. 12

Test igen, når konfigurationen ændres

Det, der skal godkendes, er den fastlåste konfiguration – ikke en permanent etiket som »DeepSeek V4 Pro-agent«. Kør den konfigurationsspecifikke testpakke igen efter enhver væsentlig ændring af:

• model eller leverandørrute;
• inferensindstillinger eller effektivitetsniveau;
• systemprompt eller adapter;
• agentramme eller sessionslogik;
• værktøjer eller eksterne værktøjsservere;
• rettigheds- og godkendelsespolitikker;
• routing af legitimationsoplysninger;
• hukommelse, gentagne forsøg, timeouts eller parallelitet;
• netværks- eller filsystemgrænser.

På den måde bliver runtime-sikkerhed en målbar beslutning om en konkret release i stedet for en bred antagelse om modellens kvalitet – knyttet til præcis det miljø, der kan skabe effekter i den virkelige verden.