طراحی امنیتمحور
Triggerfish بر یک اصل واحد بنا شده است: LLM هیچ اختیاری ندارد. درخواست اقدام میکند؛ لایه سیاست تصمیم میگیرد. هر تصمیم امنیتی توسط کد قطعی گرفته میشود که هوش مصنوعی نمیتواند آن را دور بزند، لغو کند یا تحت تأثیر قرار دهد.
این صفحه توضیح میدهد که چرا Triggerfish این رویکرد را اتخاذ کرده، چگونه با پلتفرمهای سنتی عامل هوش مصنوعی تفاوت دارد، و جزئیات هر مؤلفه مدل امنیتی کجا قابل دسترسی است.
چرا امنیت باید زیر LLM باشد
مدلهای زبانی بزرگ قابل تزریق prompt هستند. یک ورودی با دقت ساختهشده — چه از یک پیام خارجی مخرب، چه از یک سند آلوده، یا چه از پاسخ یک ابزار به خطر افتاده — میتواند باعث شود LLM دستورالعملهایش را نادیده بگیرد و اقداماتی انجام دهد که از آن منع شده بود. این یک خطر نظری نیست. یک مشکل مستندشده و حلنشده در صنعت هوش مصنوعی است.
اگر مدل امنیتی شما به پیروی LLM از قوانین وابسته باشد، یک تزریق موفق میتواند تمام حفاظهایی که ساختهاید را دور بزند.
Triggerfish این مشکل را با انتقال تمام اجرای امنیتی به لایه کدی حل میکند که زیر LLM قرار دارد. هوش مصنوعی هرگز تصمیمات امنیتی را نمیبیند. هرگز ارزیابی نمیکند که آیا یک اقدام باید مجاز باشد. فقط درخواست اقدام میکند و لایه اجرای سیاست — که بهعنوان کد خالص و قطعی اجرا میشود — تصمیم میگیرد که آیا آن اقدامات ادامه یابند.
امنیت لایه LLM هیچ مکانیزمی برای لغو، رد یا تأثیرگذاری بر لایه اجرای سیاست ندارد. هیچ منطق «تجزیه خروجی LLM برای دستورات دورزدن» وجود ندارد. جداسازی معماری است، نه رفتاری. :::
ثابت اصلی
هر تصمیم طراحی در Triggerfish از یک ثابت سرچشمه میگیرد:
ورودیهای یکسان همیشه تصمیم امنیتی یکسانی تولید میکنند. بدون تصادف، بدون فراخوانی LLM، بدون صلاحدید.
این به معنای آن است که رفتار امنیتی:
- قابل بازرسی است — میتوانید هر تصمیمی را بازپخش کنید و همان نتیجه را بگیرید
- قابل آزمون است — کد قطعی را میتوان با تستهای خودکار پوشش داد
- قابل تأیید است — موتور سیاست متنباز (مجوز Apache 2.0) است و هرکسی میتواند آن را بررسی کند
اصول امنیتی
| اصل | معنا | صفحه جزئیات |
|---|---|---|
| طبقهبندی داده | تمام دادهها یک سطح حساسیت دارند (RESTRICTED، CONFIDENTIAL، INTERNAL، PUBLIC). طبقهبندی توسط کد هنگام ورود داده به سیستم تعیین میشود. | معماری: طبقهبندی |
| عدم نوشتن به پایین | دادهها فقط میتوانند به کانالها و گیرندگانی با سطح طبقهبندی مساوی یا بالاتر جریان یابند. دادههای CONFIDENTIAL نمیتوانند به کانال PUBLIC برسند. بدون استثنا. | قانون عدم نوشتن به پایین |
| Taint نشست | وقتی نشستی به دادهای در یک سطح طبقهبندی دسترسی پیدا میکند، کل نشست به آن سطح آلوده میشود. Taint فقط میتواند بالا برود، هرگز کاهش نمییابد. | معماری: Taint |
| Hookهای قطعی | هشت Hook اجرایی در نقاط بحرانی هر جریان داده اجرا میشوند. هر Hook همزمان، ثبتشده و غیرقابل جعل است. | معماری: موتور سیاست |
| هویت در کد | هویت کاربر توسط کد در هنگام برقراری نشست تعیین میشود، نه توسط LLM که محتوای پیام را تفسیر کند. | هویت و احراز هویت |
| تفویض عامل | فراخوانیهای عامل به عامل توسط گواهینامههای رمزنگاری، سقفهای طبقهبندی و محدودیتهای عمق کنترل میشوند. | تفویض عامل |
| جداسازی رمزها | بیانات اعتبار در کلیدزنجیر سیستمعامل یا خزانهها ذخیره میشوند، هرگز در فایلهای پیکربندی. Pluginها نمیتوانند به بیانات اعتبار سیستمی دسترسی یابند. | مدیریت رمزها |
| ثبت همه چیز | هر تصمیم سیاست با زمینه کامل ثبت میشود: مُهر زمانی، نوع Hook، شناسه نشست، ورودی، نتیجه و قوانین ارزیابیشده. | بازرسی و انطباق |
عاملهای هوش مصنوعی سنتی در مقابل Triggerfish
اکثر پلتفرمهای عامل هوش مصنوعی برای اجرای ایمنی به LLM تکیه میکنند. سیستم prompt میگوید «دادههای حساس را به اشتراک نگذار» و به عامل اعتماد میشود که اطاعت کند. این رویکرد ضعفهای بنیادی دارد.
| جنبه | عامل هوش مصنوعی سنتی | Triggerfish |
|---|---|---|
| اجرای امنیت | دستورالعملهای سیستم prompt به LLM | کد قطعی زیر LLM |
| دفاع در برابر تزریق prompt | امید به مقاومت LLM | LLM از ابتدا هیچ اختیاری ندارد |
| کنترل جریان داده | LLM تصمیم میگیرد چه چیزی امن است | برچسبهای طبقهبندی + قانون عدم نوشتن به پایین در کد |
| تأیید هویت | LLM تفسیر میکند «من مدیر هستم» | کد هویت رمزنگاری کانال را بررسی میکند |
| رد بازرسی | گزارشهای مکالمه LLM | گزارشهای ساختاریافته تصمیمات سیاست با زمینه کامل |
| دسترسی به بیانات اعتبار | حساب سرویس سیستمی برای همه کاربران | بیانات اعتبار تفویضشده کاربر؛ مجوزهای سیستم منبع به ارث رسیده |
| قابلیت آزمون | مبهم — وابسته به عبارتپردازی prompt | قطعی — ورودی یکسان، تصمیم یکسان، هر بار |
| باز برای تأیید | معمولاً اختصاصی | مجوز Apache 2.0، کاملاً قابل بازرسی |
Triggerfish ادعا نمیکند که LLMها غیرقابل اعتماد هستند. ادعا میکند که LLMها لایه نادرستی برای اجرای امنیت هستند. یک LLM با prompt خوب اکثر اوقات دستورالعملهایش را دنبال میکند. اما «اکثر اوقات» یک تضمین امنیتی نیست. Triggerfish تضمینی ارائه میدهد: لایه سیاست کد است و کد همیشه آنچه گفته شده انجام میدهد. :::
دفاع در عمق
Triggerfish سیزده لایه دفاعی پیادهسازی میکند. هیچ لایه واحدی به تنهایی کافی نیست؛ با هم، یک مرز امنیتی تشکیل میدهند:
۱. احراز هویت کانال — هویت تأییدشده توسط کد در هنگام برقراری نشست ۲. دسترسی داده آگاه از مجوز — مجوزهای سیستم منبع، نه بیانات اعتبار سیستمی ۳. ردیابی Taint نشست — خودکار، اجباری، فقط افزایشی ۴. نسب داده — زنجیره منشأ کامل برای هر عنصر داده ۵. Hookهای اجرای سیاست — قطعی، غیرقابل دورزدن، ثبتشده ۶. MCP Gateway — دسترسی ابزار خارجی امن با مجوزهای هر ابزار ۷. سندباکس Plugin — جداسازی دوگانه Deno + WASM ۸. جداسازی رمزها — کلیدزنجیر سیستمعامل یا خزانه، هرگز فایلهای پیکربندی ۹. سندباکس ابزار سیستم فایل — محدودیت مسیر، طبقهبندی مسیر، مجوزهای I/O محدود به Taint ۱۰. هویت عامل — زنجیرههای تفویض رمزنگاری ۱۱. ثبت بازرسی — غیرقابل غیرفعالسازی ۱۲. جلوگیری از SSRF — لیست رد IP + بررسیهای رفع DNS ۱۳. دروازهبندی طبقهبندی حافظه — نوشتن در سطح خود، خواندن فقط به پایین
گامهای بعدی
| صفحه | توضیحات |
|---|---|
| راهنمای طبقهبندی | راهنمای عملی انتخاب سطح مناسب برای کانالها، سرورهای MCP و یکپارچهسازیها |
| قانون عدم نوشتن به پایین | قانون بنیادی جریان داده و نحوه اجرای آن |
| هویت و احراز هویت | احراز هویت کانال و تأیید هویت مالک |
| تفویض عامل | هویت عامل به عامل، گواهینامهها و زنجیرههای تفویض |
| مدیریت رمزها | نحوه مدیریت بیانات اعتبار توسط Triggerfish در سطوح مختلف |
| بازرسی و انطباق | ساختار رد بازرسی، ردیابی و صادرات انطباق |