استقرارِ امنِ ایجنت‌های هوش مصنوعی

Claude Code و Agent SDK ابزارهای قدرتمندی هستند که می‌توانند کد اجرا کنند، به فایل‌ها دسترسی داشته باشند و از طرفِ تو با سرویس‌های بیرونی تعامل کنند. مثلِ هر ابزاری با این توانایی‌ها، استقرارِ سنجیده‌ی آن‌ها تضمین می‌کند که از مزایایشان بهره ببری در حالی که کنترل‌های مناسب را حفظ می‌کنی.

برخلافِ نرم‌افزارِ سنتی که مسیرهای کدِ از پیش‌تعیین‌شده را دنبال می‌کند، این ابزارها اقداماتشان را به‌صورتِ پویا بر اساسِ کانتکست و اهداف تولید می‌کنند. همین انعطاف‌پذیری است که آن‌ها را مفید می‌کند، اما این یعنی رفتارشان می‌تواند تحتِ تأثیرِ محتوایی که پردازش می‌کنند — فایل‌ها، صفحاتِ وب یا ورودیِ کاربر — قرار بگیرد. به این گاهی prompt injection می‌گویند. مثلاً اگر README یک مخزن شاملِ دستورهای غیرعادی باشد، Claude Code ممکن است آن‌ها را به‌گونه‌ای در اقداماتش بگنجاند که اپراتور انتظارش را نداشت. این راهنما راه‌های عملیِ کاهشِ این خطر را پوشش می‌دهد.

خبرِ خوب این است که ایمن‌سازیِ استقرارِ یک ایجنت به زیرساختِ عجیب‌وغریب نیاز ندارد. همان اصولی که برای اجرای هر کدِ نیمه‌مورد‌اعتماد به کار می‌رود اینجا هم صدق می‌کند: ایزولاسیون، حداقلِ امتیاز، و دفاعِ لایه‌لایه. Claude Code چند قابلیتِ امنیتی دارد که به نگرانی‌های رایج کمک می‌کند، و این راهنما این‌ها را به‌همراهِ گزینه‌های سخت‌سازیِ اضافی برای کسانی که نیاز دارند مرور می‌کند.

هر استقراری به حداکثرِ امنیت نیاز ندارد. توسعه‌دهنده‌ای که Claude Code را روی لپ‌تاپش اجرا می‌کند نیازهایی متفاوت از شرکتی دارد که داده‌های مشتری را در محیطی چنداجاره‌ای (multi-tenant) پردازش می‌کند. این راهنما گزینه‌هایی را از قابلیت‌های امنیتیِ توکار Claude Code تا معماری‌های تولیدیِ سخت‌سازی‌شده ارائه می‌دهد، تا بتوانی آنچه را که به موقعیتت می‌خورد انتخاب کنی.

مدلِ تهدید

ایجنت‌ها می‌توانند به‌خاطرِ prompt injection (دستورهای جاسازی‌شده در محتوایی که پردازش می‌کنند) یا خطای مدل اقداماتِ ناخواسته انجام دهند. مدل‌های Claude برای مقاومت در برابرِ این طراحی شده‌اند؛ برای جزئیاتِ ارزیابی مرورِ کلیِ مدل‌ها و system card مدلی که مستقر می‌کنی را ببین.

با این حال، دفاعِ لایه‌لایه همچنان شیوه‌ی خوبی است. مثلاً اگر ایجنتی فایلِ مخربی را پردازش کند که به آن دستور می‌دهد داده‌های مشتری را به سروری بیرونی بفرستد، کنترل‌های شبکه می‌توانند آن درخواست را کاملاً مسدود کنند.

قابلیت‌های امنیتیِ توکار

Claude Code چند قابلیتِ امنیتی دارد که به نگرانی‌های رایج می‌پردازد. برای جزئیاتِ کامل مستنداتِ امنیتی را ببین.

سیستمِ دسترسی‌ها: هر ابزار و هر دستورِ bash را می‌توان طوری پیکربندی کرد که اجازه بدهد، مسدود کند یا برای تأیید از کاربر بپرسد. از الگوهای glob برای ساختِ قواعدی مثلِ «اجازه به همه‌ی دستورهای npm» یا «مسدود کردنِ هر دستوری با sudo» استفاده کن. سازمان‌ها می‌توانند سیاست‌هایی تعیین کنند که در همه‌ی کاربران اعمال شود. دسترسی‌ها را ببین.
تجزیه‌ی دستور برای دسترسی‌ها: پیش از اجرای دستورهای bash، Claude Code آن‌ها را به یک AST تجزیه می‌کند و نتیجه را با قواعدِ دسترسیِ تو تطبیق می‌دهد. دستورهایی که به‌درستی تجزیه نشوند، یا با هیچ قاعده‌ی اجازه‌ای مطابقت نکنند، به تأییدِ صریح نیاز دارند. مجموعه‌ای کوچک از ساختارها مثلِ eval همیشه به تأیید نیاز دارند، فارغ از قواعدِ اجازه. این یک دروازه‌ی دسترسی است، نه یک سندباکس؛ از روی مسیرِ مقصد یا اثراتِ یک دستور استنتاج نمی‌کند که خطرناک است یا نه.
خلاصه‌سازیِ جست‌وجوی وب: نتایجِ جست‌وجو به‌جای انتقالِ محتوای خام مستقیماً به کانتکست، خلاصه می‌شوند، که خطرِ prompt injection از محتوای مخربِ وب را کاهش می‌دهد.
حالتِ سندباکس: دستورهای bash را می‌توان در محیطی سندباکس‌شده اجرا کرد که دسترسیِ فایل‌سیستم و شبکه را محدود می‌کند. برای جزئیات مستنداتِ سندباکسینگ را ببین.

اصولِ امنیتی

برای استقرارهایی که فراتر از پیش‌فرض‌های Claude Code به سخت‌سازیِ بیشتر نیاز دارند، این اصول گزینه‌های موجود را هدایت می‌کنند.

مرزهای امنیتی

یک مرزِ امنیتی، مؤلفه‌هایی با سطوحِ اعتمادِ متفاوت را از هم جدا می‌کند. برای استقرارهای با امنیتِ بالا، می‌توانی منابعِ حساس (مثلِ اعتبارنامه‌ها) را بیرونِ مرزی که شاملِ ایجنت است قرار دهی. اگر در محیطِ ایجنت اتفاقی بیفتد، منابعِ بیرونِ آن مرز محافظت‌شده می‌مانند.

مثلاً به‌جای دادنِ دسترسیِ مستقیم به یک کلید API به ایجنت، می‌توانی یک proxy را بیرونِ محیطِ ایجنت اجرا کنی که کلید را به درخواست‌ها تزریق می‌کند. ایجنت می‌تواند فراخوانیِ API انجام دهد، اما هرگز خودِ اعتبارنامه را نمی‌بیند. این الگو برای استقرارهای چنداجاره‌ای یا هنگامِ پردازشِ محتوای نامورد‌اعتماد مفید است.

حداقلِ امتیاز

در صورتِ نیاز، می‌توانی ایجنت را به فقط همان توانایی‌هایی که برای وظیفه‌ی خاصش لازم است محدود کنی:

منبع	گزینه‌های محدودسازی
فایل‌سیستم	فقط دایرکتوری‌های لازم را mount کن، ترجیحاً فقط‌خواندنی
شبکه	از طریقِ proxy به نقاطِ‌پایانی مشخص محدود کن
اعتبارنامه‌ها	به‌جای افشای مستقیم، از طریقِ proxy تزریق کن
توانایی‌های سیستمی	قابلیت‌های Linux را در کانتینرها drop کن

دفاعِ لایه‌لایه

برای محیط‌های با امنیتِ بالا، لایه‌بندیِ چند کنترل حفاظتِ بیشتری فراهم می‌کند. گزینه‌ها شامل:

ایزولاسیونِ کانتینر
محدودیت‌های شبکه
کنترل‌های فایل‌سیستم
اعتبارسنجیِ درخواست در یک proxy

ترکیبِ درست به مدلِ تهدید و الزاماتِ عملیاتیِ تو بستگی دارد.

فناوری‌های ایزولاسیون

فناوری‌های مختلفِ ایزولاسیون توازن‌های متفاوتی میانِ قدرتِ امنیتی، کارایی و پیچیدگیِ عملیاتی ارائه می‌دهند.

فناوری	قدرتِ ایزولاسیون	سربارِ کارایی	پیچیدگی
سندباکسِ رانتایم	خوب (پیش‌فرض‌های امن)	بسیار کم	کم
کانتینرها (Docker)	بسته به راه‌اندازی	کم	متوسط
gVisor	عالی (با راه‌اندازیِ درست)	متوسط/زیاد	متوسط
VMها (Firecracker, QEMU)	عالی (با راه‌اندازیِ درست)	زیاد	متوسط/زیاد

سندباکسِ رانتایم

برای ایزولاسیونِ سبک بدونِ کانتینر، sandbox-runtime محدودیت‌های فایل‌سیستم و شبکه را در سطحِ سیستم‌عامل اعمال می‌کند.

مزیتِ اصلی سادگی است: نیازی به پیکربندیِ Docker، ایمیج‌های کانتینر یا راه‌اندازیِ شبکه نیست. proxy و محدودیت‌های فایل‌سیستم توکار هستند. تو یک فایلِ تنظیمات می‌دهی که دامنه‌ها و مسیرهای مجاز را مشخص می‌کند.

چطور کار می‌کند:

فایل‌سیستم: از primitiveهای سیستم‌عامل (bubblewrap روی Linux، sandbox-exec روی macOS) برای محدودسازیِ دسترسیِ خواندن/نوشتن به مسیرهای پیکربندی‌شده استفاده می‌کند
شبکه: namespaceِ شبکه را حذف می‌کند (Linux) یا از پروفایل‌های Seatbelt استفاده می‌کند (macOS) تا ترافیکِ شبکه را از طریقِ یک proxyِ توکار مسیریابی کند
پیکربندی: allowlistهای مبتنی بر JSON برای دامنه‌ها و مسیرهای فایل‌سیستم

راه‌اندازی:

npm install @anthropic-ai/sandbox-runtime

سپس یک فایلِ پیکربندی بساز که مسیرها و دامنه‌های مجاز را مشخص کند.

ملاحظاتِ امنیتی:

کرنلِ مشترکِ میزبان: برخلافِ VMها، فرایندهای سندباکس‌شده کرنلِ میزبان را به اشتراک می‌گذارند. یک آسیب‌پذیریِ کرنل می‌تواند نظراً فرار را ممکن کند. برای برخی مدل‌های تهدید این قابل قبول است، اما اگر به ایزولاسیون در سطحِ کرنل نیاز داری، از gVisor یا یک VMِ مجزا استفاده کن.
بدونِ بازرسیِ TLS: proxy دامنه‌ها را بر اساسِ نامِ میزبانِ ارائه‌شده توسطِ کلاینت در allowlist قرار می‌دهد و ترافیکِ رمزشده را پایان نمی‌دهد یا بازرسی نمی‌کند. کدی که درونِ سندباکس اجرا می‌شود می‌تواند نظراً از domain fronting یا تکنیک‌های مشابه برای رسیدن به میزبان‌های بیرونِ allowlist استفاده کند. اگر مدلِ تهدیدت به تضمین‌های قوی‌تر نیاز دارد، یک proxyِ پایان‌دهنده‌ی TLS پیکربندی کن. برای جزئیاتِ بیشتر محدودیت‌های امنیتیِ سندباکسینگ را ببین. جدا از این، اگر ایجنت اعتبارنامه‌های گسترده‌ای برای یک دامنه‌ی مجاز دارد، مطمئن شو نمی‌تواند از آن دامنه برای راه‌اندازیِ درخواست‌های دیگرِ شبکه یا برای استخراجِ داده استفاده کند.

برای بسیاری از موارد استفاده‌ی تک‌توسعه‌دهنده و CI/CD، sandbox-runtime با حداقلِ راه‌اندازی سطح را به‌طورِ چشمگیر بالا می‌برد. بخش‌های زیر کانتینرها و VMها را برای استقرارهایی که به ایزولاسیونِ قوی‌تر نیاز دارند پوشش می‌دهند.

کانتینرها

کانتینرها ایزولاسیون را از طریقِ namespaceهای Linux فراهم می‌کنند. هر کانتینر دیدِ خاصِ خودش را از فایل‌سیستم، درختِ فرایند و پشته‌ی شبکه دارد، در حالی که کرنلِ میزبان را به اشتراک می‌گذارد.

یک پیکربندیِ کانتینرِ سخت‌سازی‌شده‌ی امنیتی ممکن است این‌گونه باشد:

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

کارِ هر گزینه:

گزینه	هدف
`--cap-drop ALL`	قابلیت‌های Linux مثلِ `NET_ADMIN` و `SYS_ADMIN` را که می‌توانند ارتقای امتیاز را ممکن کنند حذف می‌کند
`--security-opt no-new-privileges`	جلوی کسبِ امتیازِ فرایندها از طریقِ باینری‌های setuid را می‌گیرد
`--security-opt seccomp=...`	فراخوانی‌های سیستمیِ موجود را محدود می‌کند؛ پیش‌فرضِ Docker حدودِ ۴۴ تا را مسدود می‌کند، پروفایل‌های سفارشی می‌توانند بیشتر مسدود کنند
`--read-only`	فایل‌سیستمِ ریشه‌ی کانتینر را تغییرناپذیر می‌کند و جلوی پایدارسازیِ تغییرات توسطِ ایجنت را می‌گیرد
`--tmpfs /tmp:...`	یک دایرکتوریِ موقتِ قابل‌نوشتن فراهم می‌کند که با توقفِ کانتینر پاک می‌شود
`--network none`	همه‌ی واسط‌های شبکه را حذف می‌کند؛ ایجنت از طریقِ سوکتِ Unix mount‌شده‌ی زیر ارتباط برقرار می‌کند
`--memory 2g`	مصرفِ حافظه را محدود می‌کند تا از تخلیه‌ی منابع جلوگیری شود
`--pids-limit 100`	تعدادِ فرایند را محدود می‌کند تا از fork bomb جلوگیری شود
`--user 1000:1000`	به‌عنوانِ کاربرِ غیرِ root اجرا می‌شود
`-v ...:/workspace:ro`	کد را فقط‌خواندنی mount می‌کند تا ایجنت بتواند تحلیلش کند ولی تغییرش ندهد. از mount کردنِ دایرکتوری‌های حساسِ میزبان مثلِ `~/.ssh`، `~/.aws` یا `~/.config` بپرهیز
`-v .../proxy.sock:...`	یک سوکتِ Unix را mount می‌کند که به یک proxyِ در حالِ اجرا بیرونِ کانتینر متصل است (پایین را ببین)

معماریِ سوکتِ Unix:

با --network none، کانتینر اصلاً هیچ واسطِ شبکه‌ای ندارد. تنها راهِ ایجنت برای رسیدن به دنیای بیرون از طریقِ سوکتِ Unix mount‌شده است که به یک proxyِ در حالِ اجرا روی میزبان متصل می‌شود. این proxy می‌تواند allowlistهای دامنه را اعمال کند، اعتبارنامه‌ها را تزریق کند و همه‌ی ترافیک را لاگ کند.

این همان معماری‌ای است که sandbox-runtime استفاده می‌کند. حتی اگر ایجنت از طریقِ prompt injection به خطر بیفتد، نمی‌تواند داده را به سرورهای دلخواه استخراج کند. فقط می‌تواند از طریقِ proxy ارتباط برقرار کند، که کنترل می‌کند چه دامنه‌هایی قابل دسترسی هستند. برای جزئیاتِ بیشتر پستِ وبلاگِ سندباکسینگِ Claude Code را ببین.

گزینه‌های سخت‌سازیِ اضافی:

گزینه	هدف
`--userns-remap`	rootِ کانتینر را به کاربرِ بی‌امتیازِ میزبان نگاشت می‌کند؛ به پیکربندیِ daemon نیاز دارد ولی آسیبِ ناشی از فرارِ کانتینر را محدود می‌کند
`--ipc private`	ارتباطِ بین‌فرایندی را ایزوله می‌کند تا از حملاتِ بین‌کانتینری جلوگیری شود

gVisor

کانتینرهای استاندارد کرنلِ میزبان را به اشتراک می‌گذارند: وقتی کدِ درونِ کانتینر یک فراخوانیِ سیستمی می‌کند، مستقیماً به همان کرنلی می‌رود که میزبان را اجرا می‌کند. این یعنی یک آسیب‌پذیریِ کرنل می‌تواند فرارِ کانتینر را ممکن کند. gVisor با رهگیریِ فراخوانی‌های سیستمی در فضای کاربر پیش از رسیدنشان به کرنلِ میزبان، به این می‌پردازد و لایه‌ی سازگاریِ خودش را پیاده‌سازی می‌کند که بیشترِ syscallها را بدونِ درگیر کردنِ کرنلِ واقعی مدیریت می‌کند.

اگر ایجنتی کدِ مخرب اجرا کند (شاید به‌خاطرِ prompt injection)، آن کد در کانتینر اجرا می‌شود و می‌تواند سعی در اکسپلویتِ کرنل کند. با gVisor، سطحِ حمله بسیار کوچک‌تر است: کدِ مخرب باید اول پیاده‌سازیِ فضای کاربرِ gVisor را اکسپلویت کند و دسترسیِ محدودی به کرنلِ واقعی خواهد داشت.

برای استفاده از gVisor با Docker، رانتایمِ runsc را نصب کن و daemon را پیکربندی کن:

{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

سپس کانتینرها را با این اجرا کن:

docker run --runtime=runsc agent-image

ملاحظاتِ کارایی:

بار کاری	سربار
محاسباتِ CPU-bound	حدودِ ۰٪ (بدونِ رهگیریِ syscall)
syscallهای ساده	حدودِ ۲ برابر کندتر
فشردگیِ I/O روی فایل	تا ۱۰ تا ۲۰۰ برابر کندتر برای الگوهای سنگینِ open/close

برای محیط‌های چنداجاره‌ای یا هنگامِ پردازشِ محتوای نامورد‌اعتماد، ایزولاسیونِ اضافی اغلب ارزشِ سربار را دارد.

ماشین‌های مجازی

VMها ایزولاسیونِ سطحِ سخت‌افزار را از طریقِ افزونه‌های مجازی‌سازیِ CPU فراهم می‌کنند. هر VM کرنلِ خودش را اجرا می‌کند و مرزی قوی می‌سازد. یک آسیب‌پذیری در کرنلِ مهمان مستقیماً میزبان را به خطر نمی‌اندازد. با این حال، VMها لزوماً «امن‌تر» از جایگزین‌هایی مثلِ gVisor نیستند. امنیتِ VM به‌شدت به hypervisor و کدِ شبیه‌سازیِ دستگاه بستگی دارد.

Firecracker برای ایزولاسیونِ سبکِ microVM طراحی شده است. می‌تواند VMها را در کمتر از ۱۲۵ میلی‌ثانیه با کمتر از ۵ MiB سربارِ حافظه بوت کند و شبیه‌سازیِ دستگاهِ غیرضروری را حذف می‌کند تا سطحِ حمله را کاهش دهد.

با این رویکرد، VMِ ایجنت هیچ واسطِ شبکه‌ی بیرونی ندارد. در عوض، از طریقِ vsock (سوکت‌های مجازی) ارتباط برقرار می‌کند. همه‌ی ترافیک از طریقِ vsock به یک proxy روی میزبان مسیریابی می‌شود، که allowlistها را اعمال و اعتبارنامه‌ها را پیش از فوروارد کردنِ درخواست‌ها تزریق می‌کند.

استقرارهای ابری

برای استقرارهای ابری، می‌توانی هر یک از فناوری‌های ایزولاسیونِ بالا را با کنترل‌های شبکه‌ی ابری‌-بومی ترکیب کنی:

کانتینرهای ایجنت را در یک subnetِ خصوصی بدونِ internet gateway اجرا کن
قواعدِ فایروالِ ابری (AWS Security Groups، GCP VPC firewall) را طوری پیکربندی کن که همه‌ی egress را جز به سمتِ proxyت مسدود کنند
یک proxy (مثلِ Envoy با فیلترِ credential_injector آن) اجرا کن که درخواست‌ها را اعتبارسنجی، allowlistهای دامنه را اعمال، اعتبارنامه‌ها را تزریق و به APIهای بیرونی فوروارد می‌کند
حداقلِ مجوزهای IAM را به حسابِ سرویسِ ایجنت بده، و دسترسیِ حساس را تا حدِ ممکن از طریقِ proxy مسیریابی کن
همه‌ی ترافیک را در proxy برای مقاصدِ ممیزی لاگ کن

مدیریتِ اعتبارنامه‌ها

ایجنت‌ها اغلب برای فراخوانیِ APIها، دسترسی به مخازن یا تعامل با سرویس‌های ابری به اعتبارنامه نیاز دارند. چالش این است که این دسترسی را بدونِ افشای خودِ اعتبارنامه‌ها فراهم کنی.

الگوی proxy

رویکردِ توصیه‌شده این است که یک proxy را بیرونِ مرزِ امنیتیِ ایجنت اجرا کنی که اعتبارنامه‌ها را به درخواست‌های خروجی تزریق می‌کند. ایجنت درخواست‌ها را بدونِ اعتبارنامه می‌فرستد، proxy آن‌ها را اضافه می‌کند و درخواست را به مقصدش فوروارد می‌کند.

این الگو چند مزیت دارد:

ایجنت هرگز اعتبارنامه‌های واقعی را نمی‌بیند
proxy می‌تواند یک allowlist از نقاطِ‌پایانیِ مجاز را اعمال کند
proxy می‌تواند همه‌ی درخواست‌ها را برای ممیزی لاگ کند
اعتبارنامه‌ها در یک مکانِ امنِ واحد ذخیره می‌شوند، نه اینکه میانِ هر ایجنت توزیع شوند

پیکربندیِ Claude Code برای استفاده از proxy

Claude Code از دو روش برای مسیریابیِ درخواست‌های sampling از طریقِ proxy پشتیبانی می‌کند:

گزینه‌ی ۱: ANTHROPIC_BASE_URL (ساده ولی فقط برای درخواست‌های sampling API)

export ANTHROPIC_BASE_URL="http://localhost:8080"

این به Claude Code و Agent SDK می‌گوید که درخواست‌های sampling را به‌جای مستقیماً به Claude API، به proxyت بفرستند. proxyت درخواست‌های HTTP متن‌ساده را دریافت می‌کند، می‌تواند بازرسی و اصلاحشان کند (از جمله تزریقِ اعتبارنامه‌ها)، سپس به API واقعی فوروارد کند.

گزینه‌ی ۲: HTTP_PROXY / HTTPS_PROXY (سراسری)

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code و Agent SDK این متغیرهای محیطیِ استاندارد را رعایت می‌کنند و همه‌ی ترافیکِ HTTP را از طریقِ proxy مسیریابی می‌کنند. برای HTTPS، proxy یک تونلِ رمزشده‌ی CONNECT می‌سازد: بدونِ بازرسیِ TLS نمی‌تواند محتوای درخواست را ببیند یا اصلاح کند.

پیاده‌سازیِ یک proxy

می‌توانی proxy خودت را بسازی یا از یکی از موجود استفاده کنی:

Envoy Proxy: proxyِ سطحِ‌تولید با فیلترِ credential_injector برای افزودنِ هدرهای احرازِ هویت
mitmproxy: proxyِ پایان‌دهنده‌ی TLS برای بازرسی و اصلاحِ ترافیکِ HTTPS
Squid: proxyِ کش‌کننده با لیست‌های کنترلِ دسترسی
LiteLLM: دروازه‌ی LLM با تزریقِ اعتبارنامه و محدودسازیِ نرخ

اعتبارنامه‌ها برای سرویس‌های دیگر

فراتر از sampling از Claude API، ایجنت‌ها اغلب به دسترسیِ احرازِ هویت‌شده به سرویس‌های دیگر — مثلِ مخازنِ git، دیتابیس‌ها و APIهای داخلی — نیاز دارند. دو رویکردِ اصلی وجود دارد:

ابزارهای سفارشی

دسترسی را از طریقِ یک سرورِ MCP یا ابزارِ سفارشی فراهم کن که درخواست‌ها را به سرویسی در حالِ اجرا بیرونِ مرزِ امنیتیِ ایجنت مسیریابی می‌کند. ایجنت ابزار را فرا می‌خواند، اما درخواستِ احرازِ هویت‌شده‌ی واقعی بیرون اتفاق می‌افتد. ابزار به یک proxy فراخوانی می‌کند که اعتبارنامه‌ها را تزریق می‌کند.

مثلاً یک سرورِ MCP برای git می‌تواند دستورها را از ایجنت بپذیرد ولی آن‌ها را به یک proxyِ git در حالِ اجرا روی میزبان فوروارد کند، که پیش از تماس با مخزنِ راه‌دور احرازِ هویت را اضافه می‌کند. ایجنت هرگز اعتبارنامه‌ها را نمی‌بیند.

مزایا:

بدونِ بازرسیِ TLS: سرویسِ بیرونی درخواست‌های احرازِ هویت‌شده را مستقیماً انجام می‌دهد
اعتبارنامه‌ها بیرون می‌مانند: ایجنت فقط واسطِ ابزار را می‌بیند، نه اعتبارنامه‌های زیرین را

فورواردِ ترافیک

برای فراخوانی‌های Claude API، ANTHROPIC_BASE_URL به تو اجازه می‌دهد درخواست‌ها را به proxyای مسیریابی کنی که می‌تواند آن‌ها را به‌صورتِ متن‌ساده بازرسی و اصلاح کند. اما برای دیگر سرویس‌های HTTPS (GitHub، رجیستری‌های npm، APIهای داخلی)، ترافیک اغلب سرتاسر رمزشده است. حتی اگر آن را از طریقِ proxy با HTTP_PROXY مسیریابی کنی، proxy فقط یک تونلِ TLS مبهم را می‌بیند و نمی‌تواند اعتبارنامه تزریق کند.

برای اصلاحِ ترافیکِ HTTPS به سرویس‌های دلخواه، بدونِ استفاده از ابزارِ سفارشی، به یک proxyِ پایان‌دهنده‌ی TLS نیاز داری که ترافیک را رمزگشایی، بازرسی یا اصلاح، سپس پیش از فوروارد دوباره رمز می‌کند. این موارد را لازم دارد:

اجرای proxy بیرونِ کانتینرِ ایجنت
نصبِ گواهیِ CA متعلق به proxy در trust store ایجنت (تا ایجنت به گواهی‌های proxy اعتماد کند)
پیکربندیِ HTTP_PROXY/HTTPS_PROXY برای مسیریابیِ ترافیک از طریقِ proxy

این رویکرد هر سرویسِ مبتنی بر HTTP را بدونِ نوشتنِ ابزارِ سفارشی مدیریت می‌کند، اما پیچیدگیِ مدیریتِ گواهی را اضافه می‌کند.

توجه کن که همه‌ی برنامه‌ها HTTP_PROXY/HTTPS_PROXY را رعایت نمی‌کنند. بیشترِ ابزارها (curl، pip، npm، git) رعایت می‌کنند، اما برخی ممکن است این متغیرها را دور بزنند و مستقیماً متصل شوند. مثلاً fetch() در Node.js به‌صورت پیش‌فرض این متغیرها را نادیده می‌گیرد؛ در Node 24+ می‌توانی NODE_USE_ENV_PROXY=1 را تنظیم کنی تا پشتیبانی فعال شود. برای پوششِ جامع، می‌توانی از proxychains برای رهگیریِ فراخوانی‌های شبکه استفاده کنی، یا iptables را طوری پیکربندی کنی که ترافیکِ خروجی را به یک proxyِ شفاف هدایت کند.

هر دو رویکرد همچنان به proxyِ پایان‌دهنده‌ی TLS و گواهیِ CA مورد اعتماد نیاز دارند. آن‌ها فقط تضمین می‌کنند که ترافیک واقعاً به proxy می‌رسد.

پیکربندیِ فایل‌سیستم

کنترل‌های فایل‌سیستم تعیین می‌کنند ایجنت چه فایل‌هایی را می‌تواند بخواند و بنویسد.

mount کردنِ فقط‌خواندنیِ کد

وقتی ایجنت نیاز دارد کد را تحلیل کند ولی تغییرش ندهد، دایرکتوری را فقط‌خواندنی mount کن:

docker run -v /path/to/code:/workspace:ro agent-image

حتی دسترسیِ فقط‌خواندنی به یک دایرکتوریِ کد می‌تواند اعتبارنامه‌ها را افشا کند. فایل‌های رایجی که باید پیش از mount حذف یا پاک‌سازی شوند:

فایل	خطر
`.env`، `.env.local`	کلیدهای API، رمزهای دیتابیس، اسرار
`~/.git-credentials`	رمزها/توکن‌های git به‌صورت متن‌ساده
`~/.aws/credentials`	کلیدهای دسترسیِ AWS
`~/.config/gcloud/application_default_credentials.json`	توکن‌های ADC گوگل کلاد
`~/.azure/`	اعتبارنامه‌های Azure CLI
`~/.docker/config.json`	توکن‌های احرازِ هویتِ رجیستریِ Docker
`~/.kube/config`	اعتبارنامه‌های خوشه‌ی Kubernetes
`.npmrc`، `.pypirc`	توکن‌های رجیستریِ بسته
`*-service-account.json`	کلیدهای حسابِ سرویسِ GCP
`.pem`، `.key`	کلیدهای خصوصی

به کپی کردنِ فقط فایل‌های منبعِ موردِ نیاز فکر کن، یا از فیلترسازیِ سبکِ .dockerignore استفاده کن.

مکان‌های قابل‌نوشتن

اگر ایجنت نیاز به نوشتنِ فایل دارد، بسته به اینکه می‌خواهی تغییرات پایدار بمانند یا نه، چند گزینه داری:

برای فضاهای کاریِ زودگذر در کانتینرها، از mountهای tmpfs استفاده کن که فقط در حافظه وجود دارند و با توقفِ کانتینر پاک می‌شوند:

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

اگر می‌خواهی پیش از پایدارسازیِ تغییرات آن‌ها را بازبینی کنی، یک فایل‌سیستمِ overlay به ایجنت اجازه می‌دهد بدونِ تغییرِ فایل‌های زیرین بنویسد. تغییرات در لایه‌ای جداگانه ذخیره می‌شوند که می‌توانی بازرسی، اعمال یا دور بریزی. برای خروجیِ کاملاً پایدار، یک volumeِ اختصاصی mount کن ولی آن را از دایرکتوری‌های حساس جدا نگه دار.