Markdown பதிப்பு

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

# OpenRouter Armor கருவி அழைப்புகளை எப்படிச் சோதிக்கிறது; அவற்றைக் கிளையன்ட் எப்போது தடுக்க வேண்டும்

> டெவலப்பர் விதிகளின்படி முன்மொழியப்பட்ட கருவி அழைப்புகளை OpenRouter Armor வகைப்படுத்துகிறது. Responses, Chat Completions ஆகியவை குறியிடப்பட்ட அழைப்புகளைத் தடுத்து நிறுத்தலாம்; Messages இணக்கப் பயன்முறையில் பொறுப்பு கிளையன்டிடம் உள்ளது.

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.

OpenRouter வழங்கும் [Armor பீட்டா](https://openrouter.ai/docs/guides/features/plugins/armor) ஒரு மாதிரி முன்மொழியும் கருவி அழைப்புக்கும் அதை இயக்கக்கூடிய செயலிக்கும் இடையே விதிகளை வகைப்படுத்தும் அமைப்பை வைக்கிறது. ஏஜென்ட் டெவலப்பருக்கு முக்கியமானது, தீர்ப்பு எந்த இடத்தில் செயல்படுத்தலை உண்மையில் நிறுத்துகிறது என்பதே. Chat Completions, Responses ஆகியவற்றில் Armor குறியிடப்பட்ட அழைப்பைத் தடுத்து நிறுத்தலாம். Messages API-யின் Claude Code இணக்கப் பயன்முறையில் குறியிடப்பட்ட `tool_use` பதிலிலேயே இருக்கும்; அதை இயக்க கிளையன்ட் மறுக்க வேண்டும்.

தற்போதைய ஆவணங்கள் அக்டோபர் 2026 முதல் கிடைக்கும் பீட்டாவை விவரிக்கின்றன. BIG CHANGE அக்டோபர் 17 அன்று ஆவணப்படுத்தப்பட்ட கோரிக்கை மற்றும் பதில் ஒப்பந்தங்களை ஆய்வு செய்தது. நாங்கள் API கோரிக்கையை அனுப்பவோ, ஏஜென்டை இயக்கவோ, அதன் பாதுகாப்புச் செயல்திறனை அளவிடவோ இல்லை.

## பெரிய மாற்றம்

- **என்ன மாறியது:** முன்மொழியப்பட்ட கருவி அழைப்புகள் செயலியை அடைவதற்கு முன் டெவலப்பர் எழுதிய விதிகளைப் பயன்படுத்தும் வகைப்படுத்தி வழியாக அவற்றை OpenRouter ஏஜென்ட் அனுப்பலாம். இயல்புநிலை அமலாக்கப் பாதையில் குறியிடப்பட்ட அழைப்பை இயக்குவது தவிர்க்கப்படுகிறது; மாதிரி தொடர்வதற்காகக் காரணமும் திருப்பி அனுப்பப்படுகிறது.
- **இது ஏன் முக்கியம்:** குறுகிய அளவில் அனுமதிக்கப்பட்ட வேலைக்கான விதிவிலக்குகள் உட்பட, நடவடிக்கை அளவிலான வரம்புகளை டெவலப்பர்கள் இயல்பான மொழியில் எழுதலாம். இருந்தாலும் Messages இணக்க ஒப்பந்தம் செயல்படுத்தலின் தீர்மானிக்கும் படியைக் கிளையன்டிடமே விடுகிறது: குறியிடப்பட்ட தீர்ப்பைப் புறக்கணிக்கும் கிளையன்ட் அந்த அழைப்பை இயக்கிவிடலாம்.
- **கவனிக்க வேண்டியது:** தேர்ந்தெடுத்த API வெளியீட்டுப் பயன்முறைக்கேற்ப கிளையன்டை அமைத்து, சொந்தப் போக்குவரத்தில் விதிகளைச் சோதித்து, வகைப்படுத்தி பிழைகளை எப்படிக் கையாள வேண்டும் என்பதை அணிகள் முடிவுசெய்ய வேண்டும். பீட்டா வடிவங்கள் மாறலாம். ஏற்கத்தக்க அழைப்புகளைத் தடுப்பதும் ஏற்க முடியாத அழைப்புகளைத் தவறவிடுவதும் வகைப்படுத்திக்கு சாத்தியம் என OpenRouter கூறுகிறது.

## முன்மொழிவிலிருந்து தீர்ப்புவரை ஓர் அழைப்பைப் பின்தொடருங்கள்

முன்மொழியப்படும் ஒவ்வொரு கருவி அழைப்பையும் செயலிக்கு அனுப்புவதற்கு முன் நிறுத்தி வைப்பதாக OpenRouter கூறுகிறது. அதன் தீர்மான மாதிரி அழைப்பு, விதிகள், அதுவரையிலான உரையாடலைப் பெற்று, ஒவ்வொரு விதியும் பொருந்துகிறதா என மதிப்பிட்டு, முடிவுகளை இணைத்து `flagged` அல்லது `not_flagged` என வழங்குகிறது. குறியிடப்படாத அழைப்பு மாற்றமின்றி அனுப்பப்படுகிறது. அமலாக்கப் பயன்முறையில் குறியிடப்பட்ட அழைப்பை இயக்காமல் தவிர்க்கக் குறிக்கிறார்கள்; மாதிரி காரணத்தைப் பெற்று, இன்னும் குறுகிய அழைப்பை முயற்சிக்கலாம் அல்லது மறுப்பை விளக்கலாம். இது முன்மொழிந்த நடவடிக்கை குறித்த வகைப்படுத்தியின் தீர்ப்பு மட்டுமே; பின்னர் வரும் கருவியோ முழு ஏஜென்டோ பாதுகாப்பானது என்பதற்குச் சான்றல்ல.

விதிகளின் நிலைகள் வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. `hard_deny` பொருந்தினால் அனுமதி விதி அல்லது பயனர் கோரிக்கையைப் பொருட்படுத்தாமல் தடுக்கிறது. `soft_deny` பொருந்துவதால் ஏற்படும் மறுப்பை `allow` பொருந்துவதாலோ, உரையாடலில் பயனர் துல்லியமாக அதே இலக்கில் அதே செயல்பாட்டைக் கோருவதாலோ நீக்கலாம். `allow` விதி தனியாக ஓர் அழைப்பை ஒருபோதும் தடுப்பதில்லை. பயனர் அமைத்து இன்னும் நீக்காத எல்லைக்கான உள்ளமைந்த மென்மையான மறுப்பையும் OpenRouter ஆவணப்படுத்துகிறது. நம்பகமான களஞ்சியம் அல்லது வெளியீட்டு இலக்கு போன்ற உண்மைகளை டெவலப்பர்கள் `environment` இல் வழங்குகிறார்கள்; பழைய தகவல்கள் விதியின் துல்லியத்தைக் குறைக்கலாம். பெயரிடப்பட்ட விதி ஆப்ஜெக்ட்கள் தீர்ப்புகளில் ID மற்றும் பெயரைக் காட்டுகின்றன. விருப்பத் தேர்வு வரம்புகளின் இயல்புநிலை மதிப்புகள் மறுப்பு விதிகளுக்கு 0.6, அனுமதி விதிகளுக்கு 0.7.

ஆவணப்படுத்தப்பட்ட [Responses எடுத்துக்காட்டு](https://openrouter.ai/docs/guides/features/plugins/armor#example) ஒரு `bash` கருவிக்கு `git push` செயலுக்குக் கடுமையான மறுப்பு விதியை வழங்குகிறது. `output_mode: "custom_item"` இருந்தால் குறியிடப்பட்ட push-க்குப் பதிலாக அழைப்பும் காரணமும் உள்ள `openrouter:armor_blocked` உருப்படி வருகிறது; அடுத்து மாதிரியின் பதில் வருகிறது. சேவை என்ன திருப்பி அனுப்பும் என ஆவணங்கள் சொல்கின்றனவோ அதைத்தான் எடுத்துக்காட்டு காட்டுகிறது; இது BIG CHANGE நடத்திய சோதனை அல்ல.

## கருவிகளை இயக்கும்முன் வெளியீட்டு ஒப்பந்தத்தைத் தேர்வுசெய்யுங்கள்

Chat Completions, Responses ஆகியவற்றில் இயல்புநிலை `text` பயன்முறை தடுக்கப்பட்ட அழைப்பை நீக்கி, உதவியாளர் உரையில் `<openrouter_armor_blocked>` குறியை இடுகிறது. Responses API `custom_item` பயன்முறையையும் ஆதரிக்கிறது. இதில் வழக்கமாக `function_call` வரும் இடத்தில் வகை குறிப்பிடப்பட்ட தடை உருப்படி வருகிறது. அடுத்த Responses உள்ளீட்டில் அந்த உருப்படியை மாற்றமின்றித் திருப்பி அனுப்ப வேண்டும்; அதற்கெனத் தனியாக `function_call_output` உருவாக்கக்கூடாது என ஆவணங்கள் கூறுகின்றன. `safeguard_results` அழைப்பு ID-யின்படி தீர்ப்புகளைப் பதிவு செய்கிறது.

கோரிக்கையில் `safeguards` இருந்தால் Messages API-யின் இயல்புநிலை நடத்தை கணிசமாக வேறுபடுகிறது: `claude_code_compatibility` குறியிடப்பட்ட `tool_use` உருப்படியை `content[]` இல் விட்டுவிட்டு, அதன் `flagged` முடிவை `safeguard_results` இல் சேர்க்கிறது. **செயலி அந்த முடிவைப் படித்து, அழைப்பை இயக்க மறுக்க வேண்டும்.** தீர்ப்பைப் புறக்கணிக்கும் Messages கிளையன்ட் குறியிடப்பட்ட கருவிப் பயன்பாட்டை இயக்கிவிடும் என OpenRouter வெளிப்படையாக எச்சரிக்கிறது. கிளையன்டைக் கட்டுப்படுத்த முடியாத டெவலப்பர் Messages-இல் `output_mode: "text"` கோரலாம்; இதனால் OpenRouter அழைப்பைத் தடுத்து நிறுத்தும். API-யால் வெளிப்படுத்த முடியாத வெளியீட்டுப் பயன்முறையைக் கோரினால் 400 கிடைக்கும்.

OpenRouter-இன் Ori மெட்டாஹார்னஸ் வழியாக Claude Code தானியங்குப் பயன்முறை பயன்படுத்தப்படும்போது, கூடுதல் Armor செருகுநிரல் பதிவு இல்லாமல் Messages ஒப்பந்தத்தைப் பயன்படுத்துகிறது. Claude Code குறியிடப்பட்ட அழைப்புகளை மறுத்து, உரையாடல் பதிவில் பிழை முடிவை எழுதி, மாதிரியைத் தொடர அனுமதிப்பதாக ஆவணங்கள் கூறுகின்றன. தன் வகைப்படுத்தியை ஆதரிக்கும் Anthropic endpoint நேரடியாக முன்னனுப்பப்படும் தீர்ப்பை வழங்கலாம்; மற்ற endpoint-களில் Armor மதிப்பிடும் என்றும் கூறுகின்றன. இது ஆவணப்படுத்தப்பட்ட ஒருங்கிணைப்பு நடத்தை; ஒவ்வொரு மூன்றாம் தரப்புக் கிளையன்டும் இதைச் சரியாகச் செயல்படுத்துகிறது என்ற கூற்றல்ல.

## குறுகிய விதித்தொகுப்பை அமைத்துச் சரிபாருங்கள்

தனிப்பயன் ஏஜென்டுக்கான [Armor வழிகாட்டி](https://openrouter.ai/docs/guides/features/plugins/armor#example) ஒரு `armor` பதிவை `plugins` இல் வைக்கிறது; இதில் பதிப்பு குறிப்பிடப்பட்ட `classifier_context` (`v: 1`), `auto_mode` விதிகள், விருப்பமான சூழல் உண்மைகள் உள்ளன. விதி அடையாளம் காண வேண்டிய நடவடிக்கை மற்றும் பாதுகாக்கப்பட்ட வளத்திலிருந்து தொடங்குங்கள். பயனர் சம்மதித்தாலும் நீடிக்க வேண்டிய தடைக்கு கடுமையான மறுப்பைத் தேர்வுசெய்யுங்கள். துல்லியமான சம்மதமோ பெயரிடப்பட்ட அனுமதியோ முறையாகத் தடையை நீக்கக்கூடிய இடத்தில் மென்மையான மறுப்பைத் தேர்வுசெய்யுங்கள். ஒரு கட்டளையின் ஒற்றை எழுத்துவடிவத்திற்குப் பதிலாக நடவடிக்கையை விவரிக்கவும் சூழல் தகவல்களைப் புதுப்பித்திருக்கவும் ஆவணங்கள் அறிவுறுத்துகின்றன.

இயல்புநிலை `enforce` பயன்முறை தீர்ப்புகளின்படி செயல்படுகிறது. `audit` அதே தீர்ப்புகளைத் தெரிவிக்கும்போதும் குறியிடப்பட்டவை உட்பட எல்லா அழைப்புகளையும் அனுப்பிவிடுகிறது. அமலாக்கத்திற்கு முன் உண்மையான போக்குவரத்தை ஆய்ந்து விதிகளைச் சரிசெய்யும் வழி இது; பாதுகாப்புப் பயன்முறை அல்ல. ஆடிட்டை `claude_code_compatibility` உடன் சேர்க்க முடியாது. எந்தப் பயன்முறையிலும் `safeguard_results` படிக்க வேண்டும்: `not_flagged` என்பது அனுமதிக்கப்பட்டது, `flagged` பொருந்திய விதியைக் குறிக்கிறது, `unavailable` என்பது மதிப்பீடு தோல்வியடைந்தது, `skipped` என்பது மதிப்பிடப்படாத வழங்குநரின் நேட்டிவ் கருவியைக் குறிக்கிறது. ஸ்ட்ரீமிங்கில் தீர்ப்பு ஆப்ஜெக்ட் பதிலின் இறுதியில் வருவதால் Messages கிளையன்ட் கருவிப் பயன்பாட்டில் செயல்படும்முன் அதற்காகக் காத்திருக்க வேண்டும்.

வகைப்படுத்தியின் நேரம் முடிந்தாலோ, பிழை ஏற்பட்டாலோ, மிகப் பெரிய கோரிக்கையைக் கையாள முடியாவிட்டாலோ இயல்புநிலையாக `on_error: "block"` இருப்பதாக OpenRouter கூறுகிறது; `on_error: "log"` அழைப்பை அனுப்பிவிடுகிறது. Claude Code இணக்கப் பயன்முறையில் `unavailable` நிலையில் உள்ள அழைப்பு, தீர்ப்பு தெரியும்படி அனுப்பப்படுகிறது. வழங்குநரின் நேட்டிவ் சர்வர் கருவிகள் இயல்புநிலையாக மதிப்பீட்டில் தவிர்க்கப்படுகின்றன; ஆனால் `evaluate_native_tools` மதிப்பீட்டிற்காக அவற்றை நேட்டிவ் பாதையிலிருந்து வெளியேற்றக் கட்டாயப்படுத்தலாம். இந்த அமைப்புகளையும் உண்மையான கருவிப் பாதையையும் அணியின் ஒருங்கிணைப்புச் சோதனையில் சேர்க்க வேண்டும்; Armor பதிவு மட்டும் எல்லா கருவிகளும் மதிப்பிடப்பட்டன என்பதைக் காட்டாது.

## பீட்டாவின் செலவு, வேகம் மற்றும் செயல்பாட்டு வரம்புகள்

Claude Code இணக்க விதித்தொகுப்பு ஏற்றப்பட்டிருக்கும்போது மதிப்பீட்டால் கூடுதலாக எடுத்த நேரம் **நடுநிலையில் 279 மில்லிவிநாடிகளும் 90-வது பர்சென்டைலில் 334 மில்லிவிநாடிகளும்** என OpenRouter தெரிவிக்கிறது. இவை குறிப்பிட்ட நிலையில் விற்பனையாளர் தெரிவித்த அளவீடுகள்; குறிப்பிட்ட ஏஜென்டுக்கோ எல்லா விதித்தொகுப்புகளுக்கோ செய்யப்பட்ட பெஞ்ச்மார்க் அல்ல. அனுப்புவதற்கோ தடுப்பதற்கோ முன் ஒவ்வொரு அழைப்பும் ஒருமுறை மதிப்பிடப்படுகிறது. பீட்டாவின்போது மதிப்பீட்டிற்குக் கட்டணம் இல்லை; பொதுக் கிடைப்புக்கு முன் விலையை அறிவிப்பதாக OpenRouter கூறுகிறது. எதிர்காலக் கட்டணத்தை ஆவணங்கள் நிர்ணயிக்கவில்லை.

இயல்பான மொழியில் எழுதப்பட்ட விதிகளை அதேபோன்ற மொழியிலுள்ள ஆர்க்யுமென்ட்களுடன் ஒப்பிட்டுத் தீர்மானிப்பதால், தீர்மான மாதிரி தவறான எச்சரிக்கைகளை உருவாக்கவோ சில மீறல்களைத் தவறவிடவோ முடியும். உண்மையான போக்குவரத்தில் ஆடிட் தீர்ப்புகளைப் பயன்படுத்தி, தனித்தனி விதிகளின் வரம்புகளைச் சரிசெய்ய ஆவணங்கள் பரிந்துரைக்கின்றன. HIPAA, Zero Data Retention அல்லது தரவு பிராந்தியக் கட்டுப்பாடுள்ள கோரிக்கைகளுக்கு Armor மதிப்பீடு இன்னும் ஆதரிக்கப்படவில்லை. இச்சூழல்களில் செருகுநிரல் இயக்கப்பட்ட கோரிக்கைக்கு 403 கிடைக்கும்; Claude Code கோரிக்கை மாறாக அழைப்பை `unavailable` என அனுப்பிவிடும், பின்னர் Claude Code உள்ளூர் தானியங்குப் பயன்முறை மதிப்பீட்டிற்குத் திரும்பும். பீட்டா எச்சரிக்கையில் கட்டமைப்புப் புலங்கள், `safeguard_results` மற்றும் `openrouter:armor_blocked` உருப்படி வகையின் மாற்றங்களும் அடங்கும்.

மாதிரியிலிருந்து செயலிக்குக் கையளிக்கும் நிலையில் முன்மொழியப்பட்ட அழைப்புகளை Armor சோதிக்கிறது. எனவே இது [Microsoft-இன் MXC கட்டளைக் கட்டுப்பாடு](https://bigchange.ai/blog/mxc-agent-command-containment-guide) மற்றும் [NVIDIA-வின் OpenShell, Sentry இயக்கநேரக் கட்டுப்பாடுகள்](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) ஆகியவற்றிலிருந்து வேறுபட்ட செயல்முறை. அவை பணிச்சுமை அல்லது அதன் அணுகலைச் சுற்றிக் கட்டுப்பாடுகளை அமல்படுத்துகின்றன. Armor-இல் உடனடி செயலாக்க முடிவு என்னவென்றால், தேர்ந்தெடுத்த பதில் வடிவம் குறியிடப்பட்ட அழைப்பைத் தடுத்து நிறுத்துமா அல்லது கிளையன்ட் அதைத் தடுக்க வேண்டுமா என்பதே.

## மூலங்கள் மற்றும் மேலும் வாசிக்க

- [OpenRouter Armor ஆவணங்கள்](https://openrouter.ai/docs/guides/features/plugins/armor), அக்டோபர் 17, 2026 அன்று பார்க்கப்பட்டவை. பீட்டா நிலை, வகைப்படுத்தி வரிசை, விதி முன்னுரிமை, API பதில் ஒப்பந்தங்கள், பிழை நடத்தை, தனியுரிமைச் சூழல் விலக்குகள், தெரிவிக்கப்பட்ட தாமதம், பீட்டா கட்டணம் ஆகியவற்றிற்கான முதன்மை மூலம். இவை OpenRouter ஆவணப்படுத்திய கூற்றுகள்; BIG CHANGE செருகுநிரலை இயக்கவில்லை.
- [Microsoft MXC குறித்த BIG CHANGE கட்டுரை](https://bigchange.ai/blog/mxc-agent-command-containment-guide) ஏஜென்ட் உருவாக்கிய கட்டளைகளுக்கான கொள்கை அடிப்படையிலான கட்டுப்பாட்டை விளக்குகிறது. இது தனி அமலாக்க அடுக்கு; Armor-இன் முந்தைய கட்டம் அல்ல.
- [NVIDIA OpenShell, Sentry குறித்த BIG CHANGE கட்டுரை](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) மென்பொருள் அணுகல் கட்டுப்பாடுகளையும் விருப்பமான வன்பொருள் கண்காணிப்பு வடிவமைப்பையும் விவரிக்கிறது. இது தொடர்புடைய பின்னணி; OpenRouter அம்சத்தின் நேரடித் தொடர்ச்சி அல்ல.

## Sources

- [OpenRouter Armor ஆவணங்கள்](https://openrouter.ai/docs/guides/features/plugins/armor) — அக்டோபர் 17, 2026 அன்று சரிபார்த்த முதன்மை தயாரிப்பு ஆவணங்கள். பீட்டா நிலை, வகைப்படுத்தி மற்றும் விதி நடத்தை, API பதில் வடிவங்கள், பிழைகள், கட்டுப்படுத்தப்பட்ட சூழல்கள், தெரிவிக்கப்பட்ட தாமதம், பீட்டா கட்டணம் ஆகியவற்றை நிறுவுகின்றன. விற்பனையாளர் கூற்றுகள்; சுயாதீனச் சோதனை அல்ல.
- [BIG CHANGE: ஏஜென்ட் உருவாக்கிய கட்டளைகளுக்கு MXC கொள்கை அமைப்பது எப்படி](https://bigchange.ai/blog/mxc-agent-command-containment-guide) — தனி கட்டளைக் கட்டுப்பாட்டு செயல்முறை குறித்த முந்தைய செய்தி; கட்டுரைகளின் தொடர்புக்கான பின்னணியாக மட்டுமே பயன்படுத்தப்பட்டது.
- [BIG CHANGE: NVIDIA-வின் ஏஜென்ட் பாதுகாப்புத் தளம்](https://bigchange.ai/blog/nvidia-open-agent-safety-platform-agent-controls) — தனி இயக்கநேர அணுகல் கட்டுப்பாடுகள் மற்றும் விருப்பமான கண்காணிப்பு வடிவமைப்பு குறித்த முந்தைய செய்தி; கட்டுரைகளின் தொடர்புக்கான பின்னணியாக மட்டுமே பயன்படுத்தப்பட்டது.