DeepSeek V4 Pro är bara så säkert som agentmiljön runt modellen

Organisationer som bygger AI-agenter med DeepSeek V4 Pro bör bedöma en komplett modell–agentramverk–uppgift–miljö-konfiguration, inte modellen isolerat.

Att modellen kan nås via flera gränssnitt visar att den tekniska kommunikationen fungerar. Det bevisar däremot inte att instruktioner, verktyg, behörigheter, minne, omkörningar eller sidoeffekter fungerar likadant i olika körmiljöer.

Den praktiska tumregeln är enkel: godkänn bara en specifikt låst konfiguration efter att just den konfigurationen har klarat sin egen säkerhetsutvärdering.

Agentramverket förändrar den faktiska agenten

En agent är mer än den underliggande språkmodellen. Agentramverket – alltså den programvara som kopplar modellen till verktyg, data och externa system – avgör bland annat hur modellen får instruktioner, väljer verktyg, hanterar fel och kan påverka omvärlden.

Viktiga skillnader kan finnas i:

• systemprompter och adaptrar;
• verktygsdefinitioner och implementationer;
• behörighetsomfattning och krav på godkännande;
• filsystemsrot och nätverksåtkomst;
• källor för inloggningsuppgifter och identitet;
• underprocesser och körning av genererad kod;
• regler för omkörningar, tidsgränser och samtidighet;
• sessionsdata, sammanfattningar, cachar och beständigt minne.

Samma DeepSeek V4 Pro-backend kan därför få en annan riskprofil när den körs genom ett annat agentramverk eller i en annan exekveringsmiljö. Ett kompatibelt API-schema är en egenskap hos integrationen – inte ett säkerhetscertifikat.

Vad AgentS4D-resultaten visar – och inte visar

AgentS4D utvärderade kompletta körkonfigurationer i stället för enbart isolerade modellsvar. Studien använde 328 riskinjicerade testfall över fyra agentramverk och fem modellbackends, vilket gav 6 560 sandboxkörningar. Av dessa rapporterades 4 461 som osäkra, motsvarande 68,0 procent. I 4 344 körningar, eller 66,22 procent, bedömdes körningen både som osäker och slutförd. 13

Det centrala resultatet är att en lyckad uppgift kan sammanfalla med en osäker körning. En agent kan exempelvis skapa den efterfrågade filen eller leveransen, men samtidigt göra en förbjuden ändring, hantera känsliga uppgifter fel, kringgå en kontroll eller orsaka någon annan farlig sidoeffekt.

Siffrorna ska inte beskrivas som DeepSeek V4 Pros incidentfrekvens i produktion. Testerna använde medvetet riskinjicerade fall i en kontrollerad sandbox och slog samman resultaten från flera modell–agentramverkskombinationer. Produktionsmiljöer har andra uppgifter, skydd, angreppsytor, tillgångar och definitioner av skada. Benchmarken visar därför att säkerhet i körmiljön måste mätas direkt – inte vad varje verklig driftsättning kommer att råka ut för. 135

Begränsa den största möjliga konsekvensen

Säkerhetskontroller bör göra misstag mindre allvarliga även när modellen eller ett verktyg beter sig oväntat.

Använd separata identiteter med minsta möjliga behörighet

Skapa separata identiteter för agenter, miljöer och kunder eller hyresgäster. Undvik att ge agenter tillgång till anställdas automatiskt tillgängliga inloggningar, produktionsadministratörers rättigheter eller återanvändbara hemligheter med bred åtkomst.

Begränsa varje identitet till de resurser och operationer som krävs för ett specifikt jobb.

Begränsa filsystem och nätverk

• Montera bara en särskild arbetsyta.
• Gör orelaterade sökvägar otillgängliga, i stället för att bara dölja dem.
• Tillåt endast godkända nätverksdestinationer, metoder och portar samt, där det är relevant, en begränsad mängd utgående trafik.
• Separera läsning, utkast, skrivning i test- eller stagingmiljö och skrivning i produktion.
• Förvara hemligheter i en särskild förmedlingstjänst eller använd kortlivade token.
• Lägg aldrig långlivade inloggningsuppgifter i prompter, arbetsfiler, miljövariabler eller verktygsresultat.

Åtgärder med stor påverkan – exempelvis radering, publicering, betalningar, ändrade åtkomster, driftsättning eller extern kommunikation – bör passera en policykontroll i exekveringslagret eller kräva ett uttryckligt godkännande.

Granska hela kedjan

Förstapartsverktyg är bara en del av attackytan. Underprocesser, skal- och terminalkommandon, genererad kod, paketinstallationer, fjärranslutna verktygsservrar, insticksmoduler och så kallad skill-kod kan också skapa sidoeffekter.

Samma policy måste gälla för samtliga vägar. Förhindra särskilt att skal eller genererad kod kringgår kontroller för filsystem, nätverk, auktorisering, loggning eller godkännande.

Gör verktygen säkra även utanför modellen

Ett verktygsanrop som modellen genererar ska betraktas som en opålitlig begäran. Det är verktygsservern – inte modellen – som måste genomdriva regler för auktorisering och säkerhet.

Använd snäva scheman med kontroller som:

• begränsade uppräkningsvärden och längder;
• normaliserade sökvägar och tydliga resursidentifierare;
• listor över tillåtna destinationer;
• tak för sidindelning och resultatstorlek;
• validering av argument utanför modellen;
• serverbaserad auktorisering för den specifika anroparen, kunden, målresursen och operationen.

Separera planerings- och förhandsvisningsverktyg från verktyg som faktiskt ändrar något. För destruktiva eller svåråterkalleliga åtgärder bör organisationer:

• kräva förhandsvisning och bekräftelse eller en godkännandetoken;
• föredra mjuk radering, karantän eller andra återställbara flöden;
• kräva idempotensnycklar, så att samma begäran inte får olika oönskade effekter vid omkörning;
• definiera vad som händer när samma begäran skickas flera gånger;
• returnera beständiga kvitton så att en omkörning inte upprepar åtgärden.

Detta är viktigt eftersom ett JSON-anrop som ser korrekt ut ändå kan innehålla en obehörig målresurs, en farlig sökväg, alltför omfattande åtkomst eller en operation som kräver mänsklig granskning.

Bestäm hur tillstånd och minne ska fungera

Tillstånd kan föra risk vidare mellan turer, uppgifter, användare och miljöer. Organisationer bör dokumentera och genomdriva livscykelregler för meddelanden, uppladdade filer, arbetsfiler, sammanfattningar, verktygsresultat, cachar och beständigt minne.

Minimikravet bör omfatta:

• Isolering: separera tillstånd per användare, kund, uppgift och miljö. Tillåt inte implicit delning mellan sessioner.
• Lagringstid: fastställ tidsgränser, kryptering, åtkomstkontroll och regler för radering.
• Återställning: tillhandahåll ett dokumenterat sätt att rensa kontext, minne, arbetsytans tillstånd, inloggningsuppgifter och cachar mellan körningar.
• Omkörningar och tidsgränser: sätt tak för antal försök och resursbudget. En omkörning får inte tyst utöka behörigheter och måste bevara idempotens.
• Samtidighet: definiera låsning och konflikthantering för delade filer, godkännanden och externa operationer.

Se återställning av tillstånd som en del av säkerhetsgränsen. Om gamla instruktioner, inloggningsuppgifter eller verktygsresultat oväntat kan dyka upp i en ny uppgift, kan en modelluppgradering eller promptändring påverka risken på ett sätt som tester av enbart modellsvar inte upptäcker.

Behandla alla riskbärare som opålitlig indata

Promptinjektioner behöver inte komma i användarens direkta meddelande. Riskfyllda instruktioner kan vara inbäddade i:

• uppladdade dokument och filer i kodarkiv;
• webbsidor som hämtats in;
• externa skills och insticksmoduler;
• svar från verktygstjänster;
• sparat minne;
• sammanfattningar och cachad kontext;
• text som användaren själv tillhandahåller.

Tolkningsmässigt bör sådant material analyseras, märkas och citeras som data. Det ska inte kunna ändra agentens auktoritet, policy, verktygsval, användning av inloggningsuppgifter eller krav på godkännande. Den separationen bör genomdrivas av körmiljön och inte enbart lämnas åt modellen att upptäcka skadliga instruktioner.

Checklista för en specifik release

Innan en driftsättning godkänns bör den exakta konfigurationen låsas och dokumenteras:

1. Modell och routning: modellens identifierare och version, leverantörsrutt, inferensinställningar eller ansträngningsnivå samt kompatibilitetsadaptrar.
2. Agentramverkets beteende: version, systemprompt, sessionslogik, regler för omkörningar och tidsgränser, policy för underprocesser samt implementation av minne.
3. Verktyg och policyer: definitioner och versioner av verktyg, policyversioner, trösklar för godkännande, auktoriseringslogik och förtroendegränser mot verktygsservrar.
4. Behörigheter: identiteter, åtkomstnivåer, filsystemsrot, nätverksdestinationer, källor för inloggningsuppgifter och vägar som kan skriva i produktion.
5. Tillståndssemantik: isolering, lagringstid, återställning, cachebeteende, samtidighet och gränser mellan sessioner.
6. Adversariell täckning: promptinjektion via alla riskbärare, så kallade confused-deputy-försök, exponering av inloggningsuppgifter, sökvägsmanipulation, SSRF eller missbruk av utgående trafik, skadliga verktygssvar, duplicerade omkörningar, minnesförgiftning och kringgående av godkännanden.
7. Beviskedja: versioner av prompter och policyer, verktygsanrop och svar, godkännanden, policybeslut, skillnader i arbetsytan, utgående anrop, använd identitet, slutliga artefakter samt resultat för både slutförande och säkerhet under ett stabilt körnings-ID.

Poängsätt slutförande och säkerhet separat. En korrekt slutprodukt ska inte kompensera för en osäker sidoeffekt – det är den centrala lärdomen från AgentS4D. 12

Testa om när konfigurationen ändras

Det som ska godkännas är den låsta konfigurationen, inte en permanent etikett som ”DeepSeek V4 Pro-agent”. Kör om den konfigurationsspecifika testsviten efter varje väsentlig förändring av:

• modell eller leverantörsrutt;
• inferensinställningar eller ansträngningsnivå;
• systemprompt eller adapter;
• agentramverkets eller sessionens logik;
• verktyg eller fjärranslutna verktygsservrar;
• behörighets- och godkännandepolicyer;
• routning av inloggningsuppgifter;
• minne, omkörningar, tidsgränser eller samtidighet;
• nätverks- eller filsystemsgränser.

På så sätt blir säkerhet i körmiljön ett mätbart releasebeslut kopplat till den exakta miljö som kan skapa verkliga effekter – inte ett brett antagande om modellens kvalitet.