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

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

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

ขอบเขตการใช้งาน

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

• โฮสต์ 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 ของแอปคู่หู ไม่พร้อมใช้งาน คำขอใดก็ตามที่ตามปกติ ต้องแสดงข้อความถามจะถูกตัดสินด้วย ค่าทดแทนของ ask (ค่าเริ่มต้น: 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 เมื่อไม่ได้กำหนดตัวแปร

ไดเรกทอรีสถานะเป็นขอบเขตความเชื่อถือที่แยกจากกัน เมื่อ OPENCLAW_STATE_DIR ชี้ไปยังตำแหน่งอื่น OpenClaw จะไม่เคยนำเข้าหรือเก็บถาวร ~/.openclaw/exec-approvals.json; ให้กำหนดค่าการอนุมัติแยกต่างหากสำหรับ ไดเรกทอรีสถานะแบบกำหนดเอง Doctor จะนำเข้า plugin-binding-approvals.json แบบเดิมเฉพาะเมื่อเป็นของไดเรกทอรีสถานะ ที่ใช้งานอยู่เท่านั้น

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

{  "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 เป็นพื้นผิวนโยบายที่ปรับเป็นมาตรฐานซึ่งแนะนำให้ใช้สำหรับ exec บนโฮสต์:

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 (ไม่ต้องอนุมัติ)

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

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

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

หากต้องการการตั้งค่าที่รัดกุมยิ่งขึ้น ให้ปรับนโยบาย exec ของ 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 เป็นทางลัดฉุกเฉินที่ข้ามการอนุมัติ exec เฉพาะ เมื่อนโยบายที่ร้องขอและไฟล์การอนุมัติของโฮสต์ต่างประเมินผลเป็น 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 ผ่าน Gateway RPC เพื่อ ดึงรายการไบนารีของ Skills ปิดใช้ตัวเลือกนี้หากต้องการใช้ รายการอนุญาตแบบกำหนดเองที่เข้มงวด

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

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

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

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

ตัวเลือกเป้าหมายจะเลือก Gateway (การอนุมัติภายในเครื่อง) หรือ Node Node ต้องประกาศ system.execApprovals.get/set (แอป macOS หรือ โฮสต์ Node แบบไม่มีส่วนติดต่อผู้ใช้) หาก Node ยังไม่ประกาศการอนุมัติ exec ให้แก้ไข ไฟล์การอนุมัติภายในเครื่องของ 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 ที่ได้รับอนุมัติ:

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

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

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

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

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

ผลกระทบ

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

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