درون سیستم حفاظتی airCloset برای دسترسی امن عامل‌های هوش مصنوعی به لاگ‌ها

اگر امروز از عامل‌های هوش مصنوعی برای تحلیل لاگ‌های محیط عملیاتی استفاده می‌کنید، احتمالاً با این ترس روبرو هستید که داده‌های حساس کاربران مستقیماً به سرورهای OpenAI یا Anthropic ارسال شود. این بن‌بست امنیتی باعث می‌شود رویای سامانه‌های خود-ترمیم‌شونده در حد یک فرآیند دستی باقی بماند. کیفیت یک استک نظارت‌پذیری (Observability Stack)، در واقع سقف مطلق برای عملیات خودمختار هوش مصنوعی است. اگر یک عامل AI نتواند با امنیت کامل به یک استک-تریس (stacktrace) دسترسی پیدا کند یا لاگ‌ها را بدون نشت داده‌های شخصی متناظر سازد، سیستم‌های خود-ترمیم‌شونده هرگز از حالت دستی خارج نخواهند شد.

طبق اعلام رایان (Ryan)، مدیر فنی شرکت airCloset، حفاظت از داده‌های شناسایی شخصی (PII) دیگر صرفاً یک مسئلهٔ بهداشتی در کدنویسی یا رعایت استانداردهای اداری نیست، بلکه بازطراحی بنیادین مرزهای اعتماد در عصر هوش مصنوعی است. در گذشته، مجموعه‌ی افرادی که اجازه داشتند لاگ‌ها را بخوانند، تقریباً با مجموعه‌ی افرادی که دسترسی به پایگاه‌داده داشتند یکسان بود. برای این مهندسان، لاگ‌ها مسیر اضافی برای رسیدن به داده‌های شخصی نبودند؛ بنابراین سخت کردن دفاع در لایهٔ لاگ، تأثیر چندانی بر خط دفاع کلی سازمان‌ها نداشت.

اما هوش مصنوعی این فرض را می‌شکند. اکنون افراد غیرمهندس می‌توانند از طریق پروتکل زمینهٔ مدل (MCP) لاگ‌ها را استخراج کنند، در حالی که هیچ دسترسی مستقیمی به پایگاه‌داده ندارند. برای اولین بار در تاریخ عملیات نرم‌افزاری، لاگ‌ها به مسیری تبدیل شده‌اند که شخصی بدون دسترسی به DB می‌تواند به داده‌های شخصی دسترسی یابد. علاوه‌بر این، محتوای لاگ‌ها اکنون به ورودی‌های مدل AI تبدیل می‌شود که سطوح جدیدی از مواجهه را ایجاد می‌کند: ابتدا انتقال داده به مدل و سپس بازگشت آن در خروجی مدل.

در یک جریان ساده و ساده‌لوحانه، اپلیکیشن لاگی می‌فرستد، داده در Loki ذخیره می‌شود و هوش مصنوعی آن را از طریق MCP می‌خواند. این مسیر چندین مجرای نشت PII ایجاد می‌کند: آدرس ایمیل و شماره تلفن مشتریان در لاگ‌های خطا ظاهر می‌شوند، محتویات پاسخ‌های سفارشات در Tracingها قرار می‌گیرند و لاگ‌های کوئری‌های DB ردیف‌های کامل جداول را منتشر می‌کنند. این یعنی تجمعی از PIIهای متن-ساده در استک نظارت‌پذیری وجود دارد که AI می‌تواند مستقیماً آن‌ها را جست‌وجو کند. با این حال، حذف کامل PII هم مشکل‌ساز است، زیرا توانایی اجرای جریان‌های کاری عادی پشتیبانی، مانند بررسی تیکت یک مشتری خاص، از بین می‌رود. به نقل از راهنمای فنی منتشر شده در ۱۳ ژوئیه ۲۰۲۶ در dev.to، شرکت airCloset این تناقض را از طریق پلتفرم داخلی خود به نام cortex حل کرده است تا حفاظت از PII و قابلیت جست‌وجوی AI متضاد نباشند.

دفاع شش‌لایه در برابر نشت PII

برای ایجاد تعادل بین امنیت و کاربرد، airCloset یک رویکرد چندلایه در cortex پیاده کرد که در آن هر لایه هدفی مشخص دارد:

• برچسب‌های سیاست BigQuery (در هنگام نوشتن): پیاده‌سازی کنترل دسترسی در سطح ستون (CLS) با استفاده از یک تاکسونومی سه درجه‌ای: pii_high (بالا)، pii_medium (متوسط) و pii_low (پایین). این یک لایه امنیتی خالص است؛ بدون داشتن مجوز دقیق خواننده روی آن ستون، هر کوئری SELECT به جای ماسکینگ پویا، دقیقاً با خطای "Access Denied" مواجه می‌شود.
• ETL DLP (در هنگام نوشتن): استفاده از Cloud DLP برای حذف (Redact) داده‌های PII متن-ساده در هنگام تبدیل داده‌ها برای جداول مشتق‌شده، مانند داده‌های پشتیبانی مشتری. در اینجا از جای‌گذارهایی مثل [EMAIL_ADDRESS] و [PHONE_NUMBER] استفاده می‌شود تا ساختار داده برای تحلیل‌های آماری حفظ شود.
• هش‌گذاری لاگ (در هنگام نوشتن): متن ساده هرگز به Loki نمی‌رسد. اپلیکیشن قبل از ارسال لاگ، یک هش در سمت کلاینت/اپلیکیشن از طریق تابع hashEmail (که یک HMAC-SHA256 تولید می‌کند و پیشوند ۱۲ کاراکتری دارد) انجام می‌دهد. کلید سری این عملیات کاملاً خارج از استک نظارت‌پذیری قرار دارد.
• جست‌وجوی متقارن (هنگام جست‌وجو): در سمت جست‌وجو، همان تابع hashEmail روی ورودی کاربر اجرا می‌شود و سپس نتیجه به Loki ارسال می‌گردد. این کار اجازه می‌دهد لاگ‌های یک مشتری خاص جست‌وجو شود بدون اینکه هرگز با متن ساده ایمیل او برخورد شود.
• ماسکینگ MCP (در خروجی): وقتی هوش مصنوعی داده را مصرف می‌کند، سیستم شناسایی نام ستون‌ها، بخش محلی ایمیل را ماسک می‌کند (مثلاً r***@air-closet.com). بخش @domain حفظ می‌شود تا تیم تریاژ در پاسخ اول بتواند دامنه حساب کاربری را شناسایی کند.
• تفکیک هویت (در خروجی): ایمیل‌های کارکنان داخلی در مسیری جداگانه از PII مشتریان مدیریت می‌شوند. این ایمیل‌ها توسط Edge Router با HMAC امضا می‌شوند تا انتساب احرازی (auth attribution) مشخص باشد و وارد خط لوله ماسکینگ نمی‌شوند.

کالبدشکافی گمنام‌سازی و همبستگی

داده‌های PII فقط شامل ایمیل نیستند؛ سیستم روی نام‌ها (شامل خوانش‌های فونتیک)، شماره تلفن‌ها، آدرس‌ها، کدهای پستی، تاریخ تولد، جزئیات کارت و بانکی و شناسه‌های سرویس‌های خارجی نظارت دارد. تکنیک گمنام‌سازی بر اساس ماهیت هر میدان انتخاب می‌شود:

• هشینگ با تابع یکسان: برای ایمیل‌ها و شماره تلفن‌ها جهت حفظ قابلیت همبستگی (Correlation).
• ماسکینگ جزئی: برای نام‌ها و آدرس‌ها.
• حذف کامل (Full Redaction): برای شماره کارت‌ها و توکن‌ها.

این قانون ثابت — «گمنام‌سازی PII در هر مسیر داده‌ای که به هوش مصنوعی می‌رسد» — در تمامی منابع داده اعمال می‌شود و فقط محدود به لاگ‌ها نیست. برای مثال، اگر یک ابزار MCP یک پایگاه‌داده سرویس را کوئری کند و نام‌ها و آدرس‌ها را در مجموعه نتایج بیاورد، همان قوانین گمنام‌سازی پیش از بازگرداندن داده‌ها به AI اعمال می‌گردند.

حل مشکل نشت در جست‌وجو

در یک پیاده‌سازی ساده‌لوحانه، اگر کاربر بگوید «لاگ‌های مشتری A را بیاور»، سیستم ایمیل خام را به AI می‌دهد و AI آن را به ابزار MCP می‌سپارد. این یعنی نشت PII متن-ساده به مدل و تامین‌کننده مدل. برای جلوگیری از این اتفاق، cortex به جای تکیه بر قراردادهای حقوقی (Contractual Boundary)، از یک مرز ساختاری (Structural Boundary) استفاده می‌کند. تکیه بر شرایط استفاده تامین‌کننده مدل، وابستگی‌ای است که اغلب در زمان حسابرسی (Audit) ضعیف оказывается. این رویکرد سخت‌گیرانه برای جلوگیری از نفوذ، تفاوت بنیادی با روش‌های سنتی بازبینی امنیتی توسط AI دارد که اغلب به دلیل نبود نظارت انسانی در نقاط بحرانی شکست می‌خورند.

در معماری cortex، ابزار جست‌وجو یک شناسه غیر-PII را می‌گیرد، آن را در داخل سرور MCP به ایمیل تبدیل می‌کند، در همان‌جا با استفاده از همان کلید و تابعِ لایه نوشتن، آن را هش می‌کند و تنها هش را به AI برمی‌گرداند. ایمیل هرگز از سرور MCP خارج نشده و به مدل نمی‌رسد. سپس AI از طریق Grafana MCP با کوئری‌ای شبیه به {service_name="subscription"} |~ "${hash}" در Loki جست‌وجو می‌کند.

برای جلوگیری از حملات شمارش (Enumeration Attacks)، airCloset به جای هش یک‌طرفه ساده مانند SHA-256 از HMAC استفاده می‌کند. از آنجایی که ایمیل‌ها فضای ورودی با آنتروپی پایینی دارند، یک هش ساده به مهاجم اجازه می‌دهد لیستی از ایمیل‌های احتمالی را در دستگاه خود هش کرده و با مقادیر لو رفته تطبیق دهد. اما HMAC یک کلید سری را در محاسبات ترکیب می‌کند؛ بدون این کلید، مهاجم حتی نمی‌تواند تشخیص دهد که آیا یک ایمیل کاندید با هش لو رفته مطابقت دارد یا خیر.

با نگه داشتن کلید فقط در سمت نوشتن و ابزار جست‌وجو (و عدم ذخیره آن در Loki)، نشت لاگ‌ها به تنهایی باعث افشای متن ساده نمی‌شود مگر اینکه کلید نیز لو رود. کوتاه کردن هش به پیشوند ۱۲ کاراکتری (۴۸ بیت) به این معناست که تداخل‌ها (Collisions) از نظر تئوری ممکن هستند، اما در مقیاس پایگاه مشتریان آن‌ها ناچیز است. طبق مسئله روزتولد (Birthday Problem)، نقطه تداخل ۵۰٪ در حدود ۲۰ میلیون رکورد (تقریباً ۲ به توان ۲۴.۵) قرار دارد. در صورت وقوع تداخل، بدترین حالت، کاهش دقت همبستگی است (لاگ‌های یک مشتری دیگر با همان هش می‌آیند)، نه افشای داده‌های متن-ساده.

بک‌اندهای یکپارچه: انسان در برابر هوش مصنوعی

شرکت airCloset برای جلوگیری از تله‌ی ساخت «تجمیع‌کننده‌های داشبورد انسانی» و «فیدهای داده AI» به صورت مجزا — که منجر به اختلاف اعداد، زمان‌بندی‌های ناسازگار و سردرگمی در مورد داده مرجع (Canonical) می‌شود — از یک بک‌اند نظارت‌پذیری مشترک استفاده می‌کند. آن‌ها داشبورد انسانی و MCP هوش مصنوعی را به عنوان دو لایه‌ی نمایش متفاوت برای یک دامنه واحد می‌بینند.

• رابط انسانی (PI Lab): یک پورتال داخلی که داشبوردها را بر اساس هدف نظارت تجمیع می‌کند. این شامل صفحه مصرف Claude Code (cc-usage)، مصرف ابزارهای MCP (به تفکیک سرور، ابزار، کاربر و تیم) و هزینه‌های یکپارچه زیرساختی (Gemini, GCP, AWS و GitHub در یک صفحه) است.

به عنوان مثال، داشبورد مصرف MCP نشان می‌دهد که طی ۳۰ روز، ابزار service-product-graph دارای ۳۷,۹۴۶ فراخوانی (با ۷,۱۰۶ خطا)، gws دارای ۱۹,۳۵۰ و db-graph دارای ۱۷,۲۹۷ فراخوانی بوده است. نکته این است که نرخ خطای بالا در برخی سرورها شامل خطاهای مورد انتظار تایپی مانند رد درخواست به دلیل «عدم دسترسی» (permission denied) است. این نما اجازه می‌دهد روزانه بررسی شود کدام MCPها استفاده می‌شوند و شکست‌ها کجا رخ می‌دهند. عدد «۵۰,۰۰۰ فراخوانی / ۷۳ کاربر» برای annotation graph MCP در گزارش‌های قبلی نیز از همین نما استخراج شده است.

• رابط هوش مصنوعی (MCP): عامل‌ها از MCPهای تخصصی استفاده می‌کنند. Grafana MCP کوئری‌های LogQL و PromQL را مدیریت می‌کند (مثلاً تبدیل پرسش «کدام بازه زمانی هفته گذشته بیشترین خطا در سرویس X داشت؟» به یک کوئری فنی). BQ MCP (از طریق cortex-product-graph) کوئری‌های SQL را روی جداول claude_usage.claude_usage و cortex.mcp_tool_calls اجرا می‌کند.

موتور محرک چرخه خود-ترمیم

این معماری، هسته اصلی قابلیت‌های «خود-ترمیم» (Self-Healing) در airCloset است. استک نظارت‌پذیری صرفاً برای مانیتورینگ نیست، بلکه ورودی است که اقدامات AI را هدایت می‌کند. زنجیره عملیاتی به این ترتیب پیش می‌رود:

۱. تشخیص (Detect): یک هشدار تولید (production) یا شکست در CI یک هشدار LogQL در Loki را فعال می‌کند.
۲. ارسال (Deliver): هشدار به event-relay (یک مرکز وب‌هوک داخلی) ارسال می‌شود.
۳. راه‌اندازی (Launch): یک بات بازبینی خودکار (عاملی تحت پشتیبانی Claude Code) فعال می‌شود.
۴. گردآوری زمینه (Gather Context): بات لاگ‌های کامل را از طریق Grafana MCP می‌کشد و PRها، کامیت‌ها و کدهای مرتبط را از طریق Product Graph MCP ردیابی می‌کند.
۵. پیشنهاد (Propose): بات یک PR برای اصلاح خطا ارسال می‌کند.
۶. تأیید (Verify): اگر CI پاس شود، بات به طور خودکار کد را ادغام (merge) می‌کند؛ در غیر این صورت، بات دیگری نتیجه را بازبینی می‌کند. این چرخه بازخورد دقیقاً همان مکانیزمی است که می‌تواند نرخ خطای اصلاحات AI را به طور چشمگیر کاهش دهد، مشروط بر اینکه داده‌های ورودی دقیق باشند.

اگر خطاها شناسایی نشوند، استک-تریس‌ها رها شوند یا کدهای مرتبط (PR/Commit) در دسترس نباشند، این زنجیره کاملاً متوقف می‌شود. کیفیت داده‌های نظارتی، سقف خودمختاری AI است.

شکاف باقی‌مانده: طراحی خطاها

با وجود این استک صیقل‌خورده، سیستم همچنان به کیفیت «شیر خروجی» (faucet) وابسته است؛ یعنی نحوه ثبت خطاها در کد اصلی. رایان چندین حالت شکست حیاتی را شناسایی کرده که در آن نقطه ورود خراب است:

• بلوک‌های try-catch که خطاها را بدون ثبت در لاگ می‌بلعند (swallow).
• خطاهایی که در سطح info به جای error ثبت می‌شوند و باعث می‌شود سیستم آن‌ها را به عنوان شکست شناسایی نکند.
• ثبت تنها error.message در حالی که استک-تریس رها می‌شود و AI را ناتوان می‌کند تا منشأ خطا را در کد منبع ردیابی کند.
• خطاهای async مدیریت‌نشده که باعث کرش کردن کل پروسه می‌شوند.

در حال حاضر، airCloset از سه لایه ناقص برای مقابله با این مشکل استفاده می‌کند:

• لینتینگ استاتیک (Static linting): قانون no-silent-catch جلوی کچ‌های خالی و حذف‌های .catch(() => null) را می‌گیرد. اما اگر هر تابع فراخوانی شده‌ای داخل کچ باشد، لینتر راضی می‌شود و الگوهایی مثل «تغییر سطح به logger.info(err.message)» از سد آن می‌گذرند.
• مستندات راهنما: قوانینی که استفاده از serializeError(error) برای ذخیره استک-تریس‌ها به صورت فیلدهای ساختاریافته را الزامی می‌کند. حذف استک از طریق logger.error(err.message) به عنوان «تخطی شدید» (Major violation) لیست شده، اما این مورد به بازبینی انسانی یا AI وابسته است.
• بازبینی خودکار AI: باتِ PR بررسی می‌کند که آیا موارد خطا تست شده‌اند یا خیر، اما فاقد یک چک‌لیست تخصصی برای نظارت‌پذیری است تا کیفیت استک-تریس‌ها را به طور سیستماتیک بررسی کند. این چالش یادآور پروژه Loupe است که نشان داد چگونه کدهای تولید شده با AI حتی با پاس کردن تست‌ها، می‌توانند باگ‌های خاموشی داشته باشند که تنها با نظارت‌پذیری دقیق قابل کشف هستند.

رایان اشاره می‌کند که وقتی در فاز طراحی از یک AI کمک خواست، مدل پیشنهاد داد یک صفحه ادمین انسانی ساخته شود تا ایمیل‌ها را به هش تبدیل کند. این پیشنهاد رد شد زیرا هر راهکاری که نیاز به دخالت انسان داشته باشد، مانع از رسیدن به هدف خودمختاری «اصلاح پیش از آنکه کسی متوجه شود» می‌شود. شکاف باقی‌مانده، فقدان یک ابزار پیش‌کنشی (proactive harness) است که در لحظه نوشتن کد، الگوهای صحیح نظارت‌پذیری را پیشنهاد دهد. تا آن زمان، طراحی هدف (Target Design) بر عهده انسان باقی است.

جمع‌بندی: ادغام داده‌های ایستا و پویا

این مجموعه، «نسخه پویا» (Dynamic Edition) استراتژی AI شرکت airCloset را به پایان می‌رساند — نسخه‌ای که حقایق مربوط به رفتار محیط عملیاتی و هزینه‌ها را از طریق Prometheus، BQ و Loki فراهم می‌کند. این بخش مکمل «نسخه ایستا» (Static Edition) است (شامل کد-گراف، دی‌بی-گراف و انوتیشن-گراف) که حقایق مربوط به ساختار و معنای کد را ارائه می‌دهد.

در حال حاضر، این دو نسخه در کنار هم قرار دارند. برای اینکه اصل «اجازه نده AI حدس بزند — به او حقایق را بده» به کمال برسد، گام بعدی ریختن داده‌های پویا در گراف ایستا است. به طور خاص، این یعنی اضافه کردن اطلاعاتی مانند «این یال در گراف کد، در محیط عملیاتی هر چند وقت یک‌بار استفاده می‌شود؟» به گره‌های گراف ایستا. با ادغام این دو فرم از حقیقت، سیستم می‌تواند از وضعیت «استفاده از AI برای عملیات» به وضعیت «عملیات کاملاً خودمختار و یکپارچه» منتقل شود.

گام بعدی شما

• بررسی پیاده‌سازی HMAC برای ماسکینگ داده‌های حساس در لایه‌های دسترسی مدل.
• بازنگری در استانداردهای ثبت خطا (Error Logging) برای اطمینان از ارسال استک-تریس‌های کامل به عامل‌های AI.
• مطالعه پروتکل MCP برای جداسازی لایه دسترسی به داده از لایه استنتاج مدل.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.