۱ — اجرای عامل با اختیار محدود و نتیجهٔ قابل‌اثبات
بنیاد مشترک برای ASI، OERSI، connectorها، فایل‌ها، workflowها، حافظه و API؛ تمایز از طریق قابلیت اعتماد و دادهٔ واقعی ساخته می‌شود.
راهبرد محصول، معماری، امنیت و اقتصاد · نسخهٔ ۱٫۰ · ۳ نوامبر ۲۰۲۶
Darkoza Verified Work Fabric
از «چت هوشمند» به «محیط اجرای کارِ مجاز، قابل‌ردیابی و قابل‌اثبات»؛ یک معماری برای پیوند هوش، اختیار، ابزار، حریم خصوصی، نتیجه و ارزش اقتصادی.
تصمیم اصلی
باارزش‌ترین فرصت قابل‌پیشبرد برای Darkoza در وضعیت فعلی، ایجاد یک لایهٔ اجرای عامل‌محورِ مبتنی بر اختیار و مدرک نتیجه است: Darkoza Verified Work Fabric (DVWF).
این فرصت به‌جای رقابت صرف بر سر مدل یا تعداد عامل‌ها، چرخه‌ای واحد می‌سازد: درخواست ← هویت و اختیار ← برنامه ← مجوز محدود ← اجرای کنترل‌شده ← راستی‌آزمایی نتیجه ← مدرک قابل‌ردیابی ← سنجش هزینه و ارزش ← تسویهٔ مجاز.
مدل پیشنهاد می‌دهد؛ اما مدل اختیار خود را ایجاد نمی‌کند. هویت معتبر، سیاست سمت سرور و کاربر مجاز تعیین می‌کنند چه عملی روی کدام منبع و با کدام ابزار انجام شود.
این تصمیم یک فرضیهٔ راهبردی و مهندسی است؛ نه ادعای کشف علمی انحصاری یا امنیت کامل.
۱. چرا این فرصت از گزینه‌های دیگر جلوتر است؟
۲ — مسیریابی کیفیت‌محور مدل
مدل مناسب برای هر کار با معیار کیفیت، هزینه، latency و دسترس‌پذیری؛ کاهش هزینه فقط با آزمون خارج از نمونه معتبر است.
۳ — هویت و حافظهٔ خصوصی هر کاربر
پیش‌شرط اعتماد، جداسازی داده و تداوم؛ هنوز باید از حافظهٔ محلی مرورگر به معماری چندمستأجریِ قابل‌آزمون تکامل یابد.
۴ — jobهای پایدار و اجرای ابری
صف، checkpoint، لغو، resume و recovery برای کاری که نباید با قطع مرورگر از دست برود.
۵ — اقتصاد خدمات و API
فروش خروجی و workflow قابل‌سنجش، با usage ledger واقعی؛ نه صرفاً تعداد پیام و نه بازار توکنیِ پیش از موعد.
بازار agent-to-agent، Coin به‌عنوان اقتصاد اصلی، مدل پایهٔ اختصاصی و GPU بزرگ فعلاً در اولویت ساخت نیستند. GridFlex همچنان یک مسیر علمی و قابلیت تخصصی مهم است، اما برای درآمد فوری محصول باید مسیر مجزایی طی کند.
۲. پشتوانهٔ مستقل و وضعیت علم
NIST در فوریهٔ ۲۰۲۶ یک مقالهٔ مفهومی دربارهٔ هویت و مجوزدهی عامل‌ها منتشر کرد و تأکید داشت عامل‌ها برای دسترسی به داده‌ها، ابزارها و برنامه‌ها به کنترل شناسایی و مجوزدهی نیاز دارند. این سند مفهومی است و استاندارد نهایی محسوب نمی‌شود. NIST: Agent Identity and Authorization
مشخصات رسمی MCP در مسیر HTTP از OAuth 2.1 و Protected Resource Metadata استفاده می‌کند؛ توکن باید برای همان منبع هدف صادر و audience آن اعتبارسنجی شود، و توکن صادرشده برای یک سرویس نباید به سرویس دیگر عبور داده شود. MCP Authorization Specification
OWASP در راهنمای عامل‌محور ۲۰۲۶ و Top 10 برنامه‌های LLM ۲۰۲۶ ریسک‌هایی مانند سوءاستفاده از ابزار، اختیار بیش‌ازحد، prompt injection و افشای داده را برجسته می‌کند. گزارش Q3 2026 نیز چند رخداد انتخابی را مستند کرده است؛ آن گزارش جامع همهٔ حوادث نیست. OWASP Agentic Top 10 · OWASP LLM Top 10 2026 · OWASP Q3 2026
پیش‌چاپ‌های پژوهشی مانند Bounded Agents و benchmarkهایی مانند InjecAgent برای طراحی آزمون مفیدند؛ نتایج این مقالات، تضمین عمومی یا ارزیابی امنیت Darkoza نیستند.
۳. وضعیت واقعی محصول در ممیزی ۳ نوامبر ۲۰۲۶
آنچه تأیید شد
صفحات عمومی darkoza.com، ASI، Marketplace و کاتالوگ عمومی علوم در زمان بررسی پاسخ HTTP 200 داشتند. سرویس‌های اصلی وب، ASI Gateway، Cognitive و Autonomy در فهرست سرویس‌های فعال دیده شدند.
بدون سقف تعداد درخواست، با مدیریت ظرفیت
release manifest برای چت سقف تعداد درخواست به‌ازای کاربر، IP یا ساعت تعریف نمی‌کند. هم‌زمانی inference محدود است و هنگام اشباع، backpressure موقت 503 با Retry-After اعمال می‌شود. «بدون محدودیت تعداد» برابر با «منابع بی‌نهایت» نیست.
هویت و حافظه هنوز شکاف دارند
در handler عمومی /chat، tenant و principal احرازشدهٔ مستقل دیده نشدند؛ کنترل Origin جای هویت را نمی‌گیرد. کتابخانهٔ خصوصی بررسی‌شده در localStorage مرورگر نگهداری می‌شود؛ این با حافظهٔ ابریِ مستقل و امن برای هر کاربر یکسان نیست.
تداوم و ورود فایل
وجود worker یا حلقهٔ Autonomy به‌تنهایی بازیابی job پس از قطع مرورگر و restart را اثبات نمی‌کند. در ماژول‌های فعالِ ورودی فایل که بررسی شدند، handlerهای drag-and-drop تمام‌صفحه پیدا نشدند؛ آزمون E2E کل صفحه هنوز لازم است.
ناهماهنگی نسخه
HTML صفحهٔ ASI فایل app-v0.2.21.js را بارگذاری می‌کند، اما manifest و نشانگر نسخه 0.2.20 را اعلام می‌کنند. این اختلاف باید پیش از release بعدی اصلاح و hashها تطبیق داده شوند.
اقتصاد API و مشتری
کاتالوگ عمومی علوم یک preview فقط‌خواندنی است و فروش API تجاری را فعال نمی‌کند. اولین مشتری پرداخت‌کننده، تسویه و contribution margin هنوز شواهد تأییدشده ندارند؛ دو تماس discovery به‌معنی مشتری یا درآمد نیستند.
این بخش وضعیت مشاهده‌شده در یک snapshot است؛ نه گواهی انطباق یا ادعای کامل‌بودن ممیزی. فشار ذخیره‌سازی و swap در زیرساخت اصلی نیز مانع اجرای سنگین یا release پرریسک پیش از رفع ظرفیت است.
۴. معماری DVWF
کنترل باید بیرون از مدل اعمال شود؛ هر کار فقط اختیاری را دریافت کند که برای همان کار لازم است.
۱ — هویت و تفویض
user، agent، service و connector هویت‌های جدا دارند. مشخص است عامل از طرف چه کاربری و در کدام task کار می‌کند.
۲ — قصد و اثر دقیق
قصد به tool، action، resource، audience، effect payload و هزینهٔ تخمینی ساختاریافته تبدیل می‌شود. هش اثر باید در gateway معتبر محاسبه شود.
۳ — مجوز کوتاه‌عمر
grant بر tenant، principal، task، capability، tool، action و resource دقیق محدود است؛ انقضا، لغو و audience دارد. wildcard و مجوز عمومی ممنوع.
۴ — تأیید مرحله‌ای
read/draft با مجوز محدود؛ ارسال بیرونی، حذف، پرداخت، تغییر credential و شبکه نیازمند تأیید مستقل متصل به اثر دقیق است. تغییر payload بعد از تأیید، تأیید تازه می‌خواهد.
۵ — اجرای sandboxed
executor جدا از مدل، با credential کوتاه‌عمر، audience درست، scope کمینه، filesystem و egress کنترل‌شده.
۶ — راستی‌آزمایی و ممیزی
خروجی، مدرک، خطا، idempotency، وضعیت job و هزینه ثبت می‌شوند. «completed» فقط بعد از وجود نتیجهٔ قابل‌بررسی.
چرخهٔ هدف: accepted → authorized → planned → executing → verifying → completed؛ حالت‌های awaiting_approval، blocked، failed و cancelled نیز جدا هستند.
۵. نمونهٔ فنی اجراشده — Authority Gate v0.2
برای آزمودن فرضیه، یک ارزیاب سیاست مستقل و CPU-only ساخته شد. این نمونه هیچ ابزاری را اجرا نمی‌کند و به ASI Gateway یا Cognitive متصل نشده است.
۳۷ آزمون
جداسازی tenant/principal/task/audience، scope دقیق tool/capability/action/resource، انقضا، لغو، wildcard، اثر دقیق، تأیید منقضی/نامعتبر و دست‌کاری رسید.
ضد replay هم‌زمان
در ۲۴ ارزیابی هم‌زمان از یک تأیید، فقط یک اجازه صادر شد و ۲۳ مورد دیگر به‌عنوان replay رد شدند.
Idempotency
کلید یک عملیات تغییردهنده در همان process فقط یک بار پذیرفته شد؛ تکرار رد شد.
Microbenchmark محلی
۵۰٬۰۰۰ ارزیابی مجوز read درون‌حافظه‌ای پس از ۱٬۰۰۰ warm-up: median ۳۲٫۳۸۹µs، p95 برابر ۴۸٫۷۶۳µs، و p99 برابر ۷۷٫۷۱۱µs.
این اندازه‌گیری فقط evaluator پایتون و ساخت checksum را می‌سنجد؛ نه امضای واقعی، شبکه، ذخیره‌سازی پایدار، sandbox، اجرای ابزار یا تأخیر سرتاسری. replay و idempotency فعلی در حافظهٔ process هستند و با restart پاک می‌شوند. callback تأیید، قرارداد قابل‌جایگزینی است؛ آزمون از verifier رمزنگاری‌شدهٔ واقعی استفاده نکرده است.
کد نمونه · مجموعهٔ آزمون · کد benchmark · نتایج benchmark · خلاصهٔ آزمایش · محدودیت‌ها و روش · فهرست SHA-256
۶. ارتقای محصول، فناوری و اقتصاد
| بُعد | جهت ارتقا | مرز فعلی |
|---|---|---|
| UX | یک workspace، preview اقدام، نمایش هزینه/منبع، drop از کل صفحه و وضعیت زندهٔ job | drag-and-drop تمام‌صفحه در ماژول‌های بررسی‌شده تأیید نشد |
| حریم خصوصی | tenant isolation در API، DB، embeddings، cache، logs و storage؛ export/delete/revoke | کتابخانهٔ خصوصی مشاهده‌شده محلی است؛ memory عمومی غیرفعال |
| عامل‌ها | manifest نسخه‌دار، provenance، مجوز حداقلی، draft-first، approval و sandbox | نمونهٔ جدید هنوز اجراکننده یا gateway تولیدی نیست |
| مدل | routing کیفیت/هزینه/latency و تطبیق قبض واقعی | router موجود از سنجهٔ ورودی استفاده می‌کند؛ provider cost را مستقل reconcile نمی‌کند |
| کار طولانی | صف پایدار، checkpoint، cancel، resume و recovery بعد از restart | پایداری E2E هنوز اثبات نشده |
| اقتصاد | usage-based واقعی با token، CPU/GPU، storage، egress و هزینهٔ connector | فروش تجاری API در کاتالوگ فعلی فعال نیست |
| Marketplace | connectorهای امضاشده/نسخه‌دار با scope review و قابلیت لغو | بازار عامل‌به‌عامل فعلاً زودهنگام است |
| علم | GridFlex و compute-energy scheduling به‌عنوان خط پژوهش منبع‌دار | نتایج GridFlex فعلی شبیه‌سازی‌اند، نه کنترل واقعی شبکه |
اقتصاد پیشنهادی: «کار و خروجی قابل‌اعتماد» فروخته شود، نه تعداد پیام. سقف تعداد درخواست برای کاربران ایجاد نشود؛ منابع با صف عادلانه، concurrency، backpressure، کلاس خدمت و بودجهٔ اختیاری کاربر مدیریت شوند. در عین حال مصرف واقعی اندازه‌گیری شود تا compute نامحدودِ بدون تأمین مالی ایجاد نشود.
بازار عمومی/دانش منبع‌دار می‌تواند آزاد باقی بماند؛ اجرای خصوصی، connector، storage، job طولانی و API تولیدی می‌توانند خدمات پولی باشند. اولین gate اقتصادی همچنان یک مشتری واقعی، پرداخت تسویه‌شده، خروجی سنجش‌پذیر، هزینهٔ ثبت‌شده و contribution margin قابل‌بازتولید است.
۷. نقشهٔ راه ۹۰روزه
روز ۱–۱۴ — نیاز و ایمنی
سه مکالمهٔ qualified، baseline و انتخاب یک vertical؛ تکمیل threat model؛ رفع ناهماهنگی نسخهٔ ASI و اجرای E2E برای drop تمام‌صفحه. بدون اثبات تقاضا feature جدید اضافه نشود.
روز ۱۵–۳۰ — هویت و اختیار
انتخاب IdP/OAuth/OIDC؛ پیوند هویت کاربر/عامل/tenant؛ approval امضاشده و canonicalization اثر؛ تست cross-tenant و fail-closed.
روز ۳۱–۶۰ — اجرا و اقتصاد
executor sandbox، token broker، job state پایدار، audit، usage ledger، recovery و router بر اساس trace واقعی؛ یک workflow محدود و تأییدشده برای pilot.
روز ۶۱–۹۰ — اعتبارسنجی و تصمیم
red-team و بازبینی مستقل؛ سنجش زمان/خطا/هزینه و کیفیت در برابر baseline؛ اثبات پرداخت و contribution margin؛ عرضهٔ connector فقط پس از acceptance.
معیار عبور
- صفر دسترسی cross-tenant در مجموعهٔ آزمون.
- ۱۰۰٪ عملیات high/critical با approval معتبرِ همان effect.
- صفر اجرای ابزار در ابهام هویت یا مجوز؛ صفر duplicate side-effect در آزمون idempotency.
- ۱۰۰٪ کارهای completed با شاهد نتیجه.
- هدف مسیریابی: حداقل ۳۰٪ صرفه‌جویی هزینه با حداکثر ۱ واحد درصد افت کیفیت روی hold-out؛ فعلاً فرضیه است.
- حداقل یک paid pilot و margin قابل‌محاسبه برای عبور از gate اقتصادی.
۸. وضعیت دقیق انتشار
اجرا و آزمون شده: ممیزی وضعیت محصول؛ نمونهٔ Authority Gate v0.2؛ ۳۶ آزمون؛ آزمایش replay هم‌زمان؛ benchmark محلی ۵۰٬۰۰۰ ارزیابی؛ ثبت نتایج و SHA-256.
منتشر شده: این اثر واحد و کد تحقیقاتی و آزمون‌های قابل‌مشاهده.
هنوز اجرا نشده: ادغام با ASI Gateway/Cognitive، احراز هویت چندمستأجری، OAuth/OIDC، امضای رمزنگاری‌شده، persistence، sandbox، audit production، metering، فروش API و اولین پرداخت تأییدشده.
هیچ تغییری در database/schema، سرویس تولیدی، API behavior، احراز هویت، پرداخت، wallet، DNS، firewall، credential یا membership دستگاه‌ها انجام نشده است. backup خودکار اجرا نشده است. این انتشار نسخهٔ جدید ASI نیست.
۹. قانون‌مندی و شفافیت
راهنمای رسمی کمیسیون اروپا می‌گوید الزامات شفافیت Article 50 از ۲ اوت ۲۰۲۶ اعمال می‌شوند؛ یک دورهٔ انتقال محدود تا ۲ دسامبر ۲۰۲۶ برای برخی سامانه‌های پیش از آن تاریخ و برخی الزامات نشانه‌گذاری/تشخیص محتوای تولیدی توضیح داده شده است. دامنهٔ حقوقی به نقش provider/deployer و نوع سیستم وابسته است؛ این گزارش نظر حقوقی یا تأیید انطباق Darkoza نیست.
ENGLISH EXECUTIVE SUMMARY · VERSION 1.0
From chat to verified work execution
Darkoza's highest-value near-term opportunity is a governance-first execution fabric: authenticated identity and delegation, short-lived scoped authority, exact effect binding, risk-gated approval, sandboxed execution, independent result verification, auditable evidence and actual usage metering. The model proposes; policy and the user grant authority.
A standalone CPU-only reference policy gate was implemented and passed 37 unit tests. Twenty-four concurrent uses of one approval resulted in exactly one allow and 23 replay denials. A 50,000-iteration local read-policy microbenchmark measured 32.389 μs median, 48.763 μs p95 and 77.711 μs p99. This excludes authentication, cryptographic verification, persistence, network and tool execution. It is not production-integrated or a security certification.
The commercial priority remains one verified paid pilot with measurable customer outcomes and attributable cost. No payment, production integration or API commercialization was performed in this release.