OpenRouter Armor pysäyttää agentin työkalukutsun – säännöt ratkaisevat

18. lokakuuta 2026 klo 13.44|Kirjoittaja: QUASAn toimitus|4 min lukuaika

Jev Dailyn julkistusuutisen mukaan OpenRouter toi Armor-suojauksen beetaan 15. lokakuuta 2026 ja perusteli sitä sanoin “regex-based filtering often isn't enough to detect unwanted tool calls”. TypeSafe AI:n Jev-malliin perustuva Armor arvioi tekoälyagentin työkalukutsun ennen kuin kutsu pääsee sovelluksen suoritettavaksi. Se pysäyttää säännön vastaiseksi tulkitun kutsun, joten kiellon sanamuoto ja sovelluksen tapa käsitellä päätös ratkaisevat käytännön suojan.

Myös explainx.ai:n julkaisuarvio ajoittaa Armor-betan 15. lokakuuta 2026 ja kuvaa sen OpenRouterin rajapintaan liitettäväksi suojaukseksi. Kehittäjä voi antaa agentille luonnollisella kielellä kirjoitetut säännöt: mitkä teot kielletään ehdottomasti, mitkä vaativat tarkemman luvan ja mitkä kuuluvat sallittuihin poikkeuksiin. Beta on käytettävissä dokumentoitujen rajapintojen kautta, mutta sen toimintaa ei voi päätellä pelkästä käyttöönotosta: jokainen työkalukutsu arvioidaan suhteessa annettuihin sääntöihin ja keskustelun tilanteeseen.

Kutsu odottaa arviota ennen sovellusta

Armor sijoittuu kielimallin ehdottaman työkalukutsun ja sitä käyttävän sovelluksen väliin. OpenRouter pitää kutsun odottamassa ja antaa päätösmallille kutsun, säännöt sekä siihenastisen keskustelun. Malli arvioi sääntöjen osuvuuden, minkä jälkeen kutsu joko välitetään eteenpäin tai merkitään estetyksi; agentti saa tiedon estosta ja voi jatkaa muulla tavalla.

Omaan agenttiin suojaus lisätään OpenRouter-pyynnön armor-pluginina. Säännöt ja toimintaympäristö annetaan classifier_context-kentässä, joten sama työkalun nimi ei yksin kerro, onko teko sallittu. Esimerkiksi Git-komennon merkitys riippuu päivitettävästä haarasta, käyttäjän pyynnöstä ja siitä, onko haara suojattu. Jos ympäristötiedoissa lukee vanha haara tai väärä luotettu kohde, luokitin voi soveltaa sääntöä virheelliseen tilanteeseen.

Eston esitystapa riippuu rajapinnasta. Responses-rajapinnassa estetty kutsu voidaan korvata openrouter:armor_blocked-tietueella, jolloin tavallista suoritettavaa funktiokutsua ei palauteta. Claude Code -yhteensopivassa Messages-tilassa merkitty tool_use jää vastaukseen: asiakassovelluksen on luettava safeguard_results-tieto ja jätettävä merkitty kutsu suorittamatta. Tällöin sovellus, joka sivuuttaa estomerkinnän, voi suorittaa juuri sen kutsun, jonka Armor merkitsi vaaralliseksi.

Ehdoton kielto ja rajattu poikkeus toimivat eri tavoin

Hard_deny on ehdoton kielto. Jos kutsu vastaa sitä, käyttäjän pyyntö tai allow-poikkeus ei vapauta kutsua. Soft_deny koskee tekoa, joka on yleensä kielletty mutta voi olla sallittu täsmällisessä tilanteessa: sen voi vapauttaa sopiva allow-sääntö tai käyttäjän keskustelussa antama lupa juuri kyseiseen tekoon ja kohteeseen. Allow määrittelee tällaisen poikkeuksen eikä yksin estä mitään.

Sanamuodon on kuvattava suojattava vaikutus, ei vain yhtä komentorivin kirjoitusasua. Julkaistun Git-historian uudelleenkirjoitus voi tapahtua eri komennoilla, ja tiedoston voi lähettää ulos usealla työkalulla. Yhteen merkkijonoon sidottu kielto jättää saman seurauksen muilla tavoilla toteutetut kutsut avoimiksi. Sääntöjen lisäksi environment-tieto kertoo luokittimelle esimerkiksi nykyisen haaran, luotetun tietovaraston ja sallitun lähetyskohteen.

Kolme riskikutsua tarvitsee eri rajat

Seuraavat sääntömuotoilut ovat ehdollisia esimerkkejä koodausagentista, jolla on pääsy komentotulkkiin. Ne kuvaavat eri seurauksia, vaikka kaikki voisivat näyttää agentille tavallisilta työkalukutsuilta.

Tuotantohaaran päivitys: Jos muutokset pitää hyväksyä ennen julkaisua, hard_deny voi kieltää agentilta päivityksen suojattuun main-haaraan riippumatta siitä, pyytääkö käyttäjä ajamaan git push -komennon. Säännössä kannattaa nimetä suojattu kohde ja muutos, jotta kielto kattaa myös muun tavan päivittää samaa haaraa. Ihmisen hyväksymä julkaisu kulkee silloin erillisen oikeuden tai työnkulun kautta.
Tiedoston poisto: Soft_deny voi pysäyttää tiedostojen ja hakemistojen poiston, mutta allow-poikkeus voi sallia testiajon omien väliaikaistiedostojen siivouksen. Pyyntö poistaa yksilöity hakemisto on eri asia kuin epämääräinen kehotus siivota vanhaa sisältöä. Peruuttamattomaan poistoon on perusteltua liittää sovelluksessa erillinen ihmishyväksyntä myös silloin, kun luokitin sallii kutsun.
Salaisuuden lähettäminen: Hard_deny voi kieltää tunnusten, ympäristömuuttujien ja .env-tiedoston sisällön siirtämisen luotetun kohteen ulkopuolelle. Vain curl-komennon kieltäminen ei kattaisi muuta lähetysreittiä. Säännön toimivuus edellyttää myös ajantasaista tietoa siitä, mikä vastaanottaja on luotettu.

Jevin mittaus näyttää puuttuvan vaihtoehdon riskin

PriorBenchin riippumattomassa Jev-mittauksessa malli saavutti 95,9 prosentin tuloksen 400 kohdan nollanäyteaineistossa, mutta ilman erillistä ”ei mikään näistä” -vaihtoehtoa yksikään 30 luokkien ulkopuolisesta syötteestä ei saanut oikeaa ulkopuolisen tapauksen tunnistusta; erillisessä luottamusrajakokeessa 0,99:n raja jätti arvioitavaksi 60,2 prosenttia vastauksista, jotka olivat tässä joukossa oikein. Mittaukset koskivat Jev-mallia luokitustehtävissä, eivät Armor-pluginin kykyä estää agentin vaarallisia kutsuja. Niiden prosentteja ei siten voi käyttää Armorille luvattuna estotarkkuutena.

Havainto on silti olennainen sääntöjen laatimisessa: luokitin voi valita tarjotuista vaihtoehdoista myös silloin, kun mikään niistä ei kuvaa käsillä olevaa tekoa. Armorissa kieltojen ulkopuolelle jäävä riskikutsu voi päästä läpi, eikä Jev-mittauksen 0,99:n rajaa pidä siirtää suoraan Armor-säännön asetukseksi. Korkeampi kynnys muuttaa sitä, mitkä osumat hyväksytään, mutta se ei korjaa väärin kuvattua uhkaa tai puuttuvaa kieltoa. Toisaalta liian laaja kielto voi pysäyttää turvallisen kutsun ja katkaista agentin työn tarpeettomasti.

Estopäätös tarvitsee toteuttajan

Armorin audit-tilassa luokitin palauttaa arviot mutta päästää kutsut läpi. Enforce-tilassa estävä arvio vaikuttaa kutsuun, mutta Claude Code -yhteensopivassa Messages-vastauksessa lopullinen suorittamatta jättäminen kuuluu edelleen asiakkaalle. Tavallisessa plugin-käytössä päätösmallin virheen oletustoimi on estää kutsu; yhteensopivuustilassa unavailable-tieto taas palautuu asiakkaan käsiteltäväksi. Myös palveluntarjoajan omalla puolella suoritettavat työkalut voivat jäädä Armor-arvion ulkopuolelle, ellei niiden arviointia erikseen oteta käyttöön.

Armor on beta, jonka asetusten ja vastaustietueiden muoto voi muuttua. Peruuttamattomissa teoissa rajatut käyttöoikeudet ja pakollinen ihmishyväksyntä muodostavat erillisen pysäytyskohdan silloin, kun sääntö ei tunnista riskiä tai luokitin tekee väärän arvion. Agentin toimintaa rajoittaa lopulta se, mitä sovellus sallii sen todella suorittaa.

Lue myös:

Jaa: