«احراز هویت عامل‌ها»؛ راهکار جدید سه غول پرداخت برای جلوگیری از تخلف

تصور کنید در دنیایی زندگی می‌کنیم که سؤال اصلی در ایمنی هوش مصنوعی دیگر این نیست که «ماشین چقدر می‌تواند خرج کند»، بلکه این است که «واقعاً چه کسی در حال خرج کردن است». برای پاسخ به این تغییر مسیر، شرکت‌های آنت اینترنشنال (Ant International)، ویزا (Visa) و مسترکارت (Mastercard) در ۹ و ۱۰ سپتامبر ۲۰۲۴ همکاری مشترک خود را برای ایجاد یک چارچوب تعامل‌پذیری (Interoperability Framework) تحت عنوان KYA (Know-Your-Agent) یا «عامل خود را بشناسید» اعلام کردند. این ابتکار نشان می‌دهد که صنعت پرداخت در حال عبور از محدودیت‌های ساده‌ی سقف هزینه‌ها (Quota Limits) به سمت یک سیستم سخت‌گیرانه‌ی اثبات هویت برای ماشین‌های خودمختار است.

در شش ماه گذشته، تقریباً تمام بحث‌های مربوط به عامل (Agent) — شبیه دستیاری دیجیتال که می‌تواند به‌جای شما تصمیم بگیرد و ابزارها را اجرا کند — بر این محور بود که آیا ماشین کار اشتباهی انجام می‌دهد یا خیر. وقتی متا (Meta) اخیراً به یک عامل مصرف‌کننده اجازه داد تا سفرها را رزرو کرده و به‌طور مستقل پرداخت کند، این اقدام بلافاصله بحرانی را برای شبکه‌های پرداخت ایجاد کرد. طبق گزارش منابع صنعتی، مشکل اصلی جابه‌جایی پول نیست — چرا که پول هم‌اکنون هم می‌تواند جابه‌جا شود — بلکه مشکل اصلی، تأیید هویت بازیگر (Actor) است. شبکه‌های پرداخت به‌سرعت این سؤال بنیادین را مطرح کردند: چرا باید باور کنیم این پرداخت از طرف یک عامل مجاز است و نه یک اسکریپت هک‌شده یا ربات غیرمجاز؟

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، مدیریت دسترسی‌ها در محیط‌های پویا چالش‌برانگیز است. کیف پول دیجیتال را مثل یک در تصور کنید. سال‌ها تمرکز ما روی قفل (سقف هزینه) و کلید (ابزار API) بود، اما حالا شبکه‌های پرداخت «پاسپورت» می‌خواهند. آن‌ها می‌خواهند بدانند عامل کیست، به نمایندگی از چه کسی عمل می‌کند، محدوده اختیاراتش (Mandate) چقدر است و آیا در همین لحظه هنوز در چارچوب آن اختیارات است یا خیر. این نیاز به شناسایی دقیق، در واقع تکامل یافته‌ی ایده‌ی ایجاد کیف پول‌های اختصاصی برای ربات‌هاست تا استقلال مالی AI با نظارت دقیق‌تر همراه شود. سقف هزینه یک مسئله ریاضی است، اما هویت یک مسئله اثباتی است. اگر ریاضیات را اشتباه کنید، صورت‌حساب نهایی این را نشان می‌دهد؛ اما اگر اثبات هویت را اشتباه کنید، یک پرداخت نادرست که لباس «تطبیق کامل با قوانین» به تن دارد، می‌تواند کل فرآیند را از ابتدا تا انتها دور بزند.

چارچوب KYA در برابر پروتکل‌های فعلی

چارچوب KYA به‌عنوان معادل ماشینیِ پروتکل KYC (Know Your Customer) طراحی شده است. در حالی که یک انسان هویت واحدی دارد، هویت یک عامل ترکیبی پیچیده از شخص اصلی (Principal)، محدوده حکمِ اعطایی (Scope of Mandate) و دوره اعتبار است. طبق اعلام رسمی در BusinessWire، این هویت باید توسط شخص ثالث در شبکه‌های مختلف قابل تأیید باشد؛ به همین دلیل توکنی که توسط یک پلتفرم واحد صادر شود، به‌تنهایی کافی نیست و نمی‌تواند در شبکه‌های دیگر اعتبار داشته باشد.

هدف این است که شبکه‌های کارت، کیف پول‌های دیجیتال، پلتفرم‌های عامل‌محور و بازارهای دیجیتال (Marketplaces) بر سر نحوه پذیرش (Onboarding) و شناسایی عامل‌ها به توافق برسند تا پرداخت‌های مبتنی بر هوش مصنوعی بتوانند با امنیت بیشتری مقیاس‌پذیر شوند. این تغییر رویکرد توسط رسانه‌های معتبری چون PYMNTS، Forkast و The Next Web نیز پوشش داده شده است. این استانداردسازی برای پلتفرم‌هایی که مدیریت دارایی‌ها را به عامل‌های هوش مصنوعی سپرده‌اند، حیاتی است تا تراکنش‌های زنده در محیط‌های مالی با ریسک کمتری انجام شود.

به گزارش Forkast، وضعیت فعلی KYA بیشتر یک «قصد برای تعامل‌پذیری» (Interoperability Intent) است تا یک محصول نهایی و آماده. این چارچوب در حال حاضر فاقد موارد زیر است:

• مشخصات فنی (Technical Specification)
• مکانیزم حاکمیتی (Governance Mechanism)
• جدول زمانی مشخص برای اجرا (Implementation Timeline)

این روند برای استانداردهای صنعتی عادی است — ابتدا بیانیه قصد، سپس پیش‌نویس مشخصات و در نهایت صدور گواهینامه — اما به این معناست که متخصصان و توسعه‌دهندگان نمی‌توانند منتظر نهایی شدن استاندارد بمانند تا اقدام کنند. این رویکرد با پروتکل پرداخت‌های عامل گوگل متفاوت است؛ گوگل بر ثبت اتفاقات لحظه تراکنش تمرکز دارد تا به تطبیق‌های پس از وقوع (After-the-fact reconciliation) کمک کند. همان‌طور که در گزارش Fortune آمده است، ثبت یک گزارش (Log) به معنای اجازه (Authorization) نیست؛ دانستن اینکه یک عامل پولی را بدون اجازه شما خرج کرده است، جلوی ضرر را نمی‌گیرد. یک رکورد، یک مجوز نیست.

ساخت زنجیره مجوز فوری

از آنجا که استاندارد جهانی هنوز در مرحله پیش‌نویس است، توسعه‌دهندگان نمی‌توانند منتظر بمانند تا شبکه‌ها مشخصات فنی خود را نهایی کنند. یک سیستم مستحکم نیازمند زنجیره مجوز سه‌بخشی است که همین امروز قابل پیاده‌سازی باشد. این رویکرد بر اساس سیستمی است که ۲۷۶ روز اجرا شده و یک دفترچه خطاهای (Error Ledger) دارد که ۸۰ مورد حادثه را بر اساس علامت، علت ریشه‌ای، راهکار و وضعیت ثبت کرده است.

تا به حال، آن دفترچه به سؤال «چه چیزی اشتباه پیش رفت» پاسخ می‌داد. برای تبدیل یک دفترچه تحلیل پس از حادثه (Post-mortem) به یک دفترچه پاسخگویی (Accountability Ledger)، باید فیلد اجباری approved_by (تأیید شده توسط) را به هر اقدام اضافه کنید. یک دفترچه حادثه برای کالبدشکافی خطاهاست، اما یک دفترچه مجوز برای پاسخگویی است؛ این دو، دو وظیفه کاملاً متفاوت هستند.

این پاسخگویی توسط سه مکانیزم موجود پشتیبانی می‌شود:

• دروازه سیاست‌محور (Policy-First Gate): هر اقدام قبل از اجرا، یک بررسی ALLOW / DENY یا ارجاع به انسان (Escalate-to-human) را طی می‌کند. این قوانین با کد قطعی (Deterministic) نوشته می‌شوند، نه با پرامپت‌های متنی. این لایه در بالاترین نقطه اسکریپت اجرا می‌شود و در صورت شکست، دستور exit را فراخوانی می‌کند تا تضمین شود هیچ راه فیزیکی برای دور زدن آن وجود ندارد.
• بررسی محدوده (Scope Checking): پس از اینکه عامل هویت و شخص اصلی خود را اعلام کرد، سیستم بررسی می‌کند که آیا اقدام مورد نظر در محدوده حکم اعطایی است یا خیر. محدوده به صورت یک لیست (Allowlist) مدیریت می‌شود، نه یک حس کلی؛ ابزارها بر اساس لیست مجاز اجرا می‌شوند و اعتبارنامه‌ها (Credentials) هرگز وارد محیط داخلی عامل نمی‌شوند.
• ردپای اقدامات (Append-Only Action Trail): یک رکورد دائمی و غیرقابل تغییر از هر اقدام. افزودنی حیاتی در اینجا فیلد approved_by است که تضمین می‌کند هر تک اقدام، یک تأییدکننده نام‌دار دارد.

پیاده‌سازی منطق اجرایی

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

# Authorization check: prove who, before letting it act
def authorize(agent, action):
    if not agent.identity: # who is acting
        raise Denied("no identity") # anonymous -> reject
    if action.tool not in agent.allowed_tools: # what it may do
        return escalate_to_human(action) # out of scope -> human
    if not agent.mandates.matches(action): # on whose behalf
        raise Denied("out of mandate") # beyond mandate -> reject
    if action.amount > agent.confirm_threshold:
        return escalate_to_human(action) # big action -> human
    rec = execute(action) # only place it acts
    ledger.append(rec, actor=agent.identity, approved_by=action.approval)
    return rec

برای تأیید این منطق، می‌توانید مرزها را با استفاده از اسکریپتی مانند authz.py در حالت Dry-run تست کنید:

• تست ناشناس: python3 authz.py --dry-run --anonymous (انتظار: Denied: no identity)
• تست محدوده ابزار: python3 authz.py --dry-run --tool unknown (انتظار: escalate_to_human)
• تأیید دفترچه: tail -3 ledger.jsonl (انتظار: هر رکورد باید دارای approved_by باشد)

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

ریسک انحراف حکم (Mandate Drift)

توسعه‌دهندگان باید «انحراف حکم» را هم در نظر بگیرند. اقدامی که امروز پذیرفتنی است، ممکن است سه ماه دیگر دیگر همان اقدام نباشد یا دیگر مجاز نباشد. یک حکم (Mandate) فقط به این دلیل که یک بار اعطا شده، برای همیشه معتبر نیست. ردپای مجوز باید دوره اعتبار (Validity Period) را ردیابی کند تا سناریوهای «چک سفید» پیش نیاید، جایی که یک عامل همچنان بر اساس یک مجوز منقضی شده عمل می‌کند.

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

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

گام بعدی شما

• فیلد approved_by را به تمام لاگ‌های عملیاتی عامل‌های خود اضافه کنید تا زنجیره پاسخگویی ایجاد شود.
• قوانین دسترسی را از پرامپت‌ها خارج کرده و به کدهای قطعی (Deterministic) در لایه دروازه (Gate) منتقل کنید.
• برای هر مجوز، یک تاریخ انقضا (TTL) تعریف کنید تا از انحراف حکم در بلندمدت جلوگیری شود.

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