الانتقال إلى المحتوى الرئيسي
وكيل مالي يطابق الدفاتر، ويُصدر المبالغ المستردة، ويحرّك الأموال، ويقرأ بيانات البطاقات والحسابات. نطاق انفجار استدعاء أداة سيئ واحد — حلقة استرداد منفلتة، أو DROP على جدول دفتر، أو أرقام بطاقات تتسرّب إلى مطالبة — يُقاس بالدولارات وبنتائج التدقيق. تجمّع هذه الوصفة الضوابط التي تجعل مثل ذلك الوكيل آمناً للتشغيل: استقلالية tight كأرضية، وموافقة بشرية على أدوات تحريك الأموال، وسقف تكلفة لكل تشغيل كقاطع دائرة، وحزمة امتثال SOC 2 / PCI قابلة للتثبيت تجسّد السياسة وكذلك الأدلة الموقَّعة التي سيطلبها مدقّق.
كل شيء هنا يُضبط في وحدة التحكم (Firewall → Posture / Policies، Guardrails، Compliance). تستخدم مسارات الإدارة تلك جلسة وحدة تحكّمك، لا مفتاح ترحيل — وحدها استدعاءات /v1/* التي يجريها وكيلك تحمل مفتاح sk-orca-…. تتطلب تحريرات السياسة دور Developer؛ تثبيت/إطلاق/إقامة الامتثال تتطلب Admin لمساحة العمل وخطة مدفوعة.

1. لماذا يحتاج وكيل ذكاء اصطناعي مالي آمن أكثر من حواجز الحماية

يلتقط فحص المحتوى رقم بطاقة في مطالبة. لا يوقف الوكيل عن استدعاء refund.issue عشرة آلاف مرة، أو الوصول إلى مضيف 10.x داخلي، أو تشغيل هجرة مدمّرة. موقف بمستوى مالي عليه أن يحكم المستويين دفعةً واحدة:

مستوى النص

تفحص حواجز الحماية نص الطلب والاستجابة — PII مقنَّعة، أسرار محجوبة، قبل أن يراها النموذج أبداً.

مستوى الإجراء

يحكم جدار الحماية كل استدعاء أداة، وإرسال MCP، وطلب صادر — allow، audit، deny، sanitize، تعليق، أو سقف تكلفة.
تطبّق هذه الوصفة أربعة ضوابط بعضها فوق بعض. اقرأ خط أساس الوكلاء الآمنين و حواجز الحماية مقابل جدار الحماية أولاً إن لم يكن المستويان واضحين بعد.

2. الأرضية: طبّق استقلالية tight

ابدأ من أقوى موقف ذي مفتاح واحد. في Firewall → Posture، طبّق مستوى الاستقلالية tight مستوى الاستقلالية (دور Developer). في معاملة واحدة يضبط المستويين:
المستوىما يجسّده tight
جدار الحمايةحجب-افتراضي؛ رفض الـ shell المدمّر؛ رفض egress الخاص بـ SSRF (أسماء الأدوات على هيئة جلب)
حواجز الحمايةفرض PII Shield + Secrets Blocker على الطلبات
يكتب مفتاح الاستقلالية صفوف سياسة وحاجز حماية autonomy_* حقيقية قابلة للتحرير — إنه بذرة، لا صندوق أسود. له تراجع بنقرة واحدة من لقطة تدقيق.
على وكيل يحرّك الأموال، لا تقلب مباشرةً إلى tight في الإنتاج. طبّقه في وضع الظل (أو ابدأ عند balanced) بحيث يُخفَّض كل حكم فارض إلى audit بسبب [shadow] would …. راقب Firewall → Events / Runs، أكّد أن السياسة تُطلق على ما تتوقّعه، ثم افرض.

3. الموافقات: علّق أدوات تحريك الأموال لإنسان (HITL)

الحجب-الافتراضي يوقف ما لم تسمح به. الأدوات التي تسمح بها لكنها تحرّك الأموال — refund.issue، payment.send، ledger.adjust — ينبغي ألّا تُسمَح ولا تُرفَض تلقائياً. أعطها حكم pending_approval بحيث يوقّع إنسان خارج النطاق. في Firewall → Policies، أضف قاعدة فوق افتراضيك:
  • Tool glob: refund.* (أو payment.send، ledger.adjust، …)
  • Verdict: pending_approval
عندما يستدعيها الوكيل:
  1. يعيد الاستدعاء المُعلَّق HTTP 400 firewall_approval_pending بمعرّف موافقة؛ لا يصل الاستدعاء إلى الأداة.
  2. يحلّها مراجِع — من وحدة التحكم (Developer+)، أو عبر استدعاء webhook مُوقَّع بـ HMAC إلى نظام موافقاتك الخاص في POST /api/v1/firewall/approvals/:id/callback.
  3. يستطلع الوكيل GET /api/v1/firewall/approvals/:id، ثم يعيد تقديم الاستدعاء الأصلي بترويسة X-OrcaRouter-Firewall-Approval أحادية الاستخدام — وتمرّره البوابة تلك المرة الواحدة.
ثبّت مُسنِد وسائط بحيث تحتاج العمليات الكبيرة فقط إلى إنسان: glob refund.issue بعبارة JSONPath {"path":"$.amount_cents","op":"gt","value":50000}، حكم pending_approval. تتدفق المبالغ المستردة الصغيرة؛ ينتظر استرداد 500 دولار فأكثر مراجِعاً. انظر قواعد جدار الحماية لمجموعة المشغّلات الكاملة (eq، contains، regex، in، cidr_match، gt، lt).

4. قاطع الدائرة: ضع سقفاً لتكلفة تشغيل

وكيل مالي عالق في حلقة إعادة محاولة هو خلل صحّة وخلل فوترة معاً. قاعدة cap_cost هي قاطع الحلقة المنفلتة: ترفض استدعاء أداة بمجرد أن يتجاوز الإنفاق المتراكم لتشغيل الوكيل سقف سنتات لكل قاعدة. أضف قاعدة بحكم cap_cost وسقف cap_cost_cents — مثلاً 2000 (USD $20.00) — محدّدة النطاق لأدوات وكيلك. بمجرد أن يتجاوز الإنفاق الجاري لتشغيل السقف، تُرفض الاستدعاءات الأخرى في ذلك التشغيل؛ يبدأ تشغيل جديد نظيفاً.
يضع cap_cost سقفاً لإنفاق تشغيل الوكيل، لا لميزانية عمر مفتاح واحد. لسقف صارم على مفتاح، اضبط credit_limit_usd على مفتاح API نفسه (0 = بلا حد) — يتألّفان: ميزانية المفتاح تحدّ إجمالي الإنفاق، وcap_cost يحدّ أي تشغيل واحد.

5. حزام وحمّالات على مستوى النص

يفرض tight بالفعل PII Shield وSecrets Blocker. لوكيل مالي، اتكئ على التفاصيل:
يلتقط حاجز Secrets Blocker مفاتيح API وبيانات الاعتماد في المطالبة قبل أن يراها النموذج. لبيانات البطاقات، قاعدة pii مع credit_card مضبوطة على إجراء block (عبر entity_actions لكل كيان) ترفض الطلب بالكامل بـ HTTP 400 guardrail_blocked — وحجب لا يكلّف حصة (تُطلق حجوب الإدخال قبل القياس). انظر حواجز الحماية §5.
الإعداد المسبق PII Shield قاعدة pii واحدة، mask، مرحلة both. تقنيع مرحلة الإدخال حيّ: يُعرَض iban أو ssn في الطلب كـ [IBAN] / [SSN] قبل استدعاء النموذج. (التقنيع الحي للمخرجات/التدفق على خارطة الطريق؛ تُفرض block على المخرجات في التدفق وغير التدفق اليوم.)
حكم sanitize لجدار الحماية ينقّح السلاسل الفرعية المطابقة من وسائط استدعاء أداة قبل التمرير — لا يعيد كتابة ما تعيده أداة أبداً. لإبقاء سرّ خارج طلب بالكامل، تلك مهمة حاجز Secrets Blocker على مستوى النص.

6. حزمة الامتثال: SOC 2 وPCI في تثبيت واحد

الضوابط أعلاه هي التنفيذ. يريد المدقّق الأدلة. يغلق مستوى Compliance تلك الحلقة: تصفّح كتالوج الأطر (مجاناً، أي Member)، ثم ثبّت حزمة كـ Admin لمساحة العمل على خطة مدفوعة. تثبيت حزمة يجسّد حواجز حماية وسياسات جدار حماية تخطّط إلى ضوابط الإطار — فنفس التثبيت الذي يعطيك أداة التدقيق يقيم أيضاً فرضاً حقيقياً.
# Console action (UserAuth session) — install the PCI DSS pack
POST /api/compliance/packs/pci_dss/install
# then, when you're ready to enforce:
POST /api/compliance/packs/pci_dss/golive
تشمل الحزم المؤكَّدة ذات الصلة بوكيل مالي soc2 (معايير خدمات الثقة SOC 2 من AICPA)، و**pci_dss** (PCI DSS 4.0)، و**glba** (Gramm-Leach-Bliley)، و**dora_eu** (قانون المرونة التشغيلية الرقمية) — بجانب أطر الخصوصية (gdpr، uk_gdpr، ccpa)، وأطر الأمان/الذكاء الاصطناعي (iso_27001، iso_42001، nist_ai_rmf، eu_ai_act، nist_800_53)، وحزمة owasp_llm (OWASP Top 10 لتطبيقات LLM). تصفّح الكتالوج الحي للمجموعة الكاملة.

التقرير الذي يستطيع مدقّق التحقق منه

ماذاالتفصيل
التوقيعEd25519 فوق تجزئة أدلة SHA-256 — يكشف التلاعب
التنسيقاتCSV / JSON / PDF
التحققعام — GET /api/public/compliance/pubkey، POST /api/public/compliance/verify
المشاركةرابط مدقّق للقراءة فقط: GET /api/public/compliance/share/:token
تتضمن الخطة المجانية تقريراً واحداً؛ تصدير CSV/JSON والتقارير الإضافية مدفوعة. توليد تقرير والإطلاق محكومان من الخادم للخطط المدفوعة — يبقى الكتالوج وعروض الجاهزية مجانية.

7. إقامة البيانات والاحتفاظ والمحو

موقف بمستوى مالي عليه أن يجيب “أين الأدلة، وكم تحتفظ بالسجلات”.
  • الإقامة هي منطقة عمل تقرير الامتثال — us، eu، uk، ap، cn، أو global، تُضبط عبر PUT /api/compliance/residency (Admin). تُحجب القراءات عبر المناطق. (هذا يثبّت العمل، لا أين يعمل الاستدلال.)
  • الاحتفاظ — سجلات الطلبات افتراضها 30 يوماً ومقيَّدة من الخادم إلى حد أقصى صارم 180 يوماً.
  • المحو — حذف الحساب الذاتي يدخل نافذة مهلة 30 يوماً، ثم فرك PII لا رجعة فيه يتسلسل عبر تطابقات حواجز الحماية، وسجلات الطلبات، وأحداث جدار الحماية.
كل تغيير في سياسة أو قاعدة أو امتثال يكتب صف تدقيق (مساحة العمل + المركزي). تغييرات حواجز الحماية وجدار الحماية مؤرشَفة أيضاً — diff وrevert أي حاجز حماية من تبويب History لديه.

8. تحقّق قبل أن تعتمد عليه

لا تطلق سياسة مالية بالإيمان. لكلا المستويين صندوق رمل لا يحفظ شيئاً ولا يرسل شيئاً:
  • Guardrails → Test — الصق عينة، اختر مرحلة، ارَ الحكم والنص المعروض (المقنَّع).
  • Firewall → Test (Developer+) — شغّل تجريبياً استدعاء أداة عينة وارَ الحكم، والقاعدة المطابقة، والسبب.
بمجرد التشغيل، Firewall → Events / Runs هو سجل كل تقييم لكل تشغيل، وتعلّم تغذية الشذوذ ارتفاعات المعدل/التكلفة مقابل خط أساس ساعة-الأسبوع المتعلَّم لمساحة العمل، وretry_loop، ومسارات الأدوات غير المرئية من قبل — بالضبط الإشارات التي تسبق حادثاً مالياً.

الخلاصة

خط أساس الوكلاء الآمنين

ما يجسّده tight، وكيف تحاكي قبل التطبيق.

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

مُسنِدات الوسائط، وسقوف التكلفة، وegress، والتسلسلات بعمق.

أدلة SOC 2

حوّل الضوابط المجسَّدة إلى أداة تدقيق موقَّعة.

تسجيل آمن لـ PII

أبقِ بيانات البطاقات والحسابات خارج سجلات طلباتك.

أوضاع الفرض

مراقبة ← ظل ← فرض، الطرح الآمن لأدوات تحريك الأموال.

استدعاءات الأدوات الخطرة

التهديد الذي تدافع عنه قائمة سماح أدوات وكيل مالي.