تصور کنید یک برنامهنویس برای اتوماسیون شرکتش، کلیدهای دسترسی به تمام سرویسهای ابری را مستقیماً در حافظهی یک عامل هوش مصنوعی قرار داده است؛ در واقع او کلید کل خانه به یک پارکبان داده تا فقط ماشین را پارک کند. این دقیقاً همان نقطهضعفی است که Agent Vault برای رفع آن طراحی شده است.
به نقل از مستندات منتشر شده در ۲۶ اوت ۲۰۲۶، ابزار Agent Vault محصول شرکت Infisical، با انتقال مدیریت اعتبارنامهها به یک لایهی پروکسی HTTP، ریسک نشت دادهها از طریق لاگها یا تزریق پرامپت (Prompt Injection) — که شبیه به فریب دادن یک نگهبان برای باز کردن درهای بسته است — را به کلی حذف میکند.
همانطور که در تحلیل قبلی ما دربارهی استانداردهای تأیید فراخوانی ابزارها توسط Correctover و استاندارد ۷ بُعدی آن اشاره کردیم، صنعت در حال حرکت به سمتی است که لایهی اعتماد را از مدل جدا کرده و به زیرساخت منتقل کند. در حال حاضر اکثر توسعهدهندگان بر متغیرهای محیطی (Environment Variables) تکیه میکنند که دسترسی نامحدود و کلی به تمام سرویسهایی که عامل با آنها در تماس است میدهد. اما Agent Vault این ساختار را تغییر میدهد.
این سامانه به عنوان یک واسطه بین محیط اجرای عامل (Agent Runtime) و API هدف قرار میگیرد. عامل درخواست خود را به پروکسی میفرستد و پروکسی پس از تطبیق الگو، اعتبارنامهی لازم را تزریق کرده و درخواست را ارسال میکند؛ به گونهای که عامل هرگز کلید خام را نمیبیند.
معماری پروکسی
بر اساس مستندات فنی، این سیستم برای حفظ مرزهای امنیتی به اجزای زیر متکی است:
- سرور پروکسی HTTP: برای رهگیری درخواستهای خروجی روی یک پورت محلی یا نقطه انتهایی شبکه.
- مخزن اعتبارنامه: مدیریت شده توسط موتور اسرار Infisical برای ذخیرهسازی امن.
- تطبیقدهنده مسیر: نگاشت الگوهای درخواست (مثلاً
api.github.com/*) به هویتهای خاص. - ثبتکننده حسابرسی: ثبت هر درخواست، وضعیت پاسخ و اعتبارنامهی استفاده شده.
- مدیریت چرخش: بهروزرسانی کلیدها در بازههای زمانی مشخص بدون ایجاد وقفه در کار عامل.
نمونههای پیکربندی مسیر
پروکسی از الگوهای مشخصی برای تعیین هویت استفاده میکند. برای مثال، یک پیکربندی ممکن است مسیر api.github.com/* را به یک github-bot-token متصل کند که به صورت Authorization: Bearer {token} تزریق میگردد. به همین ترتیب، مسیر api.stripe.com/* میتواند به یک stripe-restricted-key و مسیر slack.com/api/* به یک توکن slack-bot-oauth نگاشت شود. در این حالت، عامل فقط نقطه انتهایی پروکسی و مسیر هدف را میشناسد و هرگز به اعتبارنامهی واقعی دسترسی ندارد.
جریان تحلیل اعتبارنامهها
وقتی یک عامل ابزاری را فراخوانی میکند، درخواست از یک مسیر سختگیرانه عبور میکند. ابتدا، عامل درخواستی را به پروکسی ارسال میکند، مثلاً: http://localhost:8080/api.github.com/repos/owner/repo. پروکسی این مسیر را تجزیه کرده و آن را با مسیرهای پیکربندی شده تطبیق میدهد. اگر تطبیقی یافت شود، مخزن توکن را بازیابی کرده و آن را در هدر Authorization تزریق میکند.
پس از پاسخ API، پروکسی هدرهای حساس را از پاسخ حذف کرده و سپس دادهها را به عامل برمیگرداند. اگر عاملی سعی کند به API بدون مسیر تعریفشده دسترسی پیدا کند، پروکسی خطای ۴۰۳ (Forbidden) برمیگرداند. این سازوکار بهطور مؤثری جلوی تلاشهای استخراج اعتبارنامه (Credential Exfiltration) را که توسط تزریق پرامپت تحریک شدهاند، میگیرد. این رویکرد در کنار راهکارهای TrustGraph برای محدود کردن خروجیها، لایهای دفاعی در برابر خروج غیرمجاز دادهها ایجاد میکند.
مدیریت چرخش در میان جلسه
گردشهای کاری طولانیمدت که ممکن است روزها به طول بینجامند، چرخش اعتبارنامهها را به یک چالش فنی تبدیل میکنند. Agent Vault دو استراتژی برای جلوگیری از قطع اتصال در میان جلسات به کار میگیرد:
- بهروزرسانی تنبل (Lazy Refresh): پروکسی در هر درخواست تاریخ انقضا را چک میکند. اگر اعتبارنامهی کششده در یک بازه زمانی قابل تنظیم (به طور پیشفرض ۵ دقیقه) باشد، پیش از ارسال درخواست، یک توکن تازه از مخزن دریافت میکند.
- چرخش در پسزمینه (Background Rotation): یک goroutine مجزا بهطور منظم مخزن را برای تغییرات بررسی میکند. هنگامی که یک کلید تغییر میکند، پروکسی بهطور خودکار حافظهی موقت (Cache) داخلی خود را بهروز میکند.
عامل متوجه این چرخش نمیشود و فراخوانیها بر اساس منطق تجاری، بدون توجه به وضعیت کلید، با موفقیت انجام میشوند.
شناسایی و استقرار
هر تراکنش یک لاگ دقیق حسابرسی ایجاد میکند که شامل برچسب زمانی، هویت عامل (مشتق شده از گواهینامه mTLS یا کلید API)، الگوی مسیر تطبیق داده شده، شناسه اعتبارنامه، نقطه انتهایی هدف، متد HTTP، کد وضعیت، اندازه درخواست/پاسخ و میزان تأخیر (Latency) است.
این سیستم میتواند ناهنجاریهای زیر را شناسایی و علامتگذاری کند:
- حجم غیرعادی: زمانی که عامل ۱۰ برابر بیشتر از خط پایه (Baseline) تعیین شده، API فراخوانی کند.
- نقاط انتهایی جدید: تلاش عامل برای دسترسی به API که هرگز پیش از این فراخوانی نکرده است.
- احراز هویت ناموفق: پاسخهای مکرر ۴۰۱ یا ۴۰۳ که نشاندهنده تلاش برای حمله است.
- پیلودهای حجیم: اندازه پاسخهایی که از محدوده مورد انتظار فراتر میروند و نشاندهنده احتمال استخراج دادهها هستند.
این سیگنالها برای بررسی انسانی به سامانههای SIEM ارسال میشوند تا از مسدود شدن اشتباه درخواستها و ایجاد مثبت کاذب (False Positive) جلوگیری شود.
کاربران میتوانند این ابزار را به سه روش مستقر کنند:
۱. کانتینر Sidecar: ایدهآل برای کوبرنتیز، با ارائه تأخیر کم و ایزولاسیون برای هر عامل، هرچند هزینه منابع بالاتری دارد.
۲. سرویس پروکسی مشترک: هزینه منابع کمتر و لاگ متمرکز، اما ایجاد یک نقطه شکست واحد (Single Point of Failure).
۳. کتابخانه داخلی (Embedded Library): حذف گامهای شبکه (Zero network hop)، هرچند مرزهای امنیتی و استقرار عامل را پیچیده میکند.
مرزهای امنیتی و حالتهای شکست
پروکسی سه مرز سخت را اجرا میکند: عامل نمیتواند اعتبارنامهها را مستقیماً بخواند، نمیتواند به APIهای خارج از نقشه دسترسی داشته باشد (درخواستها در حالت بسته شکست میخورند) و نمیتواند استفاده از اعتبارنامههای منقضی یا لغو شده را تحمیل کند.
با این حال، تیمها باید برای حالتهای شکست خاص برنامهریزی کنند. از کار افتادن پروکسی باعث شکست فراخوانی ابزارها میشود که نیازمند بررسیهای سلامت (Health Checks) و ریاستارت خودکار است. اگر مخزن در دسترس نباشد، پروکسی میتواند برای بقا در قطعیهای کوتاه از اعتبارنامههای کششده با TTL استفاده کند. پیکربندیهای اشتباه مسیر منجر به خطاهای ۴۰۳ در لاگهای حسابرسی میشود، در حالی که عامل هیچ دیدی نسبت به دلیل شکست فراخوانی نخواهد داشت.
موازنههای فنی
طبق گزارش dev.to، این الگو برای عاملهای ناهمگونی که APIهای متعدد شخص ثالث را فراخوانی میکنند، ایدهآل است زیرا سیاست امنیتی را از منطق عامل جدا میکند. اما این روش پیچیدگی عملیاتی را افزایش داده و یک گام شبکه اضافه میکند که برای سیستمهای با نیاز به تأخیر زیر میلیثانیه مناسب نیست.
برای تیمهایی که در حال حاضر از AWS Secrets Manager با نقشهای IAM استفاده میکنند، این پروکسی ممکن است تکراری باشد. اما برای کسانی که به دنبال ردپای حسابرسی متمرکز بدون تغییر در کد عامل هستند، این الگو یک نقطه اجرای ضروری فراهم میکند. این رویکرد در واقع یکی از راهکارهای کلیدی برای رفع گلوگاههای امنیتی در محیطهای سازمانی است.
این تغییر رویکرد نشان میدهد که فاز بعدی هوش مصنوعی عاملمحور، کمتر بر استدلال مدل و بیشتر بر زیرساختهای حاکمیتی متمرکز خواهد بود. شما باید نحوه ادغام این الگوهای پروکسی با چارچوبهای نوظهور حاکمیت AI را رصد کنید تا ببینید آیا اصل «حداقل دسترسی» (Least-Privilege) به یک الزام سخت برای استقرار AI در سازمانهای بزرگ تبدیل میشود یا خیر.
گام بعدی شما
- بررسی معماری Sidecar برای استقرار در محیطهای Kubernetes جهت کاهش تأخیر.
- تعریف دقیقترین الگوهای مسیر (Route Patterns) برای اجرای اصل «حداقل دسترسی».
- اتصال لاگهای پروکسی به یک سامانه مانیتورینگ برای شناسایی سریع تلاشهای تزریق پرامپت.
این تغییر رویکرد نشان میدهد که فاز بعدی هوش مصنوعی عاملمحور، کمتر بر استدلال مدل و بیشتر بر زیرساختهای حاکمیتی متمرکز خواهد بود؛ به تحلیل ما دربارهی پروتکلهای MCP برای مدیریت ابزارها مراجعه کنید.
گفتگو