الأمان والسلامة

نموذج السلامة في كاظمة بالكامل: بوابات HITL الثلاث المستقلّة، وقوائم الأدوات الخطيرة الثلاث، وسلوك الفشل-المُغلق في كل مكان، والتكامل التشفيري (مهارات HMAC، وتفويض Ed25519)، وتوصيات التحصين. كل ادّعاء موثَّق بمرجع مصدري.

تحديث 2026-09: أُضيف سجلّ بوابات HITL (hitl_gates.db) كصاحب القرار الوحيد — بطاقة واحدة وصف واحد، والموافقة الثانية تُجاب بـ 409، والرفض التلقائي للمراقب يُدوَّن مزدوجًا في البوابة. وشمل التحديث موجات تدقيق 0–8: تثبيت IP لمسار SSRF في الكشط المباشر (إحباط الأقران الخاصّة)، ومواءمة PBKDF2 لكلمة مرور الدخول مع الخزنة (600 ألف تكرار)، وHITL ثلاثي الحالات لـ FanOut (تصويت حتى اكتمال الناخبين أو المهلة)، وبوابات فاشلة-مغلقة عند أخطاء الحالة. التفاصيل الكاملة في النسخة الإنجليزية (هي مصدر الحقيقة).

1. بوابات HITL الثلاث (ولماذا ثلاث)

تملك كاظمة ثلاث آليات مستقلّة للموافقة البشرية في الحلقة (Human-in-the-Loop). يغطّي كلٌّ منها مسار تنفيذ مختلفًا. وكسر أيٍّ منها يُنشئ فجوة أمنية لأدوات خطيرة غير مُراقَبة.

flowchart TB
    subgraph "Gate A: Graph interrupt (single-agent chat)"
        A1[tool_worker_node] -->|danger tool + hitl_config| A2[interrupt]
        A2 -->|resume Command| A3[execute with _hitl_approved=True]
    end
    subgraph "Gate B: Swarm bus (/swarm dispatch)"
        B1[ToolRegistry.execute] --> B2[SafetyMiddleware.check]
        B2 -->|danger tool| B3[bus.request_approval]
        B3 -->|adapter callback| B4[approve/reject]
    end
    subgraph "Gate C: Pipeline checkpoints"
        C1[pipeline at hitl step] --> C2[CheckpointManager pause]
        C2 -->|auto-reject timeout| C3[reject]
        C2 -->|approve_checkpoint| C4[resume_pipeline]
    end

البوابة	المسار	مكان وجودها	سطح الموافقة
A	محادثة الوكيل الواحد (Web/Telegram/Discord/Slack)	`agent/graph_builder.py`	`POST /api/approve/\{thread_id\}` أو `/hitl approve\|deny`
B	إرسال `/swarm`	`swarm/safety.py` + `tool_registry.py`	أزرار محوّل الناقل (Telegram/Discord/Slack)
C	مهام السرب PIPELINE	`swarm/checkpoint.py` + `checkpoint_manager.py`	`POST /api/swarm/tasks/\{id\}/approve`

2. البوابة A — بوابة الرسم البياني (محادثة الوكيل الواحد) {#the-graph-gate}

2.1 كيف تعمل

tool_worker_node (graph_builder.py:336) هو مكان وجود البوابة. عندما يُمرَّر hitl_config:

يُختبَر كل استدعاء أداة معلَّق بـ requires_approval(tc["name"], hitl_config) (مستوردة من kazma_core.safety.hitl، السطر 356). تُقسَم الأدوات إلى safe_tools / danger_tools (الأسطر 418-429).
لكل أداة خطيرة، يُبنى قاموس approval_input (type: "hitl_approval"، اسم الأداة، الوسائط، الرسالة) ويُستدعى interrupt(approval_input) (السطر 493) — فيُعلَّق الرسم البياني (suspend).
عند الموافقة، يُنسَخ استدعاء الأداة ويُحقَن approved_tc_args["_hitl_approved"] = True (الأسطر 495-503) كي يتخطّى tool_registry.execute() فحص الناقل الزائد.
عند الرفض، يُعاد ToolResult مع is_error=True عبر _denied_result (الأسطر 467-475).

خاملة افتراضيًا: إن كان hitl_config خاطئًا (falsy)، تنتقل جميع الأدوات إلى safe_tools (السطر 429). لا تُفعَّل البوابة إلا عند تمرير hitl_config إلى build_supervisor_graph().

2.2 مواقع البناء التي تُفعِّل البوابة

يجب تمرير hitl_config وقت البناء. يوجد ثلاثة مواقع بناء؛ اثنان يمرّرانه (مُفعَّل)، وواحد لا يمرّره (خامل):

موقع البناء	الملف:السطر	يمرّر `hitl_config`؟
`KazmaAgent.get_streaming_graph()`	`agent_runner.py:530-539`	✅ مُفعَّل (مسار محادثة SSE)
`KazmaAgent._ensure_graph()`	`agent_runner.py:566-576`	✅ مُفعَّل (مسار التشغيل)
إعادة التجميع عند بدء التشغيل في `app.py`	`kazma-ui/kazma_ui/app.py:741-751`	✅ مُفعَّل
مصنع `create_supervisor_graph()`	`graph_builder.py:974-985`	❌ خامل (دخول CLI/طرف ثالث)

تصحيح أرقام أسطر AGENTS.md: تستشهد ملاحظات أقدم بـ “app.py ~line 966”. هذا غير دقيق — فـ graph_builder.py:966 هو aiosqlite.connect غير مرتبط داخل create_supervisor_app()، الذي لا يمرّر hitl_config. إعادة التجميع الفعلية عند بدء التشغيل تقع في kazma-ui/kazma_ui/app.py:741-751.

2.3 آلية الاستئناف

يستأنف الرسم البياني عبر LangGraph Command(resume=...). نقطة نهاية الموافقة هي POST /api/approve/\{thread_id\} في kazma-ui/kazma_ui/routes_direct.py:454 (الدالة approve_tool، السطر 455) — وليست في app.py:

# routes_direct.py:525-532
from langgraph.types import Command
resume_value = {"approved": approved, "reason": body.get("reason", "")}
graph_ref.ainvoke(Command(resume=resume_value), config=config)

الأمان على نقطة النهاية هذه:

عند ضبط KAZMA_SECRET، تتطلّب ترويسة X-Kazma-Secret (أو كوكي) مطابَقة عبر secrets.compare_digest (الأسطر 456-465).
فرض الملكية (الأسطر 480-522): يُحَلّ المالك عبر المنصّات (sender_id/owner/session_id/user_id) وتُرفَض الموافقات بين المستخدمين المختلفين بـ 403.

2.4 الاستمرارية

تُحفَظ الأدوار المتوقّفة في الـ checkpointer (SQLite WAL) — فتصمد أمام إعادة التشغيل.

3. البوابة B — بوابة ناقل السرب (إرسال `/swarm`) {#the-swarm-bus-gate}

3.1 مسار التنفيذ

ToolRegistry.execute() (tool_registry.py:335):

يُخرج _hitl_approved من الوسائط (السطر 349).
إن لم يكن مُوافَقًا عليه مسبقًا، يستدعي get_safety() (السطر 395).
للأدوات الخطيرة (safety.is_danger_tool(tool_name)، السطر 397)، يستدعي await safety.check(...) (الأسطر 400-405).
إن لم تُوافَق عليها ← يُعيد is_error=True “denied by HITL approval gate” (الأسطر 406-410).
الفشل-المُغلق: أي استثناء في فحص السلامة يُعيد is_error=True “blocked — SafetyMiddleware unavailable” (الأسطر 411-417).

3.2 SafetyMiddleware

swarm/safety.py — الصنف SafetyMiddleware (السطر 47). (لا يوجد صنف باسم SafetyGate أو SafetyChecker في أي مكان — تلك التسمية في بعض الوثائق الأقدم غير دقيقة.)

الدالة	السلوك
`check()` (async، السطر 106)	للأدوات الخطيرة: إن كان `NullBusAdapter` مُفعَّلًا و`allow_headless_danger=False` ← رفض (الأسطر 147-160)؛ وإلا `bus.request_approval(...)` وانتظار (الأسطر 162-177).
`check_sync()` (السطر 179)	فشل-مُغلق افتراضيًا. NullBusAdapter + `allow_headless_danger=False` ← يُعيد `False` (الأسطر 200-209). حتى مع محوّل حقيقي، لا يستطيع المسار المتزامن الانتظار ← يحجب. أي استثناء في الناقل ← فشل-مُغلق ما لم يكن `allow_headless_danger=True` (الأسطر 214-223).
`is_danger_tool` / `is_sensitive_read`	الأسطر 96، 100.
`add_danger_tool` / `remove_danger_tool`	الأسطر 86-94.

علم المُنشئ allow_headless_danger: bool = False (السطر 70) هو مخرج الاختبار/التطوير. الافتراضي هو الفشل-المُغلق.

3.3 محوّلات الناقل وأولوية المُفرد {#bus-adapter-priority}

محوّلات الناقل (جميعها فئة فرعية من BusAdapter، ABC في swarm/bus.py:66):

المحوّل	الموقع
`TelegramBusAdapter`	`kazma-gateway/kazma_gateway/adapters/telegram_bus.py:58`
`DiscordBusAdapter`	`adapters/discord_bus.py:31`
`SlackBusAdapter`	`adapters/slack_bus.py:31`

الناقل مُفرد على مستوى الوحدة (get_message_bus()، bus.py:282-287). يكون محوّل واحد فقط مُفعَّلًا في كل مرة. توصيل الأولوية في kazma-ui/kazma_ui/app.py:506-556:

يُجرَّب Telegram أولًا (_bus_wired = True عند السطر 516).
Discord فقط if not _bus_wired (السطر 524).
Slack فقط if not _bus_wired (السطر 540).

الأولوية: Telegram > Discord > Slack.

يستثني حارس pytest (السطر 504) عن قصد توصيل محوّلات حقيقية أثناء الاختبارات.

3.4 حلّ استدعاء الموافقة

يُحلِّل handle_callback() لكل محوّل مُعرِّف استدعاء المنصّة ويُعيد asyncio.Event:

Telegram: swarm_approve_<task_id> / swarm_reject_<task_id> (telegram_bus.py:302-333).
Discord: أزرار components v2 (discord_bus.py:238).
Slack: استدعاء تفاعلي (slack_bus.py:270).

4. البوابة C — نقاط حفظ خط المعالجة

موثَّقة في تنسيق السرب ← نقاط حفظ خط المعالجة. الملخّص:

_handle_pipeline_checkpoint (engine.py:889) ← CheckpointManager.handle_pipeline_checkpoint.
تُسلَّح مهلة الرفض التلقائي إن كان checkpoint_timeout > 0.
approve_checkpoint (engine.py:920) / reject_checkpoint (engine.py:990).
يُعيد restore_paused_tasks() تسليح المهل بعد إعادة التشغيل.
نقاط النهاية: POST /api/swarm/tasks/\{id\}/approve / /reject (routes_tasks.py:612, 657).

مقاطعات التوضيح/التأكيد الدلالية (طبقة الالتزام)

ناقل HITL الموحَّد نفسه الذي يحمل موافقات الأدوات الخطيرة (البوابات A/B/C أعلاه) يحمل أيضاً نوعاً ثانياً من المقاطعة: بطاقات توضيح/تأكيد دلالية تُنتجها طبقة الالتزام.

هذه ليست موافقات أدوات خطيرة — تُطلق عندما يكون قصد الوكيل غامضاً أو حرجاً قبل تعديل دائم، لا لأن الأداة خطيرة. مثال: يقول المستخدم “ذكّرني بالاجتماع” فيستدعي النموذج أداة الجدولة بتوقيت غامض. تُعيد بوابة الالتزام (authorize_effect) صيغة clarify، ويُوقف الرسم عبر interrupt() بحمولة تحمل سؤالاً وقائمة خيارات (لكلٍّ slots_patch).

نوع المقاطعة	متى تُطلق	`kind` الحمولة
موافقة أداة خطيرة	الأداة على قائمة الخطر (البوابات A/B/C)	`hitl_approval`
توضيح دلالي	القصد غامض (مثلاً وقت نسبي + حدث قريب)	`semantic_clarify`
تأكيد دلالي	فعل حرج يحتاج موافقة صريحة	`semantic_confirm`

تُعرض على كل منصة — الويب (المحادثة + الشريط الجانبي)، تيليجرام، ديسكورد، وسلاك. كل بطاقة دلالية تعرض زراً لكل خيار؛ زرّا الموافقة/الرفض الحاليان يُعيّنان إلى أفضل خيار / إلغاء. عند الاستئناف، يُطبَّق slots_patch للخيار المختار على وسطاء الأداة ويُكمل الدور؛ الإلغاء نهائي.

خريطة القرار الكاملة ومحلّلات الأفعال ورموز النطاق والأوضاع ومفاتيح الإيقاف موثَّقة في الدليل المخصّص: طبقة الالتزام (الحل قبل التنفيذ).

5. قوائم الأدوات الخطيرة (ثلاث منها) {#danger-tool-lists-three-of-them}

تستخدم البوابات الثلاث قوائم أدوات خطيرة مختلفة. هذا متعمَّد (لكل مسار دلالات مختلفة) لكنه سهل الخطأ.

5.1 البوابة A (الرسم البياني) — `kazma.yaml safety.hitl.require_approval_for`

الافتراضي (kazma.yaml تحت safety.hitl.require_approval_for، ويجب أن يطابق CANONICAL_DANGER_TOOLS): يشمل file_write، file_apply_patch، file_delete، shell_exec، code_exec، python_exec، computer_use، مُغيّرات git/GitHub، الخزنة، المُثبّتات، إرسال/حذف البريد، request_path_access، x_post، x_delete_post. ومُختبَر التكافؤ.

‏HITL دائم (شروط X): أدوات ALWAYS_HITL_TOOLS ‏(x_post، x_delete_post، x_schedule_post، x_cancel_scheduled_post) تتطلب موافقة حتى عندما يكون YOLO أو الصلاحيات الدائمة أو تعطيل HITL سيتخطى الأدوات الخطرة الأخرى. هذا مسار المحادثة. على الويب، استوديو X (/x) و/api/scheduled/x يعاملان نقرة المشغّل كموافقة. الـ API الرسمي فقط — انظر ناشر X.

بوابة أوامر git الكتابية الدائمة (2026-08): ‏git commit وpush وmerge وrebase وreset وcheckout -- وrestore وclean وrm وما شابه تتطلب بطاقة موافقة على كل مسار تنفيذ — لا يمكن لـ YOLO الموافقة تلقائيًا على تعديلات المستودع (سوء قراءة القصد يجب أن يكلّف حوارًا، لا commit؛ حادثة 2026-08-27). أما git القرائي (status/log/diff) فمعفى. ونوافذ YOLO افتراضيًا ساعة واحدة (كانت 4) — وKAZMA_YOLO_TTL_SECONDS يتجاوزها. انظر سجل المهام.

الاحتياطي في الكود إن لم يُضبط: DEFAULT_DANGER_TOOLS = ["file_write", "file_delete", "shell_exec", "vault_retrieve", "vault_delete"] (safety/hitl.py:41). تحمي أدوات الخزنة استرجاع/حذف الأسرار.

حارس التضييق (2026-08-19): قد تنحرف القائمة الفعّالة دون المجموعة الكانونية عبر الإعدادات/YAML — يتكرر تحذير كل 15 دقيقة يسمّي الأدوات المنحرفة. ويمكن للنشرات الصارمة فرض KAZMA_HITL_CANONICAL_FLOOR=1، التي توحّد أدوات الخطر الكانونية في القائمة الفعّالة فاستحيل التضييق دونها.

5.2 البوابة B (ناقل السرب) — `_EXTENDED_DANGER`

swarm/safety.py:23-31: DEFAULT_DANGER_TOOLS (file_write، file_delete، shell_exec، vault_retrieve، vault_delete) + python_exec، code_exec، spawn_agent، spawn_agents، schedule_task، cancel_scheduled، run_tests (مشغّل اختبارات MCP IDE).

بالإضافة إلى _SENSITIVE_READS = ["sqlite_query", "file_search"] (الأسطر 34-37) — مسموحة لكن مُسجَّلة.

5.3 البوابة C / MCP — `classify_mcp_tool()`

mcp/manager.py:71-88 — مطابقة ديناميكية لنمط الاسم (أدوات MCP تُكتشَف وقت التشغيل):

خطر (danger) إن وُجد أيٌّ من: write, delete, remove, exec, run, shell, bash, command, kill, terminate, install, deploy, upload, download, fetch, request, post, put, patch.
آمنة (safe) إن وُجد أيٌّ من: read, list, search, get, info, status, check, describe, query, count, exists, help.
غير معروفة (unknown) خلاف ذلك.

غير المعروفة تُعدّ خطرة افتراضيًا. يتطلّب UnifiedToolExecutor.execute() (manager.py:725-727) موافقة لكلٍّ من danger وunknown. لا تُضعِّف هذا أبدًا.

6. التكامل التشفيري (ما وراء HITL)

6.1 توقيع HMAC للمهارات (Hub)

موثَّق في المهارات وMCP والأدوات ← التوقيع التشفيري. الملخّص:

يكتب kazma hub sign قيمتي checksum (SHA-256) + signature (HMAC-SHA256 فوق checksum، بمفتاح KAZMA_SECRET) في skill_manifest.yaml.
يتحقّق SkillLoader._load_module_from_file من كليهما عبر hmac.compare_digest (وقت ثابت) ويرفض تحميل المهارات المُعبَث بها أو غير الموقَّعة عند اشتراط ذلك.

6.2 تفويض Ed25519 + AES-256-GCM

delegation/security.py (DelegationSecurity، السطر 30):

التوقيع: Ed25519 (الأسطر 81-119).
التشفير: اتفاقية مفاتيح X25519 + AES-256-GCM (الأسطر 121-161).
تُوقَّع الطلبات عند الإرسال (protocol.py:153)، وتُتحرَّى عند الاستلام مع فشل-مُغلق عند التوقيع المفقود/غير الصالح (:179-208).

هذا تفويض بين الوكلاء — لا علاقة له بـ MCP أو المهارات.

6.3 سرّ نقطة نهاية HITL

نقطة النهاية POST /api/approve/\{thread_id\} محمية بـ KAZMA_SECRET (ترويسة/كوكي، secrets.compare_digest). مسار التوليد التلقائي: يُحلِّل get_kazma_secret() (config_store.py:36-77) البيئة KAZMA_SECRET ← KAZMA_AUTH_DISABLED ← تخطّي pytest ← security.secret في قاعدة البيانات ← توليد تلقائي عبر secrets.token_hex(16).

7. سلوكيات الفشل-المُغلق (الجرد)

المكوّن	سلوك الفشل-المُغلق
`SafetyMiddleware.check_sync`	يحجب الأدوات الخطيرة عند غياب ناقل حقيقي + `allow_headless_danger=False`.
`ToolRegistry.execute`	أي استثناء في فحص السلامة ← “blocked — SafetyMiddleware unavailable”.
`classify_mcp_tool`	`unknown` ← يتطلّب موافقة.
`SkillLoader`	توقيع مُعبَث به/مفقود ← `SkillLoadError`، دون تحميل.
Hub write API	غياب `KAZMA_SECRET` ← رفض جميع عمليات الكتابة.
استلام التفويض	توقيع مفقود/غير صالح ← رفض.
نقطة نهاية موافقة HITL	موافقة بين مستخدمين ← 403؛ غياب `KAZMA_SECRET` ← راجع التحذير أدناه.

⚠ تحذير الإنتاج: إن كان KAZMA_SECRET غير مضبوط، فقد يُعيد get_kazma_secret() سلسلة فارغة "" وتصبح نقاط نهاية الموافقة غير مُصدَّقة. اضبط KAZMA_SECRET دائمًا لأي نشر غير محلي. (لا يربط kazma serve على 0.0.0.0 إلا عند ضبط KAZMA_SECRET — وهذا عن قصد.)

8. ملفات إعداد الأمان

يُعلن kazma-security.yaml عن الوضعية عبر scanning، وdisclosure، وbug_bounty، وhardening (8 فحوصات: secrets_in_logs، input_validation، rbac_enforcement، tls_required، dependency_audit، least_privilege، audit_trail، config_integrity). راجع الإعداد ← إعداد الأمان. يُعرِّف kazma-permissions.yaml قوائم السماح/المنع لأدوات MCP المستندة إلى الأقسام (أقسام ALMuhalab) مع قواعد عبر الأقسام (require_explicit_approval، max_approval_duration_hours: 24، audit_all_access).

8.1 مُشغِّل التحصين (`security/hardening.py`)

يُشغِّل SecurityHardeningRunner الفحوصات عند بدء التشغيل؛ المفاتيح هي run_on_startup: true، fail_on_critical: true، auto_fix: false. يُعيَّن كل وسم فحص yaml إلى دالة مُنفَّذة:

الفحص (وسم yaml)	الدالة المُنفَّذة	الخطورة
`secrets_in_logs`	`check_no_hardcoded_secrets` (مسح بالتعبيرات النمطية لـ `api_key`/`secret`/`token`/`password`/`AWS`/`PRIVATE_KEY`)	critical
`tls_required`	`check_encrypted_communications` (مسح TLS/SSL/HTTPS/mTLS)	high
`rbac_enforcement`	`check_rbac_enforcement`	high
`dependency_audit`	`check_dependency_vulnerabilities` ← `DependencyScanner`	critical
(عزل MCP)	`check_mcp_sandboxing`	high
(بيانات manifest للمهارات)	`check_skill_manifest_validity`	medium
(تسجيل التدقيق)	`check_audit_logging`	high
(تصعيد الصلاحيات)	`check_permission_escalation` (`os.system`، `subprocess(...shell=True)`، `eval`، `exec`، `__import__`، `setattr(...__...)`)	critical
`least_privilege`، `config_integrity`	⚠ خارطة طريق (لا تنفيذ مخصَّص)	—

يستطيع fix_issues(auto_fix) إنشاء ملف .env وتعديل .gitignore لفحص الأسرار.

8.2 مسح التبعيات (`security/dependency_scanner.py`)

الماسح	المصادر	الذاكرة المؤقتة / التاريخ
`DependencyScanner`	OSV (`api.osv.dev`)	ذاكرة مؤقتة JSON في `kazma-data/vuln_cache.json`
`DependabotStyleScanner`	OSV + GitHub Advisories + NVD	SQLite في `kazma-data/security_scan.db`؛ يُلغي التكرار بـ `(package, vuln_id)`

كلاهما يحلِّل requirements.txt وpyproject.toml. يُشغِّل DependabotStyleScanner إضافيًا scan_skill_manifests() (يُعلِّم إعدادات MCP المشبوهة: eval/exec/system في الأوامر، ومتغيرات البيئة TOKEN/SECRET/KEY، و--privileged، وnetwork: host؛ وأنماط التصعيد مثل sudo/chmod 777/setuid)، وcreate_github_issue() عبر gh CLI، وgenerate_advisory()، وcheck_for_updates().

kazma-security.yaml: فاصل scanning 24 ساعة، severity_threshold: medium، auto_create_issues: true.

8.3 تدفّق الإفصاح (`security/disclosure.py`)

يُفرِض SQLite kazma-data/disclosure.db سلسلة الانتقال submitted → acknowledged → investigating → confirmed → patched → closed. يُولِّد publish_advisory() رمزاً نائباً لـ CVE + قالب markdown، لكن من حالتي patched/closed فقط. يُوقِّع encrypt_report() حمولة JSON باستخدام HMAC-SHA256 بمفتاح KAZMA_DISCLOSURE_KEY.

kazma-security.yaml: نافذة الاستجابة 48 ساعة، التقييم 7 أيام، عنوان URL لمفتاح PGP، القنوات المُشفَّرة (البريد + Signal)، مكافأة الثغرات 50–2000 دولار أمريكي.

تحقَّق من التطبيق وقت التشغيل لفحوصات kazma-security.yaml مقابل مُشغِّل التحصين قبل الاعتماد عليها. يُعلن الملف عن السياسة؛ أكِّد أن المُشغِّل يُفرِض كل فحص عند بدء التشغيل (hardening.run_on_startup: true، fail_on_critical: true).

9. توصيات التحصين

اضبط KAZMA_SECRET دائمًا للنشر غير المحلي. ولِّده عبر openssl rand -hex 32.
شغِّل خوادم MCP من نوع stdio في بيئة معزولة (sandbox). لا يتمتّع ناقل stdio بأي مصادقة ويرث بيئة العملية.
فضِّل MCP من نوع SSE مع مصادقة bearer لأي خادم MCP بعيد.
وقِّع جميع المهارات (kazma hub sign) وأبقِ KAZMA_SECRET متَّسقًا عبر التحميل — وإلا يفشل التحقّق من التوقيع.
أبقِ بوابات HITL الثلاث مُفعَّلة. لا تمرِّر hitl_config=None في موقع بناء إنتاجي.
لا تضبط allow_headless_danger=True في الإنتاج. إنه مخرج الاختبار/التطوير.
اعمل بحساب المستخدم غير الجذري kazma في Docker (يقوم Dockerfile بذلك أصلًا).
اربط على 127.0.0.1 ما لم يكن لديك وكيل عكسي + KAZMA_SECRET مُعدّ.
تعدد المشغّلين: اضبط قوائم السماح للمنصات + KAZMA_GATEWAY_STRICT_ALLOWLIST=1 (2026-08-19) — مُحوّلات Telegram/Discord/Slack تعمل افتراضيًا بالسماح-للجميع توافقًا مع التثبيتات الأحادية؛ والوضع الصارم يفشل مغلقًا عند قائمة سماح فارغة.
اضبط KAZMA_HITL_CANONICAL_FLOOR=1 في النشرات الصارمة حتى لا يمكن تضييق قائمة أدوات الخطر دون المجموعة الكانونية.

ملاحظات تدقيق التوثيق

اسم الصنف: صنف سلامة السرب هو SafetyMiddleware، وليس SafetyGate/SafetyChecker. حُدِّث في كامل الوثيقة.
موقع نقطة نهاية الموافقة: POST /api/approve/\{thread_id\} موجود في routes_direct.py:454، وليس في app.py.
رقم سطر موقع بناء App.py: إعادة التجميع عند بدء التشغيل تقع في kazma-ui/kazma_ui/app.py:741-751، وليس ~966.
“مستويات الثقة (Trust tiers)” غير موجودة كميزة أمان — مجرَّد علم منطقي certified وسلسلة إعداد trust: trusted غير مستخدَمة.
MCP من نوع stdio بلا مصادقة. موثَّق صراحةً؛ خطِّط للعزل وفق ذلك.
ثلاث قوائم أدوات خطيرة متميِّزة يجب أن تبقى متزامنة مع القصد. إن إضافة أداة خطرة جديدة إلى البوابة A (kazma.yaml) لا تضيفها إلى البوابة B (_EXTENDED_DANGER) أو البوابة C (المستندة إلى الأنماط).