دیدن یک دکمهٔ Approve به معنی امن‌بودن اجرا نیست. **Capability** می‌گوید Agent چه چیزی می‌تواند بخواند یا انجام دهد؛ **approval** می‌گوید انسان برای یک عمل چه رضایتی داده؛ و **OS sandbox** می‌گوید process در سطح سیستم‌عامل به چه فایل، process و شبکه‌ای دسترسی دارد. این سه را جدا کنیم تا local یا cloud agent، secret، egress و budget را واقعاً محدود کنیم.
## اهداف
پس از درس می‌توانی capability، approval و sandbox را با مثال تفکیک کنی؛ profile امنی برای local/cloud بنویسی؛ lifecycle یک secret را از صدور تا revoke ثبت کنی؛ network egress و read-only default را اعمال کنی؛ و budget و reversible action را به stop condition تبدیل کنی.
## جایگاه در چرخه
درس ۳۰ server و tool را allowlist کرد. اکنون در `Implement → Verify` مرز اجرای آن tool و Agent را طراحی می‌کنیم. این درس آخرین gate فصل ۸ است: Skill و hook بدون permission profile کافی نیستند، و approval انسانی بدون isolation یا rollback ممکن است فقط یک تشریفات باشد.
## سه مفهوم غیرقابل‌جایگزین
**Capability** مجموعهٔ مجوز عملی است: read فایل‌های repository، اجرای `vitest`، دسترسی به `booking-calendar.getAvailability` یا نوشتن database ephemeral. Capability می‌تواند از token، process identity، tool allowlist یا filesystem mapping بیاید.
**Approval** تصمیم انسانی دربارهٔ عمل یا scope است. Approval باید چه چیزی، برای چه محیطی، با چه expiry و چه evidenceای را تأیید کند. «بله» به prompt کلی، approval دقیق برای `git push` یا export tenant نیست.
**OS sandbox** محدودیت واقعی kernel/process روی filesystem، child process، syscall و network است. sandbox می‌تواند capability را constrain کند، اما policy business مثل tenant ownership را به‌تنهایی نمی‌فهمد. برعکس، approval یا متن Skill جای sandbox را نمی‌گیرد.
مثال بد
Agent روی laptop به کل home directory، SSH و network دسترسی دارد.
مدل گفت فقط تست اجرا می‌کنم و کاربر Approve زد؛ پس امن است.این setup در برابر prompt injection، dependency script، secret discovery و egress ناخواسته مرز کافی ندارد. approval گذشته هم عملیات بعدی را مجاز نمی‌کند.
مثال خوب: permission profile
mode: local, ephemeral workspace
filesystem: repository read/write؛ home، .ssh، keychain و production mount ممنوع
network: deny؛ فقط registry mirror ساختگی و از پیش allowشده در صورت نیاز
tools: vitest, formatter, calendar.getAvailability
approval: write خارج از workspace، network، migration و push
budget: 20 دقیقه، 8 tool call، 2 اجرای test suite
rollback: patch قابل revert، flag خاموش، DB fixture قابل حذفاین profile capability، approval و sandbox را جدا گزارش می‌کند؛ budget نیز یک کنترل availability و هزینه است، نه تضمین correctness.
## local و cloud
در local agent، process به workstation، credential helper، socketها، فایل‌های ignored و شبکهٔ واقعی نزدیک است؛ OS account کم‌امتیاز، workspace disposable و deny-by-default لازم است. در cloud agent، isolation زیرساختی ممکن است بهتر باشد، اما repository، logs، artifact، retention، outbound network، provider staff access و secret injection threat model جدا دارند. cloud را برابر «trust کامل» نگیرید؛ local را هم برابر «کنترل کامل» ندانید.
برای هر surface این موارد را ثبت کن: identity و owner، محل filesystem، process/container boundary، network routes، persistence مدت‌دار، audit، human approval، secret source و destruction time. local/cloud mapping تاریخ‌دار و مستند رسمی باشد؛ نام UI یا مدل هدف یادگیری نیست.
## secret lifecycle و egress
Secret را در prompt، repository، Skill، log یا screenshot نگذار. **Create** با scope و owner؛ **inject** کوتاه‌عمر در محیط محدود؛ **use** فقط برای مقصد allowlisted؛ **observe** با redaction؛ **rotate** بعد از زمان یا event؛ **revoke** در پایان یا incident؛ **destroy** cache و artifact. `EXAMPLE_TOKEN_DO_NOT_USE` تنها مقدار آموزشی است و credential نیست.
Network egress را route-by-route تعریف کن. DNS، HTTP proxy، package registry، MCP endpoint و webhook جدا هستند. deny-by-default، TLS و hostname allowlist کافی نیستند اگر IP redirect، SSRF، DNS rebinding یا upload arbitrary نادیده گرفته شود. output مدل را URL یا command قابل‌اجرا فرض نکن.
## budget و reversible action
Budget شامل wall-clock، تعداد iteration/tool call، CPU/memory، spend و حجم دادهٔ خوانده‌شده است. stop condition باید قبل از loop تعریف شود. عمل reversible مثل تغییر flag یا patch local checkpoint دارد؛ migration یا write tenantها reversible کامل نیست و backup، dry-run، approval و rollback tested می‌خواهد. هرچه برگشت‌پذیری کمتر، autonomy پایین‌تر و evidence/approval بیشتر.
*شکل: capability و داده از چند مرز عبور می‌کنند؛ approval انسانی و sandbox OS هم‌معنی نیستند. مسیر MCP و network باید جدا allowlist شوند و production بیرون از default boundary بماند.*
## سناریوی booking-platform
Agent محلی فقط روی fixture tenant `tenant-demo` کار می‌کند. repository read/write است اما `.env`, `.git`, home و keychain mount نیستند؛ network deny است؛ MCP فقط availability read را با revision pin ارائه می‌دهد. اگر Agent بخواهد migration idempotency را روی staging اجرا کند، capability ندارد و approval prompt آن را ایجاد نمی‌کند. باید Plan، migration review، ephemeral DB، backup/rollback و owner داشته باشد. اگر secret برای provider notification لازم شد، این درس آن را به production وصل نمی‌کند؛ fake adapter و credential ساختگی کافی است.
## آزمایشگاه گام‌به‌گام
**ورودی:** permission profile بالا، یک workspace temporary، test fixture و commands بی‌خطر.
۱. matrix بنویس: `action / capability / approval / sandbox / budget / rollback`. برای read file، format، test، MCP read، DB write و deploy مقدار بده.
۲. sandbox را با مسیر مجازی `./workspace` و home خالی تصور کن؛ commandها:
pnpm exec vitest run packages/contracts/src/reschedule-policy.test.ts
pnpm exec prettier --check packages/contracts/src/reschedule-policy.tsخروجی مورد انتظار `pass` یا failure قابل‌تحقیق است؛ هیچ network و secret واقعی نیاز نیست.
۳. درخواست‌های زیر را ارزیابی کن: خواندن `.env`، `curl` به endpoint واقعی، تغییر flag local، migration روی fixture، push branch، export تمام tenantها. برای هر کدام capability، approval، sandbox و recovery را بنویس.
**Recovery:** اگر process به path خارج از workspace یا network رسید، kill امن در sandbox disposable، token را revoke (اگر در محیط واقعی بود)، log redacted نگه‌دار و incident owner را مطلع کن. در این Lab هیچ secret واقعی یا destructive command اجرا نمی‌شود؛ migration فقط تحلیل یا fixture یک‌بارمصرف است.
## خطاهای رایج
- یکی گرفتن approval با permission یا sandbox.
- mount کردن home و SSH برای راحتی.
- inject کردن secret بلندمدت در environment و چاپ آن در log.
- اجازهٔ network عمومی برای نصب dependency یا MCP.
- budget نداشتن و retry بی‌پایان Agent.
- نام reversible روی migration یا exportی که rollback واقعی ندارد.
- فرض اینکه cloud retention، outbound route یا provider trust خودکاراً معلوم است.
## Verification
- [ ] capability، approval و OS sandbox جداگانه مستند شده‌اند.
- [ ] local/cloud surface، identity، persistence و egress مشخص است.
- [ ] read-only و deny-by-default حالت شروع‌اند.
- [ ] secret create/inject/use/redact/rotate/revoke/destroy lifecycle دارد.
- [ ] budget، timeout، tool-call limit و stop condition فعال‌اند.
- [ ] هر write approval دقیق، evidence، dry-run و rollback دارد.
- [ ] مسیر production credential و endpoint از Lab حذف شده است.
## تمرین و پاسخ نمونه
Agent cloud باید روی یک bug در timezone کار کند و پیشنهاد می‌دهد برای reproduction به database staging و calendar provider وصل شود. profile ایمن بنویس.
**پاسخ نمونه:** ابتدا fixture snapshot anonymized و clock/timezone محلی؛ capability read-only و database ephemeral؛ network deny یا فقط endpoint ساختگی allowlisted؛ بدون provider credential. اگر staging واقعاً لازم شد، Plan و owner، secret کوتاه‌عمر محدود، approval جدا، query read-only، budget و audit لازم است؛ write و deploy خارج از scope. recovery شامل revoke، حذف workspace/artifact و گزارش evidence است. پاسخ باید نشان دهد cloud sandbox به‌تنهایی tenant policy و secret lifecycle را حل نمی‌کند.
## جمع‌بندی
امنیت harness حاصل جمع متن خوب نیست: capability حد دسترسی، approval رضایت زمان‌دار و sandbox مرز اجرای واقعی‌اند. local/cloud را با threat model مقایسه کن؛ secret را چرخه‌دار و network را deny-by-default نگه دار؛ و budget، evidence و rollback را پیش‌فرض کن.
## منابع مستقیم
- [OpenAI Codex sandboxing](https://developers.openai.com/codex/sandboxing) — نمونهٔ رسمی تفکیک sandbox و approval؛ سطح محصول ممکن است تغییر کند.
- [Claude Code permissions](https://code.claude.com/docs/en/permissions) — permissionهای رسمی؛ جایگزین OS isolation نیست.
- [Cursor Cloud Agents](https://cursor.com/docs/cloud-agent.md) — تفاوت surface cloud و local؛ retention و workspace policy را جدا بررسی کنید.
- [NIST AI RMF 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — چارچوب ریسک، نه profile اجرایی خاص.
- [OWASP Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) — ریسک‌های agentic و کنترل‌های پیشنهادی؛ سطح guidance.
به زبان ساده
Capability می‌گوید چه عملی ممکن است، Approval رضایت انسانی برای scope و زمان خاص است و Sandbox مرز واقعی process در سیستم‌عامل را می‌سازد. هیچ‌کدام به‌تنهایی policy tenant، lifecycle secret یا rollback را حل نمی‌کند.
مثال واقعی
در محیط فرضی دوره، Agent روی fixture tenant و database ephemeral کار می‌کند و به home، keychain، network و staging credential دسترسی ندارد؛ یک approval کلی این مرزها را اضافه نمی‌کند.