الانتقال إلى المحتوى الرئيسي
عندما تحكم سياسة جدار الحماية لديك على استدعاء أداة، تكتب صفاً. تغذية الأحداث هي ذلك السجل الجاري: سجل واحد لكل تقييم، يحمل الحكم، والسطح الذي أُطلق عليه، والأداة، والسبب، والتشغيل/الجلسة التي انتمى إليها. هكذا تجيب عن السؤال الوحيد الذي يهمّ بعد أن تطرح سياسة — هل فعل جدار الحماية فعلاً ما أظنه فعل، على الاستدعاءات التي أظنه فعله عليها؟ هذا هو سطح سجلات جدار حماية الذكاء الاصطناعي لديك. كل allow، وكل deny، وكل موافقة مُعلَّقة، وكل “كان سيفعل” في وضع الظل يحطّ هنا، قابلاً للتصفية ومرتبطاً بتشغيل الوكيل الذي أنتجه.
تغذية الأحداث Developer+ للقراءة. يحجز كل صف حقل args_summary مسقوفاً للقطة وسيطة استدعاء أداة، فيقع السطح فوق الأسطح القابلة للقراءة بـ Member (الإعدادات، السياسات، الأدوات المكتشفة، وتغذية الشذوذ). اضبط كل هذا من وحدة التحكم — هذه مسارات مصادَق عليها بالجلسة، لا استدعاءات ترحيل.

​
1. ماذا يحطّ في تغذية الأحداث

يُسجَّل كل تقييم يشغّله المحرك — وليس الحجوبات فقط. allow وaudit يتركان صفاً تماماً كما يفعل deny، فتكون التغذية أثراً كاملاً، لا سجل استثناءات. الحكم على صف هو الذي رآه الوكيل فعلاً:
الحكميعني
allow / auditمُرِّر؛ audit يعلّمه كشيء أردت مراقبته.
denyمحجوب — firewall_blocked (HTTP 400) على inbound، خطأ أداة على mcp.
sanitizeمُوجَّه مع تنقيح السلاسل الفرعية المطابقة من وسائط الاستدعاء.
pending_approvalمُعلَّق لإنسان؛ يعلّم الصف أن الاستدعاء بُوِّب.
observeلم تطابق أي سياسة — ثغرة تغطية وضع observe.
لن ترى cap_cost حرفياً في التغذية أبداً. قاعدة cap-cost تُحَل إلى allow أو deny ملموس وقت التقييم، وذلك ما يُسجَّل — الحكم الذي عايشه التشغيل فعلاً.
في وضع الظل تُخفَّض الأحكام الفارضة إلى audit ويُسبَق السبب بـ [shadow] would …، فتُريك التغذية بالضبط ما كانت ستحجبه سياسة قبل أن تقلبها حيّةً.

​
2. ماذا يسجّل كل حدث

الحدث المفرد لقطة منزوعة التطبيع — كافٍ لإعادة بناء القرار دون الربط ثانيةً بأي شيء:
verdict، وsurface (inbound / response / mcp / egress)، وtool_name، وreason بشري (“destructive shell command”، “egress to 169.254.169.254 denied”). عندما يكون للقاعدة المطابقة علامة، يسمّي policy_name وrule_label القاعدة الدقيقة التي أُطلقت — فيشير الصف مباشرةً إلى السطر الذي كتبته.
request_id يربط الحدث بسجل الطلب؛ وconversation_id يجمّع جلسة متعددة الأدوار؛ وagent_run_id (مع step_id / parent_step_id) يربطه بتشغيل وكيل كامل واحد وباستدعاء LLM الذي طلب الأداة. هذه ما يجعل التغذية تتبّعاً، لا قائمة مسطّحة — انظر §4.
token_name، وmodel_name، وip المستدعي — المفتاح والنموذج والأصل وراء الاستدعاء. skill_name يسمّي المهارة المالكة عندما يكون الاستدعاء قابلاً للنسب إليها، وquarantine يعلّم تعليق حجر-صحي مهارة.
args_summary هو حقل لقطة وسيطة استدعاء الأداة المسقوف (سبب كون هذا السطح Developer+). على حدث egress، يسجّل egress_host الوجهة الصادرة التي حُكِم عليها.
args_summary مسقوف — لا تُكتب بايتات الوسائط الخام حرفياً إلى التغذية أبداً، وهضم تجميع حلقة-الإعادة الذي يدعم كشف الشذوذ خادمي فقط: لا يُشحن أبداً في الـ API.

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

أصدر وكيلك استدعاء shell.exec بـ rm -rf /data، واصطادته قاعدة deny، وتريد رؤية ذلك القرار الواحد. صفّ التغذية بالحكم والأداة: 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
تعرض وحدة التحكم نفس الصفوف كجدول قابل للتصفية — نادراً ما تطرق المسار يدوياً. اضبط المرشّحات، واحفر داخل تشغيل، وصدّر من عرض الأحداث؛ الـ curl أعلاه ليس إلا لإظهار الشكل.
$ORCA_CONSOLE_TOKEN هو رمز جلسة / وصول لديك، لا مفتاح ترحيل sk-orca-…. مسارات /api/workspace/firewall/* مصادَق عليها بوحدة التحكم ومبوَّبة بالدور؛ وحدها حركة /v1/* تستخدم مفتاح ترحيل.

​
4. اربط حسب التشغيل والجلسة

السبب في أن كل حدث يحمل agent_run_id وconversation_id هو أن تتوقف عن النظر إلى الاستدعاءات منعزلةً وتبدأ بسؤال ماذا فعل هذا الوكيل عبر تشغيله كله:
المرشّحالسؤال الذي يجيب عنه
run_id=<run>كل حكم في تشغيل وكيل واحد — أثر الإجراء الكامل.
session_id=<conv>كل حكم عبر محادثة متعددة الأدوار.
verdict=deny,pending_approvalعرض “ما الذي أُوقِف أو عُلِّق” في استعلام واحد.
surface=egressقرارات الوجهة الصادرة فقط — عدسة التسريب.
تقبل قائمة الأحداث أيضاً since / until (ثوانٍ unix) و limit / skip للترقيم. للعرض المجمَّع — صف واحد لكل تشغيل أو جلسة بتفصيل لكل حكم، وأدوات ونماذج متمايزة، وأول/آخر ظهور — تقرأ وحدة التحكم GET /api/workspace/firewall/events/aggregate?group_by=run (أو group_by=session)، وتقرأ شجرة تتبّع الوكيل /trace/by-run. كلاهما Developer+، مثل التغذية الخام.
من درج سجل-الطلب يمكنك الالتفاف في الاتجاه الآخر: GET /api/workspace/firewall/events/by-request/:request_id يعيد كل حدث جدار حماية التُقِط ضمن طلب واحد — مفيد عندما يعثر طلب واحد على عدة قواعد عبر أسطح.

​
5. الاحتفاظ والمحو

تحمل أحداث جدار الحماية أفق احتفاظ خاصاً بها — افتراضي 30 يوماً، مقيَّد خادمياً بحدّ أقصى صلب 365 يوماً. يُكتب كل حدث بانتهاء صلاحية ويُعمَّر خارجاً تلقائياً بفهرس TTL؛ لا شيء في التغذية يعيش أبعد من إعداد احتفاظك. طلب الحق في المحو يتتالى هنا أيضاً: حذف مستخدم يبدأ فترة سماح 30 يوماً، تُفرَك بعدها PII الخاصة به وتُطهَّر أحداث جدار حمايته إلى جانب سجلات الطلبات وتطابقات حواجز الحماية لنفس النطاق.

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

الأحكام

ماذا فعل كل حكم في التغذية فعلاً بالاستدعاء.

وضع الظل

اقرأ التغذية في وضع “كان سيفعل” قبل أن تفرض.

المراحل والأسطح

الأسطح الأربعة التي يسمّيها حقل surface.

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

مرجع السياسة والقاعدة والـ API الكامل.
للتهديدات التي تساعدك هذه السجلات على اصطيادها متلبّسةً، انظر تسريب البيانات و استدعاءات الأدوات الخطرة. ولكيفية اقتران جدار الحماية بفحص نص المطالبة/الاستجابة، انظر جدار الحماية + حواجز الحماية.