به گزارش از وبسایت cncf
ارسال شده در 8 ژوئیه 2026 توسط مارکو اسلوگا، پروژههای F5 — در یک KCD دربارهٔ OpenClaw گفتگوی جالبی با یکی از شرکتکنندگان داشتم که اشاره کرد در شبکهٔ خود نمایندهای (agent) قرار نمیدهند چون «ما واقعاً نمیدانیم آن چیز چه کاری انجام میدهد». این نکته مرا به فکر فرو برد؛ استقلال عاملها (agents) ظرفیت عظیمی برای خودکارسازی وظایف داشت که پیشتر به انسان نیاز داشتند، اما همزمان چالشهای عملیاتی و امنیتی جدیدی پدید میآورد. این صحبت الهامبخش من شد تا پروژهای را برای ساختن یک مرز شبکهای مخصوص عوامل هوش مصنوعی آغاز کنم. 🚀
شاید بگویید به همین دلیل است که نردهها و محافظها را داریم! در حالی که درک نیت (intent) عامل برای ممانعت از تأثیرات نامطلوب مهم است، کنترل دسترسی شبکه برای ابزارهای عامل نیز ضروری است. اجرای امنیت ترافیک شبکه یک نیاز پایهای است و راهحلهای متعددی برای آن وجود دارد؛ اما اگر بتوانیم مرزی بسازیم که هم زمان اجرا شود و هم قابلمشاهده باشد، و در عین حال نیازی به معرفی زیرساختهای کاملاً جدید نداشته باشیم، چه؟ 😊
پاسخ ساده و مؤثر بود: از دو جزء منبعباز و بالغ که در محیطهای بومی ابر مرسوم هستند استفاده کنیم — NGINX بهعنوان صفحهٔ کنترل ترافیک و OpenTelemetry بهعنوان صفحهٔ ممیزی. این دو به ما امکان مشاهدهپذیری میدهند و مرزی کارآمد فراهم میآورند که در آن میتوانیم قواعد دقیق و کاربردیِ شکلدهی ترافیک را اعمال کنیم.
تصویر: نمودار جریان درخواست
چون NGINX در هر دو سوی جریان قرار میگیرد، بهعنوان یک reverse proxy برای ترافیک ورودی عمل میکند، TLS را خاتمه میدهد و درخواستها را به عامل ارسال میکند. برای ترافیک خروجی، همان نمونه نقشِ forward proxy را ایفا میکند و هر درخواست نماینده باید از آن عبور کند. با استفاده از قوانین iptables میتوانیم جریان را کنترل کنیم و بقیهٔ ترافیک خروجی را حذف کنیم، بنابراین راه فرعی دیگری باقی نمیماند. این رویکرد، مرز را به یک ویژگی معماری تبدیل میکند، نه یک سیاستی که صرفاً امیدواریم برنامهها از آن پیروی کنند. 🔒
ماژول OpenTelemetry بومی NGINX این امکان را میدهد که برای هر درخواست یک span از نوع OTEL منتشر کنیم. اینگونه قابلیت مشاهدهٔ جریان ترافیک را در قالبی بهدست میآوریم که ابزارهای ما پیشتر آن را میشناسند و میتوانیم تعاملات کاربر را با تماسهای خارجی که عامل به نمایندگی از او انجام میدهد، مرتبط کنیم.
یک OpenTelemetry Collector میتواند این spans را در یک گزارش ممیزی نگهداری کند، یا آنها را به ابزارهای مشاهدهپذیری و امنیتی مانند Jaeger، Grafana یا پلتفرمهای SIEM ارسال کند تا تحلیل و نگهداری رخدادها بهسادگی انجام شود. 📊
برای اعتبارسنجی ایده، خوشهای تکنود Kubernetes راهاندازی کردم که چهار بارکاری در یک namespace داشت: NGINX، Ollama، OpenClaw و یک OpenTelemetry Collector. نمونهٔ آزمایشی به یک GPU مصرفکنندهٔ NVIDIA دسترسی داشت، اما این الگو را میتوان روی طیف وسیعی از پلتفرمها — از دستگاههای لبه تا زیرساختهای سازمانی AI — اجرا کرد؛ هر جایی که بتوان بارهای کاری Kubernetes را راهاندازی کرد، این طرح کاربردی است.
تصویر: کانتینرها در فضای نام openclaw
تصویر: استفاده از GPU در طول استنتاج
گسترههای OTEL که جمعآوری شدند، اطلاعات کافی در اختیار ما گذاشتند تا شروع به تعریف قواعد کنترل کنیم و بهتدریج محدودیتهای دقیقی بر محتوایی که نمونهٔ OpenClaw میتواند به آن دسترسی داشته باشد اعمال نماییم. این دادهها مبنایی برای اعمال سیاستهای دقیق شبکه و ممیزی درخواستها فراهم میآورند. 🔍
تصویر: گسترههای OTEL جمعآوری شده و وضعیتهای آن
چرا حالا این موضوع مهم است؟ اکوسیستم بومی ابر دارای ابزارهای بالغی برای احراز هویت، کنترل پذیرش، تشخیص تهدید در زمان اجرا و قابلیت مشاهده است. اما الگوهای قابلاستفادهٔ عملی برای محدود کردن و ممیزی رفتار شبکهٔ خروجیِ بارهای کاری هوش مصنوعی مستقل هنوز در حال شکلگیریاند. با پیکربندیای که همهچیز را جز nginx.org و duckduckgo.com مسدود میکند، نمونهای واضح از نحوهٔ اعمال مرز را میبینیم.
با ترکیب NGINX و OpenTelemetry، مرزِ عاملهای هوش مصنوعی را بر مبنای استانداردهای باز ایجاد کردیم و آن را با ابزارهای عملیاتی مرسوم در Kubernetes قابل استقرار نمودیم. اگرچه این پیادهسازی از NGINX بهعنوان نقطهٔ اجرا استفاده میکند، الگوهای مشابه را میتوان با سایر پروکسیها، خروجیهای mesh یا راهحلهای سیاستگذاری شبکه نیز بهکار برد.
محدودیتها و کار آینده: این رویکرد بر کنترل و مشاهدهٔ رفتار شبکه تمرکز دارد و هدفش درک نیت عامل نیست. محدود کردن محل برقراری ارتباط نماینده تضمینی برای درست یا ایمن بودن تصمیمات او نیست. افزون بر این، افزودن یک اجرای مبتنی بر پروکسی یک مؤلفهٔ عملیاتی اضافی ایجاد میکند که خود باید ایمن و پایش شود. مانند هر کنترل شبکه، این روش باید بهعنوان یک لایه در یک استراتژی دفاع عمیقتر کنار هویت، سیاستها، امنیت زمان اجرا و محافظت سطح برنامه دیده شود. کار آینده بر یافتن راههایی متمرکز خواهد بود که کنترلهای شبکه چگونه میتوانند مکانیسمهای حاکمیت سطح بالاتر را برای سیستمهای مستقل تکمیل کنند. ⚖️
اگر مایلید این استقرار را خودتان امتحان کنید، به مخزن OpenClaw Network Boundary نگاه بیندازید تا کدهای لازم برای استقرار در Kubernetes را ببینید. همچنین ممکن است از خود بپرسید چگونه قابلیتهای NGINX که در این مطلب مطرح شد با استقرار فعلی شما مرتبط است: شاید NGINX Ingress Controller (NIC) را اجرا میکنید یا از API بزرگ Kubernetes Gateway و NGINX Gateway Fabric (NGF) بهره میبرید. NIC و NGF ویژگیهایی را که در پروکسی اصلی NGINX عرضه میشوند به ارث میبرند و forward proxy یکی از این ویژگیهاست. تیمهای توسعهٔ NIC و NGF این بهروزرسانیها را دنبال میکنند و روزبهروز شکافها را برطرف میکنند.
چشمانداز هوش مصنوعی پر از فرصتهاست؛ اگر علاقهمندید در این مسیر همراه ما باشید، خوشحال میشویم به انجمن NGINX بپیوندید. NIC و NGF جلسات منظم جامعه دارند که میتوانید با نگهبانان آنها در ارتباط باشید، سؤال بپرسید و ایدههایتان را مطرح کنید. 🤝
