Bezpečnost agentů DeepSeek V4 Pro závisí na celém „harnessu“, ne jen na modelu

Organizace, které nasazují agenty postavené na DeepSeek V4 Pro, by neměly hodnotit model izolovaně. Správnou jednotkou posouzení je celá konfigurace model–harness–úkol–prostředí.

Dostupnost modelu přes web, mobilní aplikaci, API, OpenAI Responses API nebo integraci s Codexem může potvrdit kompatibilitu rozhraní. Neříká ale, že se ve všech těchto prostředích shodně chovají systémové prompty, nástroje, oprávnění, paměť, opakování požadavků nebo akce s reálnými dopady.

Praktické pravidlo je jednoduché: schvalovat je třeba konkrétní, verzemi připnutou konfiguraci — a to až poté, co projde vlastním bezpečnostním hodnocením.

Proč harness mění výsledného agenta

Agent není jen jazykový model. Harness, tedy řídicí a běhová vrstva agenta, určuje, jak model dostává instrukce, vybírá nástroje, přistupuje k datům, reaguje na chyby a působí na vnější systémy.

Mezi rozdíly, které mohou zásadně změnit rizikový profil, patří zejména:

• systémové prompty a adaptační vrstvy;
• definice a implementace nástrojů;
• rozsah oprávnění a schvalovací brány;
• kořenové adresáře a síťový přístup;
• zdroje přihlašovacích údajů a identita agenta;
• chování podprocesů a generovaného kódu;
• logika opakování, časových limitů a souběžného zpracování;
• stav relace, sumarizace, mezipaměti a trvalá paměť.

Stejný backend DeepSeek V4 Pro tak může v různých harnessích nebo běhových prostředích vykazovat odlišný bezpečnostní profil. Kompatibilní schéma API je vlastnost integrace, nikoli bezpečnostní certifikace.

Co ukázaly výsledky AgentS4D — a co z nich neplyne

Studie AgentS4D hodnotila celé běhové konfigurace, nikoli pouze izolované odpovědi modelu. Benchmark zahrnoval 328 případů s uměle vloženými riziky napříč čtyřmi harnessy a pěti modelovými backendy, celkem tedy 6 560 sandboxových běhů. Jako nebezpečných označil 4 461 běhů, tedy 68,0 %. U 4 344 běhů, což odpovídá 66,22 %, byla současně vyhodnocena nebezpečnost i dokončení úkolu. 13

Klíčové zjištění zní: úspěšné dokončení úkolu může proběhnout současně s nebezpečným chováním. Agent může vytvořit požadovaný výstup, ale přitom provést zakázanou změnu, nesprávně nakládat s citlivými údaji, obejít zamýšlenou kontrolu nebo způsobit jiný škodlivý vedlejší efekt.

Tato čísla nelze prezentovat jako míru produkčních incidentů DeepSeek V4 Pro. Studie používala záměrně rizikové případy v kontrolovaném sandboxu a výsledky agregovala přes více kombinací modelů a harnessů. V produkci se budou lišit typy úloh, zavedené kontroly, vystavení adversariálnímu obsahu, používaná aktiva i definice škody. Benchmark je důkazem, že bezpečnost běhového prostředí je nutné přímo měřit — nikoli předpovědí toho, co zažije každé nasazení. 135

Omezte nejhorší možný dopad akce agenta

Bezpečnostní opatření by měla zmenšovat následky chyby i v případě, že se model nebo nástroj zachová neočekávaně.

Používejte oddělené identity s minimálními oprávněními

Vytvořte samostatné identity pro agenty, prostředí a jednotlivé zákazníky či tenanty. Vyhněte se automatickému používání zaměstnaneckých přihlašovacích údajů, administrátorského přístupu do produkce a široce použitelných tajemství. Každou identitu omezte na zdroje a operace potřebné pro konkrétní úlohu.

Omezte souborový systém a síť

• Připojujte pouze vyhrazený kořen pracovního prostoru.
• Nesouvisející cesty znepřístupněte, nestačí je pouze skrýt.
• Povolujte konkrétní síťové cíle, metody, porty a podle potřeby i objem odchozího provozu.
• Oddělujte oprávnění pro čtení, přípravu návrhu, zápis do stagingu a zápis do produkce.
• Tajemství ukládejte do brokeru nebo systému s krátkodobými tokeny.
• Dlouhodobé přihlašovací údaje nikdy nevkládejte do promptů, pracovních souborů, proměnných prostředí ani výstupů nástrojů.

Akce s vysokým dopadem — například mazání, publikování, platby, změny přístupů, nasazení nebo komunikace navenek — by měly projít kontrolou v exekuční vrstvě, případně vyžadovat výslovné schválení.

Kontrolujte celý řetězec provádění

Prvotní nástroje jsou jen jednou částí útočné plochy. Vedlejší účinky mohou vytvářet také podprocesy, shellové příkazy, generovaný kód, instalace balíčků, vzdálené servery nástrojů, pluginy nebo kód dovedností.

Na všechny tyto cesty musí platit stejná pravidla. Zejména je nutné zabránit tomu, aby shell nebo generovaný kód obešel omezení souborového systému, sítě, autorizace, logování nebo schvalování.

Nástroje musí vynucovat pravidla mimo model

Volání nástroje vytvořené modelem je nedůvěryhodný požadavek. Autorizaci a bezpečnostní pravidla musí vynucovat server nástroje — nikoli samotný model.

Používejte úzká schémata s kontrolami, jako jsou:

• omezené výčtové hodnoty a limity délky;
• normalizované cesty a jednoznačné identifikátory zdrojů;
• seznamy povolených cílů;
• limity stránkování a velikosti výsledků;
• validace argumentů mimo model;
• autorizace na straně serveru pro konkrétního volajícího, tenanta, cíl a operaci.

Oddělujte plánovací nebo náhledové nástroje od nástrojů, které skutečně mění stav. U destruktivních nebo obtížně vratných operací:

• vyžadujte náhled a potvrzení či schvalovací token;
• pokud možno používejte měkké mazání, karanténu nebo vratné postupy;
• vyžadujte idempotency key, tedy klíč zajišťující bezpečné opakování stejného požadavku;
• předem definujte chování při opakovaném volání;
• vracejte trvalé potvrzení, aby opakování nezpůsobilo stejný efekt podruhé.

Tato opatření jsou důležitá, protože validně vypadající JSON může obsahovat neoprávněný cíl, nebezpečnou cestu, příliš široký rozsah nebo operaci, která má vyžadovat lidskou kontrolu.

Stav a paměť definujte ještě před nasazením

Stav může přenášet riziko mezi jednotlivými koly, úkoly, uživateli i prostředími. Organizace by měly zdokumentovat a vynutit pravidla životního cyklu pro zprávy, nahrané soubory, soubory v pracovním prostoru, shrnutí, výsledky nástrojů, mezipaměti a trvalou paměť.

Minimálně je třeba určit:

• Izolaci: oddělení podle uživatele, tenanta, úkolu a prostředí; žádné implicitní sdílení mezi relacemi.
• Uchovávání: dobu životnosti, šifrování, řízení přístupu a pravidla mazání.
• Reset: zdokumentovaný způsob vymazání kontextu, paměti, stavu pracovního prostoru, přihlašovacích údajů a mezipamětí mezi běhy.
• Opakování a časové limity: omezený počet pokusů a rozpočty; opakování musí zachovat idempotenci a nesmí potichu rozšiřovat oprávnění.
• Souběh: zamykání a řešení konfliktů u sdílených souborů, schválení a externích operací.

Reset stavu berte jako součást bezpečnostní hranice. Pokud se ve vnějším úkolu nečekaně znovu objeví staré instrukce, přihlašovací údaje nebo výsledky nástrojů, může změna modelu či promptu změnit riziko způsobem, který testování pouze finálních odpovědí neodhalí.

Každý nosič rizika považujte za nedůvěryhodný vstup

Prompt injection nemusí přijít přímo ve zprávě uživatele. Instrukce s bezpečnostním rizikem mohou být vloženy do:

• nahraných dokumentů a souborů v repozitáři;
• načtených webových stránek;
• externích dovedností a pluginů;
• odpovědí služeb poskytujících nástroje;
• trvalé paměti;
• shrnutí a obsahu v mezipaměti;
• textu dodaného uživatelem.

Takový materiál parsujte, označujte a citujte jako data. Nesmí měnit autoritu agenta, bezpečnostní pravidla, výběr nástrojů, používání přihlašovacích údajů ani požadavky na schválení. Toto oddělení musí vynucovat runtime, ne pouze schopnost modelu rozpoznat škodlivé instrukce.

Kontrolní seznam pro schválení konkrétního harnessu

Před schválením nasazení zmrazte a zaznamenejte přesnou konfiguraci:

1. Model a směrování: identifikátor a verzi modelu, trasu k poskytovateli, nastavení inference či úrovně úsilí a použité adaptační vrstvy.
2. Chování harnessu: jeho verzi, systémový prompt, logiku relací, pravidla opakování a časových limitů, politiku podprocesů a implementaci paměti.
3. Nástroje a pravidla: definice a verze nástrojů, verze politik, prahy schvalování, autorizační logiku a hranice důvěry vůči serverům nástrojů.
4. Oprávnění: identity, rozsahy, kořeny souborového systému, síťové cíle, zdroje přihlašovacích údajů a cesty umožňující zápis do produkce.
5. Význam stavu: izolaci, uchovávání, reset, chování mezipaměti, souběh a hranice mezi relacemi.
6. Adversariální pokrytí: prompt injection přes každý nosič rizika, pokusy o zmatení pravomocí, úniky přihlašovacích údajů, průchod mimo povolené cesty, SSRF či zneužití odchozího provozu, škodlivé odpovědi nástrojů, duplicitní opakování, otrávení paměti a obejití schvalování.
7. Důkazy: prompty a verze politik, volání a výsledky nástrojů, schválení, rozhodnutí politik, změny v pracovním prostoru, odchozí požadavky, použitou identitu, finální artefakty a výsledek dokončení i bezpečnosti pod stabilním ID běhu.

Dokončení úkolu a bezpečnost skórujte odděleně. Správný finální výstup nesmí vyvážit nebezpečný vedlejší efekt — právě to je ústřední lekce výsledků AgentS4D. 12

Testy opakujte po každé významné změně

Schvalovaným testovacím cílem je připnutá konfigurace, nikoli trvalý štítek typu „agent DeepSeek V4 Pro“. Konfiguračně specifickou sadu testů znovu spusťte po každé podstatné změně:

• modelu nebo trasy k poskytovateli;
• nastavení inference či úrovně úsilí;
• systémového promptu nebo adaptační vrstvy;
• harnessu či logiky relací;
• nástrojů nebo vzdálených serverů nástrojů;
• oprávnění a schvalovacích politik;
• směrování přihlašovacích údajů;
• chování paměti, opakování, časových limitů nebo souběhu;
• síťových či souborových hranic.

Takový přístup mění bezpečnost runtime z obecného předpokladu o kvalitě modelu na měřitelné rozhodnutí o vydání, navázané na přesné prostředí, které může vytvářet skutečné dopady.