چه کسی هوش مصنوعی شما را اداره می کند؟ چارچوب اعتماد برای عوامل و مدل های سازمانی

رهبران باتجربه فناوری اطلاعات می‌دانند که فناوری اطلاعات سایه یک مشکل دائمی است، اما هوش مصنوعی به سرعت در حال تکامل و تکثیر عوامل به این معنی است که تهدید بالقوه - و هزینه - بیشتر از همیشه است.

عوامل هوش مصنوعی غیر قطعی، مستقل و سازگار هستند. آن‌ها در حل تکالیف به روش‌های خلاقانه، که اغلب باعث تعجب خالقانشان می‌شود، عالی هستند. ما کارگزارانی را دیده‌ایم که وبلاگ‌هایی می‌نویسند که از نگهبانان پروژه انتقاد می‌کنند که درخواست‌های جذب آنها را رد کرده‌اند. یکی دیگر یک چت ربات مک کینزی را هک کرد تا بدون درخواست اجازه دسترسی خواندن/نوشتن داشته باشد. و ماموران همیشه هوشمندتر می شوند.

برایان ترزوپک، معاون ارشد محصولات DigiCert، به عنوان یک کهنه کار صنعت، یک الگوی قدیمی را می بیند. "وقتی نوید فناوری بسیار خوب است، مردم مایلند امنیت را از پنجره بیرون بیاندازند و فقط می‌خواهند خیلی سریع به این وعده برسند."

CISO ها باید نگران اجازه دادن به این عوامل بدون کنترل های سختگیرانه به زیرساخت های خود باشند، اما به هر حال این اتفاق می افتد. گزارش IBM Cost of a Data Breach در سال 2026 نشان می‌دهد که سازمان‌های بیشتری برای مدیریت هوش مصنوعی یا تشخیص هوش مصنوعی سایه 68 درصد در مقایسه با 63 درصد در سال گذشته فاقد حکمرانی هستند. تعداد نیاز به تأیید فناوری اطلاعات برای استقرار هوش مصنوعی از 45 درصد به 38 درصد کاهش یافته است.

DigiCert در تلاش است تا این مشکل را با رویکرد مدیریتی خود به نام AI Trust حل کند. چارچوب، که در این مقاله سفید مشخص شده است، بر اساس آنچه شرکت در آن خوب است استوار است: زیرساخت کلید عمومی، DNS و گواهی.

AI Trust از این ابزارها برای کمک به سازمان ها برای پاسخ دادن به پنج سوال حاکمیت هوش مصنوعی استفاده می کند:

· اینکه آیا یک عامل به خطر افتاده را می توان فورا متوقف کرد

· آیا می توان یک حادثه را با یک دنباله دستکاری آشکار بازسازی کرد

ترژوپک هشدار می دهد که تقریبا هر شرکتی در اولین مانع شکست می خورد. توسعه دهندگان عواملی را می سازند یا آنها را از فروشندگان می خرند و آنها را بدون درخواست در داخل مستقر می کنند. کاربران همچنین ممکن است عواملی را از داخل ابزارهایی مانند Claude Desktop یا OpenAI Codex تولید کنند که سپس عوامل فرعی ایجاد کنند.

او می‌گوید: «این عوامل فرعی حقوق و مسئولیت‌ها و اختیارات یکسانی را به عنوان نماینده اصلی ندارند. بنابراین آنها سعی می کنند وظایفی را که کاملا قابل کنترل باشد، محول کنند.»

اکثر شرکت‌ها هنوز ابزارهایی را برای پیگیری همه این انواع مختلف عامل ایجاد نکرده‌اند. اولین قدم شناسایی آنهاست. اینجاست که بسیاری از سازمان‌ها اولین اشتباه خود را با چسباندن عوامل به پشته هویت انسانی و مدیریت دسترسی (IAM) که قبلا دارند، مرتکب می‌شوند. ایده این است که اگر به یک نماینده یک حساب سرویس و یک کلید API با عمر طولانی بدهید، می‌توانید با او مانند یک کارمند فوق‌العاده سریع رفتار کنید. این غیر عملی است.

Trzupek می‌گوید: «IAM برای انسانی ساخته شده است که پشت صفحه‌کلید نشسته است و می‌تواند روی «تأیید» روی تلفن خود ضربه بزند. "یک نماینده نمی تواند این کار را انجام دهد. بنابراین شما به یک کلید API ثابت باز می گردید که هرگز منقضی نمی شود و دامنه آن بسیار بیشتر از آنچه که نیاز دارد، دارد، و اکنون همه چیزهایی را که قرار بود به شما اعتماد صفر بدهد، لغو کرده اید. این دقیقا اعتباری است که ما یک دهه صرف کرده ایم تا به مردم بگوییم که از شر آن خلاص شوند."

نهادهای صنعت شروع به همگرایی در پاسخ متفاوتی کرده اند. IDC اکنون توصیه می‌کند که هویت عامل را به‌عنوان یک مشکل هویت حجم کار به‌جای توسعه IAM انسانی، که با مدیریت حجم کاری هویت و افزونه‌های امنیتی IETF (WIMSE) و چارچوب امنیت سایبری نسخه 2.0 NIST همراستا شود، توصیه می‌کند. سپس می‌توانند عامل‌ها را به‌عنوان بارهای کاری کنترل‌شده که به تأیید زمان اجرا و اعتبارنامه‌های کوتاه مدت نیاز دارند، قالب‌بندی کنند.

این ایده همچنین تیم ها را به سمت شناسه نمایه سرویس (SPIFFE) و نقطه پایانی ثبت SPIFFE (SPIRE) سوق می دهد. این یک استاندارد هویت بار کاری باز است که قبلا در بسیاری از املاک Kubernetes میزبانی شده توسط hyperscaler مستقر شده است و آنها بخشی از استراتژی هوش مصنوعی DigiCert هستند.

موجودی و هویت ممکن است شما را در معرض دید قرار دهد، اما همچنان به جایی برای اجرای خط مشی نیاز دارید. DigiCert نظرات قوی در مورد مکان دارد که به تاریخچه مدیریت یکپارچگی DNS بستگی دارد.

مهم نیست که یک عامل در حال حل کردن یک نقطه پایانی API یا اتصال به یک سرور MCP است، ابتدا باید DNS را پرس و جو کند. پس چرا آن را به یک نقطه تأیید اصلی تبدیل نکنید؟

DigiCert راه حلی را پیشنهاد می کند که بسیار شبیه استاندارد DMARC مورد استفاده برای ایمیل است. یک سازمان یک سابقه سیاست عامل در DNS منتشر می کند که چندین چیز را اعلام می کند:

· مرجع صدور گواهینامه که اعتبار آنها را صادر کرده است

سپس یک دروازه می‌تواند آن رکورد را پرس و جو کند تا تأیید کند آیا یک عامل ورودی قانونی است یا خیر، و در صورت شکست چک، جلسه را خاتمه دهد. و اگر یک عامل در اواسط اجرا با دامنه غیرمجاز تماس بگیرد، DNS می تواند پرس و جو را مسدود کند و دروازه MCP جلسه را از بین می برد.

IDC این ایده را دوست دارد اما هشدار می دهد که مقیاس یک مشکل است. با افزایش تعداد عامل ها، رکوردهای DNS ممکن است ادامه نداشته باشند و سوابق قدیمی ممکن است به یک حفره تبدیل شوند. اعلامیه های بیش از حد مجاز دامنه نیز هنوز یک مشکل بالقوه است.

Trzupek پاسخ می دهد: "مشکل مقیاس واقعی است، اما این همان مشکلی است که DNS صدها بار قبلا حل کرده است." "شما چرخه عمر را خودکار می کنید، رکورد را به صدور گواهینامه گره می زنید و زمانی که گواهی منقضی شد، رکورد با آن همراه می شود."

او اضافه می‌کند که اپراتورهایی که دامنه‌های وایلد کارت را می‌نویسند، چون عجله دارند، یک مشکل نظمی است، نه یک مشکل معماری.

عواملی که در خانه ساخته می شوند در کنار عوامل شخص ثالث مانند Microsoft Copilot، Salesforce Agentforce و ServiceNow زندگی می کنند و سطوح کنترلی برای این دو دسته متفاوت است. پاسخ DigiCert یک سرور SPIRE منفرد است که برای هویت به یک DigiCert CA متصل می‌شود، با خط‌مشی که به طور مرکزی در موتور Open Policy Agent اعمال می‌شود، و یک سوئیچ کشتن یکپارچه که در هر دو دسته کار می‌کند.

پاسپورت عامل هوش مصنوعی مصنوع است که هویت را با مجوز مرتبط می کند. این یک سابقه رمزنگاری محافظت شده از سیستم های تایید شده و عملیات مجاز است. هر "گذرنامه" همچنین شامل مواردی مانند طبقه بندی حساسیت داده ها و وضعیت انقضا، همراه با یک مالک انسانی پاسخگو است.

Trzupek می‌گوید زمینه‌ای که بیشترین پس‌بک را در طراحی ایجاد می‌کند، خود خط‌مشی است، زیرا مشتریان معمولا شبکه پیچیده‌ای از سیاست‌ها را از قبل در GCP یا AWS دارند. او می‌گوید: «تلاش برای جایگزینی یا جابجایی آنها یک کار احمقانه است. بنابراین پاسپورت می تواند نشانگرهایی را به آن موتورها نگاه دارد تا جایگزینی آنها.

کارگزاران حاکم تنها نیمی از چالش هستند. مدل‌ها خود دارایی‌های استراتژیک هستند و همچنین مشمول کنترل‌های یکپارچگی و منشأ هستند. این به معنای رمزگذاری و امضای رمزنگاری مصنوعات مدل، بسته‌بندی منطبق با Open Container Initiative با ابزارهایی مانند ابتکار عمل امضای کد Sigstore، و یک صورت‌حساب مدل مواد با قابلیت تأیید رمزنگاری شده است که وزن‌ها، مجموعه داده‌ها و وابستگی‌ها را توصیف می‌کند.

این همچنین به معنای حاکم بر مدل‌ها در زمان اجراست، نه فقط ایمن کردن زنجیره تامین. چارچوب AI Trust DigiCert از اجرای سخت افزار قابل اعتماد برای کمک به حل این مشکل حمایت می کند. مدلی که در یک محیط اجرایی قابل اعتماد در Intel TDX یا AMD SEV-SNP اجرا می‌شود، در حافظه، جدا از سیستم عامل میزبان، رمزگذاری می‌شود.

DigiCert یک سرویس گواهی محاسباتی محرمانه را اجرا می کند که از معماری رویه های تأیید از راه دور IETF (RATS) پیروی می کند. محیط اجرا تایید کننده و DigiCert تایید کننده است. سیستم های پایین دستی طرف های اتکا هستند.

این رویکرد، گواهی را از یک شخص ثالث خنثی به جای اپراتور ابری که حجم کار را اجرا می کند، منتقل می کند، که به خریداران تنظیم شده خدمت می کند. هایپرمقیاس کننده ها نباید صداقت خود را تایید کنند.

آن خریداران تنظیم شده با برخی گفتگوهای سنگین حاکمیتی روبرو هستند. در مراقبت های بهداشتی، سوال این است که آیا مدل هوش مصنوعی که از طریق مسیر FDA 510(k) پاک شده است، الگوریتم دقیقی است که در استقرار بالینی اجرا می شود یا خیر. گواهی رمزنگاری به این شرکت‌ها اجازه می‌دهد قبل از هر استنتاج یکپارچگی مدل را ثابت کنند. این دستورالعمل به راهنمای امنیت سایبری 2023 FDA در مورد تأیید صحت نرم افزار و اجرای SBOM می پردازد.

اما در حالی که برخی از عمودهای تنظیم شده نیازهای خاصی دارند، حکمرانی هوش مصنوعی یک مشکل بین بخشی است. هر سازمانی که داده های مشتری را ذخیره می کند، یک نماینده می تواند به این کنترل ها دسترسی داشته باشد یا از آنها خارج شود.

این لحظه هوش مصنوعی عامل است، بنابراین شرکت ها در نقطه محوری قرار دارند و قبلا اینجا بوده اند.

بسیاری از آنها 25 سال گذشته را به دنبال یک الگوی ضد امنیت سایبری گذرانده‌اند: به سرعت برای استفاده از یک فرصت با توسعه فناوری جدید جدید حرکت کنند و بعدا با تیم امنیتی تماس بگیرند تا نقاط ضعف را تمیز کنند. خوب پیش نرفته با توجه به اینکه بسیاری از سازمان‌ها در ابتدای سفر خود به هوش مصنوعی هستند، اکنون فرصتی برای ترک این عادت و انجام کارها از همان ابتدا با استفاده از کنترل‌های قابل تأیید دارند.

Trzupek نتیجه می گیرد که با افزایش قیمت مدل های مرزی و افزایش هوش مصنوعی به عنوان هزینه قابل توجه در بودجه های سازمانی، این به یک انتخاب قابل مشاهده تبدیل خواهد شد. شرکت ها افراد را در مورد استفاده از فناوری عامل پاسخگوتر خواهند کرد. آیا خوب نیست که کنترل ها را در جای خود داشته باشیم و برای یک بار هم که شده جلوتر از بازی باشیم؟