Markdown edition

AI-translated from English; not yet reviewed by a fluent editor.

# Paano sinusuri ng OpenRouter Armor ang mga tool call, at kailan dapat pigilan ang mga ito ng client

> Inuuri ng OpenRouter Armor ang mga iminungkahing tool call ayon sa mga tuntunin ng developer. Maaaring hindi ipasa ng Responses at Chat Completions ang mga minarkahang call; sa Messages compatibility, ang client ang responsable.

By BIG CHANGE Editorial

Published: 2026-10-17T01:51:13.522Z
Updated: 2026-10-17T01:51:13.522Z
Canonical: https://bigchange.ai/blog/openrouter-armor-tool-call-screening-client-enforcement

![Conceptual charcoal illustration of a desktop monitor and idle keyboard; abstract code strokes and one orange pending-call shape appear on the unbranded screen.](https://bigchange.ai/api/media/file/openrouter-armor-call-screening-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual OpenRouter interface or tested security result is depicted.

Ang [Armor beta](https://openrouter.ai/docs/guides/features/plugins/armor) ng OpenRouter ay naglalagay ng classifier ng mga tuntunin sa pagitan ng tool call na iminungkahi ng modelo at ng application na maaaring magpatakbo nito. Para sa developer ng agent, ang mahalagang detalye ay kung saan talaga pinatitigil ng hatol ang pagpapatakbo. Sa Chat Completions at Responses, maaaring hindi ipasa ng Armor ang minarkahang call. Sa Claude Code compatibility mode ng Messages API, nananatili sa tugon ang minarkahang `tool_use` at dapat tumanggi ang client na patakbuhin ito.

Inilalarawan ng kasalukuyang dokumentasyon ang isang beta na magagamit mula noong Oktubre 2026. Sinuri ng BIG CHANGE noong Oktubre 17 ang dokumentadong mga kontrata ng request at response. Hindi kami nagpadala ng API request, nagpatakbo ng agent o nagsukat ng pagganap nito sa seguridad.

## Ang malaking pagbabago

- **Ano ang nagbago:** Maaaring ipadala ng isang OpenRouter agent ang mga iminungkahing tool call nito sa isang classifier na naglalapat ng mga tuntuning isinulat ng developer bago makarating ang mga call sa application. Sa default na landas ng pagpapatupad, hindi pinatatakbo ang minarkahang call at ibinabalik ang dahilan upang makapagpatuloy ang modelo.
- **Bakit mahalaga:** Maaaring ilahad ng mga developer sa karaniwang wika ang mga limitasyon sa antas ng aksiyon, kabilang ang mga eksepsiyon para sa trabahong may makitid na pahintulot. Ipinauubaya pa rin ng Messages compatibility contract sa client ang mapagpasyang hakbang sa pagpapatakbo: maaaring patakbuhin pa rin ng client na hindi pinapansin ang hatol ang minarkahang call.
- **Ano ang dapat bantayan:** Kailangang itugma ng mga team ang kanilang client sa napiling output mode ng API, subukan ang mga tuntunin sa sarili nilang traffic at magpasya kung paano hahawakan ang mga error ng classifier. Maaaring magbago ang mga format ng beta, at ayon sa OpenRouter, maaaring humarang ang classifier ng mga katanggap-tanggap na call at hindi mapansin ang mga hindi katanggap-tanggap.

## Sundan ang call mula sa mungkahi hanggang sa hatol

Ayon sa OpenRouter, hinahawakan muna nito ang bawat iminungkahing tool call bago ipasa sa application. Tinatanggap ng decision model nito ang call, mga tuntunin at usapan hanggang sa puntong iyon, tinatantiya kung tumutugma ang bawat tuntunin, at pinagsasama ang mga resulta bilang `flagged` o `not_flagged`. Ipinapasa nang walang pagbabago ang call na hindi minarkahan. Sa enforce mode, itinatakda na huwag patakbuhin ang minarkahang call; natatanggap ng modelo ang dahilan at maaari itong sumubok ng call na mas makitid ang saklaw o ipaliwanag ang pagtanggi. Hatol ito ng classifier sa iminungkahing aksiyon, hindi patunay na ligtas ang susunod na tool o ang buong agent.

Magkakaiba ang sinasagot ng mga antas ng tuntunin. Ang pagtugma sa `hard_deny` ay humaharang anuman ang tuntunin ng pahintulot o kahilingan ng user. Ang pagtugma sa `soft_deny` ay maaaring mapawalang-bisa sa pagtugma sa `allow` o kapag hiniling ng user sa usapan ang mismong operasyong iyon sa mismong target na iyon. Ang tuntuning `allow` ay hindi kailanman humaharang ng call nang mag-isa. Idinodokumento rin ng OpenRouter ang isang built-in na soft deny para sa hangganang itinakda ng user at hindi pa inalis. Naglalagay ang mga developer ng mga katotohanan, gaya ng pinagkakatiwalaang repository o target ng deployment, sa `environment`; maaaring bumaba ang katumpakan ng tuntunin dahil sa lumang impormasyon. Ipinapakita ng mga rule object na may pangalan ang ID at pangalan sa mga hatol. Ang default ng mga opsiyonal na threshold ay 0.6 para sa mga tuntunin ng pagtanggi at 0.7 para sa mga tuntunin ng pahintulot.

Ang [dokumentadong halimbawa sa Responses](https://openrouter.ai/docs/guides/features/plugins/armor#example) ay nagbibigay sa isang `bash` tool ng hard-deny na tuntunin para sa `git push`. Kapag ginagamit ang `output_mode: "custom_item"`, pinapalitan ang minarkahang push ng isang `openrouter:armor_blocked` item na naglalaman ng call at dahilan, kasunod ang tugon ng modelo. Ipinapakita ng halimbawa ang sinasabi ng dokumentasyon na ibinabalik ng serbisyo; hindi ito pagsubok na isinagawa ng BIG CHANGE.

## Piliin ang output contract bago magpatakbo ng mga tool

Sa Chat Completions at Responses, inaalis ng default na `text` mode ang hinarang na call at naglalagay ng `<openrouter_armor_blocked>` marker sa teksto ng assistant. Sinusuportahan din ng Responses API ang `custom_item`, na nagbabalik ng blocked item na may tiyak na uri sa lugar kung saan sana lumitaw ang isang `function_call`. Ayon sa dokumentasyon, dapat ipadala muli ang item nang walang pagbabago sa susunod na Responses input at huwag gumawa ng hiwalay na `function_call_output` para rito. Itinatala ng `safeguard_results` ang mga hatol ayon sa call ID.

Malaki ang pagkakaiba ng default na kilos ng Messages API kapag may `safeguards` sa request: pinananatili ng `claude_code_compatibility` ang minarkahang `tool_use` sa `content[]` at idinadagdag ang resulta nitong `flagged` sa `safeguard_results`. **Dapat basahin ng application ang resultang iyon at tumangging patakbuhin ang call.** Tahasang nagbabala ang OpenRouter na patatakbuhin ng Messages client na hindi pinapansin ang hatol ang minarkahang paggamit ng tool. Maaaring humiling ang developer na hindi makakontrol sa client ng `output_mode: "text"` sa Messages upang hindi ipasa ng OpenRouter ang call. Ang paghingi ng output mode na hindi kayang ilahad ng API ay nagbabalik ng 400.

Ginagamit ng Claude Code auto mode sa pamamagitan ng Ori metaharness ng OpenRouter ang Messages contract nang walang dagdag na Armor plugin entry. Ayon sa dokumentasyon, tinatanggihan ng Claude Code ang mga minarkahang call, nagsusulat ng error result sa transcript at pinahihintulutang magpatuloy ang modelo. Sinasabi rin nitong maaaring magbigay ng hatol na direktang ipinapasa ang Anthropic endpoint na sumusuporta sa classifier nito; sa ibang endpoint, Armor ang nagsusuri. Iyon ang dokumentadong kilos ng integration, hindi pahayag na tama itong ipinatutupad ng bawat third-party client.

## Mag-configure at magsuri ng isang makitid na hanay ng tuntunin

Para sa custom na agent, ang [gabay sa Armor](https://openrouter.ai/docs/guides/features/plugins/armor#example) ay naglalagay ng `armor` entry sa `plugins`, na may naka-version na `classifier_context` (`v: 1`), mga tuntuning `auto_mode` at opsiyonal na impormasyon tungkol sa environment. Magsimula sa aksiyon at protektadong resource na dapat makilala ng tuntunin. Pagkatapos, piliin ang hard deny para sa pagbabawal na dapat manatili kahit may pahintulot ng user, o soft deny kapag maaaring lehitimong alisin ito ng eksaktong pahintulot o ng pinangalanang pagbibigay-pahintulot. Ipinapayo ng dokumentasyon na ilarawan ang aksiyon sa halip na iisang paraan ng pagsulat ng command, at panatilihing napapanahon ang impormasyon tungkol sa environment.

Kumikilos ang default na `enforce` mode ayon sa mga hatol. Iniuulat ng `audit` ang parehong mga hatol habang ipinapasa ang bawat call, kabilang ang mga minarkahan. Paraan ito upang suriin ang tunay na traffic at ayusin ang mga tuntunin bago ipatupad ang mga ito, hindi isang mode na nagbibigay ng proteksiyon. Hindi maaaring ipagsama ang audit at `claude_code_compatibility`. Sa alinmang mode, basahin ang `safeguard_results`: ang `not_flagged` ay nangangahulugang pinapayagan, ang `flagged` ay tumutukoy sa tumugmang tuntunin, ang `unavailable` ay nangangahulugang nabigo ang pagsusuri, at ang `skipped` ay tumutukoy sa native na tool ng provider na hindi nasuri. Sa streaming, dumarating ang verdict object sa dulo ng tugon, kaya dapat itong hintayin ng client na gumagamit ng Messages bago kumilos sa isang paggamit ng tool.

Itinatakda ng OpenRouter ang `on_error: "block"` bilang default kapag nag-timeout, nag-error o hindi makahawak ng sobrang laking request ang classifier; ipinapasa naman ng `on_error: "log"` ang call. Sa Claude Code compatibility mode, ipinapasa ang call na `unavailable` habang nakikita ang hatol. Nilalampasan bilang default ang mga native na server tool ng provider maliban kung pilitin ng `evaluate_native_tools` na ilabas ang mga ito sa native na landas para suriin. Dapat isama sa integration check ng team ang mga setting na ito at ang aktuwal na landas ng tool; hindi ipinapakita ng Armor entry lamang na nasuri ang bawat tool.

## Mga limitasyon ng beta sa gastos, bilis at saklaw

Iniulat ng OpenRouter na nagdagdag ang pagsusuri ng **279 millisecond sa median at 334 millisecond sa ika-90 percentile** kapag naka-load ang hanay nitong tuntunin na compatible sa Claude Code. Mga sukat ito na iniulat ng vendor sa naturang kondisyon, hindi benchmark ng isang partikular na agent o ng lahat ng hanay ng tuntunin. Sinusuri ang bawat call nang isang beses bago ipasa o harangin. Walang singil ang pagsusuri sa beta; ayon sa OpenRouter, iaanunsiyo nito ang presyo bago ang pangkalahatang availability. Hindi nagtatakda ang dokumentasyon ng presyo sa hinaharap.

Maaaring magbigay ang decision model ng false positive o may hindi mapansin dahil hinahatulan nito ang mga tuntuning nakasulat sa karaniwang wika laban sa mga argumentong nakasulat din sa karaniwang wika. Iminumungkahi ng dokumentasyon ang paggamit ng audit verdict sa aktuwal na traffic at pag-aayos ng threshold ng bawat tuntunin. Hindi pa sinusuportahan ang Armor evaluation para sa HIPAA, Zero Data Retention o mga request na may limitasyon sa rehiyon ng data. Nakakakuha ng 403 ang request na may aktibong plugin sa isa sa mga kontekstong iyon; sa Claude Code request, ipinapasa sa halip ang call bilang `unavailable`, at bumabalik ang Claude Code sa lokal na auto-mode evaluation. Kasama rin sa babala sa beta ang pagbabago sa mga configuration field, `safeguard_results` at sa uri ng item na `openrouter:armor_blocked`.

Sinusuri ng Armor ang mga iminungkahing call sa paglilipat mula sa modelo patungo sa application. Iba ang mekanismong ito sa [MXC command containment ng Microsoft](https://bigchange.ai/blog/mxc-agent-command-containment-guide) at sa [OpenShell at Sentry runtime controls ng NVIDIA](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls), na naglalagay ng pagpapatupad sa paligid ng workload o access nito. Para sa Armor, ang agarang pasya sa implementasyon ay kung hindi ipapasa ng napiling response format ang minarkahang call o kung kakailanganing ang client ang pumigil dito.

## Mga sanggunian at karagdagang babasahin

- [Dokumentasyon ng OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor), binasa noong Oktubre 17, 2026. Pangunahing sanggunian sa beta status, pagkakasunod ng classifier, prayoridad ng mga tuntunin, API response contract, kilos kapag may error, mga hindi saklaw na privacy context, iniulat na latency at pagsingil sa beta. Mga dokumentadong pahayag ito ng OpenRouter; hindi pinatakbo ng BIG CHANGE ang plugin.
- [Ang artikulo ng BIG CHANGE tungkol sa Microsoft MXC](https://bigchange.ai/blog/mxc-agent-command-containment-guide) ay nagpapaliwanag ng containment na batay sa patakaran para sa mga command na ginawa ng agent. Inilalarawan nito ang hiwalay na layer ng pagpapatupad, hindi ang mas naunang yugto ng Armor.
- [Ang artikulo ng BIG CHANGE tungkol sa NVIDIA OpenShell at Sentry](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) ay naglalarawan ng software access controls at isang opsiyonal na disenyo ng hardware monitoring. Kaugnay na konteksto ito, hindi direktang pagpapatuloy ng tampok na ito ng OpenRouter.

## Sources

- [Dokumentasyon ng OpenRouter Armor](https://openrouter.ai/docs/guides/features/plugins/armor) — Pangunahing dokumentasyon ng produkto na sinuri noong Oktubre 17, 2026. Itinatatag ang beta status, kilos ng classifier at mga tuntunin, anyo ng API response, mga error, limitadong konteksto, iniulat na latency at pagsingil sa beta. Pahayag ng vendor, hindi independiyenteng pagsubok.
- [BIG CHANGE: Paano magtakda ng MXC policy para sa mga command na ginawa ng agent](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — Naunang pagtalakay sa hiwalay na mekanismo ng command containment; ginamit lamang bilang konteksto sa ugnayan ng mga artikulo.
- [BIG CHANGE: Ang platform ng NVIDIA para sa kaligtasan ng agent](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — Naunang pagtalakay sa hiwalay na runtime access controls at opsiyonal na disenyo ng monitoring; ginamit lamang bilang konteksto sa ugnayan ng mga artikulo.