پرش به محتوای اصلی
پرش به محتوای مقاله

MakerChecker با زنجیره هش جلوی تایید خودکار اقدامات عامل‌های هوش مصنوعی را گرفت

·۱۵ تیر ۱۴۰۵۵ دقیقه مطالعه
درگاه امنیتی متن‌باز و اسکنر ایستا برای عامل‌های هوش مصنوعی با کنترل دسترسی مبتنی بر نقش، تأییدیه انسانی، تفکیک وظایف و گزارش
درگاه امنیتی متن‌باز و اسکنر ایستا برای عامل‌های هوش مصنوعی با کنترل دسترسی مبتنی بر نقش، تأییدیه انسانی، تفکیک وظایف و گزارش
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

جایگزینی متدهای نرمِ نظارتی (مثل System Prompt) با یک لایه سخت‌گیرانه و قابل اثبات (Provable) بر پایه زنجیره هش، که تایید خودکار اقدامات توسط مدل را به‌صورت ساختاری غیرممکن می‌کند.

یک عامل (Agent) — مانند کارمندی که برای انجام کارهای اداری اختیار دارد اما نباید چک‌های کلان را خودش امضا کند — در صورت استفاده از MakerChecker دیگر نمی‌تواند اقدامات حساس خود را تایید کند. این لایه‌ی امنیتی متن‌باز، یک دیوار ساختاری و سخت بین عاملی که وظیفه‌ای را اجرا می‌کند و انسانی که مجاز به امضای نهایی آن است، می‌سازد.

بسیاری از چارچوب‌های فعلی در حاکمیت عامل‌ها دچار یک شکاف خطرناک هستند. در حالی که توسعه‌دهندگان می‌توانند با پرامپت‌نویسی سعی کنند مدل را «ایمن» کنند، اما به ندرت یک محدودیت فنی سخت وجود دارد که مانع از اجرای یک دستور Shell پرخطر یا جابه‌جایی وجوه مالی شود، به‌ویژه اگر مدل راهی برای دور زدن دستورالعمل‌های سیستمی (System Instructions) پیدا کند. این چالش‌های حاکمیتی در ابزارهای مختلف بررسی شده‌اند و برای مثال مقایسه‌ی قابلیت‌های Bifrost در برابر Zscaler و Netskope نشان می‌دهد که مدیریت نقطه انتهایی هوش مصنوعی تا چه حد حیاتی است. MakerChecker با قرار گرفتن مستقیم در مسیر هر فراخوانی ابزار (Tool Call) به عنوان یک ایست بازرسی و در پشت آن به عنوان یک دفتر ثبت امضاشده، این مشکل را حل می‌کند.

بر اساس مستندات این پروژه، سامانه از سیاست «پیش‌فرضِ عدم دسترسی» (Deny-by-default) پیروی می‌کند. این بدان معناست که یک عامل هیچ قابلیتی ندارد تا زمانی که یک نقش (Role) خاص، مهارتی را به او اعطا کند. برای مثال، یک عامل «معامله‌گر» (Trader) به‌طور سخت‌گیرانه از دسترسی به مهارت place-order@1 منع می‌شود و این دسترسی تنها برای نقش «میز ریسک» (Risk-desk) رزرو شده است. اگر عاملی تلاشی برای فراخوانی ابزاری خارج از سطح دسترسی‌اش کند، سامانه پیش از آنکه ابزار حتی اجرا شود، خطای GovernanceDeniedError را با کد «عدم اعطای مهارت» (skill_not_granted) صادر می‌کند.

معماری فنی و ابزارها

این پلتفرم به سه لایه‌ی عملکردی مستقل تقسیم شده است که می‌توان آن‌ها را به‌صورت جداگانه یا به عنوان یک مجموعه کامل به کار برد:

  • mc scan: یک اسکنر ایستا (Static Scanner) که بررسی می‌کند عامل چه کارهایی را می‌تواند به‌تنهایی انجام دهد. این ابزار اقدامات اثرگذار — مانند حذف داده‌ها، جابه‌جایی پول، اجرای دستورات Shell یا استخراج رازها (Secrets) — را شناسایی کرده و آن‌ها را با حوادث واقعی مشابه تطبیق می‌دهد. همچنین این ابزار می‌تواند با استفاده از فلگ --fix تولید کد حاکمیتی را به‌صورت خودکار انجام دهد.
  • makerchecker/embedded@: مجموعه‌ای از دستورات اجرایی یا Primitives وارد-شدنی (Importable) که به توسعه‌دهندگان اجازه می‌دهد ابزارها را در کدهای حاکمیتی بپیچند. این لایه تضمین می‌کند عامل‌ها تنها مهارت‌های اعطاشده را اجرا کنند و به‌صورت ساختاری نتوانند کار خود را تایید کنند.
  • سرور میزبانی شخصی (Self-Hosted Server): یک درگاه (Gateway) مبتنی بر Fastify و Postgres که یک صندوق ورودی (Inbox) برای تاییدات انسانی و یک کنسول بررسی متمرکز فراهم می‌کند. این سرور مدیریت متمرکز اجرای قوانین حاکمیتی را برای چندین عامل مختلف بر عهده دارد.

یکپارچه‌سازی و پیاده‌سازی

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، اجرای سخت‌گیرانه دسترسی‌ها تنها راه مقابله با توهمات مدل در سطح سیستم است. در کنار این لایه‌های امنیتی، ابزارهای جدیدی برای تسهیل استقرار به وجود آمده‌اند؛ چنان‌که حذف کدنویسی در بانی‌های جدید سرعت استقرار عامل‌های شخصی و میزبانی‌شده را به‌شدت افزایش داده است. MakerChecker برای این منظور اتصال‌دهنده‌های آماده‌ای (Drop-in connectors) برای چارچوب‌های محبوبی مثل LangChain (در مسیر packages/connector-langchain) و Claude Agent SDK (در مسیر packages/connector-claude-agent) ارائه داده است. علاوه بر این، SDKهای اختصاصی برای زبان‌های TypeScript و Python نیز در دسترس است.

هنگام استفاده از سرور، تابع governedTool در SDK، فراخوانی‌ها را از طریق یک نشست پروکسی (Proxy Session) هدایت می‌کند. این کار اجازه می‌دهد مجوزها و ثبت وقایع به‌صورت متمرکز مدیریت و ضبط شود. برای مثال، یک نشست می‌تواند با برچسب «recon-run» علامت‌گذاری شود تا یک فرآیند تطبیق (Reconciliation) خاص در سراسر پروکسی ردیابی شود.

ردپاهای بازرسی‌پذیر

حیاتی‌ترین ویژگی امنیتی این ابزار، دفتر ثبت زنجیره-هش (Hash-chained log) است. هر تصمیم و فراخوانی ابزار در متنی ثبت می‌شود که هر رویداد در آن، یک هش SHA-256 از JSON استاندارد (RFC 8785) آن رویداد است. این رویدادها از طریق prev_hash از نقطه آغاز (Genesis) به هم زنجیر شده و با الگوریتم Ed25519 امضا شده‌اند.

به دلیل این ساختار زنجیره-هش و امضا، بازرسان می‌توانند یک بسته داده (Bundle) را صادر کرده و کل تاریخچه را به‌صورت آفلاین تایید کنند. این یعنی دیگر نیازی به اعتماد به پایگاه‌داده یا فرآیندی که لوگ‌ها را تولید کرده است، نیست. ابزار packages/proof-verifier اجازه می‌دهد هر کسی این بسته‌ها را به‌طور مستقل اعتبارسنجی کند.

کاربردهای حاکمیتی

مثال‌های واقعی نشان می‌دهند که عامل‌ها چگونه کارهای حساس را در پشت دروازه‌های انسانی انجام می‌دهند:

  • مراقب فارماکولوژیک (Pharmacovigilance): یک عامل گزارش‌های عوارض جانبی را اولویت‌بندی و دسته‌بندی (Triage) می‌کند، اما یک بازبین پزشکی باید پیش از ارسال گزارش تنظیم‌گرای ضرب‌الاجل ۱۵ روزه، آن را امضا کند.
  • طبقه بندی شکایات تجهیزات پزشکی (MDR): یک افسر تنظیمات در پشت یک دروازه تصمیم می‌گیرد که آیا گزارش قابل ارائه به سازمان‌های نظارتی باشد یا خیر، و سپس پیش‌نویس گزارش‌ها تولید می‌شود.
  • دسترسی بیماران انکولوژی: عامل‌ها فرآیند تطبیق مزایا را مدیریت می‌کنند اما بدون امضای یک متخصص، از ارسال درخواست‌های ثبت‌نام Copay منع می‌شوند.
  • تطبیق نقدی روزانه: یک عامل مالی تراکنش‌ها را تطبیق می‌دهد اما در نقاط استثنا (Exception Gates) قفل می‌شود تا افسر وجه نقد آن را تایید و امضا کند.

استقرار و مدیریت

برای سازمان‌هایی که کنترل متمرکز می‌خواهند، سرور را می‌توان با دستور docker compose up مستقر کرد. این تنظیمات دو کلید API متمایز ایجاد می‌کند: یک کلید ادمین (Admin Key) برای احراز هویت عامل و یک کلید افسر (Officer Key) برای بازبین‌های انسانی.

در یک سناریوی زنده، سامانه تلاش‌های تایید شخصی (Self-approval) را با خطای ۴۰۳ رد می‌کند. برای مثال، در جریان مراقبت فارماکولوژیک، درخواست‌کننده به عنوان تاییدکننده پذیرفته نمی‌شود؛ تنها زمانی که یک افسر مجزا تصمیمی بگیرد (مثلاً: «جدی بودن تایید شد؛ گزارش‌های ۱۵ روزه را ثبت کن»)، اقدام پیش می‌رود.

لایسنس و بسته‌ها

این پروژه از مدل لایسنس دوگانه (Dual-licensing) استفاده می‌کند. سرور، کنسول وب و ابزارهای مشترک تحت لایسنس AGPL-3.0 هستند. با این حال، اسکنر mc scan و دستورات اجرایی embedded، SDKها و اتصال‌دهنده‌ها تحت لایسنس Apache-2.0 قرار دارند تا به‌راحتی و به‌صورت رایگان در عامل‌های Closed-source (با کد بسته) ادغام شوند.

در نهایت، این ابزار پارادایم ایمنی هوش مصنوعی را از «پرامپت‌نویسی امیدوارانه» به «اجرای سخت‌گیرانه» تغییر می‌دهد. به‌جای اینکه از هوش مصنوعی بخواهیم صادق باشد، سیستمی می‌سازیم که در آن مدل به‌طور فیزیکی نمی‌تواند دستوری ممنوعه را اجرا کند. نتیجه این کار، یک ردپای بازرسی‌پذیر و اثبات‌شدنی است که سخت‌گیرانه‌ترین الزامات نظارتی در حوزه‌های مالی و پزشکی را برآورده می‌کند.

کسانی که عامل‌های خودمختار را مستقر می‌کنند، باید بررسی کنند که یک دفتر ثبت امضاشده چگونه پروفایل مسئولیت (Liability Profile) آن‌ها را تغییر می‌دهد. شما می‌توانید با اجرای ابزار mc scan شروع کنید تا دقیقاً ببینید عامل‌های فعلی شما چه اقدامات حساسی را بدون نظارت انجام می‌دهند.

گام بعدی شما

  • ابزار mc scan را روی عامل‌های فعلی خود اجرا کنید تا متوجه شوید چه اقدامات حساسی بدون نظارت انجام می‌دهند.
  • در صورت استفاده از LangChain، اتصال‌دهنده MakerChecker را برای جایگزینی تاییدات متنی با تاییدات سخت‌گیرانه بررسی کنید.
  • ساختار لایسنس Apache-2.0 بخش‌های کلیدی را برای ادغام در محصولات تجاری خود تحلیل کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.

چرا این موضوع مهم است؟

این ابزار با تکیه بر استانداردهای رمزنگاری و امضاهای دیجیتال، اعتبار (Authority) لازم برای استفاده از عامل‌ها در محیط‌های شدیداً تنظیم‌گری شده مانند پزشکی و مالی را فراهم می‌کند. نتیجه این است که سازمان‌ها می‌توانند بدون ترس از خطاهای پیش‌بینی‌ناپذیر مدل، اتوماسیون را در سطوح حساس پیاده کنند.

تأثیر برای ایران

به‌دلیل متن‌باز بودن و لایسنس Apache-2.0 در بخش‌های کلیدی، توسعه‌دهندگان ایرانی می‌توانند بدون نیاز به APIهای خارجی، این لایه امنیتی را روی مدل‌های محلی یا میزبانی‌شده خود پیاده کنند.

·نگاه ما
تحریریه دات‌هوش

جایگزین کردن «اعتماد به مدل» با «اعتماد به ریاضیات» در لایه دسترسی، تنها راه رسیدن به استقرار واقعی عامل‌ها در صنایع حساس است. MakerChecker با استفاده از امضه‌های کریپتگرافی، مسئولیت قانونی (Liability) را از دوش مدل برداشته و به یک ساختار قابل حسابرسی منتقل می‌کند. این رویکرد نشان می‌دهد که آینده ایمنی هوش مصنوعی نه در بهینه‌سازی وزن‌ها، بلکه در معماری لایه‌های نظارتی بیرونی است.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.