Organisaatioiden kannattaa arvioida DeepSeek V4 Pro -agentteja kokonaisuutena: malli–agenttikehys–tehtävä–ympäristö-kokoonpanona, ei vain yksittäisen kielimallin perusteella. Se, että sama malli on käytettävissä esimerkiksi verkossa, mobiilisovelluksessa, API-rajapinnan kautta tai Codex-integraatiossa, osoittaa ensisijaisesti rajapintojen yhteensopivuutta. Se ei todista, että kehotteet, työkalut, käyttöoikeudet, muisti, uudelleenyritykset tai ulkoiset vaikutukset toimisivat eri suoritusympäristöissä samalla tavalla.

Käytännön sääntö on yksinkertainen: hyväksy vain tarkasti lukittu kokoonpano, joka on läpäissyt oman turvallisuusarviointinsa.

Miksi agenttikehys muuttaa agentin toimintaa?

Agentti on enemmän kuin sen taustalla oleva malli. Agenttikehys eli harness määrittää, miten malli saa ohjeita, valitsee työkaluja, käsittelee tietoja, reagoi virheisiin ja vaikuttaa ulkoisiin järjestelmiin.

Merkittäviä eroja voivat olla esimerkiksi:

• järjestelmäkehotteet ja sovittimet;
• työkalujen kuvaukset ja toteutukset;
• käyttöoikeuksien laajuus ja hyväksyntäportit;
• tiedostojärjestelmän juuret ja verkkoyhteydet;
• tunnistetietojen lähteet ja käytetty identiteetti;
• aliprosessien ja tuotetun koodin suoritus;
• uudelleenyritysten, aikakatkaisujen ja rinnakkaisuuden logiikka;
• istunnon tila, tiivistelmät, välimuistit ja pysyvä muisti.

Siksi sama DeepSeek V4 Pro -taustamalli voi muodostaa erilaisen riskiprofiilin, kun se liitetään eri agenttikehykseen tai suoritusympäristöön. Yhteensopiva API-skeema kertoo integraatiosta – ei turvallisuussertifioinnista.

Mitä AgentS4D-tulokset kertovat?

AgentS4D arvioi kokonaisia suoritusympäristöjä yksittäisten mallivastausten sijaan. Hiekkalaatikkotestissä oli 328 tarkoituksellisesti riskiä sisältävää tapausta, neljä agenttikehystä ja viisi mallitaustaa. Näistä muodostui 6 560 suoritusta. Vaarallisiksi luokiteltiin 4 461 suoritusta eli 68,0 prosenttia, ja sekä vaarallisiksi että loppuun suoritetuiksi 4 344 suoritusta eli 66,22 prosenttia. 13

Keskeinen havainto on, että onnistunut tehtävän suoritus voi tapahtua vaarallisen toiminnan rinnalla. Agentti voi esimerkiksi tuottaa pyydetyn tiedoston, mutta samalla tehdä kielletyn muutoksen, käsitellä arkaluonteisia tietoja väärin, ohittaa aiotun kontrollin tai aiheuttaa muun haitallisen sivuvaikutuksen.

Lukuja ei pidä tulkita DeepSeek V4 Pron tuotantokäytön häiriö- tai vaaratilastoksi. Testissä käytettiin tarkoituksellisesti riskiä sisältäviä tapauksia valvotussa hiekkalaatikossa, ja tulokset koottiin useista malli–agenttikehys-yhdistelmistä. Tuotannon tehtäväjakauma, kontrollit, altistuminen vihamieliselle sisällölle, käytössä olevat resurssit ja haitan määritelmät voivat olla erilaisia. Tutkimus osoittaa, että suoritusympäristön turvallisuus on mitattava erikseen – se ei ennusta sellaisenaan jokaisen käyttöönoton tuloksia. 135

Rajaa agentin toiminnan mahdolliset seuraukset

Turvallisuuskontrollien pitäisi pienentää virheiden seurauksia silloinkin, kun malli tai työkalu toimii odottamattomasti.

Käytä erillisiä, vähäoikeuksisia tunnuksia

Luo erilliset identiteetit agenteille, ympäristöille ja asiakkaille tai vuokraajille. Älä anna agentille työntekijän automaattisia tunnuksia, tuotantoympäristön ylläpitäjän oikeuksia tai laajasti uudelleenkäytettäviä salaisuuksia. Rajaa jokainen identiteetti vain tietyn tehtävän tarvitsemiin resursseihin ja toimintoihin.

Rajoita tiedostot ja verkko

• Liitä agentille vain erillinen työtilan juurihakemisto.
• Tee muut polut saavuttamattomiksi sen sijaan, että ne vain piilotettaisiin.
• Salli verkossa vain ennalta määritetyt kohteet, menetelmät, portit ja tarvittaessa myös liikenteen määrä.
• Erota luku-, luonnos-, vaiheistus- ja tuotantoon kirjoittamisen oikeudet.
• Säilytä salaisuudet välityspalvelussa tai lyhytikäisten tunnusten järjestelmässä.
• Älä koskaan sijoita pitkäikäisiä tunnistetietoja kehotteisiin, työtilan tiedostoihin, ympäristömuuttujiin tai työkalujen tulosteisiin.

Poistaminen, julkaiseminen, maksaminen, käyttöoikeuksien muuttaminen, käyttöönotot ja ulkoinen viestintä ovat esimerkkejä korkean vaikutuksen toiminnoista. Niiden tulee kulkea suorituskerroksen politiikkatarkistuksen kautta tai vaatia nimenomainen hyväksyntä.

Tarkista koko suoritusketju

Ensimmäisen osapuolen työkalut ovat vain yksi osa hyökkäyspintaa. Sivuvaikutuksia voivat aiheuttaa myös aliprosessit, komentotulkki, tuotettu koodi, pakettien asennus, etätyökalupalvelimet, liitännäiset ja agentin käyttämät taidot tai lisäosat.

Saman politiikan on koskettava kaikkia näitä reittejä. Erityisesti komentotulkin tai tuotetun koodin suoritus ei saa ohittaa tiedosto-, verkko-, valtuutus-, lokitus- tai hyväksyntäkontrolleja.

Tee työkaluista valvottavia mallin ulkopuolella

Mallin tuottama työkalukutsu on epäluotettu pyyntö. Työkalupalvelimen – ei mallin – on valvottava valtuutusta ja turvallisuussääntöjä.

Käytä suppeita skeemoja ja esimerkiksi seuraavia rajoituksia:

• rajatut luetteloarvot ja merkkipituudet;
• normalisoidut polut ja yksiselitteiset resurssitunnisteet;
• sallittujen kohteiden luettelot;
• sivutuksen ja tuloskoon ylärajat;
• argumenttien tarkistus mallin ulkopuolella;
• palvelinpuolen valtuutus juuri kyseiselle kutsujalle, asiakkaalle, kohteelle ja toiminnolle.

Erota suunnittelu- ja esikatselutyökalut vaikutuksia aiheuttavista työkaluista. Tuhoisissa tai vaikeasti peruttavissa toiminnoissa:

• vaadi esikatselu sekä vahvistus tai hyväksyntätunnus;
• suosi pehmeää poistoa, karanteenia tai muutoin peruttavia työnkulkuja;
• käytä idempotenssiavaimia eli tunnisteita, joiden avulla sama pyyntö voidaan tunnistaa uudelleen;
• määritä, mitä tapahtuu, jos sama pyyntö yritetään uudelleen;
• palauta pysyvä kuitti, jotta uudelleenyritys ei toista vaikutusta.

Kontrollit ovat tarpeen, koska oikean näköinen JSON-työkalukutsu voi silti sisältää luvattoman kohteen, vaarallisen polun, liian laajan käyttöoikeuden tai toiminnon, joka pitäisi ohjata ihmisen tarkistettavaksi.

Määritä tila ja muisti ennen käyttöönottoa

Tila voi siirtää riskin vuorosta, tehtävästä, käyttäjästä tai ympäristöstä toiseen. Organisaation on dokumentoitava ja valvottava viestien, ladattujen tiedostojen, työtilan tiedostojen, tiivistelmien, työkalutulosten, välimuistien ja pysyvän muistin elinkaari.

Määritä vähintään seuraavat asiat:

• Eristys: erota tila käyttäjän, asiakkaan, tehtävän ja ympäristön mukaan. Älä salli implisiittistä istuntojen välistä jakamista.
• Säilytys: määritä säilytysaika, salaus, käyttöoikeudet ja poistamisen säännöt.
• Nollaus: tarjoa dokumentoitu tapa tyhjentää konteksti, muisti, työtila, tunnistetiedot ja välimuistit suoritusten välillä.
• Uudelleenyritykset ja aikakatkaisut: rajaa määrät ja budjetit. Uudelleenyritykset eivät saa laajentaa oikeuksia huomaamatta, ja niiden on säilytettävä idempotenssi.
• Rinnakkaisuus: määritä lukitukset ja ristiriitojen käsittely jaetuissa tiedostoissa, hyväksynnöissä ja ulkoisissa toiminnoissa.

Käsittele tilan nollausta osana tietoturvarajaa. Jos vanhat ohjeet, tunnukset tai työkalutulokset voivat palata yllättäen uuteen tehtävään, mallipäivitys tai kehotteen muutos voi muuttaa riskiä tavalla, jota pelkkä vastausten testaaminen ei paljasta.

Käsittele kaikki riskin välittäjät epäluotettavana syötteenä

Kehoteinjektio ei tarvitse tulla käyttäjän suorassa viestissä. Riskialttiita ohjeita voi olla upotettuna esimerkiksi:

• ladattuihin asiakirjoihin ja repositorioiden tiedostoihin;
• haettuihin verkkosivuihin;
• ulkoisiin taitoihin ja liitännäisiin;
• työkalupalvelujen vastauksiin;
• pysyvään muistiin;
• tiivistelmiin ja välimuistissa olevaan kontekstiin;
• käyttäjän toimittamaan tekstiin.

Jäsennä, merkitse ja lainaa tällainen sisältö datana. Sen ei pidä voida muuttaa agentin toimivaltaa, politiikkaa, työkalujen valintaa, tunnistetietojen käyttöä tai hyväksyntävaatimuksia. Suoritusympäristön on valvottava tätä erottelua sen sijaan, että vastuu jätetään yksin mallin kyvylle tunnistaa haitalliset ohjeet.

Agenttikehyskohtainen käyttöönoton tarkistuslista

Ennen käyttöönoton hyväksymistä jäädytä ja kirjaa täsmällinen kokoonpano:

1. Malli ja reititys: mallin tunniste ja versio, palveluntarjoajan reitti, päättelyasetukset tai työskentelytaso sekä yhteensopivuussovittimet.
2. Agenttikehyksen toiminta: kehyksen versio, järjestelmäkehote, istuntologiikka, uudelleenyritykset ja aikakatkaisut, aliprosessien käytännöt sekä muistin toteutus.
3. Työkalut ja politiikat: työkalumääritysten ja -versioiden lisäksi politiikkaversiot, hyväksyntäkynnykset, valtuutuslogiikka ja työkalupalvelinten luottamusrajat.
4. Oikeudet: identiteetit, käyttöoikeusalueet, tiedostojärjestelmän juuret, verkkokohteet, tunnistetietojen lähteet ja tuotantoon kirjoittavat polut.
5. Tilan merkitys: eristys, säilytys, nollaus, välimuistien toiminta, rinnakkaisuus ja istuntojen väliset rajat.
6. Vastakkainasettelutestit: kehoteinjektio jokaisen riskin välittäjän kautta, valtuuksien sekoittamiseen perustuvat yritykset, tunnistetietojen paljastuminen, polun läpikäynti, SSRF- ja verkkoliikenteen väärinkäyttö, haitalliset työkaluvastaukset, uudelleenyritysten aiheuttama toisto, muistin myrkyttäminen ja hyväksynnän ohittaminen.
7. Todisteet: kehotteet ja politiikkaversiot, työkalukutsut ja -tulokset, hyväksynnät, politiikkapäätökset, työtilan muutokset, lähtevät pyynnöt, käytetty identiteetti, lopputulokset, tehtävän valmistuminen ja turvallisuustulos yhden pysyvän ajotunnisteen alla.

Pisteytä tehtävän valmistuminen ja turvallisuus erikseen. Oikein syntynyt lopputiedosto ei saa hyvittää vaarallista sivuvaikutusta – tämä on AgentS4D-tulosten keskeinen opetus. 12

Toista testit aina kokoonpanon muuttuessa

Hyväksynnän kohteena on lukittu kokoonpano, ei pysyvä yleisnimike kuten ”DeepSeek V4 Pro -agentti”. Kokoonpanokohtainen testisarja on ajettava uudelleen aina, kun jokin olennainen asia muuttuu:

• malli tai palveluntarjoajan reitti;
• päättelyasetukset tai työskentelytaso;
• järjestelmäkehote tai sovitin;
• agenttikehys tai istuntologiikka;
• työkalut tai etätyökalupalvelimet;
• käyttöoikeus- tai hyväksyntäpolitiikat;
• tunnistetietojen reititys;
• muistin, uudelleenyritysten, aikakatkaisujen tai rinnakkaisuuden toiminta;
• verkko- tai tiedostojärjestelmärajat.

Näin suoritusympäristön turvallisuudesta tulee yleisen oletuksen sijaan mitattava julkaisu- ja käyttöönot topäätös, joka koskee juuri sitä ympäristöä, jossa agentti voi aiheuttaa todellisia vaikutuksia.

Organisaatioiden kannattaa arvioida DeepSeek V4 Pro -agentteja kokonaisuutena: malli–agenttikehys–tehtävä–ympäristö-kokoonpanona, ei vain yksittäisen kielimallin perusteella. Se, että sama malli on käytettävissä esimerkiksi verkossa, mobiilisovelluksessa, API-rajapinnan kautta tai Codex-integraatiossa, osoittaa ensisijaisesti rajapintojen yhteensopivuutta. Se ei todista, että kehotteet, työkalut, käyttöoikeudet, muisti, uudelleenyritykset tai ulkoiset vaikutukset toimisivat eri suoritusympäristöissä samalla tavalla.

Käytännön sääntö on yksinkertainen: hyväksy vain tarkasti lukittu kokoonpano, joka on läpäissyt oman turvallisuusarviointinsa.

Miksi agenttikehys muuttaa agentin toimintaa?

Agentti on enemmän kuin sen taustalla oleva malli. Agenttikehys eli harness määrittää, miten malli saa ohjeita, valitsee työkaluja, käsittelee tietoja, reagoi virheisiin ja vaikuttaa ulkoisiin järjestelmiin.

Merkittäviä eroja voivat olla esimerkiksi:

• järjestelmäkehotteet ja sovittimet;
• työkalujen kuvaukset ja toteutukset;
• käyttöoikeuksien laajuus ja hyväksyntäportit;
• tiedostojärjestelmän juuret ja verkkoyhteydet;
• tunnistetietojen lähteet ja käytetty identiteetti;
• aliprosessien ja tuotetun koodin suoritus;
• uudelleenyritysten, aikakatkaisujen ja rinnakkaisuuden logiikka;
• istunnon tila, tiivistelmät, välimuistit ja pysyvä muisti.

Siksi sama DeepSeek V4 Pro -taustamalli voi muodostaa erilaisen riskiprofiilin, kun se liitetään eri agenttikehykseen tai suoritusympäristöön. Yhteensopiva API-skeema kertoo integraatiosta – ei turvallisuussertifioinnista.

Mitä AgentS4D-tulokset kertovat?

AgentS4D arvioi kokonaisia suoritusympäristöjä yksittäisten mallivastausten sijaan. Hiekkalaatikkotestissä oli 328 tarkoituksellisesti riskiä sisältävää tapausta, neljä agenttikehystä ja viisi mallitaustaa. Näistä muodostui 6 560 suoritusta. Vaarallisiksi luokiteltiin 4 461 suoritusta eli 68,0 prosenttia, ja sekä vaarallisiksi että loppuun suoritetuiksi 4 344 suoritusta eli 66,22 prosenttia. 13

Keskeinen havainto on, että onnistunut tehtävän suoritus voi tapahtua vaarallisen toiminnan rinnalla. Agentti voi esimerkiksi tuottaa pyydetyn tiedoston, mutta samalla tehdä kielletyn muutoksen, käsitellä arkaluonteisia tietoja väärin, ohittaa aiotun kontrollin tai aiheuttaa muun haitallisen sivuvaikutuksen.

Lukuja ei pidä tulkita DeepSeek V4 Pron tuotantokäytön häiriö- tai vaaratilastoksi. Testissä käytettiin tarkoituksellisesti riskiä sisältäviä tapauksia valvotussa hiekkalaatikossa, ja tulokset koottiin useista malli–agenttikehys-yhdistelmistä. Tuotannon tehtäväjakauma, kontrollit, altistuminen vihamieliselle sisällölle, käytössä olevat resurssit ja haitan määritelmät voivat olla erilaisia. Tutkimus osoittaa, että suoritusympäristön turvallisuus on mitattava erikseen – se ei ennusta sellaisenaan jokaisen käyttöönoton tuloksia. 135

Rajaa agentin toiminnan mahdolliset seuraukset

Turvallisuuskontrollien pitäisi pienentää virheiden seurauksia silloinkin, kun malli tai työkalu toimii odottamattomasti.

Käytä erillisiä, vähäoikeuksisia tunnuksia

Luo erilliset identiteetit agenteille, ympäristöille ja asiakkaille tai vuokraajille. Älä anna agentille työntekijän automaattisia tunnuksia, tuotantoympäristön ylläpitäjän oikeuksia tai laajasti uudelleenkäytettäviä salaisuuksia. Rajaa jokainen identiteetti vain tietyn tehtävän tarvitsemiin resursseihin ja toimintoihin.

Rajoita tiedostot ja verkko

• Liitä agentille vain erillinen työtilan juurihakemisto.
• Tee muut polut saavuttamattomiksi sen sijaan, että ne vain piilotettaisiin.
• Salli verkossa vain ennalta määritetyt kohteet, menetelmät, portit ja tarvittaessa myös liikenteen määrä.
• Erota luku-, luonnos-, vaiheistus- ja tuotantoon kirjoittamisen oikeudet.
• Säilytä salaisuudet välityspalvelussa tai lyhytikäisten tunnusten järjestelmässä.
• Älä koskaan sijoita pitkäikäisiä tunnistetietoja kehotteisiin, työtilan tiedostoihin, ympäristömuuttujiin tai työkalujen tulosteisiin.

Poistaminen, julkaiseminen, maksaminen, käyttöoikeuksien muuttaminen, käyttöönotot ja ulkoinen viestintä ovat esimerkkejä korkean vaikutuksen toiminnoista. Niiden tulee kulkea suorituskerroksen politiikkatarkistuksen kautta tai vaatia nimenomainen hyväksyntä.

Tarkista koko suoritusketju

Ensimmäisen osapuolen työkalut ovat vain yksi osa hyökkäyspintaa. Sivuvaikutuksia voivat aiheuttaa myös aliprosessit, komentotulkki, tuotettu koodi, pakettien asennus, etätyökalupalvelimet, liitännäiset ja agentin käyttämät taidot tai lisäosat.

Saman politiikan on koskettava kaikkia näitä reittejä. Erityisesti komentotulkin tai tuotetun koodin suoritus ei saa ohittaa tiedosto-, verkko-, valtuutus-, lokitus- tai hyväksyntäkontrolleja.

Tee työkaluista valvottavia mallin ulkopuolella

Mallin tuottama työkalukutsu on epäluotettu pyyntö. Työkalupalvelimen – ei mallin – on valvottava valtuutusta ja turvallisuussääntöjä.

Käytä suppeita skeemoja ja esimerkiksi seuraavia rajoituksia:

• rajatut luetteloarvot ja merkkipituudet;
• normalisoidut polut ja yksiselitteiset resurssitunnisteet;
• sallittujen kohteiden luettelot;
• sivutuksen ja tuloskoon ylärajat;
• argumenttien tarkistus mallin ulkopuolella;
• palvelinpuolen valtuutus juuri kyseiselle kutsujalle, asiakkaalle, kohteelle ja toiminnolle.

Erota suunnittelu- ja esikatselutyökalut vaikutuksia aiheuttavista työkaluista. Tuhoisissa tai vaikeasti peruttavissa toiminnoissa:

• vaadi esikatselu sekä vahvistus tai hyväksyntätunnus;
• suosi pehmeää poistoa, karanteenia tai muutoin peruttavia työnkulkuja;
• käytä idempotenssiavaimia eli tunnisteita, joiden avulla sama pyyntö voidaan tunnistaa uudelleen;
• määritä, mitä tapahtuu, jos sama pyyntö yritetään uudelleen;
• palauta pysyvä kuitti, jotta uudelleenyritys ei toista vaikutusta.

Kontrollit ovat tarpeen, koska oikean näköinen JSON-työkalukutsu voi silti sisältää luvattoman kohteen, vaarallisen polun, liian laajan käyttöoikeuden tai toiminnon, joka pitäisi ohjata ihmisen tarkistettavaksi.

Määritä tila ja muisti ennen käyttöönottoa

Tila voi siirtää riskin vuorosta, tehtävästä, käyttäjästä tai ympäristöstä toiseen. Organisaation on dokumentoitava ja valvottava viestien, ladattujen tiedostojen, työtilan tiedostojen, tiivistelmien, työkalutulosten, välimuistien ja pysyvän muistin elinkaari.

Määritä vähintään seuraavat asiat:

• Eristys: erota tila käyttäjän, asiakkaan, tehtävän ja ympäristön mukaan. Älä salli implisiittistä istuntojen välistä jakamista.
• Säilytys: määritä säilytysaika, salaus, käyttöoikeudet ja poistamisen säännöt.
• Nollaus: tarjoa dokumentoitu tapa tyhjentää konteksti, muisti, työtila, tunnistetiedot ja välimuistit suoritusten välillä.
• Uudelleenyritykset ja aikakatkaisut: rajaa määrät ja budjetit. Uudelleenyritykset eivät saa laajentaa oikeuksia huomaamatta, ja niiden on säilytettävä idempotenssi.
• Rinnakkaisuus: määritä lukitukset ja ristiriitojen käsittely jaetuissa tiedostoissa, hyväksynnöissä ja ulkoisissa toiminnoissa.

Käsittele tilan nollausta osana tietoturvarajaa. Jos vanhat ohjeet, tunnukset tai työkalutulokset voivat palata yllättäen uuteen tehtävään, mallipäivitys tai kehotteen muutos voi muuttaa riskiä tavalla, jota pelkkä vastausten testaaminen ei paljasta.

Käsittele kaikki riskin välittäjät epäluotettavana syötteenä

Kehoteinjektio ei tarvitse tulla käyttäjän suorassa viestissä. Riskialttiita ohjeita voi olla upotettuna esimerkiksi:

• ladattuihin asiakirjoihin ja repositorioiden tiedostoihin;
• haettuihin verkkosivuihin;
• ulkoisiin taitoihin ja liitännäisiin;
• työkalupalvelujen vastauksiin;
• pysyvään muistiin;
• tiivistelmiin ja välimuistissa olevaan kontekstiin;
• käyttäjän toimittamaan tekstiin.

Jäsennä, merkitse ja lainaa tällainen sisältö datana. Sen ei pidä voida muuttaa agentin toimivaltaa, politiikkaa, työkalujen valintaa, tunnistetietojen käyttöä tai hyväksyntävaatimuksia. Suoritusympäristön on valvottava tätä erottelua sen sijaan, että vastuu jätetään yksin mallin kyvylle tunnistaa haitalliset ohjeet.

Agenttikehyskohtainen käyttöönoton tarkistuslista

Ennen käyttöönoton hyväksymistä jäädytä ja kirjaa täsmällinen kokoonpano:

1. Malli ja reititys: mallin tunniste ja versio, palveluntarjoajan reitti, päättelyasetukset tai työskentelytaso sekä yhteensopivuussovittimet.
2. Agenttikehyksen toiminta: kehyksen versio, järjestelmäkehote, istuntologiikka, uudelleenyritykset ja aikakatkaisut, aliprosessien käytännöt sekä muistin toteutus.
3. Työkalut ja politiikat: työkalumääritysten ja -versioiden lisäksi politiikkaversiot, hyväksyntäkynnykset, valtuutuslogiikka ja työkalupalvelinten luottamusrajat.
4. Oikeudet: identiteetit, käyttöoikeusalueet, tiedostojärjestelmän juuret, verkkokohteet, tunnistetietojen lähteet ja tuotantoon kirjoittavat polut.
5. Tilan merkitys: eristys, säilytys, nollaus, välimuistien toiminta, rinnakkaisuus ja istuntojen väliset rajat.
6. Vastakkainasettelutestit: kehoteinjektio jokaisen riskin välittäjän kautta, valtuuksien sekoittamiseen perustuvat yritykset, tunnistetietojen paljastuminen, polun läpikäynti, SSRF- ja verkkoliikenteen väärinkäyttö, haitalliset työkaluvastaukset, uudelleenyritysten aiheuttama toisto, muistin myrkyttäminen ja hyväksynnän ohittaminen.
7. Todisteet: kehotteet ja politiikkaversiot, työkalukutsut ja -tulokset, hyväksynnät, politiikkapäätökset, työtilan muutokset, lähtevät pyynnöt, käytetty identiteetti, lopputulokset, tehtävän valmistuminen ja turvallisuustulos yhden pysyvän ajotunnisteen alla.

Pisteytä tehtävän valmistuminen ja turvallisuus erikseen. Oikein syntynyt lopputiedosto ei saa hyvittää vaarallista sivuvaikutusta – tämä on AgentS4D-tulosten keskeinen opetus. 12

Toista testit aina kokoonpanon muuttuessa

Hyväksynnän kohteena on lukittu kokoonpano, ei pysyvä yleisnimike kuten ”DeepSeek V4 Pro -agentti”. Kokoonpanokohtainen testisarja on ajettava uudelleen aina, kun jokin olennainen asia muuttuu:

• malli tai palveluntarjoajan reitti;
• päättelyasetukset tai työskentelytaso;
• järjestelmäkehote tai sovitin;
• agenttikehys tai istuntologiikka;
• työkalut tai etätyökalupalvelimet;
• käyttöoikeus- tai hyväksyntäpolitiikat;
• tunnistetietojen reititys;
• muistin, uudelleenyritysten, aikakatkaisujen tai rinnakkaisuuden toiminta;
• verkko- tai tiedostojärjestelmärajat.

Näin suoritusympäristön turvallisuudesta tulee yleisen oletuksen sijaan mitattava julkaisu- ja käyttöönot topäätös, joka koskee juuri sitä ympäristöä, jossa agentti voi aiheuttaa todellisia vaikutuksia.