DeepSeek V4 Pro is niet vanzelf veilig: de agent-harnas bepaalt het risico

Organisaties die agents met DeepSeek V4 Pro inzetten, moeten niet alleen naar het model kijken. De juiste beoordelingseenheid is de volledige model–harnas–taak–omgeving-configuratie. Dat de dienst via meerdere interfaces beschikbaar is, bewijst hooguit dat een runtime met het model kan communiceren. Het bewijst niet dat prompts, tools, rechten, geheugen, herhaalpogingen of externe effecten zich in elke runtime hetzelfde gedragen.

De praktische regel is eenvoudig: keur alleen een vastgelegde configuratie goed nadat juist die configuratie een eigen veiligheidstest heeft doorstaan.

Waarom het harnas de effectieve agent verandert

Een agent is meer dan zijn onderliggende taalmodel. Het harnas bepaalt hoe het model instructies ontvangt, tools kiest, gegevens benadert, fouten afhandelt en invloed uitoefent op externe systemen. Relevante verschillen kunnen zitten in:

• systeemprompts en adapters;
• tooldefinities en toolimplementaties;
• rechtenbereiken en goedkeuringsstappen;
• bestandssysteemroots en netwerktoegang;
• bronnen voor inloggegevens en identiteit;
• subprocessen en door de agent gegenereerde code;
• logica voor retries, time-outs en gelijktijdige uitvoering;
• sessiestatus, samenvattingen, caches en persistent geheugen.

Dezelfde DeepSeek V4 Pro-backend kan daardoor een ander risicoprofiel hebben wanneer hij via een ander harnas of in een andere uitvoeringsomgeving draait. Een compatibel API-schema zegt iets over integratie, niet over veiligheidscertificering.

Wat AgentS4D wel en niet aantoont

AgentS4D beoordeelde complete runtimeconfiguraties in plaats van losse modelantwoorden. De benchmark gebruikte 328 cases met opzettelijk geïnjecteerde risico’s, verspreid over vier agent-harnassen en vijf modelbackends. Dat leverde 6.560 runs in een sandbox op. In 4.461 runs werd onveilig gedrag vastgesteld — 68,0 procent — en 4.344 runs, oftewel 66,22 procent, waren zowel onveilig als volgens de test voltooid. 13

De belangrijkste les is dat een succesvolle taakvoltooiing kan samengaan met onveilige uitvoering. Een agent kan het gevraagde bestand opleveren en ondertussen een verboden wijziging doorvoeren, gevoelige gegevens verkeerd behandelen, een controle omzeilen of een ander ongewenst neveneffect veroorzaken.

Deze percentages mogen niet worden gepresenteerd als het incidentpercentage van DeepSeek V4 Pro in productie. De studie gebruikte doelbewust risicovolle cases in een gecontroleerde sandbox en voegde de resultaten van meerdere model-harnascombinaties samen. Productietaken, beveiligingsmaatregelen, blootstelling aan aanvallende inhoud, bedrijfsmiddelen en definities van schade zullen anders zijn. De benchmark laat zien dat runtimeveiligheid rechtstreeks moet worden gemeten; hij voorspelt niet wat elke productieomgeving zal meemaken. 135

Beperk de maximale schade

Beveiligingsmaatregelen moeten fouten minder ingrijpend maken, ook wanneer het model of een tool zich onverwacht gedraagt.

Werk met afzonderlijke identiteiten en minimale rechten

Maak aparte identiteiten voor agents, omgevingen en tenants. Gebruik geen automatisch beschikbare werknemersaccounts, productiebeheerdersrechten of breed herbruikbare geheimen. Beperk elke identiteit tot de bronnen en handelingen die voor één specifieke taak nodig zijn.

Scherm bestanden en netwerken af

• Koppel uitsluitend een aparte werkmap aan de agent.
• Maak andere paden daadwerkelijk ontoegankelijk in plaats van ze alleen te verbergen.
• Sta uitsluitend goedgekeurde netwerkbestemmingen, methoden en poorten toe en beperk waar relevant ook de hoeveelheid uitgaand verkeer.
• Scheid leesrechten, conceptrechten, schrijfrechten voor staging en schrijfrechten voor productie.
• Bewaar geheimen in een broker of systeem met kortlevende tokens.
• Zet nooit langdurige inloggegevens in prompts, werkmapbestanden, omgevingsvariabelen of tooluitvoer.

Handelingen met grote gevolgen — zoals verwijderen, publiceren, betalingen uitvoeren, toegangsrechten wijzigen, deployen of extern communiceren — moeten door een beleidscontrole in de uitvoeringslaag gaan of expliciete goedkeuring vereisen.

Controleer de volledige uitvoeringsketen

First-party-tools vormen maar een deel van het aanvalsoppervlak. Ook child processes, shellcommando’s, gegenereerde code, pakketinstallaties, externe toolservers, plug-ins en skillcode kunnen neveneffecten veroorzaken.

Laat voor al deze routes hetzelfde beleid gelden. Voorkom in het bijzonder dat shellcommando’s of gegenereerde code de beperkingen voor bestandssysteem, netwerk, autorisatie, logging of goedkeuring omzeilen.

Zorg dat tools buiten het model afdwingbaar zijn

Een door het model gegenereerde toolaanroep is een onbetrouwbaar verzoek. De toolserver — niet het model — moet autorisatie- en veiligheidsregels afdwingen.

Gebruik beperkte schema’s met onder meer:

• begrensde keuzelijsten en maximale veldlengtes;
• genormaliseerde paden en expliciete resource-ID’s;
• allowlists voor bestemmingen;
• limieten voor paginering en resultaatgrootte;
• argumentvalidatie buiten het model;
• server-side autorisatie voor de specifieke aanroeper, tenant, doelbron en handeling.

Scheid tools voor planning of previews van tools die daadwerkelijk effecten uitvoeren. Voor destructieve of moeilijk omkeerbare handelingen:

• eis een preview en bevestiging of goedkeuringstoken;
• geef de voorkeur aan soft delete, quarantaine of omkeerbare workflows;
• gebruik idempotency keys;
• leg vast wat er gebeurt wanneer hetzelfde verzoek opnieuw wordt uitgevoerd;
• geef duurzame ontvangstbewijzen terug, zodat een retry geen effect opnieuw uitvoert.

Deze maatregelen zijn nodig omdat een ogenschijnlijk geldige JSON-toolaanroep toch een ongeautoriseerd doel, een gevaarlijk pad, een te ruime scope of een handeling kan bevatten waarvoor menselijke controle nodig is.

Leg state en geheugen vooraf vast

State kan risico’s meenemen over meerdere beurten, taken, gebruikers en omgevingen. Leg daarom vast hoe berichten, uploads, werkmapbestanden, samenvattingen, toolresultaten, caches en persistent geheugen worden beheerd — en dwing die regels ook af.

Beschrijf minimaal:

• Isolatie: scheid state per gebruiker, tenant, taak en omgeving; laat geen impliciete uitwisseling tussen sessies toe.
• Bewaartermijn: bepaal bewaartermijnen, versleuteling, toegangsbeheer en verwijderingsregels.
• Reset: bied een gedocumenteerde manier om context, geheugen, werkmapstatus, inloggegevens en caches tussen runs te wissen.
• Retries en time-outs: leg aantallen en budgetten vast; retries moeten idempotent blijven en mogen rechten niet stilzwijgend uitbreiden.
• Gelijktijdigheid: definieer vergrendeling en conflictbehandeling voor gedeelde bestanden, goedkeuringen en externe handelingen.

Behandel het resetgedrag van state als onderdeel van de beveiligingsgrens. Als oude instructies, inloggegevens of toolresultaten onverwacht in een nieuwe taak kunnen opduiken, kan een modelupgrade of promptwijziging het risico veranderen zonder dat tests van alleen de uiteindelijke antwoorden dit zichtbaar maken.

Beschouw elke risicodrager als onbetrouwbare input

Promptinjectie hoeft niet in een rechtstreeks gebruikersbericht te staan. Instructies met risico kunnen ook voorkomen in:

• geüploade documenten en repositorybestanden;
• opgehaalde webpagina’s;
• externe skills en plug-ins;
• antwoorden van toolservices;
• opgeslagen geheugen;
• samenvattingen en gecachte context;
• tekst die door gebruikers is aangeleverd.

Parseer, label en citeer dit materiaal als data. Het mag de bevoegdheden, beleidsregels, toolkeuze, het gebruik van inloggegevens of de vereiste goedkeuringen van de agent niet wijzigen. De runtime moet deze scheiding afdwingen; alleen vertrouwen op het vermogen van het model om kwaadaardige instructies te herkennen is onvoldoende.

Releasechecklist per harnas

Leg vóór goedkeuring de exacte configuratie vast:

1. Model en routing: model-ID en versie, providerroute, inferentie-instellingen of inspanningsniveau en compatibiliteitsadapters.
2. Harnาสgedrag: harnasversie, systeemprompt, sessielogica, regels voor retries en time-outs, subprocessbeleid en geheugenimplementatie.
3. Tools en beleid: tooldefinities en versies, beleidsversies, goedkeuringsdrempels, autorisatielogica en vertrouwensgrenzen van toolservers.
4. Rechten: identiteiten, scopes, bestandssysteemroots, netwerkbestemmingen, bronnen van inloggegevens en paden met schrijfrechten naar productie.
5. Stateregels: isolatie, bewaartermijn, reset, cachegedrag, gelijktijdigheid en grenzen tussen sessies.
6. Adversariële dekking: promptinjectie via elke risicodrager, confused-deputy-pogingen, blootstelling van inloggegevens, path traversal, SSRF of misbruik van uitgaand verkeer, kwaadaardige toolantwoorden, dubbele uitvoering door retries, geheugenvergiftiging en het omzeilen van goedkeuringen.
7. Bewijs: prompts en beleidsversies, toolaanroepen en -resultaten, goedkeuringen, beleidsbeslissingen, wijzigingen in de werkmap, uitgaande verzoeken, gebruikte identiteit, eindproducten, voltooiingsresultaat en veiligheidsuitkomst onder een stabiele run-ID.

Beoordeel voltooiing en veiligheid afzonderlijk. Een correct eindproduct mag een onveilig neveneffect niet compenseren — dat is de centrale les van de AgentS4D-resultaten. 12

Test opnieuw na elke relevante wijziging

Het goedgekeurde testdoel is de vastgepinde configuratie, niet een blijvend label zoals ‘DeepSeek V4 Pro-agent’. Voer de configuratiespecifieke tests opnieuw uit na elke materiële wijziging aan:

• het model of de providerroute;
• inferentie-instellingen of inspanningsniveau;
• systeemprompt of adapter;
• harnas- of sessielogica;
• tools of externe toolservers;
• rechten- en goedkeuringsbeleid;
• routing van inloggegevens;
• geheugen-, retry-, time-out- of concurrencygedrag;
• netwerk- of bestandssysteemgrenzen.

Zo wordt runtimeveiligheid geen brede aanname over de kwaliteit van een model, maar een meetbare releasebeslissing die is gekoppeld aan precies de omgeving die effecten in de echte wereld kan veroorzaken.