الانتقال إلى المحتوى الرئيسي
عندما يستدعي وكيل أداة، تكون الوسائط التي يمرّرها محفوفة بالمخاطر كالمطالبة التي أنتجتها — مفتاح sk-… أُسقِط في حقل command، رقم ضمان اجتماعي لعميل لُصِق في body، رمز داخلي في ترويسة طلب. حكم sanitize في جدار الحماية يصطاد تلك المادة في وسائط استدعاء الأداة، يستبدلها برمز تنقيح مكتوب، ويعيد توجيه الاستدعاء المنظَّف — فيظل الإجراء يعمل، لكن السر لا يغادر البوابة أبداً.
“تطهير مخرجات الأداة” يعني وسائط الاستدعاء، وليس نتيجة الأداة. يبحث الناس عن تطهير مخرجات الأداة متوقّعين أن يفرك جدار الحماية ما تعيده أداة. حكم sanitize لا يلمس نتائج الأداة — بل ينقّح الوسائط التي يرسلها وكيلك في استدعاء أداة. إذا احتجت فحص النص الذي تعيده أداة أو نموذج، فتلك مهمة مرحلة مخرجات لـحواجز الحماية، وليست قاعدة sanitize في جدار الحماية.
هذا حكم واحد في لغة مطابقة جدار الحماية. للمجموعة الكاملة انظر الأحكام ومرجع القواعد؛ هذه الصفحة هي الدليل المركّز لتأليف sanitize والتفكير فيه.

​
1. ماذا يفعل sanitize — وما لا يلمسه أبداً

قاعدة بـ verdict: sanitize تجري محرك تنقيح على وسائط استدعاء الأداة قبل إرسال الاستدعاء. تُستبدل كل مطابقة برمز نمطي ويمضي الاستدعاء بالوسائط المنظَّفة — لا تزال الأداة تُنفَّذ، فقط دون السر الخام فيها.

ينقّح

وسائط JSON لـ tool_call مُصدَر من النموذج أو tools/call لـ MCP — command، body، headers، أي حقل سلسلة هبط فيه سر أو PII.

لا ينقّح أبداً

المحتوى الذي تعيده أداة، المطالبة، نص استجابة النموذج. sanitize مُنقّح للوسائط فقط. فحص النص شأن حاجز حماية.
يستبدل المُنقّح كل مطابقة برمز مكتوب: مطابقة إعداد مسبق تصبح [redacted:<preset>] (مثل [redacted:openai_key])، ومطابقة نمط مخصص تصبح [redacted:custom]. شكل الوسيطة محفوظ — تتغيّر السلسلة الفرعية الحساسة فقط — فأداة تتوقّع JSON صالحاً لا تزال تتلقّى JSON صالحاً.

​
2. الإعدادات المسبقة المدمجة للكاشف

قاعدة sanitize تسمّي إعداداً مسبقاً واحداً أو أكثر (أشكال أسرار/PII معروفة) و/أو أنماط regex مخصصة. الإعدادات المسبقة المدمجة:
الإعداد المسبقيصطاد
aws_access_keyمعرّف مفتاح وصول AWS (AKIA… / ASIA… + 16 حرفاً)
aws_secret_keyسر AWS بطول 40 حرفاً (واعٍ بالحدود)
openai_keysk- + ≥32 حرفاً
anthropic_keysk-ant- + ≥40 حرفاً
bearer_tokenBearer + رمز بطول ≥16 حرفاً (الكلمة المفتاحية محفوظة)
emailعنوان بريد إلكتروني
ssn_usرقم ضمان اجتماعي أمريكي بصيغة 3-2-4
credit_cardسلسلة 13–19 رقماً تجتاز فحص Luhn
يجب أن تعلن قاعدة sanitize عن إعداد مسبق واحد على الأقل أو نمط مخصص — مُطهّر فارغ يُرفض عند حفظ القاعدة. مطابقة credit_card تُفحَص إضافياً بـ Luhn، فرقم بنفس الطول ليس بطاقة صالحة يُترَك دون مساس بدلاً من المبالغة في تنقيحه.

​
3. مثال ملموس واحد

ألّف هذا في محرر القواعد بوحدة التحكم. المثال ينقّح مفتاح OpenAI وأي بريد إلكتروني من وسائط أي استدعاء أداة http.* يصدره وكيلك، ثم يعيد توجيه الاستدعاء المنظَّف: 
{
  "label": "strip secrets from http tool args",
  "stage": "response",
  "tool_name_glob": "http.*",
  "verdict": "sanitize",
  "sanitize_json": "{\"presets\":[\"openai_key\",\"email\"],\"custom\":[]}"
}
إذا أصدر النموذج استدعاءً مثل: 
{ "name": "http.post", "arguments": { "url": "…", "body": "key=sk-AAAA…BBBB user=jo@acme.com" } }
تعيد البوابة توجيهه بالجسم مُعاد كتابته إلى key=[redacted:openai_key] user=[redacted:email] — لا يزال الطلب يعمل، والسر والعنوان لا يغادران البوابة أبداً.
ثبّت القاعدة على مرحلة response (استدعاءات tool_calls المُصدَرة من النموذج) أو اترك المرحلة فارغة لتغطية سطح mcp أيضاً. تلك هي الأسطح التي تحمل وسائط الاستدعاء، وهو ما ينقّحه sanitize.

​
4. على سطح inbound، يتصاعد sanitize إلى deny

سطح inbound يقيّم الأدوات التي يعلن عنها وكيل على طلب — تعريفات الأدوات، التي لا تحمل وسائط استدعاء بعد. لا شيء لتنقيحه هناك، فحكم sanitize على سطح inbound يتصاعد إلى deny (فشل مغلق): يُحجب الطلب بـ firewall_blocked بدلاً من إعادة توجيهه غير منقَّح.
لا تؤلّف قاعدة sanitize متوقّعاً أن تنظّف إعلان أداة inbound — ستـحجبه. إذا أردت إزالة تعريف أداة من الطلب، استخدم deny صريحاً. احفظ sanitize لسطحي response وmcp، حيث توجد وسائط حقيقية.

​
5. sanitize مقابل الطرق الأخرى للتعامل مع سر

ثلاث طبقات يمكنها التصرف بناءً على سر يوشك وكيل على تسريبه — اختر حسب ماذا وأين:
يجرّد السر من وسائط استدعاء أداة ويظل يشغّل الاستدعاء. استخدمه عندما يكون الإجراء مشروعاً لكن الوكيل وضع شيئاً حساساً في حقل. مستوى الوسيطة فقط.
يوقف الاستدعاء بالكامل. استخدمه عندما يكون الإجراء نفسه خطراً، وليس مجرد وسيطة. هذا أيضاً ما يصبح sanitize عليه على سطح inbound. انظر حجب الأدوات.
Secrets Blocker وحواجز PII تفحص نص طلب أو استجابة (بما في ذلك، على مرحلة المخرجات، المحتوى المولَّد من النموذج). تلك هي الطبقة لـ “ما تعيده أداة أو نموذج” — الشيء الذي لا يفعله sanitize.
اختبر قبل أن تفرض. sanitize يعيد كتابة وسائط استدعاء حي على سطحي response وmcp. ألّف قواعد sanitize الخاصة بك تحت وضع الظل أولاً وراقب تغذية الأحداث لتأكيد أنها تطابق ما تتوقعه قبل أن تُعاد كتابة أي وسيطة فعلاً.

​
6. أين يظهر sanitize في أثرك

كأي حكم، يُسجَّل تقييم sanitize كحدث جدار حماية — قابل للتصفية حسب الحكم والسطح والأداة والتشغيل في سجل الأحداث ومجمَّع في التحليلات. في وضع الظل يُخفَّض حكم sanitize (كأي حكم فارض) إلى audit ويُسبَق السبب بـ [shadow] would …، فيمكنك قياس الأثر قبل أن تُعاد كتابة أي وسيطة فعلاً.

​
أين تذهب بعد ذلك

كل الأحكام

allow، audit، deny، sanitize، pending_approval، cap_cost.

التحقق من الوسائط

طابق استدعاءً بما في وسائطه — قواعد عبارة JSONPath.

حجب الأدوات

عندما يكون الإجراء نفسه هو المشكلة، ارفض الاستدعاء كله.

جدار الحماية + حواجز الحماية

افحص النص الذي تعيده أداة أو نموذج — الطبقة التي لا يغطّيها sanitize.
للتهديدات التي يساعد sanitize في احتوائها، انظر تسريب البيانات و استدعاءات الأدوات الخطرة. لقواعد القاعدة الكاملة خلف الحكم، انظر مرجع قاعدة جدار الحماية.