استقرار سیاست‌های امنیتی عامل‌های هوش مصنوعی در سخت‌افزار TEE

تصور کنید یک مدیر سیستم بدخواه، دسترسی‌های یک عامل هوش مصنوعی را در حافظه تغییر دهد یا یک تصمیم «اجازه» (Allow) را در سطح رم عوض کند؛ در این حالت، تمام لایه‌های نرم‌افزاری نظارت عملاً بی‌فایده می‌شوند. ابزار cMCP (Confidential MCP Runtime) که در ۲۳ ژوئن ۲۰۲۶ در پیش‌نمایش توسعه‌دهندگان عرضه شد، با انتقال موتور سیاست‌گذاری به یک محیط اجرای قابل‌اعتماد (TEE) — چیزی شبیه به یک گاوصندوق دیجیتالی در قلب پردازنده که حتی سیستم‌عامل هم نمی‌تواند محتویاتش را ببیند — این مشکل را حل می‌کند. cMCP در واقع نسخه Runtime مربوط به AgenTrust برای یک نسخه امن از پروتکل MCP است.

در حال حاضر، اکثر عامل‌های هوش مصنوعی برای مدیریت فراخوانی ابزارها به APIهایی مثل Salesforce یا Snowflake، به یک لایه نرم‌افزاری اعتماد می‌کنند. طبق گزارش‌های فنی، اگر سیستم‌عامل میزبان از طریق یک حفره امنیتی (CVE) compromised شود، کل حاکمیت داده‌ها از بین می‌رود. این وضعیت یک مشکل بحرانی ایجاد می‌کند: وقتی عاملی ابزاری را فراخوانی می‌کند، موتور سیاست‌گذاری می‌گوید «اجازه داده شد» و فراخوانی انجام می‌شود، اما هیچ سندی وجود ندارد که ثابت کند خودِ موتور سیاست‌گذاری دست‌کاری نشده است. این آسیب‌پذیری‌ها در مقیاس گسترده‌تر نیز مشاهده شده و برخی گزارش‌ها حاکی از آن است که حدود ۲۵٪ از استقرارهای فعلی پروتکل MCP دارای حفره‌های امنیتی شدید هستند که ریسک دسترسی‌های غیرمجاز را افزایش می‌دهد. حاکمیت نرم‌افزاری در پروتکل زمینه مدل (MCP) نمی‌تواند تضمین کند که سیاست‌های Cedar روی دیسک همان سیاست‌هایی است که اجرا شده‌اند، یا اینکه یک مدیر بدخواه پس از تأیید، بسته سیاست‌ها را تعویض نکرده است (چرا که بررسی هش‌ها در همان سیستم‌عاملی رخ می‌دهد که مدیر بر آن تسلط دارد). همچنین نمی‌توان تضمین کرد که لاگ‌های بازرسی (Audit Log) دقیقاً بازتاب‌دهنده اتفاقات واقعی باشند؛ زیرا هر کسی که کلید امضای نرم‌افزاری را در اختیار داشته باشد، می‌تواند پس از وقوع حادثه، یک زنجیره بازرسی معتبر را بازسازی کند.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های عامل‌محور اشاره کردیم، حذف اعتماد به لایه نرم‌افزاری تنها راه مقابله با حملات سطح پایین است. cMCP با استفاده از TEE، صفحه کنترل (Control Plane) را از دسترس فرآیندی که بر آن نظارت می‌کند، خارج می‌کند و یک مرز سخت‌افزاری میان عامل و مجوزهایش می‌سازد. این معماری مانع از آن می‌شود که یک حمله زنجیره تأمین در ارزیاب (Evaluator)، در همان فضای آدرس مهاجم اجرا شود. این رویکرد سخت‌افزاری در واقع مکمل تلاش‌های صنعتی برای استانداردسازی است؛ مشابه آنچه مایکروسافت با ارائه ۱۲۷ آزمون استاندارد برای تعریف مرزهای امنیتی MCP انجام داد تا یک چارچوب پیش‌بینی‌پذیر برای امنیت عامل‌ها ایجاد کند.

سازوکار گواهی سخت‌افزاری

طبق مستندات github.com، ابزار cMCP به عنوان یک درگاه (Gateway) متن‌باز عمل می‌کند که هر فراخوانی ابزار را پیش از رسیدن به سرور MCP رهگیری می‌کند. این سامانه پیش از اجرای هر کدی، هشِ بسته‌ی سیاست‌های Cedar را در یک گزارش گواهی سخت‌افزاری (Hardware Attestation Report) ثبت می‌کند. این سازوکار دقیقاً جلوی حملات «تعویض» (Swap Attack) را می‌گیرد؛ جایی که یک مدیر سیاست‌های سخت‌گیرانه را با سیاست‌های سهل‌گیرانه جایگزین می‌کند، زیرا بررسی هش خارج از کنترل سیستم‌عامل انجام می‌شود.

تمام پردازش‌ها درون این محیط امن (Enclave) رخ می‌دهد: محتوای فراخوانی ابزار به‌صورت متن ساده (Plaintext) در فضای داخلی پردازش می‌شود، در حالی که تامین‌کننده اتصال (Connectivity Provider) فقط داده‌های رمزگذاری‌شده (Ciphertext) را می‌بیند. این رویکرد با راهکارهای مبتنی بر تونلی (Tunnel-based) متفاوت است. پس از اتخاذ تصمیم (اجازه، رد یا سانسور)، درگاه یک ادعای TRACE امضا‌شده تولید می‌کند. تأکید می‌شود که هیچ کدی پیش از ثبت و اندازه‌گیری هش بسته‌ی سیاست‌های Cedar اجرا نمی‌شود.

مشخصات فنی و پشتیبانی از سخت‌افزار

این محیط اجرا برای تضمین سطح بالای امنیت، از چندین تامین‌کننده سخت‌افزاری پشتیبانی می‌کند. درگاه برای شناسایی خودکار از یک ترتیب جست‌وجوی خاص استفاده می‌کند: azure-cvm ← tpm ← sev-snp ← tdx. اولین تامین‌کننده‌ای که متد detect() آن با موفقیت اجرا شود، انتخاب می‌گردد.

• AMD SEV-SNP (در Azure DCasv5 و AWS C6a Nitro): سطح تضمین بالا از طریق AMD KDS.
• Intel TDX (در Azure DCedsv5 و GCP C3): سطح تضمین بالا از طریق Intel PCS.
• TPM 2.0 / vTPM (در Azure, AWS, GCP Trusted Launch): سطح تضمین متوسط با ارائه کوت‌های (Quotes) محلی TPM.
• NVIDIA H100/H200/Blackwell: پشتیبانی از محاسبات محرمانه GPU (gpu-cc) برای نسخه ۰.۲ از طریق سرویس NRAS (NVIDIA Remote Attestation Service) برنامه‌ریزی شده است.
• OPAQUE Confidential Runtime: به عنوان یک گزینه اختیاری (Opt-in) وجود دارد اما در شناسایی خودکار قرار ندارد؛ انتخاب دستی آن در حال حاضر خطای ATTESTATION_PROVIDER_NOT_IMPLEMENTED را برمی‌گرداند تا از سقوط بی‌صدا سیستم جلوگیری شود.

جزئیات پیکربندی و استقرار

اپراتورها درگاه را از طریق فایل cmcp-config.yaml تنظیم می‌کنند. آدرس گوش‌به‌زنگ پیش‌فرض روی 0.0.0.0:8443 و حداکثر اندازه پاسخ روی ۲,۰۹۷,۱۵۲ بایت (۲ مگابایت) است. اعتبار گواهی‌ها برای تازه‌بودن (Freshness) به‌طور پیش‌فرض ۸۶,۴۰۰ ثانیه (۲۴ ساعت) است و در صورت قدیمی شدن، سیاست fail_closed (بستن کامل دسترسی‌ها) اجرا می‌شود، هرچند گزینه warn_only نیز به عنوان جایگزین وجود دارد.

• مدیریت سیاست‌ها: پارامتر policy_bundle_path درگاه را به دایرکتوری حاوی فایل‌های .cedar و فایل manifest.json هدایت می‌کند. به‌طور پیش‌فرض، به‌روزرسانی سیاست‌ها نیازمند ری‌استارت است (مقدار policy_reload_interval_seconds: 0).
• متغیرهای محیطی:
  • CMCP_DEV_MODE=1: حالت پشتیبان نرم‌افزاری را فعال می‌کند. بدون این متغیر، درگاه در صورت عدم شناسایی سخت‌افزار، از استارت نمی‌گیرد.
  • CMCP_BEARER_TOKEN: برای الزام استفاده از توکن در تمامی درخواست‌های ورودی استفاده می‌شود.
  • OPAQUE_ATTESTATION_URL: گواهی OPAQUE Managed Runtime را از طریق فعال‌سازی صریح فعال می‌کند.
• پین‌های اختیاری: اپراتورها می‌توانند با استفاده از expected_measurement یک مقدار PCR یا اندازه‌گیری خاص را در پیکربندی پین کنند تا از صحت دقیق نسخه سخت‌افزار مطمئن شوند.

حالت‌های نظارتی و اجرایی

برای ایجاد تعادل میان ایمنی و سرعت استقرار، سه حالت distinct تعریف شده است:
۱. اجرایی (Enforcing): حالت پیش‌فرض تولید. رد سیاست‌ها منجر به خطای HTTP 403 می‌شود و فراخوانی به سرور ارسال نمی‌گردد.
۲. مشورتی (Advisory): رد سیاست‌ها در لاگ ثبت می‌شود اما فراخوانی ادامه می‌یابد. این حالت برای تنظیمات اولیه و کاهش اصطکاک استقرار طراحی شده است.
۳. ساکت (Silent): سیاست‌ها ارزیابی می‌شوند اما هیچ چیزی ثبت یا مسدود نمی‌شود. این حالت برای ایجاد خط‌کشی (Baselining) و تحلیل رفتار سیستم استفاده می‌شود.

ردپای بازرسی‌پذیر و ادعاهای TRACE

خروجی اصلی سامانه، GatewayClaim است؛ یک توکن گواهی موجودیت (EAT) که برای هر جلسه یا فراخوانی تولید می‌شود. این توکن با کلید Ed25519 امضا شده که هرگز از TEE خارج نمی‌شود. این ادعا به عنوان مدرکی غیرقابل‌دست‌کاری برای رگولاتورها و بازرسان عمل می‌کند تا بدون نیاز به اعتماد به اپراتور، صحت عملیات را بررسی کنند.

فیلدهای کلیدی در ادعای TRACE شامل موارد زیر است:

• trace.eat_profile: شناسه URI پروفایل EAT (مقدار tag:agentrust-io.com,2026:trace-v0.2).
• trace.runtime: ثبت پلتفرم TEE و اندازه‌گیری سخت‌افزاری ثبت‌شده در هنگام بوت شدن Enclave.
• trace.policy.bundle_hash: مقدار SHA-256 بسته‌ی Cedar بارگذاری شده در استارت؛ هر تغییری در هر یک از فایل‌های سیاست، این مقدار را تغییر می‌دهد.
• trace.cnf.jwk: کلید عمومی Ed25519 متصل به کلید امضای TEE.
• trace.tool_transcript: یک نمای حفظ‌کننده حریم خصوصی برای هر فراخوانی شامل نام ابزار، کلاس داده و تصمیم گرفته‌شده که از طریق هش به نوک زنجیره بازرسی متصل شده است.
• gateway.audit_chain: یک لاگ زنجیره‌ای از هش‌ها شامل ریشه (Root)، نوک (Tip) و طول زنجیره که بدون بازپخش تک‌تک ورودی‌ها قابل تایید است.
• signature: امضای Ed25519 روی JSON نرمال‌سازی شده (مطابق RFC 8785).

یک بازرس می‌تواند از کتابخانه cmcp_verify برای بررسی امضا در برابر کلید متصل به TEE و بررسی هش بسته سیاست‌ها در برابر مقدار مورد تأیید استفاده کند. طرحواره (Schema) normativ این ادعا در مسیر schemas/trace-claim.schema.json قرار دارد.

ابزارهای خط فرمان (CLI) و اعتبارسنجی

ابزار cmcp دستورات مدیریتی ضروری را فراهم می‌کند:

• cmcp start --config PATH: برای اجرا و راه‌اندازی درگاه.
• cmcp validate-config --config PATH: برای بررسی صحت فایل YAML بدون شروع سرویس.
• cmcp validate-bundle --bundle-path PATH --expected-hash sha256:<hex>: برای تایید هش بسته Cedar پیش از استقرار.
• cmcp verify CLAIM_FILE: برای اعتبارسنجی یک ادعای TRACE امضا شده، شامل بررسی امضاها، طرحواره، تازگی (Freshness)، زنجیره بازرسی و هش‌های پین‌شده (از طریق فلگ‌هایی مثل --policy-hash یا --agent-manifest).

انطباق با استانداردها

طراحی cMCP مستقیماً با چارچوب‌های امنیتی جهانی همسو است. این ابزار ریسک‌های OWASP Agentic AI Top 10 را هدف قرار می‌دهد، به‌ویژه:

• MCP10: جلوگیری از نشت داده از طریق فراخوانی ابزارها.
• MCP02: مسدود کردن ابزارهای تایید نشده.
• MCP08: ارائه حاکمیت قابل اثبات.
• MCP04: کاهش ریسک‌های زنجیره تأمین.

همچنین با مواد ۱۲ و ۱۵ قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) در مورد سوابق بازرسی هر تصمیم و کنترل‌های امنیت سایبری مبتنی بر TEE مطابقت دارد. علاوه‌ بر این، با استاندارد NIST SP 800-207 از طریق قرار دادن نقطه تصمیم سیاست (PDP) درون TEE و عدم اعتماد ضمنی به هویت Workload همسو است و در ساختار ادعاهای خود از طریق فیلد eat_profile از RATS/EAT (RFC 9711) پیروی می‌کند.

سخت‌گیری امنیتی و محدودیت‌ها

پروژه از خط لوله‌ی امنیتی گسترده‌ای استفاده می‌کند: ruff برای استایل and linting واردات، bandit برای تحلیل امنیتی پایتون، pip-audit برای اسکن آسیب‌پذیری وابستگی‌ها، mypy برای بررسی استاتیک تایپ‌ها و CodeQL برای اجرای هفتگی پرس‌وجوهای SAST گسترش‌یافته پایتون. همچنین یک OpenSSF Scorecard دارد که امتیازات هفتگی و آپلودهای SARIF را دنبال می‌کند.

با این حال، در فایل LIMITATIONS.md اشاره شده که ریسک‌هایی در فاز اول باقی مانده است که هنوز کاملاً بسته نشده‌اند، از جمله ریسک‌های P4.1 زنجیره تأمین (Typosquatting)، تزریق پیکربندی در زمان اجرا و کپچر کردن Payload توسط APM. برای جزئیات جامع، پروژه یک تحلیل STRIDE و مدل مهاجم در docs/spec/threat-model.md ارائه داده است.

برای توسعه‌دهندگانی که می‌خواهند سیستم را بدون سخت‌افزار خاص تست کنند، پشتیبانی از حالت Fallback نرم‌افزاری از طریق CMCP_DEV_MODE=1 فراهم شده است. در این حالت، درگاه ادعاهای امضا شده را بدون گواهی سخت‌افزاری تولید می‌کند. این حالت فقط برای توسعه محلی است؛ در محیط تولید، اگر سخت‌افزاری شناسایی نشود، درگاه از استارت نمی‌گیرد تا از افت بی‌صدای امنیت جلوگیری شود.

تغییر از اعتماد نرم‌افزاری به اثبات ریشه‌دار در سخت‌افزار، فرض بنیادی امنیت عامل‌محور را تغییر می‌دهد. اکنون سازمان‌ها می‌توانند به‌صورت رمزنگاری‌شده ثابت کنند که یک سیاست خاص روی یک سخت‌افزار مشخص اجرا شده است و «مدیر سیستم» دیگر به عنوان یک بردار حمله اصلی در زنجیره تأمین هوش مصنوعی عمل نمی‌کند.

گام بعدی شما

• اگر عامل‌هایی دارید که به داده‌های حساس (PII) یا مالی دسترسی دارند، پیاده‌سازی فعلی MCP خود را با مدل تهدید STRIDE در مستندات cMCP تطبیق دهید تا ریسک‌های باقی‌مانده در کپچر Payload را شناسایی کنید.
• در محیط توسعه، متغیر CMCP_DEV_MODE=1 را برای تست بدون سخت‌افزار فعال کنید اما در محیط تولید حتماً سخت‌افزارهای موردپشتیبانی (مانند Intel TDX یا AMD SEV-SNP) را فعال نمایید.
• برای سیستم‌های حساس، سیاست fail_closed را در پیکربندی فعال کنید تا در صورت قدیمی شدن گواهی‌ها، دسترسی‌ها فوراً قطع شوند.

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