الانتقال إلى المحتوى الرئيسي
الوكيل المستقل طويل التشغيل هو أصعب شيء تأمينه. يدور بنفسه ساعات، ويختار أدواته بنفسه، ويجلب روابطه بنفسه، وينفق أموالك طوال الوقت. أنماط الفشل ليست مطالبة سيئة واحدة — بل حلقة إعادة محاولة تحرق 400 دولاراً طوال الليل، أو استدعاء أداة لم تراجعه أبداً، أو مفتاح سككته لتجربة أسبوع واحد ولا يزال يعمل بعد ستة أشهر. تربط هذه الوصفة أربعة ضوابط حول ذلك الشكل من الوكيل بالضبط. تضبطها كلها في وحدة التحكم (أو REST API) — يستمر الوكيل في استدعاء https://api.orcarouter.ai/v1/... تماماً كما كان.
جديد هنا؟ طبّق خط أساس balanced أولاً وراقب ما يفعله وكيلك يوماً. هذه الصفحة هي الخطوة التالية: تحويل المراقبة إلى فرض لوكيل لا تستطيع مجالسته.

​
1. وصفة الوكيل المستقل الآمن

يحتاج وكيل مستقل آمن أربعة أشياء لا يحتاجها روبوت محادثة:

سقف تكلفة صارم

قاعدة cap_cost ترفض التشغيل بمجرد أن يتجاوز إنفاقه المتراكم سقفك — قاطع الدائرة لحلقة لن تتوقف.

كشف الارتفاعات

يتعلّم كشف الشذوذ شكل ساعة-الأسبوع الطبيعي للوكيل ويعلّم ارتفاعات المعدل والتكلفة التي تتسلّل من القواعد الساكنة.

موافقة على الاستدعاءات الخطرة

حكم pending_approval يعلّق استدعاءات الأدوات المدمّرة أو غير القابلة للرجوع لإنسان، بدلاً من الوثوق بأن الوكيل سيكون حذراً.

مفتاح تنتهي صلاحيته

حدّد نطاق مفتاح الوكيل بانتهاء صلاحية وسقف ائتماني بحيث لا تستطيع تجربة منسيّة أن تعمل — أو تنفق — للأبد.
يخطّط كل واحد إلى سياسة جدار حماية أو حقل مفتاح واحد. لا يلمس أيّ منها كود وكيلك.

​
2. ضع سقفاً لتكلفة كل تشغيل

أول شيء تفجّره حلقة منفلتة هو ميزانيتك. قاعدة cap_cost سقف تكلفة فحص مسبق صارم: عندما تطابق، تقدّر البوابة تكلفة الطلب وترفض قبل الإرسال بمجرد أن يتجاوز الإنفاق المتراكم للتشغيل السقف — فلا يصل استدعاء فوق الميزانية إلى المزود أبداً. السقف ضمن نطاق التشغيل. تجمع البوابة الإنفاق السابق عبر تشغيل الوكيل بأكمله، فيُرفض تشغيل طويل أحرق معظم ميزانيته بالفعل حتى عندما يكون الاستدعاء الفردي التالي رخيصاً. هذا ما يجعله قاطع دائرة لا حدّاً لكل طلب. أضف قاعدة wildcard واحدة إلى سياسة جدار حمايتك: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
يضع هذا سقفاً للتشغيل عند 10 دولارات (cap_cost_cents بسنتات USD). يُحَل الحكم إلى allow تحت الميزانية وdeny بمجرد أن يتجاوز التقدير السقف. معظم قوالب جدار الحماية المدمجة (البرمجة، الدعم، RAG، البيانات، DevOps، المتصفح) تطرح سقف تكلفة لكل تشغيل تماماً كهذا — طبّق واحداً وحرّر السقف.
يحتاج التراكم ضمن نطاق التشغيل التقاط سجل الطلبات مفعّلاً لمساحة العمل. مع إطفائه، يقرأ تجميع الإنفاق السابق صفراً ويتدهور السقف إلى لكل طلب فقط — لا يزال آمناً، لكنه لن يلتقط تسرّباً بطيئاً من 500 استدعاء. انظر حرمان المحفظة.

​
3. اكشف الارتفاعات مقابل خط أساس متعلَّم

السقف يوقف الكارثة؛ وكشف الشذوذ يلتقط الغريب قبل أن يصبح كارثة. يتعلّم جدار الحماية شكل استخدام الأدوات الطبيعي لكل مساحة عمل — متوسط متحرك على 14 يوماً مجمّعاً حسب ساعة-الأسبوع، فتُقارَن حركة الثلاثاء-14:00 بتاريخ الثلاثاء-14:00، لا بمتوسط يومي مسطّح — ويبرز الانحرافات على تغذية قابلة للقراءة:
حجم استدعاء كل أداة مسجَّل مقابل خط الأساس المتعلَّم. “143 استدعاء db.query في ساعة مقابل خط أساس 8” يبرز حتى عندما يكون كل استدعاء فردي مسموحاً.
نفس خط الأساس، مطبَّقاً على الإنفاق بدلاً من العدد — تشغيل يحرق فجأةً أكثر بكثير مما تفعل هذه الساعة عادةً.
توقيع وكيل مستقل عالق في إعادة محاولة نفس الاستدعاء المكسور. انظر الوكالة المفرطة.
قفزة من أداة إلى أداة لم تقم بها هذه مساحة العمل من قبل — شكل وكيل يذهب إلى مكان جديد.
تُبلّغ التغذية عن أسماء الأدوات، ومعرّفات الرموز المنقّحة، والأعداد — لا الوسائط الخام أبداً. قراءتها مفتوحة لأي Member؛ ويستطيع Developer+ تأجيل التغذية لمدة تصل إلى 7 أيام بينما يحقّق. قرِن التغذية بقاعدة cap_cost بحيث يُوقَف ارتفاع هو أيضاً فوق الميزانية، لا يُلاحَظ فحسب.

​
4. علّق الاستدعاءات الخطرة لإنسان

لا تستطيع مراجعة كل استدعاء يجريه وكيل مستقل — لكن تستطيع جعله يتوقف ويسأل قبل الحفنة التي تهمّ. يعلّق حكم pending_approval استدعاء أداة خارج النطاق:
  1. يصدر الوكيل، لنقل، استدعاء payments.transfer. تطابق القاعدة ويعيد المحرك HTTP 400 firewall_approval_pending بمعرّف موافقة — لا يصل الاستدعاء إلى الأداة أبداً.
  2. يحلّها مراجِع من وحدة التحكم (Developer+)، أو يحلّها نظامك الخاص عبر استدعاء webhook مُوقَّع بـ HMAC إلى POST /api/v1/firewall/approvals/:id/callback.
  3. يستطلع الوكيل GET /api/v1/firewall/approvals/:id؛ بمجرد الموافقة يعيد تقديم الاستدعاء الأصلي بترويسة X-OrcaRouter-Firewall-Approval أحادية الاستخدام، وتمرّره البوابة تلك المرة الواحدة.
قاعدة تعلّق الكتابات إلى سطح مدمّر: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
اطرح هذا في وضع الظل أولاً — يُخفَّض pending_approval إلى audit، فترى أي الاستدعاءات ستُعلَّق دون حجب وكيلك فعلاً. أطفئ الظل عندما تبدو التغذية صحيحة.

​
5. أعطِ الوكيل مفتاحاً تنتهي صلاحيته

الضابط الذي يعمّر أكثر من كل سياسة هو المفتاح نفسه. ينبغي أن يحصل وكيل مستقل على مفتاح محدّد النطاق، لا مفتاحك الافتراضي. اضبط هذه الحقول عند سككه (وحدة التحكم → المفاتيح، أو واجهة الرموز):
الحقلاضبطه علىلماذا
expired_timeطابع Unix زمنيتنتهي التجربة؛ يموت المفتاح معها. -1 يعني أبداً — لا تستخدم ذلك هنا.
credit_limit_usdسقف بالدولارسقف إنفاق على المفتاح مستقل عن سقف التشغيل. 0 يعني بلا حد.
firewall_policy_idسياستك أعلاهيربط قواعد cap_cost + الموافقة بهذا المفتاح.
allow_ipsعناوين IP الصادرة للوكيلمفتاح مسرَّب عديم الفائدة من أي مكان آخر.
اضبط وسم environment أيضاً، بحيث يكون المفتاح — وكل ما يفعله في Events وMatches — منسوباً إلى هذا الوكيل. مفتاح تنتهي صلاحيته، ومحدود الائتمان، ومثبَّت IP هو الخط الأخير: حتى لو جرى تجاوز كل سياسة بطريقة ما، يكون نطاق الانفجار محدوداً بالوقت والدولارات.
ضبط المفاتيح إجراء وحدة تحكم / واجهة رموز ومحكوم بالدور. قراءة النص الصريح لمفتاح بوابة جدار الحماية تتطلب Admin+.

​
6. اجمعها معاً

ينتهي وكيل مستقل مقوَّى بسياسة جدار حماية واحدة ومفتاح واحد محدّد النطاق:
الطبقةالضابطيلتقط
الميزانيةقاعدة cap_cost، ضمن نطاق التشغيلالحلقات المنفلتة، حرمان المحفظة
السلوكتغذية الشذوذ (معدل / حرق / إعادة محاولة / جديد)الغريب-لكن-المسموح
الثقةpending_approval على الأدوات المدمّرةالإجراءات غير القابلة للرجوع
النطاقمفتاح تنتهي صلاحيته، محدود الائتمان، مثبَّت IPالمفاتيح المنسيّة أو المسرَّبة
ألّف قواعد الميزانية والموافقة معاً، اضبط سقفاً لكل تشغيل بـ قواعد جدار الحماية، واقرأ بقية مرجع جدار الحماية للأسطح والأحكام والقابلية للملاحظة. للتهديدات ذات الصلة التي تدافع عنها هذه الوصفة، انظر الوكالة المفرطة، استدعاءات الأدوات الخطرة، و حرمان المحفظة.

​
7. الخطوات التالية

تقوية وكيل MCP

احكم وكيلاً يصل إلى الأدوات عبر خوادم MCP.

أوقف التسريب

قواعد egress لوكيل يجلب روابطه بنفسه.

أوضاع الفرض

مراقبة ← ظل ← فرض، الطرح الآمن.

قواعد جدار الحماية

لغة المطابقة خلف كل قاعدة أعلاه.