تصور کنید یک عامل هوش مصنوعی به دلیل یک توهم ساده، کل پایگاه‌داده تولیدی شما را پاک کند یا دسترسی‌های امنیتی شبکه را باز کند. برای جلوگیری از این کابوس، ابزاری به نام AXIOM معرفی شده است که اجازه نمی‌دهد مدل‌ها بدون نظارت، دسترسی کامل به زیرساخت‌های واقعی داشته باشند. این یک درگاه مجوزدهی (Authorization Gateway) است که به‌صورت میزبانی شخصی (Self-hosted) اجرا می‌شود و به کاربران اجازه می‌دهد به عامل‌های هوش مصنوعی دسترسی به زیرساخت‌ها را بدهند، بدون اینکه کنترل کلی سیستم را واگذار کنند.
این سامانه تضمین می‌کند که اگرچه یک عامل (Agent) — شبیه به کارمندی که اجازه دارد پیشنهاد بدهد اما حق امضای نهایی را ندارد — می‌تواند تغییری را پیشنهاد کند، اما تا زمانی که یک انسان پارامترهای دقیق درخواست را تأیید نکند، هیچ اقدام مخربی اجرا نخواهد شد.
بیشتر ابزارهای فعلی بر دادن «دست» به مدل‌ها تمرکز دارند تا بتوانند APIها را فراخوانی کنند یا سرورها را تغییر دهند، اما قوانین سخت‌گیرانه‌ای برای حاکمیت بر این اقدامات ندارند. در چیدمان‌های رایج، تقریباً هیچ مانعی بین تصمیم مدل و اجرای آن وجود ندارد. این وضعیت شکاف امنیتی بزرگی ایجاد می‌کند که در آن یک توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یا یک خطای منطقی می‌تواند منجر به شکست فاجعه‌بار زیرساخت شود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به استدلال مدل‌ها در محیط‌های عملیاتی ریسک بالایی دارد.
زمینه و فلسفه طراحی
این پروژه از تمایل به کنترل اتفاقات درون یک شبکه خصوصی متولد شد. توسعه‌دهنده اشاره کرده است که ابزارهای سنتی مثل فایروال‌ها یا VPNها فقط «لوله» یا مسیر انتقال را ایمن می‌کنند، اما «تصمیم» را ایمن نمی‌سازند. AXIOM برای کنترل تصمیم طراحی شده است: اینکه کدام عامل اجازه دارد چه کاری انجام دهد و آیا باید ابتدا یک انسان پاسخ مثبت دهد یا خیر. این رویکرد در راستای مدل‌های مدیریت ریسک است که سطوح مختلف خودمختاری را برای کنترل اقدامات هوش مصنوعی تعریف می‌کنند تا هر اقدام بر اساس میزان خطر ارزیابی شود.
نام AXIOM از واژه‌ای یونانی به معنای «شایسته» گرفته شده است؛ به معنای واقعی کلمه یعنی وزن کردن و قضاوت درباره اینکه چه چیزی شایسته است. این نام بازتاب‌دهنده عملکرد اصلی سامانه است: وزن کردن هر درخواست هوش مصنوعی و تصمیم‌گیری درباره اینکه آیا آن درخواست شایسته اجازه اجرا است یا خیر. این پروژه در ابتدا به عنوان یک پروژه «اتصال امن» شروع شد، اما زمانی که توسعه‌دهنده متوجه شد برقراری اتصال بخش آسان کار است و چالش حل‌نشده، «مجوزدهی» (Authorization) است — یعنی تعیین اینکه آیا یک عامل اجازه دارد کار خاصی را با پارامترهای دقیق انجام دهد — به یک درگاه مجوزدهی تغییر مسیر داد.
با تکیه بر نیاز به کنترل دقیق (Granular Control)، AXIOM به جای یک لوله ساده، به عنوان یک قاضی عمل می‌کند. این سیستم فقط اتصال را از طریق VPN یا فایروال ایمن نمی‌کند، بلکه قصد و نیت درخواست را ارزیابی می‌کند. به نقل از گزارشی که در ۲۳ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این پروژه با یک فرآیند سه‌مرحله‌ای ساخته شده است: ابتدا یک ایده اولیه، سپس ساخت با کمک هوش مصنوعی و در نهایت استفاده از یک هوش مصنوعی دوم به عنوان بازبین خصمانه (Adversarial Reviewer) برای یافتن نقاط ضعف. در این مسیر، انسان به عنوان دروازه نهایی برای هر تصمیم حیاتی عمل کرده است.
مکانیسم شکست-بسته (Fail-Closed)
AXIOM بر اساس فلسفه «رد پیش‌فرض» (Deny by Default) عمل می‌کند. اگر قابلیتی صراحتاً به یک هویت خاص داده نشده باشد، آن اقدام مسدود می‌شود. یک سیاست (Policy) خالی هیچ چیزی را اجازه نمی‌دهد و در صورت نبود تنظیمات، به حالت باز یا سهل‌گیرانه باز نمی‌گردد. سامانه قابلیت‌ها را بر اساس میزان آسیب احتمالی به سه سطح تقسیم می‌کند:
- خوانش‌های بی‌خطر (Harmless Reads): این درخواست‌ها بدون وقفه و به‌طور آزادانه انجام می‌شوند.
- اقدامات حساس (Sensitive Actions): این اقدامات برای اهداف حسابرسی، به‌طور کامل و با جزئیات ثبت (Log) می‌شوند.
- اقدامات مخرب (Destructive Actions): این اقدامات کاملاً متوقف می‌شوند تا زمانی که یک انسان از طریق یک چرخه تأیید متصل‌شده (Bound Approval Cycle)، پاسخ مثبت دهد.
این مکانیسم سخت‌گیرانه یادآور سامانه LEASH است که با استفاده از بودجه‌های خطا، دسترسی عامل‌های سرکش را به‌طور فیزیکی مسدود می‌کند تا از تخریب زیرساخت جلوگیری شود.
تست‌های خصمانه و کشف باگ‌ها
توسعه‌دهنده برای تست استرس این درگاه از یک هوش مصنوعی خصمانه استفاده کرد که منجر به کشف سه باگ بحرانی پیش از انتشار ابزار شد. این باگ‌ها به عنوان مدرکی بودند که ثابت کردند این فرآیند کار می‌کند، زیرا تضمین‌های فرضی را به تضمین‌های واقعی تبدیل کردند.
اولین مورد «شکست خاموش» (The Silent Failure) بود؛ برای دو روز، یک مسیر «شکست-بسته» به‌طور خاموش شکست می‌خورد. از بیرون، همه چیز درست به نظر می‌رسید، اما تضمین زیربنایی حفره‌ای داشت که فقط در شرایط واقعی آشکار می‌شد. این مورد تفاوت بین یک دیوار واقعی و «تصویری از یک دیوار» را برجسته کرد.
مورد دوم «پس‌رفت نهفته» (The Latent Regression) بود. بازبین خصمانه موردی را پیدا کرد که در آن اصلاح یک رفتار تأیید، به‌طور بی‌صدا تضمینی را در یک لایه پایین‌تر می‌شکست. چون هنوز کسی از آن مسیر خاص استفاده نمی‌کرد، این خطا تا زمان یک شکست احتمالی در آینده نهفته می‌ماند.
بحرانی‌ترین یافته اما «اجرای انکارشده» (The Executed Denial) بود؛ جایی که یک اقدام مخرب توسط سامانه رد شد اما با این حال اجرا گردید. توسعه‌دهنده این مورد را عمداً بازتولید کرد، آن را اصلاح نمود و یک تست دائمی ساخت که اگر این باگ دوباره بازگردد، تست با شکست مواجه شود.
این فرآیند ثابت می‌کند سیستمی که وعده ایمنی می‌دهد، باید از طریق «شکست» تأیید شود، نه اینکه کمال آن فرض شود. توسعه‌دهنده دیواری را که نتوان آن را تأیید کرد، «صرفاً دکوراسیون» می‌نامد.
مشخصات فنی
هسته AXIOM چندین تضمین امنیتی کلیدی برای محیط‌های میزبانی شخصی (Self-hosting) فراهم می‌کند:
- اعطای دقیق (Granular Grants): برای هر عامل یک هویت مجزا تعریف می‌شود. هر بار کاری (Workload) کلید مخصوص به خود را دریافت می‌کند و فقط قابلیت‌های خاصی که صراحتاً به آن تخصیص یافته است را در اختیار دارد.
- اتصال پارامتر (Parameter Binding): تأیید انسانی به پارامترهای دقیق درخواست گره می‌خورد. این کار مانع از آن می‌شود که هوش مصنوعی پس از دریافت تأیید، اقدام را عوض کند یا هدف را تغییر دهد.
- گزارش‌های ضد دستکاری (Tamper-Evident Logs): هر درخواست، چه پذیرفته و چه رد شده باشد، در یک رکورد زنجیره‌شده با هش (Hash-chained) ذخیره می‌شود. این تضمین می‌کند که ردپای حسابرسی قابل تأیید است و نمی‌توان آن را تغییر داد.
- جداسازی مالک (Owner Isolation): مکانیسم‌های کنترلی از هر ناحیه‌ای که هوش مصنوعی به آن دسترسی دارد، کاملاً جدا شده‌اند. طبق طراحی، هوش مصنوعی نمی‌تواند مالک انسانی را از سیستم بیرون کند یا دسترسی او را ببندد.
طبق گزارش عملیاتی در ۲۱ اوت ۲۰۲۶، این سامانه با موفقیت مانع از ایجاد یک peer در WireGuard توسط یک گره آزمایشی شد. این یک اقدام مخرب سطح ۲ بود. این درخواست یک اعلان واقعی تلگرام را از طریق Tier2ApprovalFlow به گوشی مالک ارسال کرد. به محض اینکه مالک گزینه 'Deny' را زد، اقدام متوقف شد و رویداد در گزارش‌های ضد دستکاری ثبت گردید. برای اهداف نمایشی، این پروژه شامل یک MockDestructiveCapability و یک اسکریپت دموی (axiom-gateway/examples/demo_approve_deny.rs) است تا این چرخه تمرین شود.
این تغییر معماری، صنعت را از «اعتماد» به استدلال مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به سمت مدل «مجوزدهی رسمی» می‌برد. با برخورد با درخواست‌های هوش مصنوعی به عنوان ورودی‌های غیرقابل اعتماد که باید سنجیده و قضاوت شوند، AXIOM یک مرز قابل تأیید بین خودمختاری هوش مصنوعی و پایداری زیرساخت ایجاد می‌کند.
برای کاربر عملی، این یعنی ریسک پاک شدن تصادفی یک پایگاه‌داده تولیدی یا باز کردن یک حفره امنیتی توسط یک عامل، توسط یک دروازه انسانی فیزیکی کاهش می‌یابد. این ابزار، هوش مصنوعی را از یک مدیر سیستم خودمختار به یک «پیشنهاددهنده» پیشرفته تبدیل می‌کند که برای حرکات پرریسک به امضا نیاز دارد.
کاربرانی که علاقه‌مند به تأیید این ادعاها هستند، می‌توانند به مجموعه تست‌های خصمانه در مخزن axiom-core در گیت‌هاب (larro1991 / axiom-core) دسترسی پیدا کنند. این پروژه تحت لایسنس MIT منتشر شده است تا کاربران را تشویق کند پیش از استقرار، تک‌تک خطوط کد را بخوانند.
گام بعدی شما
- اگر از عامل‌های هوش مصنوعی برای مدیریت سرورها استفاده می‌کنید، مخزن axiom-core را در گیت‌هاب (larro1991) بررسی کنید.
- کدها را تحت لایسنس MIT بخوانید تا متوجه شوید چگونه پارامترهای درخواست به تأیید انسانی گره می‌خورند.
- برای تمرین، اسکریپت دموی
demo_approve_deny.rsرا اجرا کنید تا چرخه تأیید و رد را تجربه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو