Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
authproof-sdk — إيصالات تفويض موقعة تشفيرياً للوكلاء الذكاء الاصطناعي. حدد بالضبط ما يمكن للذكاء الاصطناعي فعله وما لا يمكنه فعله — موقعة، قابلة للتحقق، مقاومة للتلاعب. | Kitploit
أدوات/GitHubGitHub/commonguy25/authproof-sdk
المصادقة والترخيصالتشفيرإدارة الهوية والوصول (IAM)أمن سلسلة التوريدأمن واجهات برمجة التطبيقاتأمن الذكاء الاصطناعي
GitHubcommonguy25/authproof-sdk

authproof-sdk

إيصالات تفويض موقعة تشفيرياً للوكلاء الذكاء الاصطناعي. حدد بالضبط ما يمكن للذكاء الاصطناعي فعله وما لا يمكنه فعله — موقعة، قابلة للتحقق، مقاومة للتلاعب.

عرض المستودع
622منذ 3 أشهرلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة
الموقع الإلكتروني

AuthProof SDK

AuthProof هو بروتوكول تفويض تشفيري لوكلاء AI. معظم البروتوكولات في هذا المجال تنفذ ضد سياسة يحددها المشغل - مما يعطي المشغل سلطة توسيع أو إعادة تفسير نية المستخدم الأصلية بعد وقوع الحدث. AuthProof مبني على نموذج ثقة مختلف: المفتاح الخاص للمستخدم يوقع كائن التفويض الذي يتحكم في التنفيذ، ويتم التحقق من حالة النموذج الحية في وقت التفويض وقبل التنفيذ مباشرة. مزيج السلطة الموقعة من المستخدم والتحكم بحالة النموذج الحية هو الادعاء المحدد - وليس قصة إنفاذ واسعة.

ما الذي يجعله مختلفًا:

  • المستخدم هو سلطة التوقيع. كل بروتوكول منافس (AIP, AITH, OAP, SAGA, AgentSpec) ينفذ ضد سياسة يحددها المشغل. في AuthProof، يوقع المفتاح الخاص للمستخدم كائن التفويض مباشرة. لا يمكن للمشغل توسيع النطاق بعد أن وقع المستخدم.

  • التزام بحالة النموذج على مرحلتين. يتم قياس النموذج في وقت التفويض وإعادة قياسه مباشرة قبل التنفيذ. إذا انحرف النموذج بين هاتين النقطتين، يتم حظر التنفيذ في التحقق قبل التنفيذ.

  • تمييز تحديث المزود عن الاستبدال الخبيث. يصنف البروتوكول تغييرات حالة النموذج إلى فئتين: تحديثات المزود الشرعية (PROVIDER_UPDATE_REQUIRES_REAUTH) والتبديلات غير المصرح بها (MALICIOUS_MODEL_SUBSTITUTION). ينتج كل منهما رمز سبب رفض قابل للقراءة آليًا يحدد المكونات التي تغيرت.

المدقق قبل التنفيذ

البوابة الحتمية التي تعمل قبل تنفيذ أي إجراء للوكيل.

يجلس PreExecutionVerifier خارج بيئة تشغيل الوكيل. لا تحصل بيئة التشغيل على التحكم أبدًا حتى يمر المدقق. لا يمكن للوكيل المخترق أو الخبيث تخطيه — يعمل قبل بدء بيئة التشغيل.

لماذا يهم

تحدث عمليات التحقق التقليدية من التفويض داخل بيئة تشغيل الوكيل. إذا تم اختراق بيئة التشغيل، يمكن تخطي تلك الفحوصات أو إعادة ترتيبها أو تجاوزها. يلغي PreExecutionVerifier سطح الهجوم هذا عن طريق نقل التفويض خارج بيئة التشغيل بالكامل. لا ينفذ الوكيل إلا إذا — وفقط إذا — نجحت جميع الفحوصات الستة المتسلسلة أولاً.

بداية سريعة```js

import { PreExecutionVerifier, DelegationLog } from 'authproof-sdk/pre-execution-verifier' import { RevocationRegistry } from 'authproof-sdk'

// 1. Set up the gate const delegationLog = new DelegationLog() const revocationRegistry = new RevocationRegistry() await revocationRegistry.init({ privateKey, publicJwk })

const verifier = new PreExecutionVerifier({ delegationLog, revocationRegistry }) await verifier.init({ privateKey: verifierKey, publicJwk: verifierPub })

// 2. Register your delegation receipt delegationLog.add(receiptHash, receipt)

// 3. Gate every action — before the agent runs const result = await verifier.check({ receiptHash, action: { operation: 'read', resource: 'calendar' }, operatorInstructions: 'Summarize meetings. Stay within scope.', programHash, // optional: prevents code substitution attacks })

if (!result.allowed) { throw new Error(Blocked: ${result.blockedReason}) } // Agent runtime only reaches here after all six checks pass

### ستة فحوصات متسلسلة (تتوقف عند أول فشل)

| # | الفحص | يمنع عند |
|---|-------|-------------|
| 1 | توقيع الإيصال | توقيع ECDSA P-256 غير صالح أو الإيصال معدل |
| 2 | الإلغاء | تم إلغاء الإيصال عبر `RevocationRegistry` |
| 3 | النافذة الزمنية | الإيصال منتهي الصلاحية أو غير صالح بعد (أوراكل الطابع الزمني للسجل، وليس ساعة العميل) |
| 4 | النطاق | الإجراء غير موجود في `ScopeSchema.allowedActions` أو فشل مطابقة النطاق النصية |
| 5 | تعليمات المشغل | التعليمات الحالية لا تتطابق مع التجزئة المقفلة في الإيصال عند الإصدار |
| 6 | تجزئة البرنامج | `programHash` المقدمة لا تتطابق مع تجزئة `executes` الملتزمة (منع استبدال الكود) |

يتم تسجيل كل نتيجة فحص - سواء نجاح أو فشل - تلقائيًا في `ActionLog` غير قابل للتغيير موقّع بمفتاح المدقق الخاص.

### تكاملات الوسيطة

أغلفة جاهزة للإطارات الشائعة. يتحكم كل غلاف في كل استدعاء عبر `PreExecutionVerifier` قبل تنفيذ الكود المغلف.

- **[LangChain](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/langchain.js)** — يغلف أي وكيل بطريقة `invoke()`
- **[Express/HTTP](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/express.js)** — وسيطة طلب لأي إطار متوافق مع Express
- **[غلاف الدالة العامة](https://github.com/commonguy25/authproof-sdk/blob/main/src/middleware/generic.js)** — يغلف أي دالة غير متزامنة```js
// LangChain
import { authproofMiddleware } from 'authproof-sdk/middleware/langchain'
const guardedAgent = authproofMiddleware(agent, { receiptHash, verifier })

// Express
import { authproofMiddleware } from 'authproof-sdk/middleware/express'
app.use(authproofMiddleware({ verifier, getReceiptHash: (req) => req.headers['x-receipt-hash'] }))

// Any function
import { guardFunction } from 'authproof-sdk/middleware/generic'
const guardedExecute = guardFunction(executeAction, { receiptHash, verifier, action })

المشكلة

كل إطار عمل حالي من IETF لهوية الوكيل — AIP, draft-klrc-aiagent-auth, WIMSE — يتناول الثقة من الخدمة إلى الوكيل: كيف تتحقق خدمة المصب من أن الوكيل مخوَّل باستدعائها. لا يتناول أي منها ثقة المستخدم إلى المشغل.

سلسلة التفويض في الأنظمة الوكيلة الحالية هي:``` User → Operator → Agent → Services

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

النتائج:

- لا يمكن للمستخدمين إثبات ما فوّضوه.
- لا يوجد لدى الجهات التنظيمية مسار تدقيق.
- لا يوجد لدى المحاكم سلسلة أدلة.
- لا تستطيع الوكلاء التمييز بين تعليمات المُشغِّل المشروعة والتعليمات المخترقة أو الخارجة عن السيطرة.

يسد AuthProof هذه الفجوة.

---

## البدائية الأساسية: إيصال التفويض

**إيصال التفويض** هو كائن تفويض موقع يُثبَّت في سجل لامركزي للإلحاق قبل بدء أي إجراء للوكيل. يحتوي على أربعة حقول إلزامية:

### النطاق

قائمة سماح صريحة للعمليات المسموح بها. كل ما ليس مدرجًا ممنوع افتراضيًا. يُعبَّر عنه بتنسيق منظم — وليس بلغة طبيعية. فئات العمليات:

| الفئة | الوصف |
|---|---|
| `reads` | وصول للقراءة إلى موارد محددة |
| `writes` | وصول للكتابة إلى موارد محددة |
| `deletes` | حذف موارد محددة |
| `executes` | تنفيذ برنامج محدد، بالإشارة إلى **تجزئة توقيع القدرة الثابتة** الخاصة به |

`executes` هي الفئة الأكثر خطورة. يجب أن تشير إلى التجزئة التشفيرية لرسم بياني للقدرات الثابتة (DAG) لبرنامج Safescript — وليس إلى اسم أو URI أو وصف. عدم تطابق التجزئة يعني عدم التنفيذ.

### الحدود

محظورات صريحة لا يمكن تجاوزها بتعليمات المُشغِّل تحت أي ظرف. حدود صلبة يحددها المستخدم وتستمر بعد أي تعليمات لاحقة من المُشغِّل.

### الإطار الزمني

فترة صلاحية التفويض. **الطابع الزمني للسجل** هو مرجع الوقت — وليس ساعة العميل. ساعات العميل مستبعدة صراحةً من التحقق من الوقت.

### تجزئة تعليمات المُشغِّل

تجزئة تشفيرية لتعليمات المُشغِّل المُعلنة في وقت التفويض. إذا قام المُشغِّل لاحقًا بتوجيه الوكيل بشكل مختلف، يمكن اكتشاف التناقض من السجل دون أي افتراضات ثقة إضافية.

يوقع المستخدم على هذا الكائن بمفتاحه الخاص عبر **WebAuthn/FIDO2 باستخدام المنطقة الآمنة للجهاز**. يتم نشر التوقيع في السجل قبل أي إجراء للوكيل. كل إجراء لاحق للوكيل يشير إلى تجزئة الإيصال. الإجراءات خارج النطاق غير صالحة تشفيريًا.

---

## بنية طبقة الثقة

ثلاث طبقات بروتوكول تقضي على ثلاثة أطراف ثالثة موثوقة:

### الطبقة 1 — بيان القدرة المُوقَّع *(يزيل الثقة في السجل)*

في النظام البيئي الحالي لـ MCP، لا يوجد أي تصديق تشفيري بأن أوصاف خادم الأداة تتطابق مع ما يفعله بالفعل. يمكن للمُشغِّل تقديم مخطط وصف (schema) تعسفي.

الحل: تنشر خوادم الأدوات **بيان قدرة مُوقَّع تشفيريًا** قبل حدوث أي تفويض من المستخدم. يشير حقل `scope` في إيصال التفويض إلى **تجزئة هذا البيان** — وليس إلى مخطط وصف المُشغِّل المُبلَغ ذاتيًا. يمكن اكتشاف الاختلاف بين سلوك الخادم والبيان في طبقة السجل.

### الطبقة 2 — إيصال التفويض *(يزيل الثقة في المُشغِّل)*

يتم تسجيل نية المستخدم الأصلية بشكل غير قابل للتغيير قبل وصول تعليمات المُشغِّل إلى الوكيل. انحراف المُشغِّل قابل للإثبات.

### الطبقة 3 — تنفيذ Safescript *(يزيل الثقة في الكود)*
تنزيل الأداة