10110010011101001011001101101110101018200.devFrom Enterprise.Systems

الوقاية النشطة

يبدأ 8200.dev بدور استكشافي — يراقب ويشرح ويُسجّل النقاط. تتيح الوقاية النشطة للمحركات أن تتصرف أيضًا: إزالة رابط عام، أو إلغاء مشاركة محفوفة بالمخاطر، أو خفض مستوى الوصول، أو تعليق وكيل مارق، أو إلغاء نطاق صلاحيات وكيل.

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

الاستكشافي مقابل الوقائي

الإنفاذ الاستكشافي — المراقبة والشرح وإصدار حكم — فعّال الآن عبر كل موصّل. أما الإنفاذ الوقائي فيتصرف لدى المورّد ويُفعّل اختياريًا لكل موصّل: يؤدي تمكين الوقاية إلى ضبط التفعيل الاختياري لكل موصّل (وفي وضع المحاكاة، يحاكي منح نطاق الكتابة المُرتفع بحيث تصبح الحلقة بأكملها قابلة للعرض التجريبي اليوم).

خمسة إجراءات معالجة

يُسقط كل اقتراح على أحد خمسة أنواع من الإجراءات، يحمل كل منها شروطه المسبقة، واستدعاء API الدقيق للمورّد الذي سيُجريه، والحالة السابقة التي يسجّلها للتراجع:

  • إزالة رابط عام — تجريد مشاركة مجهولة أو على الويب العام.
  • إلغاء مشاركة — إزالة منح خارجي أو لضيف محدد.
  • خفض مستوى الوصول — تقليل صلاحية مفرطة الاتساع (على سبيل المثال، محرّر ← مشاهد).
  • تعليق العنصر الأساسي — تعطيل هوية مارقة أو مخترَقة.
  • إلغاء نطاق صلاحيات الوكيل — سحب موافقة مفرطة الاتساع لوكيل ذكاء اصطناعي أو تطبيق.

مستويات المعالجة الأربعة

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

يعمل 8200.dev بصلاحية القراءة فقط افتراضيًا. لا يُستخدم صلاحية الكتابة إلا مع موافقة صريحة لكل مستودع على حدة لأجل Fix-PR — ولا يستخدمها الموصّل الأساسي أبدًا.

  1. 1إشعار (جميع الخطط) — تنبيه بالإضافة إلى دليل معالجة. لا يتغير شيء. هذا هو الوضع الافتراضي.
  2. 2إصلاح موجَّه (الخطط المدفوعة) — الأوامر الدقيقة، ورابط مباشر إلى إعدادات مزوّد الخدمة لذلك المورد، والخطوات. أنت تُنفّذها من جهتك؛ لا حاجة إلى صلاحية الكتابة.
  3. 3Fix-PR (خطة Business فما فوق) — يفتح 8200.dev طلب سحب للمعالجة في مستودعك؛ يراجعه ويدمجه شخص. لا يتغير شيء دون موافقة، ويتطلب منح صلاحية كتابة منفصلة وقابلة للإلغاء لكل مستودع على حدة.
  4. 4تلقائي (خطة Business فما فوق) — بالنسبة إلى القواعد التي تختارها، يطبّق 8200.dev الإصلاح تلقائيًا ضمن ضمانات الحماية التلقائية القائمة (مفتاح الإيقاف، قائمة السماح، الموافقة لكل موصّل).

اليدوي مقابل AUTO-GUARD

المعالجة اليدوية بنقرة واحدة: المحاكاة دائمًا، والتنفيذ بتأكيد صريح عندما تكون الوقاية مفعّلة. يقوم AUTO-GUARD اختياريًا بالإجراء التلقائي على الانتهاكات الحتمية عالية الثقة فقط — وهو معطّل افتراضيًا ومتاح في الفئة Business وما فوقها.

AUTO-GUARD مصمَّم ليفشل بأمان (fail-closed): لا يمكن أبدًا لحكم صادر عن النموذج وحده أن يطلق تنفيذًا تلقائيًا، وقائمة محافِظة بأنواع الإجراءات المسموح بها وحدها هي المؤهَّلة، ومفتاح إيقاف عام يتغلب على كل بوابة ويخفّض كل أشكال الإنفاذ إلى المحاكاة فقط.

محاكاة حتى يُمنح الإذن

حتى يُمنح إذن OAuth بنطاق الكتابة ويُقيَّم، يعمل كل إجراء في وضع المحاكاة ويُوسَم بذلك — فلا شيء يدّعي إجراء تغييرًا حيًا لدى المورّد لم يحدث. إنفاذ الموصِّل التجريبي حقيقي وقابل للتراجع على الرسم البياني التوضيحي، ويُوسَم كبيانات تجريبية.

كل إجراء — محاكاة كان أم حيًا — يكتب سجل تدقيق كاملًا قابلًا للتراجع: من، وماذا، ومتى، وقبل ← بعد، والنتيجة.