การอนุมัติการดำเนินการ

การอนุมัติการเรียกใช้เป็น กลไกป้องกันของแอปคู่หู / โฮสต์ Node สำหรับอนุญาตให้เอเจนต์ที่อยู่ในแซนด์บ็อกซ์เรียกใช้คำสั่งบนโฮสต์จริง (gateway หรือ node) คำสั่งจะทำงานต่อเมื่อนโยบาย + รายการอนุญาต + การอนุมัติจากผู้ใช้ (ถ้ามี) เห็นพ้องกันทั้งหมดเท่านั้น การอนุมัติทำงาน ซ้อนทับอยู่เหนือ นโยบายเครื่องมือและด่านควบคุมสิทธิ์ระดับสูง (สิทธิ์ระดับสูงแบบ full จะข้ามการอนุมัติ)

สำหรับภาพรวมที่เน้นโหมดของ deny, allowlist, ask, auto, full, การแมป Codex Guardian และสิทธิ์ของชุดทดสอบ ACPX โปรดดู โหมดสิทธิ์

ขอบเขตที่ใช้

การอนุมัติการเรียกใช้จะถูกบังคับใช้ภายในโฮสต์ที่ดำเนินการ:

• โฮสต์ Gateway -> กระบวนการ openclaw บนเครื่อง Gateway
• โฮสต์ Node -> ตัวเรียกใช้ของ Node (แอปคู่หูบน macOS หรือโฮสต์ Node แบบไม่มีส่วนติดต่อ)

แบบจำลองความเชื่อถือ

• ผู้เรียกที่ผ่านการตรวจสอบสิทธิ์โดย Gateway ถือเป็นผู้ดำเนินการที่เชื่อถือได้สำหรับ Gateway นั้น
• Node ที่จับคู่แล้วจะขยายความสามารถของผู้ดำเนินการที่เชื่อถือได้นั้นไปยังโฮสต์ Node
• การอนุมัติช่วยลดความเสี่ยงจากการเรียกใช้โดยไม่ตั้งใจ แต่ ไม่ใช่ ขอบเขตการตรวจสอบสิทธิ์ต่อผู้ใช้หรือนโยบายระบบไฟล์แบบอ่านอย่างเดียว
• เมื่ออนุมัติแล้ว คำสั่งสามารถแก้ไขไฟล์ได้ตามสิทธิ์ของระบบไฟล์ในโฮสต์หรือแซนด์บ็อกซ์ที่เลือก
• การเรียกใช้บนโฮสต์ Node ที่ได้รับอนุมัติจะผูกกับบริบทการดำเนินการมาตรฐาน ได้แก่ cwd, argv ที่ตรงทุกประการ, การผูก env เมื่อมี และพาธไฟล์ปฏิบัติการที่ตรึงไว้เมื่อใช้ได้
• สำหรับเชลล์สคริปต์และการเรียกไฟล์ผ่านอินเทอร์พรีเตอร์/รันไทม์โดยตรง OpenClaw จะพยายามผูกกับตัวถูกดำเนินการที่เป็นไฟล์ภายในเครื่องหนึ่งไฟล์ที่ระบุได้อย่างชัดเจนด้วย หากไฟล์นั้นเปลี่ยนแปลงหลังการอนุมัติแต่ก่อนการดำเนินการ ระบบจะปฏิเสธการเรียกใช้แทนที่จะดำเนินการเนื้อหาที่คลาดเคลื่อนไป
• การผูกไฟล์เป็นการดำเนินการอย่างดีที่สุดเท่าที่ทำได้ ไม่ใช่แบบจำลองที่ครอบคลุมทุกพาธการโหลดของอินเทอร์พรีเตอร์/รันไทม์อย่างสมบูรณ์ หากไม่สามารถระบุไฟล์ภายในเครื่องที่ชัดเจนได้เพียงหนึ่งไฟล์ OpenClaw จะปฏิเสธการออกสิทธิ์การเรียกใช้ที่รองรับด้วยการอนุมัติ แทนที่จะแสร้งว่าครอบคลุมทั้งหมด

การแยกส่วนบน macOS

• บริการโฮสต์ Node ส่งต่อ system.run ไปยัง แอป macOS ผ่าน IPC ภายในเครื่อง
• แอป macOS บังคับใช้การอนุมัติและดำเนินการคำสั่งในบริบทของ UI

การตรวจสอบนโยบายที่มีผลบังคับใช้

เอกสารอ้างอิง CLI ฉบับเต็ม (แฟล็ก เอาต์พุต JSON การเพิ่ม/ลบรายการอนุญาต): CLI การอนุมัติ

เมื่อขอบเขตภายในเครื่องร้องขอ host=node คำสั่ง exec-policy show จะรายงานว่าขอบเขตนั้นจัดการโดย Node ขณะทำงาน แทนที่จะถือว่าไฟล์การอนุมัติภายในเครื่องเป็นแหล่งข้อมูลจริง

หาก UI ของแอปคู่หู ไม่พร้อมใช้งาน คำขอใดก็ตามที่ปกติต้องแสดงข้อความถามจะได้รับการตัดสินโดย ค่าทดแทนเมื่อถามไม่ได้ (ค่าเริ่มต้น: deny)

การตั้งค่าและพื้นที่จัดเก็บ

การอนุมัติจัดเก็บอยู่ในไฟล์ JSON ภายในโฮสต์ที่ดำเนินการ เมื่อกำหนด OPENCLAW_STATE_DIR ไฟล์จะอยู่ภายใต้ไดเรกทอรีสถานะนั้น มิฉะนั้นจะใช้ไดเรกทอรีสถานะเริ่มต้นของ OpenClaw:

$OPENCLAW_STATE_DIR/exec-approvals.json# มิฉะนั้น~/.openclaw/exec-approvals.json

ซ็อกเก็ตการอนุมัติเริ่มต้นใช้รากเดียวกัน: $OPENCLAW_STATE_DIR/exec-approvals.sock หรือ ~/.openclaw/exec-approvals.sock เมื่อไม่ได้กำหนดตัวแปร

รุ่นก่อน 2026.6.6 จะเก็บไฟล์ไว้ใน ~/.openclaw เสมอ หาก OPENCLAW_STATE_DIR ชี้ไปยังตำแหน่งอื่นและยังมีไฟล์การอนุมัติอยู่ใน ไดเรกทอรีเริ่มต้น ให้เรียกใช้ openclaw doctor --fix โดยตรงหนึ่งครั้งเพื่อนำเข้า ไฟล์ดังกล่าวไปยังไดเรกทอรีสถานะ (ไฟล์ต้นฉบับจะถูกเก็บถาวรโดยเติมส่วนต่อท้าย .migrated) คำสั่ง doctor แบบโต้ตอบสามารถแสดงตัวอย่างและยืนยันการนำเข้าได้เช่นกัน การเรียกใช้ เพื่อซ่อมแซมจากการอัปเดตอัตโนมัติและการเฝ้าดู Gateway จะไม่นำเข้าข้ามไดเรกทอรีสถานะ: ไดเรกทอรีสถานะชั่วคราวหรือสำหรับจัดเตรียมต้องไม่รับการอนุมัติของการติดตั้งเริ่มต้น ขอบเขตเดียวกันนี้ใช้กับการนำเข้า plugin-binding-approvals.json แบบเดิมเข้าสู่ สถานะ SQLite ที่ใช้ร่วมกัน

ตัวอย่างสคีมา:

{  "version": 1,  "socket": {    "path": "~/.openclaw/exec-approvals.sock",    "token": "base64url-token"  },  "defaults": {    "security": "deny",    "ask": "on-miss",    "askFallback": "deny",    "autoAllowSkills": false  },  "agents": {    "main": {      "security": "allowlist",      "ask": "on-miss",      "askFallback": "deny",      "autoAllowSkills": true,      "allowlist": [        {          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",          "pattern": "~/Projects/**/bin/rg",          "source": "allow-always",          "lastUsedAt": 1737150000000,          "lastUsedCommand": "rg -n TODO",          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"        }      ]    }  }}

ตัวควบคุมนโยบาย

tools.exec.mode

tools.exec.mode เป็นพื้นผิวนโยบายที่ปรับเป็นมาตรฐานซึ่งแนะนำให้ใช้สำหรับการเรียกใช้บนโฮสต์:

tools.exec.security / tools.exec.ask แบบเดิมยังคงรองรับและยังคง มีผลทุกขอบเขตที่ไม่ได้กำหนด mode

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

ตัวอย่างที่โหมดเข้มงวดตรวจจับได้: python -c, node -e/--eval/-p, ruby -e, perl -e/-E, php -r, lua -e, osascript -e (รวมถึงรูปแบบอินไลน์ของ awk, sed, make, find -exec และ xargs)

ในโหมดเข้มงวด คำสั่งเหล่านี้ต้องผ่านผู้ตรวจสอบหรือการอนุมัติอย่างชัดแจ้ง เมื่อใช้ tools.exec.mode: "auto" ผู้ตรวจสอบอาจอนุญาตการเรียกใช้ที่มีความเสี่ยงต่ำหนึ่งครั้งเมื่อ คำสั่งมีแผนที่บังคับใช้ได้ มิฉะนั้น OpenClaw จะถามมนุษย์ การอนุมัติคำสั่ง Codex app-server ที่ไปถึงผู้ตรวจสอบสำรองจะถามมนุษย์ เนื่องจากคำขออนุมัติไม่ได้เปิดเผยไฟล์ปฏิบัติการที่แก้พาธแล้วและสามารถบังคับใช้ได้ allow-always จะไม่บันทึกรายการใหม่ลงในรายการอนุญาตสำหรับคำสั่งประเมินแบบอินไลน์

tools.exec.commandHighlighting

กำหนดแบบส่วนกลางภายใต้ tools.exec.commandHighlighting หรือกำหนดต่อเอเจนต์ภายใต้ agents.list[].tools.exec.commandHighlighting

โหมด YOLO (ไม่ต้องอนุมัติ)

หากต้องการเรียกใช้บนโฮสต์โดยไม่แสดงข้อความขออนุมัติ ให้เปิดนโยบาย ทั้งสอง ชั้น: นโยบายการเรียกใช้ที่ร้องขอในการกำหนดค่า OpenClaw (tools.exec.*) และ นโยบายการอนุมัติภายในโฮสต์ในไฟล์การอนุมัติของโฮสต์ที่ดำเนินการ

เมื่อละเว้น askFallback ค่าเริ่มต้นคือ deny ให้กำหนด askFallback ของโฮสต์เป็น full อย่างชัดแจ้ง เมื่อต้องการให้ข้อความขออนุมัติที่ไม่มี UI ใช้การอนุญาตเป็นทางเลือกสำรอง

ผู้ให้บริการที่ทำงานผ่าน CLI และมีโหมดสิทธิ์แบบไม่โต้ตอบของตนเอง สามารถปฏิบัติตามนโยบายนี้ได้ Claude CLI จะเพิ่ม --permission-mode bypassPermissions เมื่อนโยบายการเรียกใช้คำสั่งที่มีผลของ OpenClaw เป็น YOLO สำหรับเซสชัน Claude แบบสดที่ OpenClaw จัดการ นโยบายการเรียกใช้คำสั่ง ที่มีผลของ OpenClaw จะมีอำนาจเหนือกว่าโหมดสิทธิ์ดั้งเดิมของ Claude: YOLO จะปรับการเริ่มต้นแบบสดให้ใช้ --permission-mode bypassPermissions และ นโยบายการเรียกใช้คำสั่งที่มีผลแบบจำกัดจะปรับการเริ่มต้นแบบสดให้ใช้ --permission-mode default แม้ว่าอาร์กิวเมนต์ดิบของแบ็กเอนด์ Claude จะระบุ โหมดอื่นก็ตาม

หากต้องการการตั้งค่าที่รัดกุมกว่า ให้ปรับนโยบายการเรียกใช้คำสั่งของ OpenClaw กลับเป็น allowlist / on-miss หรือ deny

การตั้งค่า "ไม่ต้องถามอีก" แบบถาวรสำหรับโฮสต์ Gateway

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

openclaw approvals set --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

ทางลัดภายในเครื่อง

openclaw exec-policy preset yolo

อัปเดตทั้ง tools.exec.host/security/ask ภายในเครื่องและค่าเริ่มต้นของไฟล์ การอนุมัติภายในเครื่อง (รวมถึง askFallback: "full") โดยตั้งใจให้มีผล เฉพาะภายในเครื่องเท่านั้น หากต้องการเปลี่ยนการอนุมัติของโฮสต์ Gateway หรือโฮสต์ Node จากระยะไกล ให้ใช้ openclaw approvals set --gateway หรือ openclaw approvals set --node <id|name|ip>

ค่าที่ตั้งไว้ล่วงหน้าในตัวอื่น ๆ ได้แก่ cautious (host=gateway, security=allowlist, ask=on-miss, askFallback=deny) และ deny-all (host=gateway, security=deny, ask=off, askFallback=deny) ใช้ด้วยวิธีเดียวกัน: openclaw exec-policy preset cautious

หากต้องการตั้งค่าแต่ละฟิลด์แทนการใช้ค่าที่ตั้งไว้ล่วงหน้าทั้งชุด ให้ใช้ openclaw exec-policy set --host <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> โดยระบุแฟล็กเหล่านั้นเพียงบางส่วนก็ได้

โฮสต์ Node

ใช้ไฟล์การอนุมัติเดียวกันบน Node แทน:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

ทางลัดเฉพาะเซสชัน

• /exec security=full ask=off เปลี่ยนเฉพาะเซสชันปัจจุบัน
• /elevated full เป็นทางลัดสำหรับกรณีฉุกเฉินที่ข้ามการอนุมัติการเรียกใช้คำสั่งเฉพาะ เมื่อนโยบายที่ร้องขอและไฟล์การอนุมัติของโฮสต์ให้ผลลัพธ์เป็น security: "full" และ ask: "off" ทั้งคู่เท่านั้น ไฟล์ของโฮสต์ที่เข้มงวดกว่า เช่น ask: "always" จะยังคงแสดงคำขอให้อนุมัติ

หากไฟล์การอนุมัติของโฮสต์ยังคงเข้มงวดกว่าการกำหนดค่า นโยบายของโฮสต์ ที่เข้มงวดกว่าจะยังคงมีผลเหนือกว่า

รายการอนุญาต (ต่อเอเจนต์)

รายการอนุญาตเป็นแบบ ต่อเอเจนต์ หากมีหลายเอเจนต์ ให้สลับเอเจนต์ ที่กำลังแก้ไขในแอป macOS รูปแบบจะจับคู่ด้วย glob

รูปแบบอาจเป็น glob ของพาธไบนารีที่แก้ไขแล้ว หรือ glob ของชื่อคำสั่งล้วน ชื่อแบบล้วนจะจับคู่เฉพาะคำสั่งที่เรียกผ่าน PATH ดังนั้น rg จึงจับคู่กับ /opt/homebrew/bin/rg ได้เมื่อคำสั่งคือ rg แต่ ไม่ จับคู่กับ ./rg หรือ /tmp/rg ให้ใช้ glob ของพาธเพื่อเชื่อถือไบนารีในตำแหน่งที่เจาะจงเพียงแห่งเดียว

รายการ agents.default แบบเดิมจะถูกย้ายไปยัง agents.main เมื่อโหลด สายคำสั่งเชลล์ เช่น echo ok && pwd ยังคงกำหนดให้ทุกส่วนระดับบนสุด ผ่านกฎของรายการอนุญาต

ตัวอย่าง:

• rg
• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

การจำกัดอาร์กิวเมนต์ด้วย argPattern

เพิ่ม argPattern เมื่อรายการในรายการอนุญาตควรจับคู่ทั้งไบนารีและ รูปแบบอาร์กิวเมนต์ที่เจาะจง OpenClaw ใช้ความหมายของนิพจน์ทั่วไปแบบ ECMAScript (JavaScript) บนทุกโฮสต์ และประเมินนิพจน์กับอาร์กิวเมนต์คำสั่ง ที่แยกวิเคราะห์แล้ว โดยไม่รวมโทเค็นของไฟล์ปฏิบัติการ (argv[0]) สำหรับรายการที่เขียนด้วยตนเอง ระบบจะเชื่อมอาร์กิวเมนต์ด้วยช่องว่างหนึ่งตัว ดังนั้น ให้ยึดรูปแบบกับจุดเริ่มต้นและจุดสิ้นสุดเมื่อต้องการการจับคู่แบบตรงทั้งหมด

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

รายการดังกล่าวอนุญาต python3 safe.py ส่วน python3 other.py ไม่ตรงกับ รายการอนุญาต หากมีรายการที่ระบุเฉพาะพาธสำหรับไบนารีเดียวกันอยู่ด้วย อาร์กิวเมนต์ที่ไม่ตรงกันยังสามารถย้อนกลับไปใช้รายการที่ระบุเฉพาะพาธนั้นได้ ให้ละเว้น รายการที่ระบุเฉพาะพาธเมื่อเป้าหมายคือจำกัดไบนารีให้ใช้ได้เฉพาะกับอาร์กิวเมนต์ที่ประกาศไว้

รายการที่บันทึกโดยขั้นตอนการอนุมัติจะใช้รูปแบบตัวคั่นภายในเพื่อจับคู่ argv แบบตรงทั้งหมด ควรใช้ UI หรือขั้นตอนการอนุมัติเพื่อสร้างรายการเหล่านั้นใหม่ แทนการแก้ไขค่าที่เข้ารหัสด้วยตนเอง หาก OpenClaw ไม่สามารถแยกวิเคราะห์ argv ของส่วนคำสั่งได้ รายการที่มี argPattern จะไม่จับคู่

รายการอนุญาตแต่ละรายการรองรับ:

อนุญาต CLI ของ Skills โดยอัตโนมัติ

เมื่อเปิดใช้ อนุญาต CLI ของ Skills โดยอัตโนมัติ (autoAllowSkills) ไฟล์ปฏิบัติการ ที่อ้างอิงโดย Skills ที่รู้จักจะถือว่าอยู่ในรายการอนุญาตบน Node (Node ของ macOS หรือโฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้) กลไกนี้ใช้ skills.bins ผ่าน RPC ของ Gateway เพื่อ ดึงรายการไบนารีของ Skills ปิดใช้ตัวเลือกนี้หากต้องการรายการอนุญาตแบบกำหนดเอง อย่างเข้มงวด

ไบนารีที่ปลอดภัยและการส่งต่อการอนุมัติ

สำหรับไบนารีที่ปลอดภัย (เส้นทางลัดที่รับเฉพาะ stdin) รายละเอียดการผูกอินเทอร์พรีเตอร์ และ วิธีส่งต่อคำขออนุมัติไปยัง Slack/Discord/Telegram (หรือเรียกใช้เป็น ไคลเอ็นต์การอนุมัติแบบดั้งเดิม) โปรดดู การอนุมัติการเรียกใช้คำสั่ง - ขั้นสูง

การแก้ไขผ่าน Control UI

ใช้การ์ด Control UI -> Nodes -> Exec approvals เพื่อแก้ไขค่าเริ่มต้น การเขียนทับต่อเอเจนต์ และรายการอนุญาต เลือกขอบเขต (Defaults หรือเอเจนต์) ปรับนโยบาย เพิ่ม/ลบรูปแบบในรายการอนุญาต แล้วกด Save UI จะแสดงข้อมูลเมตาการใช้งานล่าสุดของแต่ละรูปแบบ เพื่อให้คุณดูแลรายการให้เป็นระเบียบได้

ตัวเลือกเป้าหมายใช้เลือก Gateway (การอนุมัติภายในเครื่อง) หรือ Node Node ต้องประกาศ system.execApprovals.get/set (แอป macOS หรือโฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้) หาก Node ยังไม่ประกาศการอนุมัติการเรียกใช้คำสั่ง ให้แก้ไข ไฟล์การอนุมัติภายในเครื่องของ Node โดยตรง

โฮสต์ Node บางประเภท รวมถึงแอปร่วมสำหรับ Windows ใช้รูปแบบนโยบายการอนุมัติ ที่แตกต่างกัน Control UI จะแสดงนโยบายดั้งเดิมของโฮสต์เหล่านี้แบบอ่านอย่างเดียว ให้ใช้ แอปร่วมหรือ openclaw approvals set --node <id|name|ip> พร้อมโครงสร้างนโยบาย ดั้งเดิมเพื่อแก้ไข โปรดดู CLI การอนุมัติ

CLI: openclaw approvals รองรับการแก้ไข Gateway หรือ Node โปรดดู CLI การอนุมัติ

ขั้นตอนการอนุมัติ

เมื่อต้องขออนุมัติ Gateway จะกระจาย exec.approval.requested ไปยังไคลเอ็นต์ของผู้ดูแล Control UI และแอป macOS จะดำเนินการผ่าน exec.approval.resolve จากนั้น Gateway จะส่งต่อคำขอ ที่ได้รับอนุมัติไปยังโฮสต์ Node

สำหรับ host=node คำขออนุมัติจะมีเพย์โหลด systemRunPlan มาตรฐาน Gateway ใช้แผนดังกล่าวเป็นบริบทคำสั่ง/cwd/เซสชันที่มีอำนาจสูงสุด เมื่อส่งต่อคำขอ system.run ที่ได้รับอนุมัติ:

• เส้นทางการเรียกใช้คำสั่งของ Node จัดเตรียมแผนมาตรฐานหนึ่งชุดไว้ล่วงหน้า
• ระเบียนการอนุมัติจัดเก็บแผนดังกล่าวและข้อมูลเมตาการผูกของแผน
• เมื่อได้รับอนุมัติ การเรียก system.run ที่ส่งต่อขั้นสุดท้ายจะนำแผนที่จัดเก็บไว้กลับมาใช้ แทนการเชื่อถือการแก้ไขของผู้เรียกในภายหลัง
• หากผู้เรียกเปลี่ยน command, rawCommand, cwd, agentId หรือ sessionKey หลังจากสร้างคำขออนุมัติแล้ว Gateway จะปฏิเสธการเรียกใช้ที่ส่งต่อ เนื่องจากการอนุมัติไม่ตรงกัน

เหตุการณ์ของระบบและการปฏิเสธ

วงจรชีวิตการเรียกใช้คำสั่งจะโพสต์ข้อความระบบ Exec finished ไปยังเซสชันของเอเจนต์ หลังจาก Node รายงานว่าเสร็จสิ้นแล้ว OpenClaw ยังสามารถส่งการแจ้งเตือนว่า กำลังดำเนินการหลังได้รับการอนุมัติ เมื่อผ่านเวลา tools.exec.approvalRunningNoticeMs (ค่าเริ่มต้น 10000, ค่า 0 ใช้ปิดการทำงาน) การอนุมัติการเรียกใช้คำสั่งที่ถูกปฏิเสธถือเป็นสถานะสิ้นสุดสำหรับคำสั่งของโฮสต์: คำสั่งจะไม่ทำงาน

• สำหรับการอนุมัติแบบอะซิงโครนัสของเอเจนต์หลักที่มีเซสชันต้นทาง OpenClaw จะโพสต์การปฏิเสธกลับไปยังเซสชันนั้นเป็นการติดตามผลภายใน เพื่อให้ เอเจนต์หยุดรอคำสั่งอะซิงโครนัสและไม่ต้องซ่อมแซมผลลัพธ์ที่ขาดหายไป
• หากไม่มีเซสชันหรือไม่สามารถดำเนินเซสชันต่อได้ OpenClaw ยังสามารถ รายงานการปฏิเสธแบบกระชับไปยังผู้ดูแลหรือเส้นทางแชตโดยตรง
• การปฏิเสธสำหรับเซสชันของเอเจนต์ย่อยและ Cron จะไม่ถูกโพสต์กลับเข้าไปใน เซสชันนั้น

การอนุมัติการเรียกใช้คำสั่งของโฮสต์ Gateway จะส่งเหตุการณ์วงจรชีวิตการเสร็จสิ้น แบบเดียวกัน การเรียกใช้คำสั่งที่ถูกควบคุมด้วยการอนุมัติจะนำรหัสการอนุมัติกลับมาใช้ เพื่อเชื่อมโยงคำขอที่รอดำเนินการกับข้อความเสร็จสิ้น/ปฏิเสธ (Exec finished (gateway id=...) / Exec denied (gateway id=...))

ผลกระทบ

• full มีอำนาจสูง ควรใช้รายการอนุญาตเมื่อทำได้
• ask ช่วยให้คุณยังมีส่วนร่วมในการตัดสินใจ ขณะเดียวกันก็อนุมัติได้อย่างรวดเร็ว
• รายการอนุญาตต่อเอเจนต์ป้องกันไม่ให้การอนุมัติของเอเจนต์หนึ่งรั่วไหลไปยังเอเจนต์อื่น
• การอนุมัติใช้เฉพาะกับคำขอเรียกใช้คำสั่งบนโฮสต์จาก ผู้ส่งที่ได้รับอนุญาต ผู้ส่งที่ไม่ได้รับอนุญาตไม่สามารถเรียก /exec ได้
• /exec security=full เป็นตัวเลือกอำนวยความสะดวกระดับเซสชันสำหรับผู้ดูแลที่ได้รับอนุญาต และข้ามการอนุมัติตามการออกแบบ หากต้องการปิดกั้นการเรียกใช้คำสั่งบนโฮสต์อย่างเด็ดขาด ให้ตั้งค่าความปลอดภัยของการอนุมัติเป็น deny หรือปฏิเสธเครื่องมือ exec ผ่านนโยบายเครื่องมือ

ที่เกี่ยวข้อง