IronCurtain

بيئة تشغيل آمنة* للوكلاء الاصطناعيين المستقلين، حيث تُشتق سياسة الأمان من دستور قابل للقراءة البشرية.

*عندما يكتب أحدهم "آمن"، يجب أن تشك على الفور. ماذا نعني بآمن؟

[!WARNING] نموذج بحثي. IronCurtain هو مشروع بحثي في مرحلة مبكرة يستكشف كيفية جعل وكلاء الذكاء الاصطناعي آمنين بما يكفي ليكونوا مفيدين فعليًا. قد تتغير واجهات البرمجة (APIs)، وصيغ الإعدادات، والبنية المعمارية. المساهمات والملاحظات مرحّب بها.

عرض توضيحي

يُطلب من الوكيل استنساخ مستودع ودفع التغييرات. يتم تصعيد كلٍّ من git_clone وgit_push بواسطة محرك السياسات، لكن الموافق التلقائي يعتمدهما تلقائيًا — إذ وفّر إدخال المستخدم الموثوق من وضع الأوامر (Ctrl-A) نية واضحة، لذا لم تكن هناك حاجة إلى /approve يدوي.

المشكلة

تستطيع وكلاء الذكاء الاصطناعي المستقلون إدارة الملفات، وتشغيل أوامر git، وإرسال الرسائل، والتفاعل مع واجهات البرمجة (APIs) نيابةً عنك. لكن أُطر عمل الوكلاء الحالية تمنح الوكيل نفس صلاحيات المستخدم، مثل الوصول الكامل إلى نظام الملفات وبيانات الاعتماد والشبكة. يطلق باحثو الأمان على هذا السلطة المحيطة (ambient authority)، ويعني ذلك أن حقنة تعليمات واحدة (prompt injection) أو انحرافًا عبر جولات متعددة (multi-turn drift) يمكن أن يدفع الوكيل إلى حذف الملفات، أو تسريب البيانات، أو دفع تعليمات برمجية خبيثة.

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

النهج

تتبع IronCurtain مسارًا مختلفًا: عبّر عن نيتك الأمنية بالإنجليزية البسيطة، ثم دع النظام يكتشف كيفية التنفيذ.

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

الأفكار الأساسية:

• الوكيل غير موثوق. تفترض IronCurtain أن نموذج اللغة الكبير (LLM) قد يكون مخترقًا عبر حقنة تعليمات أو انحراف. لا يعتمد الأمان على كون النموذج "جيدًا".
• إنجليزية في المُدخل، وتنفيذ في المُخرَج. أنت تكتب النية ("لا عمليات git تدميرية دون موافقة")؛ يقوم النظام بتجميعها في قواعد حتمية تُطبَّق دون مزيد من تدخل LLM في وقت التشغيل.
• الوساطة الدلالية (Semantic interposition). بدلاً من منح الوكيل وصولًا خامًا إلى النظام، تمر جميع التفاعلات عبر خوادم MCP (نظام الملفات، git، إلخ). يمر كل استدعاء أداة عبر محرك سياسات يمكنه السماح أو الرفض أو التصعيد إلى المستخدم للموافقة.
• الدفاع في العمق. يعمل كود الوكيل في معزل V8 بدون وصول مباشر إلى المضيف. الطريق الوحيد للخروج هو عبر استدعاءات أدوات MCP ذات معنى دلالي، وكل واحدة منها تُفحص مقابل السياسة.

البنية المعمارية

تدعم IronCurtain وضعين للجلسات بنماذج ثقة مختلفة:

• الوكيل المدمج (وضع الكود Code Mode) — يكتب وكيل LLM الخاص بـ IronCurtain مقاطع TypeScript تُنفَّذ في صندوق رمل V8. تتحكم IronCurtain في الوكيل وصندوق الرمل ومحرك السياسات. يخرج كل استدعاء أداة من صندوق الرمل كطلب MCP منظم، ويمر عبر محرك السياسات (سماح / رفض / تصعيد)، وعندها فقط يصل إلى خادم MCP الحقيقي.

• وضع وكيل Docker — وكيل خارجي (Claude Code أو Goose أو غيره) يعمل داخل حاوية Docker دون وصول إلى الشبكة. تقوم IronCurtain بالتوسط في التأثيرات الخارجية: تمر استدعاءات API الخاصة بـ LLM عبر وكيل MITM ينهي TLS (قائمة مضيفين مسموح بها، واستبدال المفاتيح من الوهمية إلى الحقيقية)، وتمر استدعاءات أدوات MCP عبر نفس محرك السياسات، وتُثبَّت الحزم (npm/PyPI) عبر وكيل سجل تحقق.

في كلا الوضعين، الوكيل غير موثوق. لا يعتمد الأمان على اتباع النموذج للتعليمات — بل يُفرض عند الحدود.

انظر SANDBOXING.md للبنية الكاملة مع الرسوم البيانية، وتحليل الثقة طبقة-بطبقة، وملاحظات منصة macOS.

بدء سريع

المتطلبات الأساسية

• Node.js 22 أو 24 أو 26 — إصدارات Node.js الرئيسية ذات الأرقام الزوجية التي تختبرها IronCurtain (مطلوبة بواسطة isolated-vm؛ يعمل 24 و26 بتثبيت ملفات ثنائية مُجهزة مسبقًا، بينما يُجمَّع Node 22 من المصدر عند التثبيت ويحتاج إلى سلسلة أدوات C/C++). الإصدارات ذات الأرقام الفردية (23، 25) تعمل لكنها غير مُختبرة — يحذّر ironcurtain doctor عند ذلك.
• Docker — غير مطلوب لكن موصى به بشدة لوضع وكيل Docker، الذي يوفر أقوى عزل. على macOS 26+ (رقائق Apple)، يعمل container من Apple كبديل للخلفية (VM لكل حاوية؛ يُستخدم تلقائيًا عندما تكون خدماته قيد التشغيل — انظر containerRuntime في ironcurtain config)
• مفتاح API لمزود LLM واحد على الأقل (Anthropic أو Google أو OpenAI)

التثبيت

كأداة CLI عمومية (للمستخدمين النهائيين):```bash npm install -g @provos/ironcurtain

**من المصدر (التطوير):**```bash
git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install

الإعداد لمرة واحدة

1. عيّن مفتاح API الخاص بك:```bash export ANTHROPIC_API_KEY=sk-ant-...

يمكنك أيضًا وضع المفاتيح في ملف `.env` في جذر المشروع (يتم تحميله تلقائيًا عبر `dotenv`)، أو إضافتها إلى `~/.ironcurtain/config.json` عبر `ironcurtain config`. متغيرات البيئة لها الأولوية على قيم ملف الإعداد. المدعومة: `ANTHROPIC_API_KEY`, `GOOGLE_GENERATIVE_AI_API_KEY`, `OPENAI_API_KEY`.

**2. تشغيل معالج الإعداد الأول** (قم بتشغيله صراحةً قبل استخدام مسار mux الموصى به؛ كما يتم تشغيله تلقائيًا عند أول `ironcurtain start` غير mux):```bash
ironcurtain setup

يرشدك خلال إعداد رمز GitHub، وموفر البحث على الويب، واختيار النموذج، والإعدادات الأخرى. ينشئ ~/.ironcurtain/config.json بخياراتك.

تشغيل IronCurtain

يأتي IronCurtain مع سياسة افتراضية موجهة نحو تجربة المطور — العمليات للقراءة فقط مسموحة، بينما التغييرات (الكتابة، الدفع، إنشاء طلبات السحب) تتطلب موافقة بشرية. يمكنك البدء باستخدامه فورًا بعد الإعداد.

مُضاعِف المحطات الطرفية (موصى به)

الطريقة الموصى بها لاستخدام IronCurtain. تمنحك القوة الكاملة لواجهة TUI التفاعلية لوكيلك (Claude Code أو Goose) بينما يتوسط IronCurtain في كل استدعاء أداة عبر محرك السياسات الخاص به — كل ذلك في محطة طرفية واحدة.```bash ironcurtain mux

**القدرات الأساسية:**

- **واجهة TUI كاملة للوكيل** — يعمل الوكيل في PTY داخل حاوية Docker بدون وصول إلى الشبكة. تتفاعل معه تمامًا كما لو كان يعمل محليًا.
- **معالجة التصعيد المضمّنة** — عندما تحتاج استدعاء أداة إلى موافقة، تظهر أداة اختيار التصعيد فوق الشاشة بإجراءات بمفتاح واحد (a/d/w للموافقة/الرفض/القائمة البيضاء). استخدم `/approve+ N` لإضافة نطاق أو مسار إلى القائمة البيضاء لبقية الجلسة.
- **إدخال مستخدم موثوق** — النص المكتوب في وضع الأوامر (Ctrl-A) يُلتقط على جانب المضيف قبل دخول الحاوية. وهذا ينشئ إشارة نية موثَّقة يمكن للموافِق التلقائي استخدامها — على سبيل المثال، كتابة "push my changes to origin" ستوافق تلقائيًا على تصعيد `git_push` لاحق.
- **إدارة التبويبات** — قم بإنشاء جلسات متزامنة متعددة (`/new`)، والتبديل بينها (`/tab N`، Alt-1..9)، وإغلاقها (`/close`). يمكن تشغيل مثيلات mux متعددة بالتوازي.

انظر [DEVELOPER_GUIDE.md](https://github.com/provos/ironcurtain/blob/master/DEVELOPER_GUIDE.md) للشرح الكامل: أوضاع الإدخال، نموذج أمان الإدخال الموثوق، سير عمل التصعيد، ومرجع لوحة المفاتيح.

### جلسات غير mux

استخدم `ironcurtain start` للمهام السريعة لمرة واحدة، أو السكربتات، أو عندما تريد صراحةً الوكيل المحلي المدمج. للعمل التفاعلي المعتاد مع وكيل Docker، استخدم `ironcurtain mux`.```bash
ironcurtain start "Summarize the files in ./src"     # Single-shot mode
ironcurtain start -w ./my-project "Fix the tests"    # Single-shot workspace mode
ironcurtain start --agent builtin                    # Local builtin REPL, no Docker
ironcurtain start --persona my-assistant "Check my email"  # Use a persona

أوضاع التشغيل الأخرى

يدعم IronCurtain أيضًا استئناف الجلسة (--resume <session-id>) ووضعًا إرثيًا لـ PTY الخام/التصحيح ونقل رسائل Signal للموافقة عبر الجوال ووضعًا خفيًا للمهام المجدولة عبر cron. يوفر الوضع الخفي واجهة ويب اختيارية (--web-ui) للمراقبة عبر المتصفح ومعالجة التصعيد. راجع RUNNING_MODES.md للتفاصيل.

سير عمل متعدد الوكلاء

ينسّق IronCurtain عمل وكلاء ذكاء اصطناعي متعددين عبر سير عمل منظمة. يسعى سير عمل اكتشاف الثغرات المرفق إلى اصطياد أخطاء أمان الذاكرة والأخطاء المنطقية في الكود الأصلي عبر خط أنابيب تسخير متعدد المستويات (المستوى 1 وظيفة معزولة → المستوى 2 متعدد المكونات → المستوى 3 بناء كامل) مع بوابات تغطية libFuzzer/AFL++ وحالات discover/triage مدفوعة بالفرضيات وبوابة نهائية لمراجعة التقرير بشريًا. يشغّل سير عمل التصميم والترميز دورات تخطيط / تصميم / تنفيذ / مراجعة، مع بوابات بشرية أيضًا. يعمل كل وكيل في حاوية Docker خاصة به مع حدود سياسات خاصة بالدور؛ يدير المحرك انتقالات الحالات وتمرير القطع الأثرية ونقاط فحص استئناف التعطل تلقائيًا. مفتوح المصدر، ويعمل بالكامل على جهازك، ويفرض سياسات أمنية لكل وكيل عبر محرك السياسات القائم على الدستور، ويعمل مع أي وكيل داخل حاوية Docker — مماثل في النطاق لـ Amazon Kiro وGoogle Jules في مهام البرمجة، لكن مع أمان من الدرجة الأولى وتنسيق تعريف سير عمل قابل للتوسيع.

واجهة الويب هي الواجهة المقصودة لتشغيل سير العمل. ابدأ الوضع الخفي، وافتح الرابط المطبوع، وقم بإدارة التشغيلات من صفحة Workflows — الرسم البياني لآلة الحالة أعلاه مباشر، يبث الخط الزمني لرسائل الوكلاء مع عرض Markdown، تتضمن مراجعات البوابة مساحة عمل + مستعرض القطع الأثرية، وتبقى التشغيلات السابقة مدرجة.```bash ironcurtain daemon --web-ui

الوصول إلى CLI متاح للبرمجة النصية والأتمتة والتصحيح:```bash
ironcurtain workflow start vuln-discovery \
  "Find memory-safety bugs in libical" --workspace ~/src/libical
ironcurtain workflow start design-and-code \
  "Build a REST API with authentication"

انظر WORKFLOWS.md للحصول على الوثائق الكاملة.

تخصيص سياستك

تعمل السياسة الافتراضية بشكل جيد للتطوير العام، لكن يمكنك تكييفها مع سير عملك:

1. خصّص دستورك (اختياري لكن يُنصح به):```bash ironcurtain customize-policy

محادثة بمساعدة LLM تولّد دستورًا مخصصًا لسير عملك، يُحفظ في `~/.ironcurtain/constitution-user.md`. يمكنك أيضًا تعديل هذا الملف مباشرةً.

**2. تجميع السياسة:**```bash
ironcurtain compile-policy

يترجم دستورك إلى قواعد حتمية، ويولّد سيناريوهات اختبار، ويتحقق منها. تذهب المخرجات المُجمَّعة إلى ~/.ironcurtain/generated/.

الشخصيات

الشخصيات هي ملفات تعريف سياسات مسماة — كلٌّ منها يضم دستورًا، وسياسة مُجمَّعة، ومساحة عمل دائمة، وذاكرة دلالية. استخدمها لتشغيل وكلاء بأدوار أو مستويات وصول مختلفة.```bash ironcurtain persona create my-assistant # Create a persona ironcurtain persona compile my-assistant # Compile its policy ironcurtain start --persona my-assistant "Check my calendar"

في وضع mux، يُنشئ `/new my-assistant` تبويبًا باستخدام تلك الشخصية. يمكن أيضًا إسناد الشخصيات إلى مهام cron. راجع [DAEMON.md](https://github.com/provos/ironcurtain/blob/master/DAEMON.md) لإعداد المهام المجدولة.

يمكن أيضًا إدارة الشخصيات من [واجهة الويب](https://github.com/provos/ironcurtain/blob/master/DAEMON.md#persona-policy-management) — تصفح، وأنشئ، وعدّل الدساتير، وجمّع السياسات مع تقدم مباشر. ولأن السياسة تمثل حدًا أمنيًا، فإن أدوات التحكم في التعديل بواجهة الويب تكون للقراءة فقط ما لم يُشغَّل البرنامج الخفي مع `--allow-policy-mutation` (معطّل افتراضيًا).

### المهارات

ضع حزم SKILL.md تحت `~/.ironcurtain/skills/<name>/` لجعل الإرشادات المخصصة (سكربتات مساعدة، فحوصات حتمية، معرفة بالمجال) متاحة لكل جلسة وكيل Docker. تُجهَّز المجموعة المدمجة في دليل مضيف خاص بكل حزمة وتُثبَّت bind-mounted **للقراءة فقط** داخل الحاوية عند المسار الذي يجتازه الاكتشاف الأصلي للوكيل النشط — يُوجَّه Claude Code إلى دليل الإعداد عبر `--add-dir`، ويفحص Goose المسار `~/.config/goose/skills/<name>/SKILL.md`. يكتشف الوكيل هذه المهارات تلقائيًا ويقرر متى يقرأها بناءً على وصف frontmatter لكل مهارة. إن _تنسيق_ SKILL.md هو المعيار المفتوح الذي تبنته Claude Code وGoose وCodex؛ ويختلف _مسار الاكتشاف_ فقط من وكيل إلى آخر. يمكن أن تحمل سير العمل مهارات خاصة بكل حالة داخل حزمة سير العمل — راجع [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/master/WORKFLOWS.md#skills).

## السياسة: الدستور → الإنفاذ

تكتب النية باللغة الإنجليزية البسيطة؛ يقوم IronCurtain بتجميعها في قواعد حتمية:```
constitution.md → [Annotate] → [Compile] → [Resolve Lists] → [Generate Scenarios] → [Verify & Repair]
                      │              │              │                  │                     │
                      ▼              ▼              ▼                  ▼                     ▼
              tool-annotations  compiled-policy  dynamic-lists   test-scenarios       verified policy
                  .json            .json            .json            .json          (or build failure)

1. التعليق — صنّف وسائط كل أداة MCP حسب الدور (read-path، write-path، delete-path، none).
2. التجميع — ترجم الدستور الإنجليزي إلى قواعد if/then حتمية. تُصدر المراجع الفئوية ("major news sites"، "my contacts") كمراجع رمزية @list-name.
3. حل القوائم — حلّ القوائم الرمزية إلى قيم ملموسة عبر معرفة LLM أو استخدام أدوات MCP (مثل الاستعلام عن قاعدة بيانات جهات الاتصال). تُكتب إلى dynamic-lists.json، ويمكن للمستخدم تعديلها. تُتخطى عندما لا توجد قوائم.
4. توليد السيناريوهات — أنشئ سيناريوهات اختبار من الدستور بالإضافة إلى اختبارات الثبات الإلزامية المكتوبة يدويًا.
5. التحقق والإصلاح — شغّل السيناريوهات على محرك السياسات الفعلي. يحلل محكّم LLM حالات الفشل ويولّد إصلاحات موجهة (حتى جولتين). يفشل البناء إذا تعذر التحقق من السياسة.

جميع المخرجات مخزنة مؤقتًا حسب تجزئة المحتوى — فقط المدخلات المتغيرة تسبب إعادة التجميع.

كيف تبدو القواعد المجمّعة

بند من الدستور مثل:```markdown

• The agent may perform read-only git operations (status, diff, log) within the sandbox without approval.
• The agent must receive human approval before git push, pull, fetch, or any remote-contacting operation.

يُجمَّع إلى:```json
[
  { "tool": "git_status", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_diff", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_push", "decision": "escalate", "reason": "Remote-contacting git operations require human approval" }
]

أي استدعاء لا يطابق قاعدة allow أو escalate صريحة يُرفض افتراضيًا.```bash ironcurtain annotate-tools --server filesystem # Annotate one server (merge with existing) ironcurtain annotate-tools --all # Re-annotate all servers ironcurtain compile-policy # Compile constitution into rules and verify ironcurtain refresh-lists # Re-resolve dynamic lists without full recompilation ironcurtain refresh-lists --list major-news # Refresh a single list

راجع ملف `~/.ironcurtain/generated/compiled-policy.json` المُنشأ — هذه هي القواعد الدقيقة المُطبَّقة في وقت التشغيل.

## الإعدادات

يخزّن IronCurtain بيانات الإعدادات والجلسات في `~/.ironcurtain/`:```
~/.ironcurtain/
├── config.json              # User configuration
├── constitution.md          # User-local base constitution (overrides package default)
├── constitution-user.md     # Your policy customizations (generated by customize-policy)
├── generated/               # User-compiled policy artifacts (overrides package defaults)
├── personas/                # Persona directories (constitution, policy, workspace, memory)
├── skills/                  # User-global SKILL.md packages, mounted into every Docker session
├── jobs/                    # Cron job definitions, workspaces, and run records
├── sessions/
│   └── {sessionId}/
│       ├── sandbox/         # Per-session filesystem sandbox
│       ├── escalations/     # File-based IPC for human approval
│       ├── audit.jsonl      # Per-session audit log
│       └── session.log      # Diagnostics
└── workflow-runs/           # Shared-container workflow runs (see below)

تشغيلات الجلسة الواحدة (ironcurtain start، تبويبات mux، مهام cron) تُكتب تحت sessions/. بينما تُكتب تشغيلات سير العمل ذات الحاوية المشتركة تحت workflow-runs/ — راجع القسم التالي.

تخطيط تشغيل سير العمل

يمكن لتعريف سير العمل الاشتراك في حاوية Docker مشتركة عن طريق تعيين settings.sharedContainer: true في ملف YAML الخاص به. في هذا الوضع، تعمل كل حالة عامل داخل نفس الحاوية طويلة العمر وتتشارك مثيلاً واحداً لمحرك السياسات؛ وبين الحالات، يقوم المُنسِّق بتبديل السياسة النشطة على الفور بحيث يرى كل شخصية قواعدها الخاصة. تُخزَّن جميع مخرجات التشغيل في شجرة واحدة:``` ~/.ironcurtain/workflow-runs// ├── audit.jsonl # Persona-tagged append-only audit ├── messages.jsonl # Orchestrator message log ├── workspace/ # Agent workspace (filesystem MCP root) ├── bundle/ # Shared container support (claude-state, orientation, sockets, escalations, system-prompt.txt) ├── states/ │ └── ./ # session.log + session-metadata.json per invocation └── proxy-control.sock # Coordinator UDS for policy hot-swap

لا يتم إنشاء أي إدخالات لكل جلسة تحت `~/.ironcurtain/sessions/` لتشغيل سير عمل بحاوية مشتركة. الأوامر المرئية للمستخدم (`ironcurtain workflow start|resume|inspect|list`) لم تتغير. راجع [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/master/WORKFLOWS.md) لتأليف تعريفات سير العمل ودورة الحياة الكاملة.

تحرير التكوين بشكل تفاعلي:```bash
ironcurtain config

مجالات التكوين الرئيسية: النماذج ومفاتيح API، وميزانيات الموارد (حدود الرموز/الخطوات/الوقت/التكلفة)، وتصعيدات الموافقة التلقائية، ومزود البحث على الويب، وتنقيح التدقيق، وإعدادات LLM لخادم الذاكرة. راجع CONFIG.md للحصول على المرجع الكامل.

لتوجيه حركة مرور LLM عبر بوابة مثل LiteLLM أو OpenRouter (في كل من Code Mode وDocker Agent Mode)، راجع MODEL_ROUTING.md.

وجّه وكلاء Docker عبر ملفات تعريف مزودي النماذج (مثل GLM-5.2 عبر OpenRouter، بدون sidecar) باستخدام ironcurtain config → Model Providers، ثم اختر ملفًا تعريفيًا في /new أو باستخدام --provider-profile — راجع MODEL_ROUTING.md.

الإمكانات المضمنة

يأتي IronCurtain مع ستة خوادم MCP مكوّنة مسبقًا. جميع استدعاءات الأدوات (باستثناء الذاكرة) تخضع لسياسة المُجمَّعة الخاصة بك.

العمليات للقراءة فقط مسموحة في السياسة الافتراضية؛ العمليات المعدِّلة (الكتابة، الدفع، إنشاء PR) تُصعَّد لموافقة بشرية. تستخدم الأدوات تسمية server.tool (مثل filesystem.read_file وmemory.recall). راجع ADDING_MCP_SERVERS.md لإضافة خادم خاص بك.

النفاذ عبر الشبكة (وضع Docker Agent)

في وضع Docker Agent، لا تملك الحاوية وصولاً إلى الشبكة — تتدفق كل حركة المرور عبر وكيل MITM الخاص بـ IronCurtain. افتراضيًا، لا يمكن الوصول إلا إلى نطاقات مزودي LLM. يمكن للوكيل طلب الوصول إلى نطاقات إضافية أثناء التشغيل عبر خادم MCP الافتراضي proxy (add_proxy_domain). يتطلب كل طلب موافقة بشرية عبر عملية التصعيد.

تحصل النطاقات المعتمدة على نفق نفاذ خام — تُمرَّر اتصالات HTTP وHTTPS وWebSocket دون فحص محتوى أو حقن بيانات اعتماد. يمنح هذا الوكيل فائدة أكبر (استدعاء واجهات برمجة تطبيقات خارجية، بث بيانات من خدمات خارجية) لكنه يعني أن حركة المرور إلى تلك النطاقات بدون وساطة. راجع SECURITY_CONCERNS.md القسم 2b-i لنموذج التهديد وDEVELOPER_GUIDE.md لتفاصيل الاستخدام.

نموذج الأمان

صُمم IronCurtain حول نموذج تهديد محدد: تمرد LLM. يمكن أن يحدث ذلك عبر حقن المطالبات (prompt injection) (بريد إلكتروني خبيث أو صفحة ويب تختطف الوكيل) أو عبر الانحراف متعدد الجولات (multi-turn drift) (حيث ينحرف الوكيل تدريجيًا عن نية المستخدم خلال جلسة طويلة).

ما يفرضه IronCurtain

• احتواء نظام الملفات — تحليل مسار يدرك الروابط الرمزية (symlink-aware) يمنع هجمات اجتياز المسار (path traversal) والهروب عبر الروابط الرمزية (symlink-escape).
• سياسة لكل أداة — يُقيَّم كل استدعاء أداة MCP مقابل القواعد المُجمَّعة. يصنّف محرك السياسة وسائط الأدوات حسب الدور (read-path، write-path، delete-path) لاتخاذ قرارات دقيقة.
• ثوابت بنيوية — بعض وسائل الحماية مبرمجة بشكل ثابت (hardcoded) ولا يمكن تجاوزها عبر الدستور: لا يمكن للوكيل أبدًا تعديل ملفات السياسة الخاصة به أو سجلات التدقيق أو الإعدادات.
• التصعيد البشري — عندما تقول السياسة "صعّد"، يتوقف الوكيل ويجب على المستخدم الموافقة أو الرفض صراحةً. اختياريًا، يتعامل مُوافِق تلقائي قائم على LLM مع الحالات غير الغامضة (راجع CONFIG.md).
• سجل التدقيق — يُسجَّل كل استدعاء أداة وكل قرار سياسة في سجل تدقيق JSONL يُلحق به فقط (append-only).
• حدود الموارد — ميزانيات الرموز (token) والخطوات والوقت والتكلفة تمنع الجلسات الجامحة.

القيود المعروفة

هذا نموذج أولي بحثي. تشمل الفجوات المعروفة ما يلي:

• دقة تجميع السياسة — يمكن للمترجم القائم على LLM أن يسيء تفسير نية الدستور. تلتقط خط أنابيب التحقق (verification pipeline) العديد من الأخطاء لكنها ليست شاملة. راجع دائمًا compiled-policy.json المُجمّع.
• حدود معازل V8 — يستخدم Code Mode معازل V8 (isolates) وليس محاكاة افتراضية على مستوى نظام التشغيل. قد تسمح ثغرة يوم الصفر (zero-day) في V8 بالهروب.
• لا يوجد فحص للمحتوى الصادر — يمكن لوكيل مسموح له بكتابة الملفات ترميز بيانات حساسة لتجاوز الضوابط على مستوى المحتوى. مخطط له: فحوصات قابلية فهم قائمة على LLM للمحتوى الصادر.
• إرهاق التصعيد — كثرة التصعيدات الإيجابية الخاطئة قد تؤدي إلى موافقات اعتيادية. اضبط دستورك لتقليل المطالبات غير الضرورية.

راجع docs/SECURITY_CONCERNS.md للحصول على تحليل تفصيلي للتهديدات.

استكشاف الأخطاء وإصلاحها

التطوير```bash

npm test # Run all tests npm test -- test/policy-engine.test.ts # Run a single test file npm test -- -t "denies delete_file" # Run a single test by name npm run lint # Lint npm run build # TypeScript compilation + asset copy

انظر [TESTING.md](https://github.com/provos/ironcurtain/blob/master/TESTING.md) للحصول على دليل الاختبار الكامل، بما في ذلك أعلام اختبار التكامل والاصطلاحات.

### هيكل المشروع```
src/
├── index.ts                    # Entry point
├── cli.ts                      # CLI command dispatcher
├── config/                     # Configuration loading, constitution, MCP server definitions
├── session/                    # Multi-turn session management, budgets, loop detection
├── sandbox/                    # V8 isolated execution environment
├── trusted-process/            # Policy engine, MCP proxy, audit log, escalation handler
├── pipeline/                   # Constitution → policy compilation pipeline
├── escalation/                 # Escalation listener: session registry, TUI dashboard, state
├── mux/                        # Terminal multiplexer: PTY bridge, renderer, trusted input
├── persona/                    # Persona management (create, compile, resolve)
├── memory/                     # Memory server integration (config, annotations, path resolution)
├── signal/                     # Signal messaging transport (bot daemon, setup, formatting)
├── daemon/                     # Unified daemon (Signal + cron scheduler, control socket)
├── cron/                       # Cron job management (scheduler, job store, git sync, policy)
├── docker/                     # Docker agent mode, PTY session, MITM proxy, registry proxy
├── workflow/                   # Multi-agent workflow engine (orchestrator, state machine, gates)
├── web-ui/                     # Web UI backend (JSON-RPC dispatch, event bus, workflow manager)
├── servers/                    # Built-in MCP servers (fetch, web search providers)
└── types/                      # Shared type definitions
packages/
└── memory-mcp-server/          # Standalone memory MCP server (publishable npm package)

الترخيص

Apache-2.0