Agent Authority Matrix

داشتن یک tool به معنی داشتن اختیار استفاده از آن نیست. یک support agent ممکن است از نظر فنی بتواند سفارش را بخواند، متن پاسخ را draft کند، refund بزند یا حتی رکورد production را تغییر دهد؛ اما این چهار کار یک سطح اختیار ندارند. اگر همه‌ی آن‌ها زیر یک برچسب مبهم مثل «admin agent» قرار بگیرند، capability به‌اشتباه جای authority می‌نشیند و مرز read، recommend، draft و execute از بین می‌رود.

خروجی این درس Agent Authority Matrix & Approval Gate v1 است: ماتریسی که برای هر agent و هر action مشخص می‌کند روی چه subject/resource/environmentی چه سطح اختیاری دارد، آیا action مجاز است، آیا approval لازم است، approver چه نقشی دارد، کدام guardrail و tool contract اعمال می‌شود، حالت deny-default چیست، escalation کجا می‌رود و تصمیم چگونه audit می‌شود.

قاعده‌ی اصلی: اگر ماتریس نتواند permission را اثبات کند، action حساس باید fail closed شود؛ «شاید مجاز باشد» معادل «مجاز است» نیست.

مرز درس و مسیر یادگیری

AGN-004 فقط مالک authority matrix و approval gate است. AGN-003 قرارداد typed، version و handoff interface را مالک است؛ AGN-005 memory boundary را. این درس نه standing authority صادر می‌کند، نه داده‌ی واقعی کاربر را نگه می‌دارد، نه action production واقعی انجام می‌دهد. ما فقط از evidence مصنوعی و آفلاین برای ساختن یک تصمیم قابل‌ممیزی استفاده می‌کنیم.

پیش‌نیاز سخت AGN-001 است: learner باید مرز agent و مسئولیت انسانی را بفهمد. AGN-003 پیش‌نیاز نرم است: داشتن stable identity و tool contract کمک می‌کند authority row به چیزی قابل‌ردیابی وصل شود. اگر contract ناقص باشد، نتیجه را HOLD/UNKNOWN می‌کنیم؛ authority را حدس نمی‌زنیم.

مدل ذهنی: capability ≠ authority

برای هر درخواست، این زنجیره را طی کنید:

agent + requested action → action/scope/environment lookup → deny-default → guardrail → approval if required → allow | deny | escalate → audit

سه لایه را از هم جدا نگه دارید:

1. Capability: سیستم از نظر فنی چه tool یا functionی را می‌تواند صدا بزند؟
2. Authority: سازمان به این agent برای این action، روی این subject/resource و در این environment چه اختیاری داده است؟
3. Approval: حتی اگر action در دامنه‌ی اختیار است، آیا اجرای همین نمونه نیازمند تصمیم انسانی است؟

Authority را row-level ببینید، نه role-level. support-agent ممکن است روی order.read اختیار مستقیم داشته باشد، روی refund.execute <= 100 فقط با approval، و روی account.production_mutate هیچ اختیاری نداشته باشد. یک نام واحد برای agent نباید این تفاوت‌ها را محو کند.

حالت‌های HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, BLOCKED شکست مدل نیستند؛ این‌ها stateهای سالمی هستند که جلوی success جعلی را می‌گیرند.

مبانی: mechanism بیرونی در برابر policy محلی

مستندات فعلی OpenAI Agents SDK نشان می‌دهد که tool می‌تواند needs_approval داشته باشد؛ در این حالت run متوقف می‌شود و pending approval برای approve/reject بیرون می‌آید. همین SDK برای function toolها tool guardrail دارد که می‌تواند call را پیش از اجرا بررسی و مسدود کند یا خروجی را بعد از اجرا کنترل کند. OpenAI Model Spec نیز chain of command را صریح می‌کند: صرفِ وجود یک instruction به آن اختیار مساوی با instruction سطح بالاتر نمی‌دهد.

این‌ها FACT درباره‌ی mechanism یا مدل رفتاری یک vendor هستند. این FACTها نمی‌گویند در کسب‌وکار شما چه کسی مجاز است refund را approve کند، سقف refund چقدر است یا کدام محیط production محسوب می‌شود. آن بخش DESIGN/Policy محلی MAKNOW است.

پس:

• approval primitive ابزار اجرای policy است، نه خود policy؛
• guardrail enforcement hook است، نه منبع authority؛
• chain-of-command مثال مفیدی برای تفکیک authority است، نه استاندارد عمومی RBAC سازمان شما.

توضیح عمیق Matrix و Gateها

قرارداد working ما ۲۰ فیلد دارد:

agent_id, action_class, verb, subject_scope, resource_scope, environment_scope, data_classification, authority_level, allowed, approval_required, approver_role, guardrail_ref, tool_contract_ref, exception_policy_ref, deny_default, escalation_path, decision_state, decision_reason, audit_ref, review_due.

Gate 1 — هویت action

action_class و verb باید دقیق باشند. draft با execute یکی نیست. تغییر draft به execute بدون بازبینی authority یک mutation مهم است.

Gate 2 — Subject / Resource / Environment

Permission باید روی هر سه dimension match شود. authority برای staging خودبه‌خود به production منتقل نمی‌شود. همین‌طور authority روی customer_owned_order به all_accounts گسترش پیدا نمی‌کند.

Gate 3 — Authority level

سطوح read / recommend / draft / execute را جدا نگه دارید. READ_RECOMMEND اجازه‌ی side effect نمی‌سازد. اگر action بالاتر از authority level باشد، تصمیم باید deny یا hold شود.

Gate 4 — Allowed + deny-default

allowed=true فقط وقتی معتبر است که row کامل و قابل‌ردیابی باشد. نبود row، نبود owner یا نبود evidence باید از مسیر deny-default به HOLD/DENY برود، نه allow ضمنی.

Gate 5 — Approval gate

اگر approval_required=true است، approver_role نباید خالی باشد و approval باید برای همان action/scope ثبت شود. approval مبهم مثل «یک نفر تأیید کرد» evidence کافی نیست.

Gate 6 — Guardrail و tool contract

Guardrail می‌تواند ورودی خطرناک را متوقف کند و tool contract مرز پارامترها را تعریف کند؛ اما هیچ‌کدام authority را ایجاد نمی‌کنند. اگر tool جدید bulk_update دامنه‌ای وسیع‌تر از subject_scope موجود می‌پذیرد، authority باید recompute شود.

Gate 7 — Exception و escalation

Exception باید bounded و قابل‌ممیزی باشد. اگر exception policy وجود ندارد، agent نباید خودش مسیر میان‌بُر بسازد. escalation مشخص می‌کند UNKNOWN، DISPUTED یا high-impact request به چه roleای می‌رود.

Gate 8 — Audit و review

هر تصمیم باید audit_ref داشته باشد و در صورت policy/tool/environment change دوباره review شود. authority یک property ابدی نیست.

مثال‌های حل‌شده

۱. Read سفارش

support-agent برای order.read روی سفارش متعلق به همان customer در production، authority سطح READ دارد. action side effect ندارد، approval لازم نیست و guardrail هویت/tenant boundary را چک می‌کند. نتیجه ALLOW است.

۲. Draft پاسخ مشتری

همان agent می‌تواند response را draft کند، ولی ارسال نهایی در scope این row نیست. draft مجاز است؛ اگر verb به send یا execute تغییر کند، row قبلی oracle نیست.

۳. Refund محدود

برای refund.execute تا سقف مشخص، row می‌تواند allowed=true باشد اما approval_required=true. تا وقتی support_lead همان call را approve نکرده، state نهایی APPROVAL_REQUIRED است، نه EXECUTED.

۴. Mutation نامعتبر: staging → production

اگر authority row فقط staging را پوشش دهد و request به production تغییر کند، environment mismatch است. داشتن همان tool یا همان agent هیچ authority جدیدی ایجاد نمی‌کند. تصمیم DENY_ENVIRONMENT_SCOPE یا bounded HOLD است.

۵. Mutation نامعتبر: draft → execute

اگر action از draft به execute تغییر کند ولی approval_required همچنان false بماند، matrix inconsistent است. باید authority و approval policy دوباره محاسبه شود.

۶. Transfer: bulk update جدید

اضافه‌شدن bulk_update را به‌عنوان capability جدید ثبت کنید. چون accepted parameters می‌تواند از subject/resource scope قبلی وسیع‌تر باشد، تا recompute کامل، state باید HOLD_AUTHORITY_RECOMPUTE باشد.

Failure modeهای رایج

• Tool-list authorization: «tool در لیست agent هست، پس استفاده از آن مجاز است.»
• Role collapse: read/recommend/draft/execute زیر یک role کلی ادغام می‌شوند.
• Environment inheritance: staging permission به production کپی می‌شود.
• Subject creep: authority محدود به یک customer به مجموعه‌ی وسیع‌تری تعمیم داده می‌شود.
• Approval theater: approval_required=true است ولی approver، call identity یا audit ref مشخص نیست.
• Guardrail-as-authority: چون guardrail داریم، action مجاز فرض می‌شود.
• Missing-row allow: نبود row به جای fail-closed به allow تبدیل می‌شود.
• Exception leak: exception موقت تبدیل به standing authority می‌شود.
• Tool expansion: tool جدید دامنه‌ی ورودی بزرگ‌تری دارد اما matrix بازبینی نمی‌شود.
• Stale authority: tool/policy/environment عوض شده ولی review_due و audit evidence همان قبلی مانده است.

گزینه‌ها و Trade-offها

Matrix بسیار ریزدانه کنترل بهتر می‌دهد، اما نگهداری و review بیشتری می‌خواهد. Matrix خیلی درشت ساده‌تر است، اما احتمال privilege creep را بالا می‌برد. Approval انسانی برای actionهای حساس ریسک را پایین می‌آورد، ولی latency و بار عملیاتی ایجاد می‌کند. Guardrail خودکار سریع است، اما فقط همان ruleهایی را enforce می‌کند که صریحاً پیاده شده‌اند.

اصل تصمیم این نیست که «همه‌چیز approval بخواهد». اصل این است که هزینه‌ی approval در برابر impact action سنجیده شود و هیچ actionی فراتر از evidence موجود allow نشود. read کم‌ریسک ممکن است مستقیم باشد؛ execute مالی یا mutation production معمولاً به evidence و approval قوی‌تر نیاز دارد.

پل مسیر باتجربه

برای هر call حساس هشت سؤال کافی است:

1. agent دقیقاً کدام stable identity است؟
2. action و verb چیست؟
3. subject و resource دقیقاً کدام‌اند؟
4. environment چیست؟
5. authority level این row چیست؟
6. approval لازم است؟ اگر بله، چه roleای؟
7. guardrail/tool contract چه چیزی را enforce می‌کند و چه چیزی را نمی‌کند؟
8. اگر evidence کامل نیست، deny/hold/escalate کدام است و audit کجا ثبت می‌شود؟

اگر پاسخ ۲ تا ۶ با row match نمی‌کند، capability را به permission تبدیل نکنید.

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

ابتدا جدول authority را مرور کنید. بعد Lab آفلاین را اجرا کنید:

python -B lab/AGN-004-LAB1/learner/run_checks.py

در تمرین مستقل، baseline را با چهار mutation تغییر دهید: environment را production کنید، draft را execute کنید، approver را حذف کنید و tool جدید bulk_update اضافه کنید. برای هر مورد فقط fieldهای تغییرکرده را پیدا نکنید؛ تصمیم را از نو محاسبه کنید و نشان دهید چرا row قبلی دیگر permission را اثبات نمی‌کند.

شواهد Verification

قبولی یعنی تصمیم از evidence آشکار و deterministic بازتولید شود. Lab باید حداقل این موارد را تشخیص دهد:

• staging-only authority در برابر production request؛
• draft→execute بدون approval recompute؛
• approval_required=true با approver خالی؛
• tool جدید با scope وسیع‌تر از authority موجود؛
• evidence decisive گمشده که باید UNKNOWN/HOLD بدهد؛
• transfer که baseline decision را بدون recompute کپی می‌کند.

هیچ call شبکه، API key، production credential یا داده‌ی واقعی لازم نیست. Final state باید از ruleهای قابل‌مشاهده حاصل شود.

Assessment و Transfer

در transfer، همان support agent به staging منتقل می‌شود و tool جدید bulk_update می‌گیرد. learner باید برای هر action، subject و environment matrix را دوباره بسازد. staging بودن environment به معنی «هر toolی مجاز است» نیست؛ tool جدید باید tool contract، subject scope، authority level و approval requirement مخصوص خودش را داشته باشد.

جواب کامل باید بگوید چه چیزی ALLOW، چه چیزی DENY، چه چیزی APPROVAL_REQUIRED و چه چیزی HOLD/UNKNOWN است، و برای هر state decision_reason, audit_ref و escalation قابل‌ردیابی ارائه کند.

منابع و تازگی

• OpenAI Agents SDK — Human-in-the-loop: pause/approve/reject برای tool callهای نیازمند approval.
• OpenAI Agents SDK — Guardrails: input/output و function-tool guardrails به‌عنوان enforcement hook.
• OpenAI Model Spec (2025-04-11): chain of command و levels of authority در محدوده‌ی رفتار مدل OpenAI.
• Frozen Lesson Bible lesson://AGN-004: authority محلی MAKNOW برای fieldها، stateها و fail-closed policy.

منابع SDK در 2026-09-14 دوباره بررسی شدند و تا 2026-10-18 یا زودتر در صورت تغییر مادی باید recheck شوند. Model Spec در boundary خودش استفاده شده و به‌عنوان enterprise authorization standard معرفی نمی‌شود. این درس هیچ production action واقعی اجرا نمی‌کند.