تصور کنید یک عامل هوش مصنوعی برای به‌روزرسانی یک کتابخانه ساده در کد شما استخدام شده، اما در اثر یک توهم، کل پایگاه داده تولیدی شما را پاک می‌کند. این کابوس امنیتی، دلیل اصلی پیدایش معماری جدیدی است که Tenuo Engineering در ۲۱ سپتامبر ۲۰۲۶ برای مدیریت امن عامل‌ها معرفی کرد. آن‌ها ابزاری به نام safe-upgrade را توسعه دادند تا اطمینان حاصل کنند که یک عامل AI نمی‌تواند به طور تصادفی یا عمدی، در حالی که صرفاً سعی در به‌روزرسانی نسخه یک بسته دارد، دیتابیس محیط Production را حذف کند.
بسیاری از عامل‌های فعلی با دسترسی‌های «همه یا هیچ» کار می‌کنند؛ یعنی اگر به آن‌ها اجازه دهید برای تست کردن کد، ترمینال را باز کنند، عملاً تمام اختیارات حساب کاربری شما را به دست می‌گیرند. این موضوع یک شکاف امنیتی عظیم ایجاد می‌کند که در آن یک توهم ساده می‌تواند منجر به حذف فاجعه‌بار فایل‌ها یا فراخوانی‌های غیرمجاز API شود. طبق گزارش tenuo.ai، سیستم safe-upgrade این مشکل را با جداسازی لایه «قضاوت» (چه کاری انجام شود) از لایه «اختیار» (چه کاری مجاز است) حل می‌کند.
همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد مطلق به خروجی مدل‌های زبانی بزرگ ریسک‌های عملیاتی بالایی دارد. در این معماری، سه جزء اصلی برای حفظ مرزهای ایمنی تعریف شده‌اند. قانون اصلی طراحی این است که قضاوت، جریان کنترل و اختیار را کاملاً از هم جدا نگه دارند:
- Jev: مانند یک مدل «سیستم یک» عمل می‌کند که شواهد پراکنده و نامنظم مخزن کد را به تصمیمات تایپ‌شده و احتمالی تبدیل می‌کند. این مدل هرگز کد اجرا نمی‌کند و فقط بهترین گام بعدی را از یک فهرست پیش‌تأییدشده انتخاب می‌کند.
- LangGraph: مدیریت جریان کاری بادوام (durable workflow) را بر عهده دارد و وضعیت مخزن، یافته‌ها و تصمیمات را در طول کل فرآیند اجرا حفظ می‌کند.
- Tenuo: لایه امنیتی است که «ضمانت‌نامه‌های محدود به وظیفه» (task-scoped warrants) صادر می‌کند تا دقیقاً محدود کند که یک Worker در طول یک فراخوانی خاص چه کارهایی می‌تواند انجام دهد.
زمینه: پیچیدگی به‌روزرسانی‌ها
به‌روزرسانی وابستگی‌ها شاید در ظاهر مکانیکی به نظر برسد، اما اغلب سوالات دشواری درباره سازگاری در خود نهفته دارد. یک تغییر نسخه ساده می‌تواند APIهایی را حذف کند که مخزن کد از آن‌ها استفاده می‌کند، فرمت یک ماژول را تغییر دهد یا رفتاری را تغییر دهد که تست‌های موجود آن را پوشش نمی‌دهند.
در این موارد، ممکن است نصب بسته و فرآیند CI با موفقیت به پایان برسد، اما اپلیکیشن در عمل خراب شده باشد. یک عامل کاربردی باید بتواند شواهد مربوط به انتشار نسخه جدید (Release Evidence) را تفسیر کند، آن را با یک مخزن کد ناآشنا مرتبط سازد، کارهای لازم را تصمیم‌گیری کند، کد را تغییر دهد و در نهایت ثابت کند که نتیجه نهایی سالم است. این فرآیند نیازمند دسترسی به فایل‌های منبع، نصب بسته‌ها، دستورات تست، Git و مخازن راه دور است. این رویکرد در مدیریت خودکار مخازن کد، مشابه سازوکار همگام‌سازی عامل‌های SlideOps با مخازن زنده است که برای حفظ سازگاری مستندات با کد استفاده می‌شود.
جزئیات: نحوه عملکرد تصمیمات تایپ‌شده
در گردش‌کار safe-upgrade، ابتدا کدهای قطعی (Deterministic) محاسبه می‌کنند که چه اقداماتی واجد شرایط هستند. سپس Jev با استفاده از یک فراخوانی TypeSafe SDK، مفیدترین اقدام را انتخاب می‌کند. Jev سوالات معنایی (Semantic) را مدیریت می‌کند که قوانین معمولی در پاسخ به آن‌ها ضعیف هستند؛ مثلاً اینکه آیا یک یادداشت انتشار (Release Note) بر نحوه استفاده از یک مخزن خاص تأثیر می‌گذارد یا اینکه آیا یک تست موجود می‌تواند یک خرابی گزارش‌شده را شناسایی کند یا خیر.
برای پیاده‌سازی این مورد، آداپتور تولیدی از @typesafe-ai/sdk استفاده می‌کند. توسعه‌دهنده گزینه‌های موجود و معیارها را تعریف می‌کند و Jev یک گزینه انتخاب‌شده، یک توزیع احتمالی و یک امتیاز اطمینان (Confidence Score) را برمی‌گرداند.
در یک اجرای ثبت‌شده، Jev گزینه author_tests را با اطمینان ۰.۸۲ انتخاب کرد. توزیع احتمالی نشان داد که این گام به طور قابل توجهی محتمل‌تر از assess_verification (۰.۱۸) یا implement (۰.۰۸) است.
مسیریابی تصمیمات و جایگزین‌ها
سیستم به طور کورکورانه از هوش مصنوعی پیروی نمی‌کند. یک مسیریاب (Router) برچسب انتخاب‌شده را با استفاده از TypeScript در برابر کاندیداهای اصلی اعتبارسنجی می‌کند. اگر سطح اطمینان مدل از یک آستانه مشخص پایین‌تر بیاید، سیستم به‌جای حدس زدن، یک تابع deterministicFallback(input) را فعال می‌کند.
این مکانیسم تضمین می‌کند که اطمینان پایین، پاسخ‌های بدشکل یا شکست‌های در انتقال داده، گردش‌کار را به یک مسیر امن و قطعی هدایت کنند. وضعیت غنی مخزن حفظ می‌شود، اما به صورت یک تصمیم کوچک و تایپ‌شده وارد گراف می‌شود.
اعمال اختیارات محدود شده
پس از اتخاذ تصمیم، Tenuo اختیارات عامل را محدود می‌کند. یک «ضمانت‌نامه والد» (Parent Warrant) حداکثر دسترسی‌های ممکن برای کل اجرا را تعیین می‌کند. در محیط تولید، Tenuo با یک کلید عمومی صادرکننده مورد اعتماد مقداردهی شده و یک ضمانت‌نامه اجرای صادر شده خارجی و کلید مالکیت آن را وارد می‌کند.
هر Worker به طور مجزا یک «جلسه فرزند» (Child Session) با قابلیت‌های بسیار محدود دریافت می‌کند. این کار از طریق فرآیند تنگ کردن (Narrowing) و سخت‌گیرانه کردن دسترسی‌ها انجام می‌شود:
- نویسنده تست (The Test Author): جلسه‌ای دریافت می‌کند که از ضمانت‌نامه والد محدود شده است. به این عامل دسترسی
READ_ONLY، اجازهwrite_test_fileوrun_checkداده می‌شود. قابلیتrun_checkباز هم محدودتر شده تا فقط اجازه اجرای نوعtestرا بدهد. این جلسه دارای TTL ۶۰۰ ثانیه‌ای است و به عنوان یک جلسه نهایی (Terminal) علامت‌گذاری شده تا نتواند اختیارات خود را به جای دیگری تفویض کند. - مجری (The Implementer): یک جلسه فرزند مجزا برای تغییرات منبع و به‌روزرسانی دقیق وابستگی دریافت می‌کند. نکته حیاتی این است که
write_test_fileاز پروفایل این عامل حذف شده است. - تأییدکننده (The Verifier): بررسی‌ها را می‌خواند و اجرا می‌کند، در حالی که فایل‌های کاندید در حالت فقط-خواندنی (Read-only) نگه داشته شده‌اند.
اجرای مطلق محدودیت‌ها
اجرای محدودیت‌های Tenuo مطلق است. اگر یک Worker مجری سعی کند برای اینکه بیلد (Build) را پاس کند، یک تست رگرسیون را تضعیف کند — برای مثال با فراخوانی write_test_file تا عبارت test.skip('regression', () => {}) را اضافه کند — سیستم بلافاصله یک رکورد TENUO_TOOL_NOT_AUTHORIZED تولید می‌کند.
این رکورد عدم دسترسی شامل نام Worker (مجری)، قابلیت مورد نظر (write_test_file)، هش آرگومان‌ها و شناسه جلسه است. برای امنیت بیشتر، محتوای فایلی که قصد تغییرش بوده در این رکورد ذکر نمی‌شود. تابع نوشتن زیرین هرگز اجرا نمی‌شود زیرا بررسی مجوز دقیقاً قبل از فراخوانی ابزار رخ می‌دهد.
یکپارچگی با گردش‌کار LangGraph
LangGraph حقایق مخزن، یافته‌ها، تصمیمات، تلاش‌ها و شواهد را در طول اجرا نگه می‌دارد. هر گره (Node) وضعیت صریحی را دریافت کرده و یک به‌روزرسانی برمی‌گرداند، در حالی که نقاط بازرسی (Checkpoints) پیشرفت را در مرزهای معنادار حفظ می‌کنند. جریان به این ترتیب است:
۱. شواهد مخزن جمع‌آوری می‌شود.
۲. کد مورد اعتماد، انتقال‌های مجاز را محاسبه می‌کند.
۳. Jev از میان آن مجموعه تایپ‌شده، یکی را انتخاب می‌کند.
۴. کد مورد اعتماد، اقدام را به یک Worker متصل می‌کند.
۵. Tenuo یک ضمانت‌نامه محدود شده برای آن Worker صادر می‌کند.
۶. ابزارهای محافظت‌شده، شواهد را به LangGraph بازمی‌گردانند.
یک فاز ارزیابی (Assessment) تنها از Workerهای خواندنی برای ثبت فایل‌های متأثر، یافته‌های مهاجرت (Migration) و شکاف‌های تأیید استفاده می‌کند. این ارزیابی به کامیت خاص، فایل مانیفست، Lockfile و وضعیت Working-tree که بررسی شده است، متصل است.
امنیت در خط لوله‌های CI/CD
این معماری به‌ویژه برای عامل‌هایی که بدون نظارت در GitHub Actions اجرا می‌شوند، حیاتی است. یک Job در CI معمولاً دارای Checkout مخزن، کش مدیریت بسته و یک توکن گیت‌هاب است. در حالی که مجوزهای گیت‌هاب هویت کلی گردش‌کار را محدود می‌کنند (مثلاً contents: read و pull-requests: write)، اما فاقد جزئیاتی هستند که توضیح دهند چرا یک فایل یا بسته خاص در حال تغییر است.
safe-upgrade می‌تواند یک Pull Request مربوط به Dependabot را ارزیابی کند یا یک به‌روزرسانی تأیید شده را به صورت پیش‌نویس باز کند. در محیط تولید، فرآیند CI یک ضمانت‌نامه اجرا را که توسط یک ریشه (Root) مورد اعتماد صادر شده، وارد می‌کند. این ضمانت‌نامه می‌تواند اجرا را به موارد زیر محدود کند:
- بسته درخواست شده و نسخه دقیق آن.
- Worktree موقت.
- یک شاخه (Branch) خاص.
- انتشار فقط در حالت پیش‌نویس (Draft-only).
این ساختار دو سطح کنترل ایجاد می‌کند: مجوزهای GitHub Actions هویت گردش‌کار را محدود می‌کنند، در حالی که ضمانت‌نامه‌های Tenuo ابزارها، آرگومان‌ها، مسیرها و طول عمر هر وظیفه تفویض شده را محدود می‌کنند.
تعریف «اجرای امن» برای هوش مصنوعی
Tenuo ایمنی را از طریق چندین ویژگی قابل بازرسی تعریف می‌کند:
- تصمیمات بسته (Closed Decisions): Jev فقط از میان انتقال‌هایی انتخاب می‌کند که قبلاً توسط کد مورد اعتماد، مجاز شناخته شده‌اند.
- تفکیک وظایف (Separated Duties): نوشتن تست، پیاده‌سازی، تأیید و انتشار از مجوزهای نوشتاری متفاوتی استفاده می‌کنند.
- شواهد مستقل (Independent Evidence): تأییدیه هر یافته را ارزیابی می‌کند در حالی که فایل‌های کاندید فقط-خواندنی می‌مانند.
- فرآیندهای محصور (Contained Processes): Tenuo فراخوانی‌های ابزارهای محافظت‌شده را مجاز می‌کند، در حالی که یک Sandbox در سطح سیستم‌عامل محدود می‌کند که فرآیندهای مخزن و بسته به چه چیزهایی دسترسی دارند.
- عدم قطعیت صریح (Explicit Uncertainty): اطمینان پایین، وضعیت قدیمی، نقض سیاست‌ها و شواهد ناقص منجر به یک نتیجه مشروط یا توقف کامل می‌شود.
یک الگوی قابل استفاده مجدد
این الگو فراتر از به‌روزرسانی وابستگی‌ها گسترش می‌یابد. هر گردش‌کاری که نیاز به تفویض اختیار در موارد حساس دارد می‌تواند از این پشته (Stack) پیروی کند:
۱. محاسبه انتقال‌های معتبر از وضعیت مورد اعتماد.
۲. پرسیدن یک سوال معنایی محدود از Jev درباره آن انتقال‌ها.
۳. اعتبارسنجی پاسخ تایپ‌شده و متصل کردن آن به یک Worker شناخته شده.
۴. تفویض یک ضمانت‌نامه Tenuo محدود شده به وظیفه آن Worker.
۵. بازگرداندن شواهد به LangGraph و تأیید مستقل آن.
اصل بنیادی این است که جزء توصیه کننده اقدام را از جزء تعریف کننده اختیار جدا نگه دارید.
برای توسعه‌دهندگانی که به دنبال پیاده‌سازی این سیستم هستند، این معماری با استفاده از @typesafe-ai/sdk 0.6.0 و @tenuo/core 0.3.0-beta.0 ساخته شده است. این پیاده‌سازی را می‌توان از طریق npm با دستور npx @tenuo/safe-upgrade doctor یا npx @tenuo/safe-upgrade assess --repository . اجرا کرد. پیاده‌سازی کامل و تست‌های Smoke end-to-end در مخزن متن‌باز safe-upgrade در دسترس است.
گام بعدی شما
- اگر از عامل‌های خودکار در CI/CD استفاده می‌کنید، مدل «تفکیک تصمیم از اجرا» را در معماری خود پیاده کنید.
- ابزار safe-upgrade را از طریق دستور
npx @tenuo/safe-upgrade assess --repository .روی مخازن خود تست کنید. - مستندات
@typesafe-ai/sdkرا برای پیاده‌سازی تصمیمات تایپ‌شده مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو