التحكم في كود كلود في المؤسسات: تحديد نطاق أداة MCP وسجلات التدقيق

كود كلود هو مضاعف للإنتاجية وفجوة في الحوكمة في نفس التثبيت. مع 200 مطور وبدون نقطة تحكم مركزية، يمكن لأي منهم الوصول إلى أي نظام خلفي يقرر وكيلهم استخدامه. البوابة هي المكان الذي تُسد فيه هذه الفجوة.

لا يمتلك كود كلود ضوابط مؤسسية مدمجة

كود كلود يحقق مكاسب إنتاجية كبيرة. فهو يقرأ قواعد الأكواد، ويُجري الاختبارات، ويستعلم قواعد البيانات، ويحل مهام هندسية متعددة الخطوات بشكل مستقل. هذه القدرة هي بالضبط ما يجعل نموذج الأمان غير مريح. الوكيل ليس خدمة عن بعد تتولى المهمة أحيانًا؛ بل هو حلقة مستقلة تعمل على جهاز كمبيوتر محمول للمطور باستخدام أي بيانات اعتماد يمكن الوصول إليها من هذا الجهاز.

بطبيعته، لا يمتلك كود كلود أي مفهوم لحوكمة المؤسسات. امنحه إعدادات خادم MCP وسيفترض سلطة كاملة على كل أداة يكشفها هذا الخادم. قم بإعداد خادم postgres-mcp-server حتى تتمكن الوكلاء من الاستعلام عن بيانات الاختبار، ولا توجد آلية مدمجة لمنع وكيل مفرط الثقة — أو نقطة نهاية مطور مخترقة — من إصدار أمر DROP TABLE إذا كانت بيانات الاعتماد الأساسية تسمح بذلك. ملفات التكوين المحلية التي تطلب من المطورين التصرف بمسؤولية ليست هي الحل؛ بل هي غياب للحل.

الطريقة الصحيحة للتفكير في هذا الأمر هي: كان الإنسان الذي يشرف على الحلقة هو محدد المعدل ومحرك السياسات وسجل التدقيق في آن واحد. يزيل الوكيل الإنسان من مسار كل إجراء. يجب الآن إعادة بناء أي حواجز حماية قدمها البشر ضمنيًا بشكل صريح — والمكان الوحيد لوضعها هو قبل الوكيل، على الشبكة، حيث يمكن لفريق واحد امتلاكها.

ما الذي يحدث خطأ بدون بوابة

نموذج التهديد هو إمكانية وصول واسعة النطاق للغاية مقترنة بعدم القدرة على التنبؤ بالوكيل. تظهر ثلاثة أنماط فشل في الإنتاج خلال الشهر الأول من أي نشر غير بسيط لكود كلود.

تجاوز النطاق الموجه نحو الهدف. يقوم مطور بربط كود كلود بالشبكة الداخلية لتصحيح "الخطأ في تدفق مصادقة المستخدم". يقرر الوكيل، بعد التفكير في المشكلة، أنه بحاجة إلى رؤية بيانات مستخدم حقيقية لإعادة إنتاج الخطأ. يلتقط خادم kubernetes-mcp-server، ويعيد توجيه المنفذ إلى قاعدة بيانات إنتاج، ويستخرج معلومات التعريف الشخصية (PII)، ويلصق ملخصًا في الطرفية المحلية — أو يرسله إلى المزود كجزء من المطالبة التالية. هذا ليس سلوكًا خبيثًا. إنه وكيل يحقق هدفه باستخدام الأداة الأكثر تساهلاً المتاحة.

تدمير عرضي. يحاول الوكيل إصلاح وحدة Terraform بتطبيقها. يحاول تنظيف فرع تم تكوينه بشكل خاطئ عن طريق حذفه. يقوم بتشغيل ترحيل قاعدة بيانات للتحقق من أن المخطط الجديد يعمل. تبدو كل خطوة فردية منطقية محليًا؛ لكن النتيجة الإجمالية هي حادث إنتاج.

SSRF عبر الوكيل. يلتقط الوكيل أداة شبكة للتحقق من التكامل. يقرأ الوكيل وصف أداة مسمومًا يشير إلى أن مضيفًا معينًا هو الموثوق به. يجلب الوكيل هذا المضيف، والذي يصادف أنه داخل خدمة بيانات تعريف السحابة. تتسرب بيانات الاعتماد. لا يدرك المستخدم أن أيًا من هذا قد حدث — فقد أبلغ الوكيل ببساطة عن نجاح مهمته.

بدون نقطة تحكم مركزية، كل واحدة من هذه الأمور ممكنة افتراضيًا. بوجودها، يصبح كل منها قرار تكوين.

‍

‍

تحديد نطاق الوصول إلى أدوات MCP حسب الفريق والبيئة

الحل هو نشر بوابة بين كود كلود وخوادم MCP الداخلية، وتشغيل تحديد نطاق الأدوات الافتراضي الرافض بناءً على الهوية. يتم التعبير عن السياسة بشكل تصريحي، لا مدفونة في الكود، وتتم مراجعتها في طلبات السحب مثل أي جزء آخر من البنية التحتية:

سياسة Cedar · TrueFoundry

// Frontend engineers can read staging databases.
// Nobody is granted production write access by default.
permit(
  principal == Role::"frontend-developer",
  action    == Action::"mcp:invoke-tool",
  resource  == McpServer::"staging-database"
) when {
  context.tool_name   == "read_only_query" &&
  context.environment == "staging"
};

يتيح Cedar (أو OPA، أو أي محرك سياسات تعتمده منصتك) للمؤسسة أن توضح ببساطة: يصل مهندسو الواجهة الأمامية إلى أدوات MCP الخاصة بالواجهة الأمامية، ولا يمتلك أي وكيل صلاحية الكتابة في قواعد بيانات الإنتاج ما لم يتم استدعاء إجراء "كسر الزجاج" المحدد بوقت. تفحص البوابة رمز JWT للمطور الذي يشغل كود كلود، وتقارن الطلب بالسياسة، وتحظر المكالمات غير المصرح بها على طبقة الشبكة — قبل وقت طويل من وصول منطق الوكيل إلى قاعدة البيانات. يتم تضمين كل من حواجز حماية Cedar وحواجز حماية OPA في TrueFoundry كحواجز حماية MCP مدمجة، مع تطبيق دلالات الرفض الافتراضي عند نقطة ربط "Pre Tool".

مقارنة بين Cedar و OPA — متى تختار أيهما

الجدول 1 — مقارنة بين Cedar و OPA. كلاهما يأتيان كضوابط مدمجة في TrueFoundry مع دلالات الرفض الافتراضي. Cedar أسهل في البدء؛ OPA هي الأداة الأكثر مرونة على المدى الطويل. اختر أيهما يفضله فريق منصتك.

الدلالة المهمة هي توقيت تشغيل هذا الفحص. توفر ضوابط MCP في TrueFoundry نقطتي ربط لكل استدعاء أداة: Pre Tool يعمل بشكل متزامن قبل تنفيذ الأداة، و Post Tool يعمل بعد عودتها. تتخذ قرارات Cedar/OPA عند نقطة ربط Pre Tool، مما يعني أن الاستدعاء المرفوض لا يصل أبدًا إلى قاعدة البيانات، أو واجهة برمجة تطبيقات السحابة، أو الخدمة الداخلية. يستمر منطق الوكيل؛ ولا يتم تنفيذ الإجراء الخطير.

من مطالبات OIDC إلى سياق Cedar

الربط بين الهوية والسياسة مباشر. يصادق المطور نفسه مقابل موفر الهوية المؤسسي (Okta, Azure AD)، ويتلقى رمز JWT موقعًا من موفر الهوية، ويقدمه إلى البوابة في كل طلب. تتحقق البوابة من التوقيع مقابل المفاتيح العامة المخزنة مؤقتًا لموفر الهوية (لا يوجد استدعاء لموفر الهوية لكل طلب — يتم تنزيل المفاتيح مرة واحدة عند بدء التشغيل وتخزينها مؤقتًا في ذاكرة العملية). ثم يتم تعيين المطالبات التي تم التحقق منها إلى سياق Cedar الذي يقيمه محرك السياسة:

تدفق · مطالبات OIDC ← سياق Cedar

‍

‍

تحديد المعدل لكل مطور على طبقة استدعاء الأداة

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

على وجه التحديد، تنتمي حدود المعدل إلى طبقة استدعاء الأداة، وليس طبقة الموجه. قد يرسل المطور خمسة موجهات في الساعة. قد ينفذ الوكيل خمسة آلاف استدعاء أداة لخدمة تلك الموجهات. التقييد يكون حسب استدعاء الأداة. تستخدم بوابة TrueFoundry خوارزمية دلو الرموز ذات النافذة المنزلقة في الخلفية — نافذة منزلقة مدتها 60 ثانية مبنية من اثني عشر دلوًا مدة كل منها 5 ثوانٍ، يتم الاحتفاظ بها جميعًا في ذاكرة العملية على كل وحدة بوابة (pod). تتم مزامنة الحدود عبر النسخ المتماثلة من خلال NATS، وتظل الخوارزمية مستقرة حتى معدل 250 طلبًا في الثانية تقريبًا لكل وحدة معالجة مركزية واحدة (pod) الموثق للبوابة.

يستخدم نموذج التكوين معرفات قواعد ثابتة مدمجة مع `rate_limit_applies_per` لتحديد نطاق الحدود للكيانات. يتم التعبير عن حدود المعدل في YAML، وتخضع للتحكم في الإصدار، وقابلة للمراجعة مثل أي جزء آخر من السياسة:

YAML · حدود لكل مطور + لكل مشروع

name: claude-code-rate-limits
type: gateway-rate-limiting-config
rules:
  # Each developer gets their own per-day token budget.
  - id: "user-daily-tokens"
    when: {}
    limit_to: 1_000_000
    unit: tokens_per_day
    rate_limit_applies_per: ["user"]

  # Each user-model pair gets its own minute-window cap.
  - id: "user-model-minute"
    when: {}
    limit_to: 200
    unit: requests_per_minute
    rate_limit_applies_per: ["user", "model"]

  # Each project (via X-TFY-METADATA) gets its own hourly cap.
  - id: "project-hourly-tokens"
    when: {}
    limit_to: 50_000
    unit: tokens_per_hour
    rate_limit_applies_per: ["metadata.project_id"]

ثلاثة أمور تستحق الإشارة إليها بخصوص هذا التكوين. أولاً، يتم تقييم القواعد من الأعلى إلى الأسفل وتفوز القاعدة المطابقة الأولى — الترتيب يحدد الأولوية. ثانيًا، `rate_limit_applies_per` يحل محل تنسيق معرف القاعدة الديناميكي الأقدم ({user}-daily-limit وما إلى ذلك)؛ الترحيل ميكانيكي ولكنه قد يسبب تعطلًا، ويستحق القيام به مرة واحدة. ثالثًا، يمكنك دمج ما يصل إلى كيانين لكل قاعدة، لذا يمكن التعبير عن حدود لكل مستخدم لكل نموذج وحدود لكل مشروع لكل بيئة دون انفجار في عدد القواعد.

عندما ينفد الدلو، تعيد البوابة رمز HTTP 429. يفسر Claude Code ذلك كإشارة تراجع قياسية ويوقف الحلقة بشكل طبيعي، بدلاً من تعطيل قاعدة البيانات النهائية. يعيد الوكيل المحاولة عندما يمتلئ الدلو، وهذا هو السلوك الذي تريده بالضبط.

مسارات تدقيق واضحة التلاعب

عندما يحدث خطأ ما — ارتفاع في التكلفة، حادث أمني، سؤال من جهة تنظيمية — تحتاج فرق المنصة إلى سجل تحليلي. توفر البوابة سجلًا، يكون خارج جهاز المطور ويستحيل على المستخدم تعديله. هذا هو الجزء من البنية الذي يحول عبارة "نعتقد أنه كان وكيل بوب" إلى "كان وكيل بوب في الساعة 14:32:05 بالتوقيت العالمي المنسق، وإليك التتبع."

يحتوي إدخال سجل TrueFoundry على كل ما يحتاجه المحلل لإعادة بناء السبب والنتيجة:

الجدول 2 — حقول السجل لسجل تحليلي. معرف التتبع هو الحقل الذي يهتم به المدققون بالفعل — إنه ما يسمح للمحلل بالانتقال من "المطور طلب X" مرورًا بـ "النموذج قرر Y" وصولًا إلى "الأداة نفذت Z" في استعلام واحد.

تتدفق السجلات من البوابة إلى ClickHouse (مدعومة بتخزين الكائنات) ومن هناك إلى أي نظام SIEM تعتمده المؤسسة. لا تكتب البوابة أبدًا بشكل متزامن إلى مسار السجل — بل تنشر إلى NATS، ونظام السجلات الفرعي غير متزامن بطبيعته. إذا كانت قائمة انتظار السجلات معطلة، فإن البوابة لا تفشل الطلب. موثوقية مسار الطلب تتفوق على قابلية مراقبة مسار الطلب؛ وتُستعاد قابلية المراقبة عند عودة قائمة الانتظار للعمل.

كشف الشذوذ في أنماط استخدام الأدوات

لا يمكن للقواعد الثابتة أن تتوقع كل تهديد، ومراجعة بشرية لكل سطر من سجل التدقيق ليست استراتيجية قابلة للتطوير. يُعد تدفق التدقيق أيضًا خط أساس سلوكيًا. المطور الذي يستخدم عادةً git-mcp و jira-mcp والذي يبدأ فجأة في الوصول إلى aws-iam-mcp خمسين مرة في الثانية هو إشارة — ربما جهاز محمول مخترق، أو وكيل غير مهيأ بشكل صحيح، وبالتأكيد يستحق المراجعة.

تقوم فرق المنصة بتكوين قواطع الدائرة على هذه الأنماط. فوق عتبة z-score قابلة للتكوين، تعزل البوابة وصول الوكيل الخاص بالمطور وتُرسل تنبيهًا لمستجيب الأمن المناوب. يستمر المطور في العمل في بيئة التطوير المتكاملة (IDE) الخاصة به؛ وتبقى حلقة الوكيل الخاصة به خاملة حتى تتم مراجعتها. يقع كشف الشذوذ بعد سجل التدقيق، وليس في مسار الطلب، لذا فإن تكلفة زمن الوصول في الحالة المستقرة هي صفر — يتم تقييم الشذوذ على تدفق المقاييس المجمعة الذي تنشره البوابة بالفعل.

السلوكيات التي تستحق التنبيه عليها، مرتبة حسب تكرار حدوثها الفعلي في عمليات النشر الحقيقية، هي: ارتفاعات مفاجئة في معدل الاستدعاء (وكيل عالق في حلقة)، واستدعاءات الأدوات بأشكال معلمات لم ينتجها المطور من قبل (بيانات اعتماد مخترقة)، وفجوات متعددة الثواني تليها دفعات (أنماط وصول شبيهة بالروبوتات)، والوصول إلى أدوات خارج مخطط العمل الطبيعي للمطور (الحركة الجانبية). الميزات التي تدفع z-score بسيطة — الاستدعاءات في الدقيقة، والأدوات المميزة في الساعة، وتوزيع حجم الحمولة — والرياضيات هي متوسط وانحراف معياري للمتوسط المتحرك. التعقيد هنا يضر في الغالب؛ المهم هو أن الإنذار ينطلق بشكل موثوق ويسهل إسكاته عندما يكون إيجابيًا كاذبًا.

ربط نطاق الأدوات بهوية تسجيل الدخول الموحد (SSO)

تكمن الأناقة الهيكلية لهذه البنية في أن كل شيء يعود إلى موفر الهوية المؤسسي — Okta، Azure AD، أو أي نظام تديره المؤسسة. المصادقة هي OAuth/SAML/OIDC؛ تقوم البوابة بتخزين المفاتيح العامة لموفر الهوية (IdP) في ذاكرة العملية وتتحقق من كل رمز JWT وارد محليًا دون استدعاء خارجي. التخويل هو تقييم السياسة مقابل مطالبات OIDC، ويتم ذلك أيضًا في الذاكرة. لا يوجد استدعاء لكل طلب إلى موفر الهوية (IdP)؛ البوابة سريعة لأن كل هذه الفحوصات تحدث في ذاكرة الوصول العشوائي للبود، وليس عبر الشبكة.

عندما يغير المطور فرق العمل، تتغير عضويات مجموعاتهم في موفر الهوية (IdP). ولأن البوابة تقيّم السياسات ديناميكيًا مقابل مطالبات OIDC الحديثة، فإن Claude Code الخاصة بالمطور تفقد الوصول إلى خوادم MCP الحساسة على الفور، مع عدم وجود تعديلات محلية على التكوين. يصبح إنهاء الخدمة تعديلًا واحدًا في موفر الهوية (IdP). تنتشر تغييرات الأدوار، وانتقالات الفرق، وإنهاء عقود المقاولين بنفس الطريقة. البوابة هي نقطة الالتقاء حيث تلتقي هوية الشركة بحلقة الوكيل، وهذه النقطة هي حيث تصبح الحوكمة قابلة للتطبيق عمليًا بدلاً من أن تكون مجرد طموح دائم.

سيتم طرح Claude Code في مؤسستك — إن لم يكن هذا الربع، ففي الربع التالي. السؤال هو ما إذا كان سيتم طرحه عبر نقطة التقاء يتحكم فيها فريق المنصة لديك، أو عبر ألف ملف تكوين فردي لا يسيطر عليها فريق المنصة لديك. هناك إجابة واحدة فقط من هذه الإجابات تصمد أمام التدقيق.

الأسئلة الشائعة

كيف تعمل إجراءات الوصول الطارئ (break-glass) للوصول إلى بيئة الإنتاج؟

الوصول الدائم إلى بيئة الإنتاج هو الافتراضي الخاطئ؛ الترقية المحددة بوقت هي الصحيحة. النمط الذي يعمل في بيئة الإنتاج: قاعدة Cedar/OPA منفصلة تمنح مهندسًا أقدم دورًا مرتفعًا لمدة 30 دقيقة عندما يقدم طلبًا مبررًا من خلال سير عمل موافقة (بوت Slack، حادث PagerDuty، تذكرة JIRA). يتم تسجيل الترقية نفسها عبر البوابة، وينتهي الدور تلقائيًا، ويسجل سجل التدقيق كلاً من الطلب والإجراءات المتخذة بموجبه. لا يوجد لدى البوابة رمز خاص بالوصول الطارئ — إنه نفس تدفق مطالبات JWT إلى سياق Cedar، ولكن بدور مختلف ووقت انتهاء صلاحية يفرضه موفر الهوية (IdP).

ماذا لو اختلف المطور مع قرار سياسة في حينه؟

تعيد البوابة رمز 403 منظمًا مع معرف القاعدة الذي رفض الاستدعاء. معرف القاعدة هذا هو عنوان لمحادثة: يشير إلى ملف Cedar/OPA في مستودع المنصة، والذي يمكن مراجعته في طلب سحب عادي. إذا كانت السياسة خاطئة، فالحل هو طلب سحب. إذا كانت السياسة صحيحة، فلدى المطور الإيصال الذي يحتاجه لطلب استثناء عبر قناة منفصلة. لا يوجد مفتاح تجاوز من جانب المطور حسب التصميم — هذا المفتاح هو بالضبط ما يفترض أن تزيله البوابة.

كيف يتفاعل هذا مع مطالبات أذونات Claude Code الخاصة بها؟

مطالبات أذونات Claude Code المحلية مفيدة كتجربة مستخدم ولكنها ليست حدودًا أمنية — فهي تعيش على جهاز المطور ويمكن تعطيلها أو قبولها تلقائيًا. تقع البوابة أسفل هذه المطالبات وتتحكم في الاستدعاء الفعلي للأداة. تتكامل الطبقتان: تمنح المطالبات المطور فحصًا منطقيًا؛ وتمنح البوابة للمؤسسة سياسة. تعامل مع المطالبات كدفاع متعمق، وليست الطبقة الحاملة للحمل.

كيف تحافظ على قابلية صيانة السياسات مع نمو المؤسسة؟

يجب أن تعكس السياسات هيكل مجموعة موفر الهوية (IdP) بدلاً من تعداد كل زوج (مستخدم، أداة). قم بتجميع المطورين في أدوار في موفر الهوية (IdP) — مطور واجهة أمامية، مطور واجهة خلفية، مهندس موثوقية الموقع (SRE)، متعاقد — واكتب السياسات بناءً على تلك الأدوار. يرث الموظفون الجدد الوصول في اليوم الأول عبر عضويتهم في المجموعة؛ إنهاء الخدمة هو تعديل واحد في موفر الهوية (IdP). يجب أن ينمو عدد قواعد السياسة مع عدد فئات خوادم MCP / الأدوات، وليس مع عدد المطورين.

هل البوابة نقطة فشل واحدة؟

تقع في مسار الطلب، لذا فإن هندستها لتحقيق التوافر العالي ليست اختيارية. طبقة البوابة عديمة الحالة، وتعمل كنسخ متعددة، وتستمر في الخدمة بناءً على آخر تكوين معروف إذا كانت طبقة التحكم غير قابلة للوصول لفترة وجيزة. يتم تسوية التكوين الجديد عبر NATS وإعادة نشره بالكامل كل 10 دقائق كشبكة أمان. في عمليات النشر الإنتاجية، قم بتشغيل ما لا يقل عن ثلاث نسخ متماثلة للبوابة عبر مناطق التوفر وضعها خلف موازن تحميل HTTP عادي؛ نمط الفشل الذي يجب أن تصمم لمواجهته هو "إعادة تشغيل بود واحد أثناء انقطاع طبقة التحكم"، وليس "إعادة تشغيل جميع البودات في وقت واحد"، وهو أمر نادر بما يكفي ليكون مقبولاً.

‍