یک عامل نمی‌تواند ناظر خودش باشد: تفکیک وظایف در هوش مصنوعی

عامل حساب‌های پرداختنی ایمیل تأمین‌کننده را می‌خواند، شماره حساب تازه را استخراج می‌کند، آزادسازی وجه را پیشنهاد می‌دهد، پرداخت می‌کند و بعد سند را «تطبیق‌شده» می‌نامد. هر گام معقول به نظر می‌رسد؛ اما در کنار هم یک مسیر تصمیم را متولی شاهد، تأیید، دارایی و اثبات نتیجه می‌کند.

تصمیم خواننده این است: کدام گام‌ها می‌توانند حوزه کنترل مشترک داشته باشند و کدام مسئولیت‌ها مجوز و راستی‌آزمایی مستقل می‌خواهند؟ پاسخ به پیامد، برگشت‌پذیری، انگیزه، شاهد و اثر جزء تسخیرشده بر دیگر اجزا بستگی دارد.

قاعده مرکزی ساده است: یک کنشگر مؤثر نباید درخواست پرپیامد را بسازد، تأیید و اجرا کند و نتیجه را درست اعلام کند. این کنشگر فقط نام نقش نیست؛ حساب انسان، عامل، بافت مدل، هویت سرویس، اعتبارنامه، محیط اجرا، مدیر سیاست و منبع شاهد را هم در بر می‌گیرد.

چند مرحله لزوماً چند وظیفه مستقل نیست

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

استقلال دست‌کم پنج بُعد دارد:

هر کار به دو انسان یا فروشنده نیاز ندارد؛ کنترل باید همان شکست هدف را تاب بیاورد. دو شخصیت در یک بافت آلوده، تزریق پرامپت را مهار نمی‌کنند و دو سرویس زیر کنترل یک مدیر شاید مانع سوءاستفاده داخلی نشوند. برای خطای مدل، اعتبارسنج قطعی روی داده مرجع می‌تواند از نظر دوم مدل قوی‌تر باشد.

منابع اصلی چه چیزی را تثبیت می‌کنند

کنترل AC-5 در NIST SP 800-53 ویرایش ۵ شناسایی وظایف نیازمند جداسازی و مجوزهای دسترسی پشتیبان را می‌خواهد. این فهرست مجوز دوگانه برخی اقدام‌های ممتاز و حفاظت سابقه حسابرسی از اپراتور را نیز پوشش می‌دهد. این‌ها کنترل سامانه‌اند، نه جمله پرامپت.

کتاب سبز ۲۰۲۵ دیوان محاسبات دولت آمریکا، که در دامنه فدرال خود از سال مالی ۲۰۲۶ اجرا می‌شود، اختیار، نگهداشت دارایی و حسابداری را جدا می‌کند. اگر جداسازی کامل عملی نیست کنترل جبرانی لازم است؛ تفکیک وظایف نیز تبانی را حذف نمی‌کند.

راهنمای مدیریت ریسک مدل مشترک نهادهای بانکی آمریکا در آوریل ۲۰۲۶، چالش مؤثر را نیازمند استقلال، صلاحیت، نفوذ و اختیار می‌داند. متن صریحاً هوش مصنوعی مولد و عامل‌محور را خارج می‌کند؛ پس مقررات عامل نیست. درس محدودش سنجش استقلال با انگیزه، تعارض، تخصص و نتیجه است، نه برچسب سازمانی.

هسته داوطلبانه AI RMF مؤسسه NIST بر پاسخ‌گویی، تفکیک نقش انسان و هوش مصنوعی، نظارت و ریسک متناسب تأکید می‌کند. خطر اختیار بیش‌ازحد OWASP قابلیت، مجوز و خودمختاری زیاد را ریشه اقدام زیان‌بار می‌داند و مجوز پایین‌دستی را پیشنهاد می‌کند.

راهنمای شاخه حفاظت‌شده GitHub می‌تواند تأیید آخرین تغییر را از فردی غیر از فرستنده بخواهد و پس از تغییر فایل‌ها آن را باطل کند. RFC 9396 جزئیات ساخت‌یافته مجوز OAuth را برای اقدام، مکان، شناسه و فیلد تراکنش تعریف می‌کند.

گراف نقش، پوش تأیید، مثال و سنجه‌ها تحلیل ژرف برآمده از این منابع است؛ الگوی مهندسی، نه مشاوره حقوقی، حسابرسی، بانکی یا سرمایه‌گذاری.

پیش از انتساب نقش، وظایف ناسازگار را پیدا کنید

از نتیجه محافظت‌شده آغاز کنید، نه عنوان شغلی. تراکنش را از دریافت شاهد تا راستی‌آزمایی بنویسید. ترکیب‌هایی را علامت بزنید که به یک کنشگر اجازه ساختن وضعیت زیان‌بار و تأیید، پنهان یا تحریف آن را می‌دهند.

یک تجزیه عملی چنین است:

1. ایجاد: درخواست یا منبع را عرضه کند.
2. تفسیر: واقعیت را استخراج و اقدام را پیش‌نویس کند.
3. اعتبارسنجی: سیاست، شاهد، سقف، تکرار و ناهنجاری را بررسی کند.
4. مجوز: مسئولیت اقدام مشخص را بپذیرد.
5. اجرا: وضعیت بیرونی را تغییر دهد.
6. ثبت: درخواست، تصمیم، نتیجه و استثنا را نگه دارد.
7. تطبیق: اقدام را با نتیجه مرجع بیرونی مقایسه کند.
8. مدیریت: سیاست، نقش، آستانه، مدل یا قاعده شاهد را تغییر دهد.

همه جفت‌ها متعارض نیستند؛ یک عامل می‌تواند تیکت برگشت‌پذیر و نمونه‌برداری‌شده را طبقه‌بندی و اعتبارسنجی کند. اما در فرایند مهم، این ترکیب‌ها جدا می‌شوند:

• ایجادکننده و تنها مجوزدهنده، وقتی پذیرش به او سود می‌رساند؛
• پیشنهاددهنده و اجراکننده پول، دسترسی، انتشار، حذف یا تعهد؛
• اجراکننده و تطبیق‌دهنده، چون رسید اجرا نتیجه بیرونی را ثابت نمی‌کند؛
• مدیر سیاست و تأییدکننده استثنا؛
• نگهبان شاهد و ارزیاب؛
• مالک گردش‌کار و تنها اعتبارسنج، وقتی انگیزه راه‌اندازی متعارض است.

این بحث مرز تأیید انسانی را کامل می‌کند. آن راهنما می‌پرسد قضاوت انسان کجا قرار گیرد؛ تفکیک وظایف می‌پرسد آیا فرد یا سازوکار روی آن مرز می‌تواند بدون اشتراک انگیزه، اختیار و نقطه کور پیشنهاددهنده، درخواست را به‌راستی به چالش بکشد.

به‌جای فهرست نقش، گراف تعارض بسازید

نقش‌ها را گره و ترکیب ناسازگار را یال در نظر بگیرید. برای هر یال اعمال فنی مشخص کنید:

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

راهنمای هویت و مجوز عامل مدل هویتی مکمل را شرح می‌دهد. برچسب مستقل عامل فقط وقتی ارزش دارد که سامانه پایین‌دستی بتواند آن را راستی‌آزمایی و سیاست بتواند اقدام ناسازگار را رد کند.

تأیید را به همان تراکنش دقیق متصل کنید

واژه «تأیید شد» وقتی از موضوع بررسی جدا باشد خطرناک است. پیش از بازبینی، شیء نیت را به صورت معیار بسازید و روی هر فیلدی که پیامد را عوض می‌کند، هش تغییرناپذیر بگیرید:

{
  "intent_id": "payable-4821-v3",
  "action": "release_payment",
  "resource": "invoice-4821",
  "counterparty_id": "supplier-771",
  "destination_id": "bank-account-fingerprint-9c2e",
  "amount": {"currency": "EUR", "value": "123.50"},
  "evidence_refs": ["invoice:sha256:...", "po:sha256:..."],
  "policy_version": "payables-18",
  "expires_at": "2026-08-28T10:15:00Z",
  "intent_digest": "sha256:..."
}

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

RFC 9396 الگویی برای روشن‌کردن اقدام، مکان، شناسه، مبلغ، ارز و طرف معامله است؛ اما تفکیک وظایف، امضای تأیید، سیاست کسب‌وکار یا جلوگیری از بازپخش را تأمین نمی‌کند.

به کنترل‌کننده شاهد و اختیار مستقل بدهید

بازبین چیزی را که نمی‌بیند به چالش نمی‌کشد. بسته بازبینی به ارجاع منبع، واقعیت نرمال‌شده، اختلاف، سیاست، اثر پیشنهادی، اقدام پیشین و رفتار پس از تأیید نیاز دارد. توضیح مدل ادعاست، نه شاهد منبع.

برای کنترل مهم، اعتبارسنج یا تطبیق‌دهنده باید واقعیت تعیین‌کننده را مستقل بازیابی کند: هویت تأمین‌کننده را از فهرست نگهداری‌شده فروشندگان بگیرد، نه ایمیل؛ وضعیت دسترسی جاری را از سرور منبع بخواند، نه متن عامل؛ و وضعیت تسویه را از ارائه‌دهنده پرداخت بپرسد، نه جمله «موفق بود» که ابزار ساخته است.

کنترل‌کننده به قدرت رویه‌ای هم نیاز دارد:

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

انسان مستقل بدون شاهد، تشریفات و اعتبارسنج بدون قدرت توقف فقط مشاهده‌پذیری است. چالش مؤثر اطلاعات و مداخله می‌خواهد.

جداسازی را بیرون از مدل اعمال کنید

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

واسط اجرا فقط پس از کنترل قطعی این موارد درخواست را بپذیرد:

• نیت معیار و اصیل‌های پیشنهاد و تأیید نامتعارض‌اند؛
• تأیید جاری همان هش را می‌پوشاند؛
• سقف، طرف معامله، تکرار و پیش‌نیاز قبول‌اند؛
• اعتبارنامه به همان اقدام و منبع محدود است؛
• نیت وضعیت نهایی قبلی ندارد؛
• ثبت تغییرناپذیر پیش از اثر آماده است.

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

مثال عملی: تغییر حساب بانکی تأمین‌کننده

شرکتی می‌خواهد صورتحساب عادی و تأییدشده‌ای را بپردازد؛ اما ایمیل تأمین‌کننده هم‌زمان شماره حساب تازه‌ای پیشنهاد می‌دهد. مقدارها نمایشی‌اند و این یک مثال معماری است، نه ادعای استقرار در ژرف.

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

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

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

چهارم، تأییدکننده نیت مقید می‌بیند: منبع، راستی‌آزمایی، تعارض، مبلغ، ارز، اثر انگشت مقصد، سیاست و انقضا. تأیید به هش می‌چسبد و هر ویرایش آن را باطل می‌کند.

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

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

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

کنترل متناسب و جبرانی را انتخاب کنید

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

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

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

شکست‌هایی که استقلال نمایشی می‌سازند

شکست هم‌بسته به‌اندازه تعارض رسمی مهم است. دو اعتبارسنج با یک مدل می‌توانند همان خطای نظام‌مند را تکرار کنند. دو سرویس روی پایگاه نوشتنی مشترک از یک رخنه اثر می‌پذیرند. یک مدیر ابر شاید بتواند هویت همه بارکاری‌ها را جعل کند. نقاط کنترل مشترک را ثبت و درباره پذیرش ریسک باقی‌مانده تصمیم بگیرید.

بسنجید استقلال در عمل کار می‌کند یا نه

جامعه واقعی را بشمارید، نه تعداد سند سیاست را:

• نیت‌های پرپیامد دارای گراف تعارض و مالک؛
• تلاش ردشده به‌دلیل تعارض نقش پیشنهاد، تأیید، اجرا، تطبیق یا مدیریت؛
• تأیید باطل‌شده بر اثر تغییر پس از بازبینی، انقضا، مصرف دوباره یا تغییر سیاست؛
• تأیید دارای شاهد و بازیابی مستقل واقعیت تعیین‌کننده؛
• نیت اجراشده‌ای که در پنجره مقرر با نتیجه مرجع بیرونی تطبیق شده است؛
• اثر نامطابق، نامعین، تکراری و بازنویسی دستی بر پایه شدت؛
• اختلاف، نرخ بازگشت برای شاهد، زمان تصمیم، سن صف و نشانه تأیید تشریفاتی؛
• دفعات، مدت، دامنه، شاهد بستن و بازبینی عقب‌افتاده دسترسی اضطراری؛
• آزمون شکست مشترک با فرض تسخیر یک مدل، صادرکننده هویت، مدیر، پایگاه یا فروشنده.

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

بازبینی انتشار یک مرز استقلال

پیش از فعال‌کردن اقدام پرپیامد هوش مصنوعی پاسخ دهید:

• کدام نتیجه محافظت می‌شود و مسیر خطا، سوءاستفاده یا پنهان‌کاری چیست؟
• کدام وظایف ناسازگارند و تعارض کجا اعمال می‌شود؟
• آیا اصیل، قابلیت، وضعیت، شاهد و مدیریت برای تهدید به‌اندازه کافی جدا هستند؟
• آیا کنترل‌کننده واقعیت را بدون خلاصه پیشنهاددهنده می‌گیرد؟
• آیا تأیید به تراکنش دقیق متصل و با تغییر باطل می‌شود؟
• آیا اجراکننده فقط در پوش مجاز و یک‌بار عمل می‌کند؟
• آیا تطبیق نتیجه مرجعِ بازنویسی‌ناپذیر برای اجراکننده را می‌بیند؟
• کدام شکست مشترک، تبانی یا مسیر اضطراری باقی مانده است؟
• اگر جداسازی عملی نیست، کدام کنترل جبرانی همان ریسک را می‌گیرد؟
• کدام سنجه بازبینی تشریفاتی یا ناممکن را آشکار می‌کند؟

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

یادداشت منابع — بازبینی‌شده در ۲۰۲۶

• NIST، SP 800-53 ویرایش ۵: تفکیک وظایف AC-5، مجوز دوگانه، کمترین امتیاز و حفاظت سابقه حسابرسی.
• دیوان محاسبات دولت آمریکا، کتاب سبز ۲۰۲۵: وظایف ناسازگار، اختیار، نگهداشت و حسابداری، کنترل جبرانی و محدودیت تبانی.
• فدرال رزرو، OCC و FDIC، راهنمای مدیریت ریسک مدل ۲۰۲۶: حاکمیت مبتنی بر ریسک، چالش مؤثر، تعارض و محدودیت صریح دامنه هوش مصنوعی مولد و عامل‌محور.
• NIST، هسته AI RMF: پاسخ‌گویی، تفکیک نقش انسان و هوش مصنوعی، نظارت و مدیریت متناسب ریسک چرخه عمر.
• پروژه امنیت هوش مصنوعی مولد OWASP، اختیار بیش‌ازحد LLM06: قابلیت، مجوز و خودمختاری بیش‌ازحد و اعمال مجوز پایین‌دستی.
• مستندات GitHub، شاخه‌های حفاظت‌شده: استقلال بازبین از آخرین تغییر و بی‌اعتباری تأیید پس از تغییر تفاوت فایل‌ها.
• IETF، RFC 9396 درخواست مجوز ریزدانه OAuth 2.0: جزئیات ساخت‌یافته مجوز برای اقدام، منبع و فیلد تراکنش.