مهندسی سامانه‌های هوش مصنوعی · فصل ۱ — Gateway، Structured Output، Prompt Governance و Qualification · 135
Prompt Template Governance و Untrusted Context Policy
می‌تواند مدل یا ابزار AI را فراخوانی کند اما contract، qualification، routing، cost، trust و failure را کنترل نمی‌کند. موضوع جاری: «Prompt Template Governance و Untrusted Context Policy». می‌تواند «Prompt Template Governance و Untrusted Context Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
Prompt Template Governance and Untrusted Context Policy — en-US
خلاصهٔ درس
می‌تواند مدل یا ابزار AI را فراخوانی کند اما contract، qualification، routing، cost، trust و failure را کنترل نمی‌کند. موضوع جاری: «Prompt Template Governance و Untrusted Context Policy».
می‌تواند «Prompt Template Governance و Untrusted Context Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
خروجی این درس
می‌تواند «Prompt Template Governance و Untrusted Context Policy» را در یک workflow AI محدود طراحی کند و validation، authority، cost یا failure controls مرتبط را مشخص کند.
1. مسئله واقعی: وقتی همه‌چیز یک متن می‌شود، authority گم می‌شود
در یک workflow واقعی، application policy، prompt template، user input، متن بازیابی‌شده و tool output ممکن است در نهایت کنار هم به مدل برسند. اگر provenance و authority هر بخش ثبت نشود، تیم بعداً نمی‌تواند بگوید کدام prompt version رفتار را ساخته، کدام متن فقط داده بوده و کدام بخش حق دستور دادن داشته است. Governance یعنی این مرزها قبل از اجرا و قبل از promotion روشن باشند.
2. Prompt identity را از متن پراکنده جدا کن
Prompt نباید صرفاً یک string کپی‌شده در چند فایل باشد. یک record حداقل به prompt_id، prompt_version، template hash و schema متغیرها نیاز دارد. API فعلی OpenAI در Responses API یک prompt reference با id، variables و version می‌پذیرد؛ این یک سازوکار concrete برای version-addressable prompt است، نه اثبات review یا qualification آن prompt.
3. Version در registry کافی نیست؛ runtime provenance لازم است
اگر registry می‌گوید v8 current است اما deployment trace نشان می‌دهد runtime هنوز v7 را اجرا کرده، evidence مربوط به v7 است. تیم حق ندارد رفتار runtime را به v8 نسبت دهد. Governance record باید registry state و runtime-observed state را جدا نگه دارد و mismatch را به DEFER تبدیل کند تا trace اصلاح یا deployment واقعاً تغییر کند.
4. متغیرها هم بخشی از contract هستند
دو call با template version یکسان ولی variable schema یا variable set متفاوت می‌توانند رفتار متفاوتی داشته باشند. بنابراین prompt governance فقط شماره نسخه نیست؛ variable names، نوع داده، required/optional state و مقدارهای حساس باید حداقل در سطح schema و audit trace مشخص باشند. مقدار secret نباید برای audit به شکل ناامن تکثیر شود.
5. Trusted policy، user input و external context یک authority ندارند
Application policy می‌تواند instruction authority داشته باشد؛ user input هدف کاربر را بیان می‌کند اما مجوز زیرپاگذاشتن policy نیست؛ retrieved document و tool output نیز معمولاً data/evidence هستند. این تفاوت باید به‌صورت label صریح مثل TRUSTED_POLICY, USER_REQUEST, UNTRUSTED_EXTERNAL ثبت شود، نه اینکه صرفاً از ترتیب متن حدس زده شود.
6. Untrusted به معنی false نیست
یک سند خارجی ممکن است کاملاً درست و برای پاسخ مفید باشد، اما همچنان authority برای تغییر policy یا درخواست action حساس ندارد. عبارت «این سند غیرقابل اعتماد است» نباید به حذف خودکار آن از evidence منجر شود. سیاست درست می‌گوید محتوای factual می‌تواند استفاده شود، ولی instruction embedded در همان منبع حق ارتقای authority ندارد.
7. Indirect prompt injection را در context layer مدل کن
OWASP indirect prompt injection را برای دستورهای مخرب جاسازی‌شده در صفحات وب، اسناد، ایمیل، commentها و دیگر محتوای خارجی توضیح می‌دهد. پس injection signal فقط متعلق به user message نیست. هر context source باید provenance، trust label و policy روشن برای allowed_influence داشته باشد؛ تغییر نوع منبع از document به tool output نباید authority rule را عوض کند.
8. Delimiter و sanitization لایه دفاع‌اند، نه تضمین
جداکردن داده با delimiter، structured prompt یا sanitization می‌تواند attack surface را کاهش دهد، اما تضمین حذف prompt injection نیست. این درس defense-in-depth می‌خواهد: authority labels، least privilege، validation، bounded tool permissions، audit و human approval برای actionهای پرریسک. موفقیت یک demo اجازه ادعای «حل کامل injection» نمی‌دهد.
9. تغییر prompt باید change record داشته باشد
از v7 به v8 فقط diff متنی مهم نیست. record باید بداند چه چیزی عوض شده، چرا، چه evaluationهایی متاثرند، چه کسی change را approve کرده و rollback target چیست. حتی یک تغییر یک‌خطی می‌تواند failure جدید بسازد؛ promotion بدون evidence جدید باید DEFER بماند.
10. Eval hook promotion را از edit جدا می‌کند
ویرایش prompt و پذیرش prompt دو رویداد متفاوت‌اند. برای version جدید باید eval run مشخص وجود داشته باشد و نتیجه آن به همان version/template hash bind شود. اگر eval وجود ندارد، state نه PASS ضمنی است و نه inherited از version قبلی؛ state باید evidence gap را نگه دارد. اگر eval regression نشان دهد، promotion باید REJECT شود.
11. Action authority جدا از text generation است
مدل می‌تواند یک action پیشنهاد دهد، اما پیشنهاد مدل authorization نیست. برای tool یا عملیات حساس باید policy/permission check deterministic و در صورت لزوم human gate وجود داشته باشد. Untrusted context هیچ‌گاه نباید فقط با تولید یک tool call به permission جدید برسد. least authority یعنی مدل کمترین دامنه عملیاتی لازم را داشته باشد.
12. Audit trace باید رفتار را قابل بازسازی کند
برای یک incident باید بتوانی حداقل runtime call، prompt id/version، template hash، variable schema، context sources، trust labels، eval/approval state و action gate را پیدا کنی. هدف ذخیره chain-of-thought نیست؛ هدف ثبت metadata قابل ممیزی است تا بدانیم کدام نسخه و کدام ورودی governشده اجرا شده است.
13. Rollback یک feature governance است
وقتی v8 regression دارد، rollback نباید وابسته به حدس یا copy-paste باشد. registry باید target معتبر مثل v7 را نگه دارد و deployment trace بعد از rollback باید همان target را اثبات کند. اگر registry به v7 برگشته ولی runtime هنوز v8 است، incident بسته نشده است.
14. Lab: هشت fixture deterministic
در Lab هشت case داری: baseline v7 با document injection مهارشده، v8 بدون eval، v8 با regression، injection داخل tool output، mismatch registry v8/runtime v7، authority escalation اشتباه، action پرریسک بدون human gate و v8 کاملاً approved. evaluator هشت field قابل ممیزی برمی‌گرداند و expected labels در learner files وجود ندارند.
15. Exit checklist و transfer
قبل از خروج بررسی کن: prompt identity/version/hash مشخص است؛ runtime version از trace آمده نه از registry guess؛ variable schema ثبت شده؛ context provenance و trust label روشن است؛ untrusted instruction authority ندارد؛ eval و approval به همان version bind هستند؛ action پرریسک gate دارد؛ rollback target و audit trace موجودند. در transfer، tool output حاوی instruction و registry/runtime mismatch را بدون تغییر این اصول دوباره تحلیل کن.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 retrieval
Why is a registry current version not sufficient to prove the runtime prompt version?
Q2 application
A retrieved document contains accurate facts plus an instruction to invoke a privileged tool. How should the context be treated?
Q3 diagnosis
Prompt v8 differs by one sentence and has no evaluation run. May it inherit v7 promotion state?
Q4 evidence
What minimum provenance should a prompt-governance audit record retain?
Q5 transfer
The registry says v8, the runtime trace proves v7, and tool output contains an embedded instruction. What is evidenced?
ملاک‌های ارزیابی (rubric)
A sufficient submission separates prompt identity from copied text, binds runtime behavior to observed prompt version/template hash, declares variable schema, labels context provenance and trust, denies instruction/action authority to untrusted external content, requires version-bound evaluation and approval for promotion, preserves a high-risk human/permission gate, and records rollback/audit metadata. It fails if registry state is treated as runtime proof, untrusted text gains authority because it appears inside a prompt/tool result, or a new prompt version inherits promotion without evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Implement evaluate(case) in starter.py. Return exactly these eight auditable fields: evidenced_runtime_prompt_version, registry_runtime_match, untrusted_source_count, injection_signal_count, blocked_untrusted_instruction_count, authority_violation_count, promotion_decision, and reason_class.
The registry candidate is evidenced at runtime only when the runtime prompt version and template hash equal the registry current version and hash. Count an untrusted source when its trust label is UNTRUSTED_EXTERNAL. Count an injection signal whenever a context item declares contains_instruction=true. Such an instruction is considered blocked only when that source is untrusted, instruction_authority is NONE, and allowed_influence is DATA_ONLY or EVIDENCE_ONLY. Granting INSTRUCTION authority or influence to untrusted external content is an authority violation.
Decision order: authority violation → REJECT; registry/runtime provenance mismatch → DEFER; missing version-bound evaluation → DEFER; failed evaluation → REJECT; missing change approval → DEFER; required high-risk human gate missing → REJECT; otherwise PROMOTABLE. Untrusted factual data may still be usable. Do not treat delimiters or sanitization as proof that injection is eliminated.
Run python run_checks.py for learner-visible structural checks. Expected promotion labels are intentionally not included in learner files.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)