فوّض الأثر، لا مجرّد الوصول إلى الأداة.
التحكّم بالوصول يحدّ ما يمكن للبرمجية بلوغه. وExecution Authorization يحدّ الأثر الدقيق الذي يجوز لها إحداثه. وAction Proof هو البروتوكول الذي يُنتج السلسلة القابلة للتحقّق: grant موقَّع لاستخدام واحد لعملية قياسية واحدة، يُطبَّق في نقطة تتحكّم بها أنت، ويُختَم بدليل يستطيع أي شخص فحصه دون اتصال.
برهان تشفيري على التفويض. دليل موقَّع على نتيجة التنفيذ. يثبت Execution Grant ما جرى تفويضه؛ ويحفظ Action Receipt دليلًا موقَّعًا على النتيجة التي استطاع الـGuardian المسجَّل إثباتها.
السحابة تفوّض، وGuardian الخاص بك ينفّذ
مفاتيح لكل مستأجر، وبيانات اعتماد بأقل امتياز
إيصالات موقَّعة، قابلة للتحقق دون اتصال
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }الوصول ليس تفويضًا بالتصرّف
أن يكون لديك وصول إلى معالج المدفوعات ليس كأن تكون مفوَّضًا بإجراء استرداد محدّد.
الوصول
يمكن للوكيل استدعاء واجهات API الخاصة بالاسترداد لدى معالج المدفوعات
Execution Authorization
refund.create charge ch_89172 amount USD 1,427.00 destination original_payment_method maxUses 1 expires 14:02 UTC
تفويض الموارد يجيب عمّا يمكن لـprincipal الوصول إليه. وExecution Authorization يجيب عن الأثر الخاص بمعاملة بعينها الذي يجوز له إحداثه. حتى الوصول fine-grained يترك المعاملة نفسها غير معرَّفة: أي مورد، وأي مبلغ، وأي وجهة، وكم مرة.
ثلاث خطوات
التعريف
ما الأثر الدقيق المطلوب؟ الـGuardian — لا النموذج — يقرأ حالة المزوّد ويحوّلها إلى عملية قياسية بمعاملات صريحة.
التفويض
اربط ذلك الأثر بـExecution Grant موقَّع لاستخدام واحد داخل سياستك، بالصلاحية التي يشترطها البروتوكول لتلك العملية.
التحقّق
نفّذ في نقطة تتحكّم بها أنت واحتفظ بـAction Receipt موقَّع يُعاد حسابه دون اتصال.
read_message_request
يُعيد ما تطلبه الرسالة، من الإشارات وحدها. ولا يغادر المتن الجهاز أبدًا.
analyze_message_intent
يربط الإشارات المجردة بنوايا الإجراءات الحساسة. إشارات فقط، دون نص خام.
verify_counterparty
يتحقق مما إذا كان المرسل أو الطرف المقابل مطابقًا لسجل المستأجر.
get_safe_next_step
يحسب أكثر الخطوات التالية أمانًا انطلاقًا من وقائع معلنة في السجل.
authorize_action
يُعيد Action Verdict وSafe Next Step وإيصالًا قبل أي إجراء حساس.
create_action_challenge
ينشئ تحققًا يدويًا بضابط مزدوج تجاه طرف مقابل معروف.
issue_action_receipt
يُصدر Action Receipt موقَّعًا لوقائع محسوبة سلفًا.
get_source_envelope
يسترجع المظروف الموقَّع على الجهاز الذي رآه شخص فعليًا ووافق عليه.
request_execution_grant
يطلب تفويضًا يُستخدم مرة واحدة لتنفيذ أثر دقيق. ويُعيد HOLD حتى توافق الصلاحية البشرية أو النصاب المطلوب.
get_execution_status
يُبلغ عن موضع عملية التنفيذ، بما في ذلك النتائج التي لا تزال غير محددة فعلًا.
طبقة التنفيذ
التفويض ليس إذنًا بالارتجال
يرتبط Execution Grant بـdigest أثر واحد وبإصدار السياسة النافذ، وينتهي، ويُستخدم مرة واحدة بالضبط. يعيد الـGuardian الخاص بك قراءة حالة المزوّد قبيل التعديل مباشرةً، ويطالب بالـgrant مقابل ledger خاص به، ويوقّع النتيجة — بما فيها النتائج الغامضة. ولا يصل grant مُعاد تشغيله إلى أي مزوّد أبدًا.
- الـgrants لاستخدام واحد ومرتبطة بـdigest أثر دقيق واحد. وmaxUses يساوي 1 دائمًا.
- الصلاحية المطلوبة يحدّدها البروتوكول؛ ولا يستطيع المستدعي خفضها.
- كل منح امتياز يتطلّب quorum بصيغة M-of-N، ولا يمكن لمقدّم الطلب أن يعتمد طلبه أبدًا.
- ملفات الـquorum هي لقطات سياسة موقَّعة، لا قيم صلاحية: فالبرهان يستند إلى الـthreshold وقائمة المعتمِدين وhash السياسة.
- النتائج هي succeeded أو failed_no_effect أو indeterminate — ولا يُقرَّب الغموض إلى الأعلى أبدًا.
- تُتحقَّق حِزَم proof bundle دون اتصال، ودون أي مكالمة عودة إلى SecureStamp.
المَثَل 3
الوكيل يتوقّف قبل تغيير حساب
يتلقى سير عمل طلبًا من مورّد بتغيير الحساب المصرفي. وبدل تحديث الحساب، يستدعي authorize_action عبر حارس MCP البعيد ببصمة وإشارات مجردة. تُعيد SecureStamp القيمة needs_confirmation وخطوة تالية آمنة: مراجعة الطرف المقابل. ولا يُنفَّذ شيء حتى يردّ شخص.
الوكيل يرصد إجراءً حسّاسًا
يتعرّف على تغيير في حساب مصرفي ويرسل إشارات مهيكلة فقط مع sourceMessageHash.
SecureStamp يتحقّق من وقائع الـtenant
يحصر مفتاح API الاستعلام في owner graph واحد، وفي السياسات المعلنة والتعليمات المسجَّلة.
الوكيل يتلقّى verdict
الاستجابة سجلّ قرار يتضمّن Safe Next Step وreceiptId، لا إذنًا بالتنفيذ.
يؤكّد البشر أو الطرف المقابل
عند الحاجة، يفتح create_action_challenge مسار تأكيد يدوي قبل أن تمضي العملية.
سقف التفويض المحلي
تفويض السحابة ضروري، لكنه وحده لا يكفي أبدًا.
لا يتحوّل الـgrant إلى تنفيذ إلا إذا كان يندرج أيضًا ضمن السياسة التي وقّعتها مؤسستك وثبّتتها بجوار الـGuardian. تلك السياسة deny-only: تثبّت الـtenant والـgateway والعمليات وmanifest المحوّلات والصلاحيات وإصدارات السياسة المقبولة والموارد والمعاملات والحدود المالية والتزامن ووجهات الشبكة. ويرفض وضع الإنتاج الإقلاع من دونها.
الإذن الفعلي =
grant السحابة
∩ السياسة المحلية الموقَّعة
∩ قيود المحوّل
∩ kill switchesيستطيع SecureStamp Cloud أن يجعل التفويض أضيق. ولا يستطيع أن يجعله أوسع ممّا سمحت به مؤسستك محليًا.
العقود
ما يعيد المدقّق حسابه
ExecutionGrantV1مُخرَج التفويض. يحمل digest الأثر والصلاحية وإصدار السياسة (apol_v1:) ومهلة الانتهاء. وmaxUses يساوي 1.
ActionReceiptV2 / V3مُخرَج الدليل. تضيف V3 إصدار السياسة وdigest السياسة المحلية الموقَّعة (gpol_v1:) التي حدّت التنفيذ. وتبقى V2 متوافقة بايتًا ببايت من أجل السجل التاريخي.
ActionProofBundleV1 / V2كل ما يحتاجه طرف ثالث لإعادة حساب السلسلة. تضيف V2 السياسة المحلية الموقَّعة وواصف assurance الخاص بالموصِّل.
AdapterManifestV1واصف مكتفٍ بذاته وغير قابل للتغيير لعملية موصِّل واحدة. يفحص المدقّق الـmanifest الموجود في الـbundle بدل إعادة توليده، فلا تُبطل العمليات الجديدة البراهين القديمة أبدًا.
تحقّق من receipt دون اتصال
المدقّق حزمة منشورة مستقلة بلا وصول إلى الشبكة، ويصدر قبل المخرجات التي يتحقّق منها. ويمكن التحقّق من الـreceipts دون اتصال ودون التواصل مع SecureStamp، ولا يعتمد التحقّق على خدمة SecureStamp عاملة.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
حدود الدليل
يثبت Action Receipt ما مرّ عبر Guardian مسجَّل، والنتيجة التي استطاع ذلك الـGuardian إثباتها. وهو لا يثبت أنه لم يقع أي إجراء خارج SecureStamp، ولا يقرّر الملكية القانونية لحساب المزوّد. وحدّ الدليل هو مسار التنفيذ المسجَّل.