طراحی ابزارهای نوشتن امن برای عامل های هوش مصنوعی در فروشگاه های آنلاین: الگوی پیش نمایش، تایید و ثبت در یک سرور MCP برای ووکامرس

_چکیده

با گسترش پروتکل Model Context Protocol (MCP)، اتصال عامل های مبتنی بر مدل های زبانی بزرگ به سامانه های عملیاتی مانند فروشگاه های آنلاین ساده شده است. اما دسترسی خواندنی و دسترسی نوشتنی از نظر ریسک هم ارز نیستند: عاملی که می تواند قیمت را تغییر دهد، سفارش را تکمیل کند یا مبلغی را بازگرداند، روی داده و پول مشتریان واقعی اثر مستقیم دارد. این مقاله طراحی ابزارهای نوشتن را در woocommerce-mcp، یک سرور متن باز MCP برای مدیریت فروشگاه های ووکامرس، شرح می دهد و تحلیل می کند. این سرور در نسخه 0.4.0 دارای 47 ابزار است که 28 ابزار آن خواندنی و 19 ابزار آن نوشتنی است. سازوکارهای اصلی عبارت اند از: حالت پیش فرض فقط خواندنی برای هر فروشگاه، چرخه دو مرحله ای پیش نمایش و تایید که در آن پیش نمایش با اجرای همان کد واقعی ابزار روی یک کلاینت برنامه ریز ساخته می شود، شناسه previewId که به صورت یک اثر انگشت بی حالت از نام ابزار، شناسه فروشگاه و آرگومان ها محاسبه می شود و تایید یک درخواست متفاوت را رد می کند، و یک گزارش ممیزی با قالب JSON که تصمیم ها را ثبت می کند و نتایج خواندن را ثبت نمی کند. این سازوکارها با سه ریشه خطر «عاملیت بیش از حد» در فهرست OWASP تطبیق داده شده اند. در بخش بحث، محدودیت های طرح، از جمله این که شناسه پیش نمایش به محتوای درخواست گره می خورد و نه به وضعیت فروشگاه، بررسی و یک بررسی پیش شرط به عنوان کار آینده پیشنهاد می شود.

کلیدواژه ها: عامل هوش مصنوعی، Model Context Protocol، ووکامرس، امنیت ابزار، انسان در حلقه، گزارش ممیزی، عاملیت بیش از حد

_Abstract

The Model Context Protocol (MCP) makes it straightforward to connect agents built on large language models to operational systems such as online stores. Read access and write access, however, carry very different risks: an agent that can change a price, complete an order, or record a refund acts directly on real customers' data and money. This paper describes and analyzes the design of the write tools in woocommerce-mcp, an open-source MCP server for operating WooCommerce stores, which in version 0.4.0 exposes 47 tools, 28 reads and 19 writes. The design rests on a read-only default per store; a two-step preview and confirm cycle in which the preview is produced by running the real tool code against a planning client; a previewId, a stateless fingerprint of the tool name, store id and canonicalized arguments that causes a confirmation with different arguments to be refused; and a JSON Lines audit log that records decisions but not read results. The mechanisms are mapped to the three root causes of Excessive Agency in the OWASP Top 10 for LLM Applications. The discussion states the limitations openly, in particular that the preview id binds the request and not the store state, and proposes a precondition check as future work.

Keywords: AI agents, Model Context Protocol, WooCommerce, tool safety, human in the loop, audit logging, excessive agency

_{1. مقدمه}

پروتکل Model Context Protocol یک قرارداد باز برای ارتباط میان برنامه های میزبان مدل زبانی و سرورهایی است که «ابزار»، «منبع» و «پرامپت» در اختیار مدل می گذارند [1]. در این قرارداد، ابزار تابعی است که مدل می تواند آن را فراخوانی کند و نتیجه آن را در ادامه استدلال خود به کار ببرد [2]. همین سادگی باعث شده است که اتصال یک عامل به سامانه ای مانند فروشگاه ووکامرس از نظر فنی کار دشواری نباشد: رابط REST ووکامرس مستند است [3] و یک سرور MCP می تواند هر نقطه پایانی آن را در قالب یک ابزار عرضه کند.

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

این مقاله تجربه طراحی woocommerce-mcp را گزارش می کند [9] و نسخه گسترش یافته و علمی تر یادداشت انگلیسی نویسنده درباره همین موضوع است [11]. این سرور متن باز با مجوز MIT منتشر شده و در نسخه 0.4.0 دارای 47 ابزار، شامل 28 ابزار خواندنی و 19 ابزار نوشتنی، است. تمرکز مقاله بر 19 ابزار نوشتنی و تصمیم های طراحی پیرامون آن هاست. سهم این مقاله سه بخش دارد: (الف) توصیف یک الگوی عملی پیش نمایش، تایید و ثبت برای ابزارهای نوشتنی MCP، (ب) معرفی یک سازوکار بی حالت برای گره زدن تایید به محتوای پیش نمایش، و (ج) تحلیل صادقانه تضمین ها و محدودیت های این طرح.

_{2. بیان مسئله}

مسئله را می توان این گونه صورت بندی کرد: یک عامل مبتنی بر مدل زبانی از طریق یک سرور MCP به یک یا چند فروشگاه زنده متصل است. یک انسان، مثلا مدیر فروشگاه، به عامل دستور می دهد و انتظار دارد تغییرات تنها با آگاهی و تایید او انجام شوند. هدف طراحی ابزارهایی است که سه ویژگی داشته باشند:

1. حداقل دامنه اثر: هیچ تغییری بدون تصمیم صریح مالک فروشگاه ممکن نباشد و سطح دسترسی برای هر فروشگاه جداگانه تعیین شود.
2. تطابق تایید با محتوا: آنچه اعمال می شود همان چیزی باشد که انسان دیده و تایید کرده است.
3. قابلیت ممیزی: پس از وقوع، بتوان مشخص کرد چه چیزی تلاش شد، چه کسی آن را درخواست کرد و نتیجه چه بود، بدون این که داده های مشتریان در گزارش انباشته شوند.

مشخصه MCP در بخش ابزارها تصریح می کند که برای اعتماد و ایمنی، همواره باید انسانی در حلقه باشد که بتواند فراخوانی ابزار را رد کند [2]. این توصیه در سطح برنامه میزبان مطرح شده است. پرسش این مقاله آن است که خود سرور، مستقل از رفتار میزبان، چه سهمی در تحقق این اصل می تواند داشته باشد.

_{3. پیشینه و کارهای مرتبط}

Model Context Protocol. مشخصه MCP قالب پیام ها، چرخه عمر اتصال، و انواع قابلیت های سرور را تعریف می کند [1]. در بخش ابزارها، علاوه بر لزوم حضور انسان در حلقه، بر نمایش روشن ابزارهای در دسترس و درخواست تایید برای عملیات حساس از سوی برنامه میزبان تاکید شده است [2]. این مشخصه سازوکار مشخصی برای پیش نمایش یا گره زدن تایید به محتوای فراخوانی در سطح پروتکل تعریف نمی کند و این کار را به پیاده سازی ها می سپارد.

عاملیت بیش از حد. پروژه OWASP در فهرست ده خطر مهم برنامه های مبتنی بر مدل زبانی [5]، خطر LLM06:2025 را «عاملیت بیش از حد» (Excessive Agency) نام گذاری کرده است [4]. بر اساس این منبع، ریشه این خطر در سه عامل است: کارکرد بیش از حد (ابزارهایی بیش از نیاز کار)، مجوز بیش از حد (دسترسی بیش از نیاز به سامانه های پایین دستی) و خودمختاری بیش از حد (انجام اقدامات پرپیامد بدون تایید مستقل). همین منبع راهکارهایی مانند محدود کردن ابزارها، اعمال اصل حداقل دسترسی و الزام به تایید انسانی برای اقدامات پرپیامد را پیشنهاد می کند. طرح ارائه شده در این مقاله را می توان یک پیاده سازی مشخص از این راهکارها برای حوزه تجارت الکترونیک دانست.

احراز هویت و مجوز. برای دسترسی راه دور، سرور از دو استاندارد IETF بهره می برد: بررسی وضعیت توکن در OAuth 2.0 (RFC 7662) [6] و فراداده منبع محافظت شده OAuth 2.0 (RFC 9728) [7] که کلاینت های MCP از آن برای یافتن سرور مجوز استفاده می کنند.

رابط ووکامرس. همه عملیات از طریق رابط REST ووکامرس انجام می شود [3]. بنابراین هر ابزار نوشتنی در نهایت به یک درخواست HTTP با روش و مسیر مشخص تبدیل می شود. این ویژگی امکان نمایش دقیق «درخواستی که ارسال خواهد شد» را فراهم می کند و پایه سازوکار پیش نمایش است.

_{4. روش و طراحی}

4.1. مدل تهدید

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

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

خارج از دامنه این طرح: به خطر افتادن میزبان یا کلاینت MCP، به خطر افتادن خود سرور ووکامرس، و تغییرات همزمانی که انسان یا سامانه دیگری مستقیما در فروشگاه اعمال می کند (این مورد در بخش 6 بررسی می شود).

4.2. حالت پیش فرض فقط خواندنی (پاسخ به ت1 و ت3)

هر فروشگاه تا زمانی که صریحا خلاف آن تنظیم نشود فقط خواندنی است. در حالت تک فروشگاه این کار با WOOCOMMERCE_READ_ONLY=false و در حالت چند فروشگاهی با readOnly: false در ورودی هر فروشگاه انجام می شود. در غیر این صورت، ابزارهای نوشتنی پیش از هر ارتباطی با فروشگاه با خطای read_only متوقف می شوند و حتی اجرای آزمایشی نیز رد می شود. انگیزه این پیش فرض آن است که رایج ترین کاربرد اولیه یک عامل فروشگاهی گزارش گیری است و به دسترسی نوشتنی نیازی ندارد.

افزون بر این، فهرست ابزارهای مجاز و ممنوع (WOOCOMMERCE_TOOLS_ALLOW و WOOCOMMERCE_TOOLS_DENY) نام یا الگو می پذیرند. فهرست ممنوع بر فهرست مجاز اولویت دارد و الگویی که با هیچ ابزاری منطبق نشود خطای پیکربندی محسوب می شود، بنابراین یک اشتباه تایپی هنگام راه اندازی آشکار می شود و نه به صورت بی صدا. هر فروشگاه نیز می تواند allowTools و denyTools اختصاصی داشته باشد که در هر فراخوانی بررسی می شوند. ابزار پنهان شده اساسا در فهرست ابزارها نمایش داده نمی شود.

4.3. چرخه پیش نمایش و تایید (پاسخ به ت1)

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

{

 "status": "confirmation_required",

 "store": "default",

 "previewId": "pv_4f1c9a2e7b3d0856",

 "message": "The change was NOT applied. Review the request below with the user, then call this tool again with the same arguments, confirm: true, and this previewId.",

 "request": { "method": "PUT", "path": "orders/1015", "query": {}, "body": { "status": "completed" } }

}

تغییر تنها زمانی اعمال می شود که ابزار با همان آرگومان ها و confirm: true دوباره فراخوانی شود. پارامتر dryRun: true نیز همیشه فقط پیش نمایش تولید می کند، حتی اگر الزام تایید غیرفعال شده باشد.

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

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

4.4. گره زدن تایید به پیش نمایش با previewId (پاسخ به ت2)

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

هر پیش نمایش اکنون یک previewId دارد که به این صورت تعریف می شود:

previewId = "pv_" + hex(SHA-256(tool + "\n" + store + "\n" + canonicalJson(args)))[0:16]

در این رابطه، canonicalJson آرگومان ها را با کلیدهای مرتب شده و حذف اعضای تعریف نشده سریال سازی می کند تا ترتیب کلیدها در نتیجه اثری نداشته باشد. تابع درهم ساز SHA-256 طبق استاندارد FIPS 180-4 تعریف شده است [8]. فراخوانی تایید می تواند این شناسه را بازگرداند. سرور شناسه را از ابزار، فروشگاه و آرگومان های خود فراخوانی تایید دوباره محاسبه می کند و در صورت عدم تطابق، نوشتن با خطای preview_mismatch رد می شود و هیچ درخواستی به فروشگاه ارسال نمی شود. در این حالت، پیش نمایش و نوشتن یک شناسه مشترک در گزارش ممیزی خواهند داشت.

دقت در بیان ماهیت این شناسه ضروری است. previewId یک اثر انگشت است، نه یک راز و نه یک توکن یک بار مصرف. سرور هیچ سابقه ای از پیش نمایش های صادر شده نگه نمی دارد، بنابراین بررسی نمی کند که پیش نمایش واقعا درخواست شده باشد، چه مدت از آن گذشته باشد یا قبلا استفاده شده باشد. آرگومان های یکسان همیشه شناسه یکسانی تولید می کنند، پس شناسه پس از راه اندازی دوباره سرور معتبر می ماند و میان نشست های HTTP نیز کار می کند. استفاده از آن نیز اختیاری است: فراخوانی تایید بدون شناسه همچنان کار می کند و سطر ممیزی آن شناسه ای را که آرگومان هایش تولید می کردند ثبت می کند.

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

4.5. گزارش ممیزی (پاسخ به ت5 و الزام ممیزی)

با تنظیم WOOCOMMERCE_AUDIT_LOG به یک مسیر فایل یا stderr، هر تلاش برای نوشتن به یک سطر JSON با یکی از پنج نتیجه زیر تبدیل می شود: applied، dry_run، confirmation_required، refused و failed. هر سطر شامل زمان، نام ابزار، فروشگاه، آرگومان ها، کلاینت احراز هویت شده (در صورت وجود)، روش و مسیر درخواست برای پیش نمایش ها، کد خطا در صورت بروز خطا، و previewId است. اگر فراخواننده previewId فرستاده باشد، فیلد previewMatch نیز ثبت می شود.

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

4.6. جداسازی چند فروشگاهی (پاسخ به ت1 و ت3)

هر فروشگاه کلیدهای دسترسی، کلید فقط خواندنی و فهرست ابزارهای خود را دارد. بنابراین یک سرور می تواند هم زمان روی فروشگاه اصلی فقط خواندنی و روی نسخه آزمایشی قابل نوشتن باشد. مستندات پروژه همچنین توصیه می کند برای فروشگاه های فقط خواندنی از کلید ووکامرس با سطح Read استفاده شود، تا محدودیت در دو لایه مستقل (سرور و خود فروشگاه) اعمال شود.

4.7. دسترسی راه دور و سطح مجوز (پاسخ به ت4)

سرور به صورت محلی روی stdio اجرا می شود. در حالت HTTP، از توکن های ثابت حامل یا بررسی وضعیت توکن در OAuth 2.0 [6] پشتیبانی می کند. توکن های کامل دامنه woocommerce:write و توکن های خواندنی تنها دامنه woocommerce:read را دارند و هرگز نمی توانند فروشگاه را تغییر دهند. بدون احراز هویت، سرور HTTP از اتصال به نشانی ای غیر از loopback خودداری می کند.

بر اساس مستندات امنیتی پروژه، هر نوشتن به ترتیب از چهار بررسی عبور می کند: داشتن دامنه woocommerce:write در توکن (در HTTP با احراز هویت)، فقط خواندنی نبودن فروشگاه، وجود confirm: true (مگر آن که الزام تایید غیرفعال شده باشد)، و مجوز نوشتن کلید ووکامرس.

4.8. تطبیق با خطر عاملیت بیش از حد

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

مجوز بیش از حد: حالت پیش فرض فقط خواندنی، دامنه های woocommerce:read و woocommerce:write، و توصیه به کلید Read.

خودمختاری بیش از حد: چرخه پیش نمایش و تایید، previewId و رد با preview_mismatch، و گزارش ممیزی.

_{5. پیاده سازی}

سرور با TypeScript برای Node.js نسخه 20 و بالاتر نوشته شده و از کتابخانه های رسمی MCP برای سرور استفاده می کند [9]. منطق مشترک همه ابزارهای نوشتنی در یک لایه ثبت ابزار (src/tools/registry.ts) متمرکز است و هر ابزار تنها کار اصلی خود را پیاده سازی می کند. ترتیب پردازش یک فراخوانی نوشتنی در این لایه چنین است: تعیین فروشگاه، بررسی مجاز بودن ابزار برای آن فروشگاه، بررسی دامنه توکن، محاسبه previewId، بررسی حالت فقط خواندنی، و سپس یا اجرای واقعی (در صورت تایید و تطابق شناسه) یا اجرا روی کلاینت برنامه ریز برای تولید پیش نمایش. در هر یک از این مسیرها، نتیجه با یکی از پنج وضعیت تعریف شده در گزارش ممیزی ثبت می شود و خطاهای رد شده (فقط خواندنی، نبود مجوز، ابزار غیرفعال و عدم تطابق پیش نمایش) با وضعیت refused از سایر خطاها جدا می شوند.

محاسبه شناسه در ماژول src/tools/preview-id.ts با ماژول node:crypto انجام می شود. کلاینت برنامه ریز، به جای ارسال درخواست نوشتنی، یک استثنای مخصوص می سازد که درخواست برنامه ریزی شده را در خود دارد. لایه ثبت ابزار این استثنا را دریافت و به پاسخ پیش نمایش تبدیل می کند. اگر اجرای ابزار بدون نیاز به نوشتن پایان یابد، برای نمونه در یک مجموعه تغییرات خالی، پاسخ با وضعیت no_change برگردانده می شود. در پیش نمایش ها، رازهای پیکربندی شده مانند راز وب هوک پیش از نمایش پنهان می شوند.

سایر محدودیت های ایمنی در سطح ابزارها پیاده سازی شده اند:

• محدودیت عملیات گروهی: به روزرسانی گروهی محصولات و تغییر قیمت حداکثر 100 محصول در هر فراخوانی را می پذیرند. تغییر قیمت ابتدا قیمت های فعلی را می خواند و قیمت قدیم و جدید هر محصول را برمی گرداند.
• بازپرداخت: ابزار woocommerce_create_refund به صورت پیش فرض یک بازپرداخت دستی ثبت می کند و پولی جابه جا نمی کند. بازگرداندن وجه از طریق درگاه پرداخت به apiRefund: true صریح نیاز دارد و توضیح ابزار به عامل اعلام می کند که بازپرداخت قابل بازگشت نیست.
• پنهان سازی داده شخصی: با WOOCOMMERCE_REDACT_PII=true یا redactPii برای هر فروشگاه، نام ها، شرکت ها، نشانی ها، کدهای پستی، نام های کاربری، نشانی های IP و مشخصات مرورگر به [redacted] تبدیل می شوند. از ایمیل تنها نویسه نخست و دامنه، و از تلفن تنها دو رقم آخر باقی می ماند. شهر، استان و کشور حفظ می شوند تا گزارش ها و دسته بندی مشتریان کار کنند. یک فراخوانی نمی تواند پنهان سازی را برای فروشگاهی که آن را فعال کرده است خاموش کند.

بسته از طریق npm با فرمان npx -y @sadrmanesh/woocommerce-mcp و به صورت ایمیج Docker در دسترس است و در MCP Registry رسمی ثبت شده است. مستندات طراحی نوشتن امن در [10] آمده است.

_{6. تحلیل و بحث}

6.1. آنچه طرح تضمین می کند

با فرض درستی پیکربندی، طرح این ویژگی ها را فراهم می کند: (1) در فروشگاه فقط خواندنی هیچ درخواست نوشتنی به فروشگاه نمی رسد، (2) در حالت پیش فرض، هیچ نوشتنی بدون یک فراخوانی دوم با confirm: true اعمال نمی شود، (3) اگر فراخوانی تایید previewId را همراه داشته باشد، آرگومان های اعمال شده دقیقا همان آرگومان های پیش نمایش هستند، و (4) هر تلاش نوشتن، از جمله تلاش های رد شده و ناموفق، در صورت فعال بودن گزارش ممیزی ثبت می شود.

6.2. محدودیت ها

گره خوردن به درخواست و وضعیت فروشگاه. از نسخه 0.5.0، ابزارهایی که برای محاسبه تغییر از فروشگاه می خوانند، از رکوردهای خوانده شده (قیمت، موجودی و date_modified) اثر انگشت می گیرند و آن را در previewId می گذارند. هنگام تایید، سرور همان رکوردها را دوباره می خواند و اگر چیزی تغییر کرده باشد، با خطای stale_preview نوشتن را رد می کند و چیزی به فروشگاه فرستاده نمی شود. این یک قفل نیست، چون REST API ووکامرس نوشتن شرطی ندارد، و فقط داده هایی را پوشش می دهد که تغییر به آنها وابسته است.

نبود حالت. چون سرور سابقه پیش نمایش ها را نگه نمی دارد، نمی تواند ثابت کند که پیش نمایشی واقعا به انسان نمایش داده شده است. عاملی که آرگومان ها را می داند می تواند شناسه را خود محاسبه کند یا مستقیما با confirm: true و بدون شناسه فراخوانی کند. بنابراین previewId در برابر عامل متخاصم تضمینی نمی دهد و نقش آن تشخیص ناهمخوانی و ایجاد پیوند قابل ممیزی است. حضور واقعی انسان در حلقه همچنان به برنامه میزبان وابسته است [2].

گزارش ممیزی اختیاری. گزارش ممیزی تا زمانی که WOOCOMMERCE_AUDIT_LOG تنظیم نشود خاموش است. این انتخاب راه اندازی را ساده می کند، اما برای فروشگاهی که نوشتن در آن فعال است، فراموش کردن آن آسان است. همچنین شکست در نوشتن گزارش، فراخوانی را متوقف نمی کند، پس کامل بودن گزارش تضمین نمی شود.

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

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

6.3. درس های طراحی

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

_{7. نتیجه گیری و کارهای آینده}

این مقاله نشان داد که سرور MCP، مستقل از برنامه میزبان، می تواند بخش مهمی از ایمنی ابزارهای نوشتنی را بر عهده بگیرد: با بسته نگه داشتن پیش فرض دسترسی، با جدا کردن پیش نمایش از اجرا، با گره زدن تایید به محتوای پیش نمایش، و با ثبت تصمیم ها در یک گزارش قابل خواندن. سازوکار previewId نمونه ای از یک راه حل بی حالت است که شکاف میان آنچه انسان دیده و آنچه اعمال می شود را بدون افزودن ذخیره سازی می بندد، و محدودیت های آن به صراحت قابل بیان است.

کارهای آینده عبارت اند از:

1. حالت با حالت (stateful) اختیاری: پیش نمایش هایی که منقضی می شوند و تنها یک بار قابل استفاده اند، برای تیم هایی که به این تضمین نیاز دارند و هزینه ذخیره سازی آن را می پذیرند.
2. حل تغییرات نسبی در زمان پیش نمایش: دستوری مانند «افزایش ده درصدی» در زمان پیش نمایش به مقدار مطلق، مانند «تغییر قیمت از 20.00 به 22.00»، تبدیل شود تا پیش نمایش دقیقا همان چیزی را نشان دهد که نوشته خواهد شد.
3. بررسی پیش شرط: بررسی پیش شرط در نسخه 0.5.0 پیاده سازی شد. گام بعدی یک حالت اختیاری با نگهداری وضعیت است که در آن پیش نمایش ها منقضی می شوند و فقط یک بار قابل استفاده اند.
4. سخت تر کردن فراموشی گزارش ممیزی در فروشگاه هایی که نوشتن در آن ها فعال است.
5. ارزیابی تجربی رفتار عامل ها در برابر این سازوکارها، از جمله سناریوهای تزریق دستور از طریق داده های فروشگاه.

_منابع

[1] Model Context Protocol. Specification, version 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25

[2] Model Context Protocol. Specification, version 2025-11-25: Server features, Tools. https://modelcontextprotocol.io/specification/2025-11-25/server/tools

[3] WooCommerce. WooCommerce REST API Documentation, WP REST API v3. https://woocommerce.github.io/woocommerce-rest-api-docs/

[4] OWASP Gen AI Security Project. (2025). LLM06:2025 Excessive Agency. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

[5] OWASP Gen AI Security Project. (2025). OWASP Top 10 for LLM Applications 2025. https://genai.owasp.org/llm-top-10/

[6] Richer, J. (Ed.). (2015). OAuth 2.0 Token Introspection (RFC 7662). IETF. https://www.rfc-editor.org/rfc/rfc7662

[7] Jones, M. B., Hunt, P., & Parecki, A. (2025). OAuth 2.0 Protected Resource Metadata (RFC 9728). IETF. https://www.rfc-editor.org/rfc/rfc9728

[8] National Institute of Standards and Technology. (2015). Secure Hash Standard (SHS) (FIPS PUB 180-4). https://csrc.nist.gov/pubs/fips/180-4/upd1/final

[9] Sadrmanesh, N. (2026). woocommerce-mcp (Version 0.4.0) [Source code]. GitHub. https://github.com/sadrmanesh/woocommerce-mcp

[10] Sadrmanesh, N. (2026). woocommerce-mcp documentation: Safe writes. https://sadrmanesh.github.io/woocommerce-mcp/safe-writes/

[11] Sadrmanesh, N. (2026). Preview, confirm, audit: designing safe write tools for AI agents on a live store. LinkedIn. https://www.linkedin.com/pulse/preview-confirm-audit-designing-safe-write-tools-ai-live-sadrmanesh-jwy5f/