تصور کنید یک عامل هوش مصنوعی کدنویس، برنامه‌ای بی‌نقص برای به‌روزرسانی زیرساخت شما می‌نویسد، اما دقیقاً در لحظه اجرا، سیاست‌های امنیتی شرکت شما استفاده از آن ابزار را ممنوع می‌کند. اگر مدل اجازه داشته باشد خودش تصمیم بگیرد، این تضاد می‌تواند منجر به یک فاجعه امنیتی در محیط تولید شود. در واقع، حتی اگر یک عامل کدنویس قادر به نوشتن یک برنامه کامل باشد، نباید اختیار اجرای آن را داشته باشد.
NAEOS (سیستم‌عامل مهندسی هوش مصنوعی نوسانتارا)، پروژه‌ای متن‌باز که در ۲۳ سپتامبر ۲۰۲۶ جزئیات آن منتشر شد، با معرفی یک لایه حاکمیتی، «پیشنهاد مدل» را از «مجوز سیستم» جدا می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی شکاف «متصل اما غیرقابل‌نوشتن» اشاره کردیم، خطر اصلی زمانی رخ می‌دهد که عامل‌ها بر اساس زمینه‌های قدیمی (Stale Context) عمل کنند. این چالش در واقع ریشه در شکاف میان صحت پیاده‌سازی و صحت سیستمی دارد که باعث می‌شود عامل‌ها علی‌رغم نوشتن کد صحیح، در درک محدودیت‌های کلان سیستم شکست بخورند. در یک جریان کاری معمولی، یک عامل (Agent) — شبیه به کارآموزی که دستورات را اجرا می‌کند اما نباید کلید خزانه را داشته باشد — ممکن است برای استفاده از یک وابستگی نرم‌افزاری خاص برنامه‌ریزی کند، اما در میانه راه، سیاست امنیتی شرکت آن وابستگی را ممنوع کند. بدون لایه حاکمیتی، عامل به دلیل وجود برنامه قدیمی در پنجره زمینه (Context Window) — که مثل میز کاری است و فقط مقدار محدودی اطلاعات را در لحظه نگه می‌دارد — به اجرای اشتباه ادامه می‌دهد، زیرا برنامه قدیمی همچنان در حافظه مدل باقی مانده است.
بستر قدرت عامل‌ها
عامل‌های کدنویس امروزی توانایی‌های گسترده‌ای دارند. آن‌ها می‌توانند مخازن کد را بررسی کنند، فایل‌ها را ایجاد یا تغییر دهند، وابستگی‌ها را نصب کنند، دستورات را اجرا نمایند و پیکربندی‌ها را تغییر دهند. علاوه بر این، آن‌ها قادرند ابزارهای خارجی را فراخوانی کنند، درخواست‌های Pull Request باز کنند و جریان‌های کاری CI/CD را فعال نمایند.
طبق مستندات این پروژه در dev.to، NAEOS استدلال می‌کند که داشتن زمینه (Context) برای پیشنهاد این اقدامات، به معنای داشتن مجوز (Authority) نیست. سیستم باید هر اقدام را دقیقاً پیش از اجرا، دوباره با سیاست‌های فعلی سنجیده و ارزیابی کند تا ایمنی تضمین شود. این سامانه یک خط لوله چهارمرحله‌ای سخت‌گیرانه را اجرا می‌کند:
- مدل پیشنهاد می‌دهد $\rightrightarrows$ سیاست تصمیم می‌گیرد $\rightrightarrows$ محیط اجرا عملی می‌کند $\rightrightarrows$ مشاهده تأیید می‌کند.
این معماری تضمین می‌کند که مدل هرگز تصمیم‌گیرنده نهایی در مورد مجاز بودن یا نبودن یک اقدام نباشد.
چارچوب حاکمیتی و کنترل
برای جلوگیری از خطاهای مجوزدهی، NAEOS پنج مفهوم کلیدی را از هم تفکیک می‌کند. این سیستم تشخیص می‌دهد که وضعیت یک سند — خواه CURRENT (فعلی)، LEGACY (قدیمی)، UNKNOWN (ناشناخته) یا STOP (متوقف شده) باشد — به تنهایی برای مجوزدهی به یک اقدام کافی نیست:
- اطلاعات: آنچه سیستم می‌داند (مانند مستندات پروژه).
- سیاست: آنچه طبق استانداردهای مهندسی در حال حاضر مجاز است.
- مجوز: قابلیت‌های خاصی که به عامل اعطا شده است.
- اجرا: اقدام واقعی که توسط محیط اجرا صورت می‌گیرد.
- مشاهده: شواهد قابل تأیید خارجی (مانند ID استقرار) که موفقیت اقدام را ثابت کند.
این ساختار باعث می‌شود گزارش‌های بازرسی (Audit Log) صرفاً نقل‌قولی از ادعاهای عامل نباشد، بلکه سوابقی از تغییرات تأییدشده در وضعیت سیستم باشد. NAEOS بر این اصل استوار است که ردپای بازرسی باید طولانی‌تر از حافظه عامل باشد. به جای اینکه به جمله «من برنامه را با موفقیت مستقر کردم» اعتماد کند، سیستم یک رسید قابل تأیید مانند ID ارائه‌دهنده استقرار، وضعیت سلامت (Health Status) یا وضعیت بازگشت (Rollback Status) را می‌طلبد.
استقلال از تامین‌کننده
این سیستم به‌گونه‌ای طراحی شده که مستقل از تامین‌کننده (Vendor-neutral) باشد؛ یعنی سیاست‌های یکسان برای GitHub Copilot، Claude Code، OpenAI Codex، Cursor، Gemini CLI، OpenCode، Cline یا Roo Code اعمال می‌شود.
برای توسعه‌دهنده، این یعنی تمرکز از مهندسی پرامپت (Prompt Engineering) — که مثل هنر سؤال درست پرسیدن از یک مشاور است — به کنترل مهندسی تغییر می‌کند. به جای امید داشتن به اینکه مدل دستورات را دنبال کند، شما یک «قانون اساسی» تعریف می‌کنید که محیط اجرا نمی‌تواند آن را دور بزند. این امر یک ضربه‌گیر امنیتی ایجاد می‌کند که در آن لایه حاکمیتی می‌تواند یک برنامه نامعتبر را مسدود کند، حتی اگر مدل کاملاً متقاعد شده باشد که برنامه درست است.
این رویکرد فرض بنیادی جریان‌های کاری عامل‌محور را تغییر می‌دهد و با مدل برخورد می‌کند که قطعه‌ای قابل جایگزین است. حاکمیت مهندسی ثابت می‌ماند و می‌توان مدل زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — را بدون بازنویسی قوانین امنیتی و انطباق مخزن، تعویض کرد.
معماری و توسعه فعلی
در حال حاضر NAEOS معماری خود را حول محورهای کلیدی زیر توسعه می‌دهد:
- قوانین حاکمیتی و قوانین اساسی مهندسی
- محیط‌های اجرای سیاست (Policy Runtimes) و عامل‌های هوش مصنوعی
- افزونه‌ها و پلاگین‌ها
- زیرساخت‌های تأیید و بازرسی رویدادها (Audit/event infrastructure)
- انتقال‌های مستقل از پروتکل (Protocol-neutral handoffs)
گام بعدی شما
- اگر در حال ساخت خط لوله‌های هوش مصنوعی برای محیط تولید هستید، گام حیاتی بعدی این است که تعیین کنید کدام محدودیت‌ها باید خارج از پنجره زمینه مدل قرار گیرند.
- مخزن عمومی NAEOS در گیت‌هاب را برای بررسی معماری فعلی و مشارکت در پروژه بررسی کنید.
- سیاست‌های امنیتی فعلی تیم خود را به صورت کد (Policy as Code) مستند کنید تا آماده اتصال به لایه‌های حاکمیتی شوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو