ความปลอดภัย

กำหนดขอบเขตก่อน: โมเดลความปลอดภัยของผู้ช่วยส่วนตัว

แนวทางความปลอดภัยของ OpenClaw ถือว่าเป็นการปรับใช้แบบ ผู้ช่วยส่วนตัว: ขอบเขตผู้ปฏิบัติงานที่เชื่อถือได้หนึ่งขอบเขต และอาจมีเอเจนต์หลายตัว

• สถานะความปลอดภัยที่รองรับ: ผู้ใช้/ขอบเขตความเชื่อถือหนึ่งรายต่อ Gateway (แนะนำให้ใช้ผู้ใช้ OS/โฮสต์/VPS หนึ่งชุดต่อขอบเขต)
• ไม่ใช่ขอบเขตความปลอดภัยที่รองรับ: Gateway/เอเจนต์ร่วมหนึ่งตัวที่ใช้โดยผู้ใช้ที่ไม่เชื่อถือกันหรือเป็นปฏิปักษ์ต่อกัน
• หากต้องแยกผู้ใช้ที่เป็นปฏิปักษ์ ให้แยกตามขอบเขตความเชื่อถือ (Gateway + ข้อมูลประจำตัวแยกกัน และถ้าเป็นไปได้ควรแยกผู้ใช้/โฮสต์ OS ด้วย)
• หากผู้ใช้ที่ไม่เชื่อถือกันหลายคนสามารถส่งข้อความถึงเอเจนต์ที่เปิดใช้เครื่องมือหนึ่งตัว ให้ถือว่าพวกเขาใช้สิทธิ์เครื่องมือที่มอบหมายให้เอเจนต์นั้นร่วมกัน

หน้านี้อธิบายการเสริมความแข็งแรงด้านความปลอดภัย ภายในโมเดลนั้น ไม่ได้อ้างว่ามีการแยกแบบหลายผู้เช่าที่เป็นปฏิปักษ์บน Gateway ร่วมหนึ่งตัว

ก่อนเปลี่ยนการเข้าถึงระยะไกล นโยบาย DM reverse proxy หรือการเปิดเผยสาธารณะ ให้ใช้ คู่มือปฏิบัติการการเปิดเผย Gateway เป็นรายการตรวจสอบก่อนเริ่มงานและสำหรับย้อนกลับ

ตรวจอย่างรวดเร็ว: openclaw security audit

ดูเพิ่มเติม: การพิสูจน์เชิงรูปแบบ (โมเดลความปลอดภัย)

รันสิ่งนี้เป็นประจำ (โดยเฉพาะหลังจากเปลี่ยน config หรือเปิดเผยพื้นผิวเครือข่าย):

openclaw security auditopenclaw security audit --deepopenclaw security audit --fixopenclaw security audit --json

security audit --fix ตั้งใจให้มีขอบเขตแคบ: จะเปลี่ยนนโยบายกลุ่มเปิดทั่วไปเป็นรายการอนุญาต กู้คืน logging.redactSensitive: "tools" ทำให้สิทธิ์ state/config/include-file เข้มงวดขึ้น และใช้การรีเซ็ต Windows ACL แทน POSIX chmod เมื่อรันบน Windows

เครื่องมือนี้จะชี้จุดเสี่ยงที่พลาดง่ายทั่วไป (การเปิดเผย auth ของ Gateway, การเปิดเผยการควบคุมเบราว์เซอร์, รายการอนุญาตที่มีสิทธิ์สูง, สิทธิ์ระบบไฟล์, การอนุมัติ exec ที่ผ่อนปรน และการเปิดเผยเครื่องมือในช่องทางเปิด)

OpenClaw เป็นทั้งผลิตภัณฑ์และการทดลอง: คุณกำลังเชื่อมพฤติกรรมของโมเดลแนวหน้าเข้ากับพื้นผิวการส่งข้อความจริงและเครื่องมือจริง ไม่มีการตั้งค่าใดที่ "ปลอดภัยสมบูรณ์แบบ" เป้าหมายคือการตัดสินใจอย่างรอบคอบเกี่ยวกับ:

• ใครสามารถคุยกับบอตของคุณได้
• บอตได้รับอนุญาตให้ทำงานที่ใด
• บอตสามารถแตะต้องอะไรได้บ้าง

เริ่มด้วยการเข้าถึงที่เล็กที่สุดที่ยังใช้งานได้ แล้วค่อยขยายเมื่อคุณมั่นใจมากขึ้น

การล็อก dependency ของแพ็กเกจที่เผยแพร่

ซอร์สเช็กเอาต์ของ OpenClaw ใช้ pnpm-lock.yaml แพ็กเกจ npm openclaw ที่เผยแพร่และแพ็กเกจ npm Plugin ที่ OpenClaw เป็นเจ้าของมี npm-shrinkwrap.json ซึ่งเป็น lockfile dependency ที่เผยแพร่ได้ของ npm ดังนั้นการติดตั้งแพ็กเกจจะใช้กราฟ dependency ทางอ้อมที่ผ่านการตรวจทานจากรีลีส แทนที่จะ resolve กราฟใหม่ขณะติดตั้ง

Shrinkwrap เป็นขอบเขตสำหรับเสริมความแข็งแรงด้านซัพพลายเชนและทำให้รีลีสทำซ้ำได้ ไม่ใช่แซนด์บ็อกซ์ สำหรับโมเดลภาษาเข้าใจง่าย คำสั่งของผู้ดูแล และการตรวจสอบการสำรวจแพ็กเกจ โปรดดู npm shrinkwrap

ความเชื่อถือในการปรับใช้และโฮสต์

OpenClaw ถือว่าโฮสต์และขอบเขต config เชื่อถือได้:

• หากมีใครสามารถแก้ไข state/config ของโฮสต์ Gateway (~/.openclaw รวมถึง openclaw.json) ให้ถือว่าคนนั้นเป็นผู้ปฏิบัติงานที่เชื่อถือได้
• การรัน Gateway หนึ่งตัวสำหรับผู้ปฏิบัติงานหลายคนที่ไม่เชื่อถือกัน/เป็นปฏิปักษ์ต่อกัน ไม่ใช่การตั้งค่าที่แนะนำ
• สำหรับทีมที่มีความเชื่อถือผสม ให้แยกขอบเขตความเชื่อถือด้วย Gateway แยกกัน (หรืออย่างน้อยแยกผู้ใช้/โฮสต์ OS)
• ค่าเริ่มต้นที่แนะนำ: ผู้ใช้หนึ่งรายต่อเครื่อง/โฮสต์ (หรือ VPS), Gateway หนึ่งตัวสำหรับผู้ใช้นั้น และเอเจนต์หนึ่งตัวหรือมากกว่าใน Gateway นั้น
• ภายในอินสแตนซ์ Gateway เดียว การเข้าถึงของผู้ปฏิบัติงานที่ผ่านการยืนยันตัวตนเป็นบทบาท control-plane ที่เชื่อถือได้ ไม่ใช่บทบาทผู้เช่ารายผู้ใช้
• ตัวระบุเซสชัน (sessionKey, ID เซสชัน, ป้ายกำกับ) เป็นตัวเลือกเส้นทาง ไม่ใช่โทเค็นการอนุญาต
• หากหลายคนสามารถส่งข้อความถึงเอเจนต์ที่เปิดใช้เครื่องมือหนึ่งตัว แต่ละคนสามารถกำกับชุดสิทธิ์เดียวกันนั้นได้ การแยกเซสชัน/หน่วยความจำรายผู้ใช้ช่วยเรื่องความเป็นส่วนตัว แต่ไม่ได้เปลี่ยนเอเจนต์ร่วมให้เป็นการอนุญาตโฮสต์รายผู้ใช้

การดำเนินการไฟล์ที่ปลอดภัย

OpenClaw ใช้ @openclaw/fs-safe สำหรับการเข้าถึงไฟล์ที่จำกัดตามราก การเขียนแบบ atomic การแตก archive พื้นที่ทำงานชั่วคราว และตัวช่วยไฟล์ลับ OpenClaw ตั้งค่าเริ่มต้นให้ตัวช่วย POSIX Python แบบไม่บังคับของ fs-safe เป็น ปิด; ตั้ง OPENCLAW_FS_SAFE_PYTHON_MODE=auto หรือ require เฉพาะเมื่อคุณต้องการการเสริมความแข็งแรงเพิ่มเติมสำหรับการเปลี่ยนแปลงแบบอ้างอิง fd และสามารถรองรับ runtime Python ได้

รายละเอียด: การดำเนินการไฟล์ที่ปลอดภัย

เวิร์กสเปซ Slack ที่ใช้ร่วมกัน: ความเสี่ยงจริง

หาก "ทุกคนใน Slack สามารถส่งข้อความถึงบอตได้" ความเสี่ยงหลักคือสิทธิ์เครื่องมือที่ถูกมอบหมาย:

• ผู้ส่งที่อนุญาตคนใดก็สามารถชักนำให้เกิดการเรียกเครื่องมือ (exec, เบราว์เซอร์, เครื่องมือเครือข่าย/ไฟล์) ภายในนโยบายของเอเจนต์ได้;
• การแทรก prompt/เนื้อหาจากผู้ส่งหนึ่งรายอาจทำให้เกิดการกระทำที่กระทบ state อุปกรณ์ หรือผลลัพธ์ร่วม;
• หากเอเจนต์ร่วมหนึ่งตัวมีข้อมูลประจำตัว/ไฟล์ที่ละเอียดอ่อน ผู้ส่งที่อนุญาตคนใดก็อาจสั่งให้รั่วไหลข้อมูลผ่านการใช้เครื่องมือได้

ใช้เอเจนต์/Gateway แยกกันพร้อมเครื่องมือน้อยที่สุดสำหรับเวิร์กโฟลว์ของทีม; เก็บเอเจนต์ข้อมูลส่วนตัวให้เป็นส่วนตัว

เอเจนต์ที่บริษัทใช้ร่วมกัน: รูปแบบที่ยอมรับได้

สิ่งนี้ยอมรับได้เมื่อทุกคนที่ใช้เอเจนต์นั้นอยู่ในขอบเขตความเชื่อถือเดียวกัน (เช่น ทีมบริษัทเดียวกัน) และเอเจนต์ถูกจำกัดขอบเขตเฉพาะงานธุรกิจอย่างเข้มงวด

• รันบนเครื่อง/VM/container เฉพาะ;
• ใช้ผู้ใช้ OS เฉพาะ + เบราว์เซอร์/โปรไฟล์/บัญชีเฉพาะสำหรับ runtime นั้น;
• อย่าลงชื่อเข้าใช้ runtime นั้นด้วยบัญชี Apple/Google ส่วนตัว หรือโปรไฟล์ตัวจัดการรหัสผ่าน/เบราว์เซอร์ส่วนตัว

หากคุณผสมอัตลักษณ์ส่วนตัวและบริษัทใน runtime เดียวกัน คุณจะทำลายการแยกขอบเขตและเพิ่มความเสี่ยงการเปิดเผยข้อมูลส่วนตัว

แนวคิดความเชื่อถือของ Gateway และโหนด

ให้ถือว่า Gateway และโหนดเป็นโดเมนความเชื่อถือของผู้ปฏิบัติงานเดียวกัน แต่มีบทบาทต่างกัน:

• Gateway คือ control plane และพื้นผิวนโยบาย (gateway.auth, นโยบายเครื่องมือ, การกำหนดเส้นทาง)
• Node คือพื้นผิวการเรียกใช้งานระยะไกลที่จับคู่กับ Gateway นั้น (คำสั่ง การกระทำกับอุปกรณ์ ความสามารถเฉพาะโฮสต์)
• ผู้เรียกที่ยืนยันตัวตนกับ Gateway แล้วถือว่าเชื่อถือได้ในขอบเขต Gateway หลังจากจับคู่แล้ว การกระทำของโหนดถือเป็นการกระทำของผู้ปฏิบัติงานที่เชื่อถือได้บนโหนดนั้น
• ระดับขอบเขตของผู้ปฏิบัติงานและการตรวจสอบเวลาขออนุมัติสรุปไว้ใน ขอบเขตผู้ปฏิบัติงาน
• ไคลเอนต์แบ็กเอนด์แบบ direct loopback ที่ยืนยันตัวตนด้วยโทเค็น/รหัสผ่าน Gateway ที่ใช้ร่วมกันสามารถทำ RPC ภายใน control-plane ได้โดยไม่ต้องแสดงอัตลักษณ์อุปกรณ์ของผู้ใช้ นี่ไม่ใช่การข้ามการจับคู่ระยะไกลหรือเบราว์เซอร์: ไคลเอนต์เครือข่าย, ไคลเอนต์โหนด, ไคลเอนต์ device-token และอัตลักษณ์อุปกรณ์แบบชัดเจนยังคงผ่านการจับคู่และการบังคับใช้การยกระดับขอบเขต
• sessionKey คือการเลือกเส้นทาง/บริบท ไม่ใช่ auth รายผู้ใช้
• การอนุมัติ exec (รายการอนุญาต + ถาม) เป็น guardrail สำหรับเจตนาของผู้ปฏิบัติงาน ไม่ใช่การแยกแบบหลายผู้เช่าที่เป็นปฏิปักษ์
• ค่าเริ่มต้นของผลิตภัณฑ์ OpenClaw สำหรับการตั้งค่าผู้ปฏิบัติงานเดียวที่เชื่อถือได้คือการอนุญาตให้ host exec บน gateway/node ทำงานได้โดยไม่ต้องแจ้งขออนุมัติ (security="full", ask="off" เว้นแต่คุณจะทำให้เข้มงวดขึ้น) ค่าเริ่มต้นนี้เป็น UX ที่ตั้งใจ ไม่ใช่ช่องโหว่โดยตัวมันเอง
• การอนุมัติ exec ผูกกับบริบทคำขอที่แน่นอนและ operand ไฟล์ภายในเครื่องแบบ best-effort โดยตรง; แต่ไม่ได้จำลองความหมายของทุกเส้นทาง loader ของ runtime/interpreter ใช้แซนด์บ็อกซ์และการแยกโฮสต์สำหรับขอบเขตที่แข็งแรง

หากคุณต้องการแยกผู้ใช้ที่เป็นปฏิปักษ์ ให้แยกขอบเขตความเชื่อถือตามผู้ใช้/โฮสต์ OS และรัน Gateway แยกกัน

เมทริกซ์ขอบเขตความเชื่อถือ

ใช้สิ่งนี้เป็นโมเดลแบบรวดเร็วเมื่อคัดแยกความเสี่ยง:

ไม่ใช่ช่องโหว่ตามการออกแบบ

Baseline ที่เสริมความแข็งแรงใน 60 วินาที

ใช้ baseline นี้ก่อน แล้วค่อยเปิดใช้เครื่องมือซ้ำแบบเลือกเฉพาะต่อเอเจนต์ที่เชื่อถือได้:

{  gateway: {    mode: "local",    bind: "loopback",    auth: { mode: "token", token: "replace-with-long-random-token" },  },  session: {    dmScope: "per-channel-peer",  },  tools: {    profile: "messaging",    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],    fs: { workspaceOnly: true },    exec: { security: "deny", ask: "always" },    elevated: { enabled: false },  },  channels: {    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },  },}

สิ่งนี้ทำให้ Gateway อยู่เฉพาะภายในเครื่อง แยก DM และปิดเครื่องมือ control-plane/runtime โดยค่าเริ่มต้น

กฎด่วนสำหรับ inbox ที่ใช้ร่วมกัน

หากมีมากกว่าหนึ่งคนที่สามารถ DM บอตของคุณได้:

• ตั้งค่า session.dmScope: "per-channel-peer" (หรือ "per-account-channel-peer" สำหรับช่องทางหลายบัญชี)
• คง dmPolicy: "pairing" หรือ allowlist ที่เข้มงวดไว้
• อย่ารวม DM ที่ใช้ร่วมกันเข้ากับการเข้าถึงเครื่องมือแบบกว้าง
• สิ่งนี้ช่วยเสริมความแข็งแกร่งให้กล่องขาเข้าแบบร่วมมือ/ใช้ร่วมกัน แต่ไม่ได้ออกแบบมาเป็นการแยกผู้เช่าร่วมที่เป็นอันตรายเมื่อผู้ใช้ใช้สิทธิ์เขียนโฮสต์/การกำหนดค่าร่วมกัน

โมเดลการมองเห็นบริบท

OpenClaw แยกแนวคิดสองอย่าง:

• การอนุญาตทริกเกอร์: ใครสามารถทริกเกอร์เอเจนต์ได้ (dmPolicy, groupPolicy, allowlist, เกตการ mention)
• การมองเห็นบริบท: บริบทเสริมใดที่ถูกฉีดเข้าไปในอินพุตของโมเดล (เนื้อหาการตอบกลับ, ข้อความที่อ้างอิง, ประวัติเธรด, เมตาดาตาที่ส่งต่อ)

allowlist ควบคุมทริกเกอร์และการอนุญาตคำสั่ง การตั้งค่า contextVisibility ควบคุมวิธีกรองบริบทเสริม (การตอบกลับที่อ้างอิง, รากของเธรด, ประวัติที่ดึงมา):

• contextVisibility: "all" (ค่าเริ่มต้น) คงบริบทเสริมไว้ตามที่ได้รับ
• contextVisibility: "allowlist" กรองบริบทเสริมให้เหลือเฉพาะผู้ส่งที่ได้รับอนุญาตโดยการตรวจสอบ allowlist ที่ใช้งานอยู่
• contextVisibility: "allowlist_quote" ทำงานเหมือน allowlist แต่ยังคงเก็บการตอบกลับที่อ้างอิงอย่างชัดเจนไว้หนึ่งรายการ

ตั้งค่า contextVisibility ต่อช่องทางหรือต่อห้อง/การสนทนา ดูรายละเอียดการตั้งค่าได้ที่ แชตกลุ่ม

คำแนะนำการคัดแยก advisory:

• ข้อกล่าวอ้างที่แสดงเพียงว่า "โมเดลสามารถเห็นข้อความที่อ้างอิงหรือข้อความประวัติจากผู้ส่งที่ไม่ได้อยู่ใน allowlist" เป็นข้อค้นพบด้านการเสริมความแข็งแกร่งที่แก้ได้ด้วย contextVisibility ไม่ใช่การเลี่ยงขอบเขต auth หรือ sandbox ด้วยตัวเอง
• หากจะมีผลกระทบด้านความปลอดภัย รายงานยังต้องมีการสาธิตการเลี่ยงขอบเขตความไว้วางใจ (auth, นโยบาย, sandbox, การอนุมัติ หรือขอบเขตอื่นที่มีเอกสารกำกับ)

สิ่งที่การตรวจสอบ audit ตรวจ (ภาพรวมระดับสูง)

• การเข้าถึงขาเข้า (นโยบาย DM, นโยบายกลุ่ม, allowlist): คนแปลกหน้าสามารถทริกเกอร์บอตได้หรือไม่
• รัศมีผลกระทบของเครื่องมือ (เครื่องมือสิทธิ์สูง + ห้องเปิด): prompt injection อาจกลายเป็นการกระทำ shell/ไฟล์/เครือข่ายได้หรือไม่
• การเบี่ยงเบนระบบไฟล์ของ exec: เครื่องมือระบบไฟล์ที่เปลี่ยนแปลงข้อมูลถูกปฏิเสธในขณะที่ exec/process ยังใช้งานได้โดยไม่มีข้อจำกัดระบบไฟล์ของ sandbox หรือไม่
• การเบี่ยงเบนการอนุมัติของ exec (security=full, autoAllowSkills, allowlist ของ interpreter ที่ไม่มี strictInlineEval): guardrail ของ host-exec ยังทำในสิ่งที่คุณคิดอยู่หรือไม่
  • security="full" เป็นคำเตือนด้าน posture แบบกว้าง ไม่ใช่หลักฐานของบั๊ก เป็นค่าเริ่มต้นที่เลือกไว้สำหรับการตั้งค่าผู้ช่วยส่วนตัวที่เชื่อถือได้; ทำให้เข้มงวดขึ้นเฉพาะเมื่อโมเดลภัยคุกคามของคุณต้องใช้ guardrail แบบอนุมัติหรือ allowlist
• การเปิดเผยเครือข่าย (การ bind/auth ของ Gateway, Tailscale Serve/Funnel, โทเค็น auth ที่อ่อน/สั้น)
• การเปิดเผยการควบคุมเบราว์เซอร์ (โหนดระยะไกล, พอร์ต relay, ปลายทาง CDP ระยะไกล)
• สุขอนามัยดิสก์ภายในเครื่อง (สิทธิ์, symlink, config include, เส้นทาง "โฟลเดอร์ที่ซิงค์")
• Plugins (plugins โหลดโดยไม่มี allowlist ที่ชัดเจน)
• การเบี่ยงเบนนโยบาย/การกำหนดค่าผิด (ตั้งค่า sandbox docker ไว้แต่ปิดโหมด sandbox; รูปแบบ gateway.nodes.denyCommands ไม่มีผลเพราะการจับคู่เป็นชื่อคำสั่งแบบตรงเท่านั้น (เช่น system.run) และไม่ตรวจข้อความ shell; รายการ gateway.nodes.allowCommands ที่อันตราย; tools.profile="minimal" ส่วนกลางถูกแทนที่โดยโปรไฟล์ต่อเอเจนต์; เครื่องมือที่ Plugin เป็นเจ้าของเข้าถึงได้ภายใต้นโยบายเครื่องมือที่ผ่อนปรน)
• การเบี่ยงเบนความคาดหวังของรันไทม์ (เช่น สมมติว่า exec แบบ implicit ยังหมายถึง sandbox เมื่อ tools.exec.host ตอนนี้มีค่าเริ่มต้นเป็น auto หรือการตั้งค่า tools.exec.host="sandbox" อย่างชัดเจนขณะที่โหมด sandbox ปิดอยู่)
• สุขอนามัยของโมเดล (เตือนเมื่อโมเดลที่กำหนดค่าดูเป็นรุ่นเก่า; ไม่ใช่การบล็อกแบบแข็ง)

หากคุณรัน --deep OpenClaw จะพยายาม probe Gateway แบบสดตามความสามารถด้วย

แผนผังที่เก็บข้อมูลรับรอง

ใช้ส่วนนี้เมื่อตรวจสอบการเข้าถึงหรือตัดสินใจว่าจะสำรองข้อมูลใด:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• โทเค็นบอต Telegram: config/env หรือ channels.telegram.tokenFile (ไฟล์ปกติเท่านั้น; symlink จะถูกปฏิเสธ)
• โทเค็นบอต Discord: config/env หรือ SecretRef (ผู้ให้บริการ env/file/exec)
• โทเค็น Slack: config/env (channels.slack.*)
• allowlist การจับคู่:
  • ~/.openclaw/credentials/<channel>-allowFrom.json (บัญชีเริ่มต้น)
  • ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json (บัญชีที่ไม่ใช่ค่าเริ่มต้น)
• โปรไฟล์ auth ของโมเดล: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
• สถานะรันไทม์ Codex: ~/.openclaw/agents/<agentId>/agent/codex-home/
• เพย์โหลด secret ที่อิงไฟล์ (ไม่บังคับ): ~/.openclaw/secrets.json
• การนำเข้า OAuth แบบเดิม: ~/.openclaw/credentials/oauth.json

เช็กลิสต์การตรวจสอบความปลอดภัย

เมื่อ audit พิมพ์ข้อค้นพบ ให้จัดการตามลำดับความสำคัญนี้:

1. อะไรก็ตามที่ "เปิด" + เปิดใช้งานเครื่องมือ: ล็อก DM/กลุ่มก่อน (การจับคู่/allowlist) จากนั้นทำให้นโยบายเครื่องมือ/sandboxing เข้มงวดขึ้น
2. การเปิดเผยเครือข่ายสาธารณะ (LAN bind, Funnel, ไม่มี auth): แก้ไขทันที
3. การเปิดเผยการควบคุมเบราว์เซอร์ระยะไกล: ถือว่าเหมือนการเข้าถึงระดับ operator (เฉพาะ tailnet, จับคู่โหนดอย่างตั้งใจ, หลีกเลี่ยงการเปิดเผยสาธารณะ)
4. สิทธิ์: ตรวจให้แน่ใจว่า state/config/credentials/auth ไม่สามารถอ่านได้โดย group/world
5. Plugins: โหลดเฉพาะสิ่งที่คุณไว้วางใจอย่างชัดเจน
6. การเลือกโมเดล: เลือกโมเดลสมัยใหม่ที่เสริมความแข็งแกร่งด้าน instruction สำหรับบอตใดก็ตามที่มีเครื่องมือ

อภิธานศัพท์การตรวจสอบความปลอดภัย

ข้อค้นพบ audit แต่ละรายการถูกผูกกับ checkId ที่มีโครงสร้าง (เช่น gateway.bind_no_auth หรือ tools.exec.security_full_configured) คลาสความรุนแรงระดับ critical ที่พบบ่อย:

• fs.* - สิทธิ์ระบบไฟล์ของ state, config, credentials, โปรไฟล์ auth
• gateway.* - โหมด bind, auth, Tailscale, Control UI, การตั้งค่า trusted-proxy
• hooks.*, browser.*, sandbox.*, tools.exec.* - การเสริมความแข็งแกร่งรายพื้นผิว
• plugins.*, skills.* - ซัพพลายเชนของ plugin/skill และข้อค้นพบจากการสแกน
• security.exposure.* - การตรวจสอบข้ามส่วนที่นโยบายการเข้าถึงมาบรรจบกับรัศมีผลกระทบของเครื่องมือ

ดูแคตตาล็อกฉบับเต็มพร้อมระดับความรุนแรง, fix key และการรองรับ auto-fix ได้ที่ การตรวจสอบ audit ความปลอดภัย

Control UI ผ่าน HTTP

Control UI ต้องใช้ บริบทที่ปลอดภัย (HTTPS หรือ localhost) เพื่อสร้างอัตลักษณ์อุปกรณ์ gateway.controlUi.allowInsecureAuth เป็นสวิตช์ความเข้ากันได้ภายในเครื่อง:

• บน localhost อนุญาต auth ของ Control UI โดยไม่มีอัตลักษณ์อุปกรณ์เมื่อโหลดหน้าเว็บผ่าน HTTP ที่ไม่ปลอดภัย
• ไม่เลี่ยงการตรวจสอบการจับคู่
• ไม่ผ่อนคลายข้อกำหนดอัตลักษณ์อุปกรณ์ระยะไกล (ที่ไม่ใช่ localhost)

แนะนำให้ใช้ HTTPS (Tailscale Serve) หรือเปิด UI บน 127.0.0.1

สำหรับสถานการณ์ break-glass เท่านั้น gateway.controlUi.dangerouslyDisableDeviceAuth จะปิดการตรวจสอบอัตลักษณ์อุปกรณ์ทั้งหมด นี่เป็นการลดระดับความปลอดภัยอย่างรุนแรง; ปิดไว้เว้นแต่คุณกำลังดีบักอยู่และสามารถย้อนกลับได้อย่างรวดเร็ว

แยกจากแฟล็กอันตรายเหล่านั้น gateway.auth.mode: "trusted-proxy" ที่สำเร็จ สามารถยอมรับเซสชัน Control UI ระดับ operator ได้โดยไม่มีอัตลักษณ์อุปกรณ์ นี่เป็น พฤติกรรม auth-mode ที่ตั้งใจไว้ ไม่ใช่ทางลัด allowInsecureAuth และยังคง ไม่ขยายไปถึงเซสชัน Control UI บทบาท node

openclaw security audit เตือนเมื่อเปิดใช้การตั้งค่านี้

สรุปแฟล็กที่ไม่ปลอดภัยหรืออันตราย

openclaw security audit จะแจ้ง config.insecure_or_dangerous_flags เมื่อ เปิดใช้สวิตช์ดีบักที่ทราบว่าไม่ปลอดภัย/อันตราย ปล่อยค่าเหล่านี้ให้ไม่ถูกตั้งค่าใน production แฟล็กที่เปิดใช้งานแต่ละรายการจะถูกรายงานเป็นข้อค้นพบของตัวเอง หากกำหนดค่า การ suppress audit ไว้ security.audit.suppressions.active จะยังคงอยู่ใน เอาต์พุต audit ที่ใช้งานอยู่ แม้เมื่อข้อค้นพบที่ตรงกันย้ายไปที่ suppressedFindings

การกำหนดค่า reverse proxy

หากคุณรัน Gateway อยู่หลัง reverse proxy (nginx, Caddy, Traefik ฯลฯ) ให้กำหนดค่า gateway.trustedProxies เพื่อจัดการ IP ไคลเอนต์ที่ถูกส่งต่ออย่างถูกต้อง

เมื่อ Gateway ตรวจพบ proxy header จากที่อยู่ที่ ไม่ได้ อยู่ใน trustedProxies ระบบจะ ไม่ ถือว่าการเชื่อมต่อนั้นเป็นไคลเอนต์ภายในเครื่อง หากปิด auth ของ gateway การเชื่อมต่อเหล่านั้นจะถูกปฏิเสธ สิ่งนี้ป้องกันการเลี่ยง authentication ที่การเชื่อมต่อผ่าน proxy อาจดูเหมือนมาจาก localhost และได้รับความไว้วางใจโดยอัตโนมัติ

gateway.trustedProxies ยังป้อนให้ gateway.auth.mode: "trusted-proxy" ด้วย แต่ auth mode นั้นเข้มงวดกว่า:

• auth แบบ trusted-proxy ล้มเหลวแบบปิดสำหรับ proxy ที่มีแหล่งที่มาเป็น loopback ตามค่าเริ่มต้น
• reverse proxy แบบ loopback บนโฮสต์เดียวกันสามารถใช้ gateway.trustedProxies สำหรับการตรวจจับไคลเอนต์ภายในเครื่องและการจัดการ IP ที่ส่งต่อได้
• reverse proxy แบบ loopback บนโฮสต์เดียวกันสามารถผ่าน gateway.auth.mode: "trusted-proxy" ได้เฉพาะเมื่อ gateway.auth.trustedProxy.allowLoopback = true; ไม่เช่นนั้นให้ใช้ auth แบบ token/password

gateway:  trustedProxies:    - "10.0.0.1" # reverse proxy IP  # Optional. Default false.  # Only enable if your proxy cannot provide X-Forwarded-For.  allowRealIpFallback: false  auth:    mode: password    password: ${OPENCLAW_GATEWAY_PASSWORD}

เมื่อกำหนดค่า trustedProxies แล้ว Gateway จะใช้ X-Forwarded-For เพื่อระบุ IP ของไคลเอนต์ X-Real-IP จะถูกละเว้นตามค่าเริ่มต้น เว้นแต่จะตั้งค่า gateway.allowRealIpFallback: true อย่างชัดเจน

trusted proxy header ไม่ได้ทำให้การจับคู่อุปกรณ์ node ได้รับความไว้วางใจโดยอัตโนมัติ gateway.nodes.pairing.autoApproveCidrs เป็นนโยบาย operator แยกต่างหากที่ปิดตามค่าเริ่มต้น แม้เมื่อเปิดใช้งาน เส้นทาง header แบบ trusted-proxy ที่มีแหล่งที่มาเป็น loopback จะถูกยกเว้นจากการอนุมัติ node อัตโนมัติ เพราะผู้เรียกภายในเครื่องสามารถปลอม header เหล่านั้นได้ รวมถึงเมื่อเปิดใช้ auth แบบ loopback trusted-proxy อย่างชัดเจน

พฤติกรรม reverse proxy ที่ดี (เขียนทับ forwarding header ขาเข้า):

proxy_set_header X-Forwarded-For $remote_addr;proxy_set_header X-Real-IP $remote_addr;

พฤติกรรม reverse proxy ที่ไม่ดี (ต่อท้าย/คง forwarding header ที่ไม่น่าเชื่อถือ):

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

หมายเหตุ HSTS และ origin

• OpenClaw gateway ให้ความสำคัญกับภายในเครื่อง/loopback ก่อน หากคุณสิ้นสุด TLS ที่ reverse proxy ให้ตั้งค่า HSTS บนโดเมน HTTPS ที่หันเข้าหา proxy ที่นั่น
• หาก gateway สิ้นสุด HTTPS เอง คุณสามารถตั้งค่า gateway.http.securityHeaders.strictTransportSecurity เพื่อให้ส่งส่วนหัว HSTS จากการตอบกลับของ OpenClaw
• แนวทางการ deploy โดยละเอียดอยู่ใน การยืนยันตัวตนด้วย Proxy ที่เชื่อถือได้
• สำหรับการ deploy Control UI ที่ไม่ใช่ loopback จะต้องตั้งค่า gateway.controlUi.allowedOrigins ตามค่าเริ่มต้น
• gateway.controlUi.allowedOrigins: ["*"] เป็นนโยบายอนุญาต browser-origin ทั้งหมดอย่างชัดเจน ไม่ใช่ค่าเริ่มต้นที่เสริมความปลอดภัยแล้ว หลีกเลี่ยงการใช้นอกการทดสอบภายในเครื่องที่ควบคุมอย่างเข้มงวด
• ความล้มเหลวในการยืนยันตัวตน browser-origin บน loopback ยังคงถูกจำกัดอัตรา แม้เมื่อเปิดใช้ ข้อยกเว้น loopback ทั่วไป แต่คีย์การล็อกเอาต์จะถูกจำกัดขอบเขตต่อค่า Origin ที่ normalize แล้ว แทนที่จะใช้ bucket localhost ร่วมกันหนึ่งชุด
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true เปิดใช้โหมด fallback ต้นทางจากส่วนหัว Host ให้ถือว่านี่เป็นนโยบายอันตรายที่ผู้ปฏิบัติงานเลือกเอง
• ให้ถือว่า DNS rebinding และพฤติกรรมส่วนหัว proxy-host เป็นเรื่องการเสริมความปลอดภัยของการ deploy รักษา trustedProxies ให้แคบ และหลีกเลี่ยงการเปิด gateway โดยตรงสู่อินเทอร์เน็ตสาธารณะ

บันทึกเซสชันภายในเครื่องอยู่บนดิสก์

OpenClaw เก็บ transcript ของเซสชันไว้บนดิสก์ภายใต้ ~/.openclaw/agents/<agentId>/sessions/*.jsonl สิ่งนี้จำเป็นสำหรับความต่อเนื่องของเซสชันและดัชนีหน่วยความจำเซสชัน (ถ้าเปิดใช้) แต่ก็หมายความว่า process/ผู้ใช้ใดก็ตามที่มีสิทธิ์เข้าถึง filesystem สามารถอ่านบันทึกเหล่านั้นได้ ให้ถือว่าการเข้าถึงดิสก์เป็นขอบเขตความไว้วางใจ และล็อกสิทธิ์บน ~/.openclaw ให้แน่นหนา (ดูส่วน audit ด้านล่าง) หากคุณต้องการ การแยกที่เข้มงวดยิ่งขึ้นระหว่าง agent ให้รัน agent ภายใต้ผู้ใช้ OS แยกกันหรือโฮสต์แยกกัน

การเรียกใช้ Node (system.run)

หากจับคู่ node ของ macOS ไว้ Gateway จะเรียกใช้ system.run บน node นั้นได้ นี่คือ การเรียกใช้โค้ดจากระยะไกล บน Mac:

• ต้องมีการจับคู่ node (การอนุมัติ + token)
• การจับคู่ node ของ Gateway ไม่ใช่พื้นผิวการอนุมัติรายคำสั่ง แต่เป็นการสร้างตัวตน/ความไว้วางใจของ node และการออก token
• Gateway ใช้นโยบายคำสั่ง node แบบ global คร่าว ๆ ผ่าน gateway.nodes.allowCommands / denyCommands
• ควบคุมบน Mac ผ่าน Settings → Exec approvals (security + ask + allowlist)
• นโยบาย system.run ต่อ node คือไฟล์ exec approvals ของ node เอง (exec.approvals.node.*) ซึ่งอาจเข้มงวดกว่าหรือผ่อนปรนกว่านโยบาย command-ID แบบ global ของ gateway
• node ที่รันด้วย security="full" และ ask="off" กำลังทำตามโมเดล trusted-operator เริ่มต้น ให้ถือว่านี่เป็นพฤติกรรมที่คาดไว้ เว้นแต่การ deploy ของคุณจะต้องใช้ท่าทีการอนุมัติหรือ allowlist ที่เข้มงวดกว่าอย่างชัดเจน
• โหมดการอนุมัติจะผูกกับบริบทคำขอที่แน่นอน และเมื่อเป็นไปได้ จะผูกกับ operand ของสคริปต์/ไฟล์ภายในเครื่องหนึ่งรายการที่ชัดเจน หาก OpenClaw ไม่สามารถระบุไฟล์ภายในเครื่องโดยตรงเพียงหนึ่งไฟล์สำหรับคำสั่ง interpreter/runtime ได้อย่างแน่นอน การเรียกใช้ที่อิงการอนุมัติจะถูกปฏิเสธ แทนที่จะรับประกันการครอบคลุมเชิงความหมายทั้งหมด
• สำหรับ host=node การรันที่อิงการอนุมัติยังเก็บ systemRunPlan ที่เตรียมไว้แบบ canonical ด้วย การส่งต่อที่อนุมัติในภายหลังจะใช้แผนที่เก็บไว้นั้นซ้ำ และการตรวจสอบของ gateway จะปฏิเสธการแก้ไข command/cwd/session context จาก caller หลังจากสร้าง คำขออนุมัติแล้ว
• หากคุณไม่ต้องการการเรียกใช้จากระยะไกล ให้ตั้งค่า security เป็น deny และลบการจับคู่ node สำหรับ Mac เครื่องนั้น

ความแตกต่างนี้สำคัญต่อการ triage:

• node ที่จับคู่ไว้และเชื่อมต่อใหม่พร้อมประกาศรายการคำสั่งที่แตกต่างไป ไม่ใช่ช่องโหว่ในตัวมันเอง หากนโยบาย global ของ Gateway และ exec approvals ภายในเครื่องของ node ยังคงบังคับใช้ขอบเขตการเรียกใช้จริง
• รายงานที่ถือว่า metadata การจับคู่ node เป็นชั้นการอนุมัติรายคำสั่งที่ซ่อนอยู่อีกชั้น มักเป็นความสับสนด้านนโยบาย/UX ไม่ใช่การ bypass ขอบเขตความปลอดภัย

Skills แบบไดนามิก (watcher / node ระยะไกล)

OpenClaw สามารถ refresh รายการ skills ระหว่างเซสชันได้:

• Skills watcher: การเปลี่ยนแปลงใน SKILL.md สามารถอัปเดต snapshot ของ skills ใน agent turn ถัดไป
• node ระยะไกล: การเชื่อมต่อ node ของ macOS สามารถทำให้ skills เฉพาะ macOS มีสิทธิ์ใช้งานได้ (อิงจากการ probe bin)

ให้ถือว่าโฟลเดอร์ skill เป็น โค้ดที่เชื่อถือได้ และจำกัดว่าใครสามารถแก้ไขได้

โมเดลภัยคุกคาม

ผู้ช่วย AI ของคุณสามารถ:

• เรียกใช้คำสั่ง shell ใดก็ได้
• อ่าน/เขียนไฟล์
• เข้าถึงบริการเครือข่าย
• ส่งข้อความถึงใครก็ได้ (หากคุณให้สิทธิ์เข้าถึง WhatsApp)

คนที่ส่งข้อความถึงคุณสามารถ:

• พยายามหลอก AI ของคุณให้ทำสิ่งไม่ดี
• ใช้วิศวกรรมสังคมเพื่อเข้าถึงข้อมูลของคุณ
• probe รายละเอียดโครงสร้างพื้นฐาน

แนวคิดหลัก: การควบคุมการเข้าถึงก่อนความฉลาด

ความล้มเหลวส่วนใหญ่ที่นี่ไม่ใช่ exploit ซับซ้อน แต่เป็น “มีคนส่งข้อความหา bot แล้ว bot ก็ทำตามที่เขาขอ”

ท่าทีของ OpenClaw:

• ตัวตนก่อน: ตัดสินใจว่าใครคุยกับ bot ได้ (การจับคู่ DM / allowlist / “open” อย่างชัดเจน)
• ขอบเขตถัดมา: ตัดสินใจว่า bot ได้รับอนุญาตให้ทำงานที่ใด (allowlist ของกลุ่ม + mention gating, tools, sandboxing, สิทธิ์ของอุปกรณ์)
• โมเดลสุดท้าย: สมมติว่า model อาจถูกชักจูงได้ ออกแบบให้การชักจูงมีรัศมีผลกระทบจำกัด

โมเดลการอนุญาตคำสั่ง

Slash commands และ directives จะถูกรับรองเฉพาะสำหรับ ผู้ส่งที่ได้รับอนุญาต เท่านั้น การอนุญาตได้มาจาก allowlist/การจับคู่ของ channel บวกกับ commands.useAccessGroups (ดู การกำหนดค่า และ Slash commands) หาก allowlist ของ channel ว่างหรือมี "*", commands จะเปิดใช้งานสำหรับ channel นั้นโดยมีผลจริง

/exec เป็นความสะดวกเฉพาะเซสชันสำหรับผู้ปฏิบัติงานที่ได้รับอนุญาต มัน ไม่ เขียน config หรือ เปลี่ยนเซสชันอื่น

ความเสี่ยงของเครื่องมือ control plane

เครื่องมือในตัวสองรายการสามารถทำการเปลี่ยนแปลง control-plane แบบถาวรได้:

• gateway สามารถตรวจสอบ config ด้วย config.schema.lookup / config.get และสามารถเปลี่ยนแปลงถาวรด้วย config.apply, config.patch, และ update.run
• cron สามารถสร้างงานตามกำหนดเวลาที่ยังคงรันต่อหลังจาก chat/task เดิมสิ้นสุดแล้ว

เครื่องมือ runtime gateway ที่หันเข้าหา agent ยังคงปฏิเสธการเขียนทับ tools.exec.ask หรือ tools.exec.security; alias เก่า tools.bash.* จะถูก normalize ไปยังเส้นทาง exec ที่ได้รับการป้องกันเดียวกันก่อนการเขียน การแก้ไข gateway config.apply และ gateway config.patch ที่ขับเคลื่อนโดย agent จะ fail-closed ตามค่าเริ่มต้น: มีเพียงชุดแคบ ๆ ของการปรับแต่ง runtime ที่มีความเสี่ยงต่ำ, mention-gating, และเส้นทาง visible-reply เท่านั้นที่ agent ปรับได้ ค่าเริ่มต้นของ model แบบ global และ prompt overlays ยังคงอยู่ภายใต้การควบคุมของผู้ปฏิบัติงาน ดังนั้น config tree ใหม่ที่ละเอียดอ่อน จึงได้รับการป้องกัน เว้นแต่จะถูกเพิ่มเข้า allowlist โดยตั้งใจ

สำหรับ agent/surface ใดก็ตามที่จัดการเนื้อหาที่ไม่น่าเชื่อถือ ให้ deny สิ่งเหล่านี้ตามค่าเริ่มต้น:

{  tools: {    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],  },}

commands.restart=false บล็อกเฉพาะการ restart เท่านั้น มันไม่ได้ปิดใช้การดำเนินการ config/update ของ gateway

Plugins

Plugins รัน ใน process ร่วมกับ Gateway ให้ถือว่าเป็นโค้ดที่เชื่อถือได้:

• ติดตั้ง plugins จากแหล่งที่คุณเชื่อถือเท่านั้น
• ควรใช้ allowlist plugins.allow ที่ระบุชัดเจน
• ตรวจทาน config ของ plugin ก่อนเปิดใช้
• restart Gateway หลังจากเปลี่ยนแปลง plugin
• หากคุณติดตั้งหรืออัปเดต plugins (openclaw plugins install <package>, openclaw plugins update <id>) ให้ถือว่าเหมือนการรันโค้ดที่ไม่น่าเชื่อถือ:
  • เส้นทางติดตั้งคือไดเรกทอรีต่อ plugin ภายใต้ root การติดตั้ง plugin ที่ใช้งานอยู่
  • OpenClaw ไม่รันการบล็อก dangerous-code ภายในเครื่องแบบ built-in ระหว่าง install/update ใช้ security.installPolicy สำหรับการตัดสินใจ allow/block ภายในเครื่องที่ผู้ปฏิบัติงานเป็นเจ้าของ และใช้ openclaw security audit --deep สำหรับการสแกนวินิจฉัย
  • การติดตั้ง plugin จาก npm และ git จะรัน package-manager dependency convergence เฉพาะระหว่าง flow install/update ที่ชัดเจนเท่านั้น เส้นทางภายในเครื่องและ archive จะถูกถือว่าเป็นแพ็กเกจ plugin ที่สมบูรณ์ในตัว OpenClaw จะคัดลอก/อ้างอิงโดยไม่รัน npm install
  • ควรตรึงเวอร์ชันแบบ exact (@scope/pkg@1.2.3) และตรวจสอบโค้ดที่แตกออกมาบนดิสก์ก่อนเปิดใช้
  • --dangerously-force-unsafe-install เลิกใช้แล้วและไม่เปลี่ยนพฤติกรรม install/update ของ plugin อีกต่อไป
  • กำหนดค่า security.installPolicy เมื่อผู้ปฏิบัติงานต้องการคำสั่งภายในเครื่องที่เชื่อถือได้เพื่อทำการตัดสินใจ allow/block เฉพาะโฮสต์สำหรับการติดตั้ง skill และ plugin นโยบายนี้รันหลังจาก source material ถูก stage แล้ว แต่ก่อนการติดตั้งจะดำเนินต่อ ใช้กับ ClawHub skills ด้วย และไม่ถูก bypass ด้วย flag unsafe ที่เลิกใช้แล้ว

รายละเอียด: Plugins

โมเดลการเข้าถึง DM: การจับคู่, allowlist, open, disabled

ทุก channel ปัจจุบันที่รองรับ DM รองรับนโยบาย DM (dmPolicy หรือ *.dm.policy) ที่ gate DM ขาเข้า ก่อน ข้อความจะถูกประมวลผล:

• pairing (ค่าเริ่มต้น): ผู้ส่งที่ไม่รู้จักจะได้รับรหัสจับคู่สั้น ๆ และ bot จะเพิกเฉยต่อข้อความจนกว่าจะได้รับอนุมัติ รหัสหมดอายุหลัง 1 ชั่วโมง; DM ซ้ำจะไม่ส่งรหัสอีกจนกว่าจะมีการสร้างคำขอใหม่ คำขอที่รอดำเนินการถูกจำกัดที่ 3 ต่อ channel ตามค่าเริ่มต้น
• allowlist: ผู้ส่งที่ไม่รู้จักถูกบล็อก (ไม่มี pairing handshake)
• open: อนุญาตให้ทุกคน DM ได้ (สาธารณะ) ต้อง ให้ allowlist ของ channel มี "*" (opt-in อย่างชัดเจน)
• disabled: เพิกเฉยต่อ DM ขาเข้าทั้งหมด

อนุมัติผ่าน CLI:

openclaw pairing list <channel>openclaw pairing approve <channel> <code>

รายละเอียด + ไฟล์บนดิสก์: การจับคู่

การแยกเซสชัน DM (โหมดผู้ใช้หลายคน)

ตามค่าเริ่มต้น OpenClaw จะ route DM ทั้งหมดเข้าสู่เซสชันหลัก เพื่อให้ผู้ช่วยของคุณมีความต่อเนื่องข้ามอุปกรณ์และ channel หาก หลายคน สามารถ DM หา bot ได้ (DM แบบ open หรือ allowlist หลายคน) ให้พิจารณาแยกเซสชัน DM:

{  session: { dmScope: "per-channel-peer" },}

สิ่งนี้ป้องกันการรั่วไหลของบริบทข้ามผู้ใช้ ในขณะที่ยังคงแยก group chat ออกจากกัน

นี่เป็นขอบเขต messaging-context ไม่ใช่ขอบเขต host-admin หากผู้ใช้เป็นฝ่ายตรงข้ามกันและใช้โฮสต์/config Gateway เดียวกัน ให้รัน gateway แยกกันต่อขอบเขตความไว้วางใจแทน

โหมด DM ที่ปลอดภัย (แนะนำ)

ให้ถือว่า snippet ด้านบนเป็น โหมด DM ที่ปลอดภัย:

• ค่าเริ่มต้น: session.dmScope: "main" (DM ทั้งหมดใช้เซสชันเดียวกันเพื่อความต่อเนื่อง)
• ค่าเริ่มต้นของการ onboarding ผ่าน CLI ภายในเครื่อง: เขียน session.dmScope: "per-channel-peer" เมื่อยังไม่ได้ตั้งค่า (คงค่าที่ระบุชัดเจนอยู่แล้วไว้)
• โหมด DM ที่ปลอดภัย: session.dmScope: "per-channel-peer" (คู่ channel+sender แต่ละคู่ได้บริบท DM ที่แยกกัน)
• การแยก peer ข้าม channel: session.dmScope: "per-peer" (ผู้ส่งแต่ละคนได้หนึ่งเซสชันข้ามทุก channel ประเภทเดียวกัน)

หากคุณรันหลายบัญชีบน channel เดียวกัน ให้ใช้ per-account-channel-peer แทน หากบุคคลเดียวกันติดต่อคุณผ่านหลาย channel ให้ใช้ session.identityLinks เพื่อรวมเซสชัน DM เหล่านั้นเป็นตัวตน canonical หนึ่งเดียว ดู การจัดการเซสชัน และ การกำหนดค่า

Allowlists สำหรับ DM และกลุ่ม

OpenClaw มีสองชั้นแยกกันของ “ใครสามารถ trigger ฉันได้?”:

• รายการอนุญาต DM (allowFrom / channels.discord.allowFrom / channels.slack.allowFrom; เลกาซี: channels.discord.dm.allowFrom, channels.slack.dm.allowFrom): ผู้ที่ได้รับอนุญาตให้คุยกับบอตในข้อความโดยตรง
  • เมื่อ dmPolicy="pairing" การอนุมัติจะถูกเขียนไปยังที่เก็บรายการอนุญาตการจับคู่ตามขอบเขตบัญชีภายใต้ ~/.openclaw/credentials/ (<channel>-allowFrom.json สำหรับบัญชีเริ่มต้น, <channel>-<accountId>-allowFrom.json สำหรับบัญชีที่ไม่ใช่ค่าเริ่มต้น) แล้วรวมกับรายการอนุญาตจากคอนฟิก
• รายการอนุญาตกลุ่ม (เฉพาะช่องทาง): กลุ่ม/ช่องทาง/กิลด์ที่บอตจะยอมรับข้อความ
  • รูปแบบทั่วไป:
    • channels.whatsapp.groups, channels.telegram.groups, channels.imessage.groups: ค่าเริ่มต้นต่อกลุ่ม เช่น requireMention; เมื่อตั้งค่าแล้ว จะทำหน้าที่เป็นรายการอนุญาตกลุ่มด้วย (ใส่ "*" เพื่อคงพฤติกรรมอนุญาตทั้งหมด)
    • groupPolicy="allowlist" + groupAllowFrom: จำกัดว่าใครสามารถเรียกบอต ภายใน เซสชันกลุ่มได้ (WhatsApp/Telegram/Signal/iMessage/Microsoft Teams)
    • channels.discord.guilds / channels.slack.channels: รายการอนุญาตต่อพื้นผิว + ค่าเริ่มต้นการกล่าวถึง
  • การตรวจสอบกลุ่มทำงานตามลำดับนี้: groupPolicy/รายการอนุญาตกลุ่มก่อน แล้วจึงเปิดใช้งานด้วยการกล่าวถึง/ตอบกลับ
  • การตอบกลับข้อความของบอต (การกล่าวถึงโดยนัย) ไม่ ข้ามรายการอนุญาตผู้ส่ง เช่น groupAllowFrom
  • หมายเหตุด้านความปลอดภัย: ให้ถือว่า dmPolicy="open" และ groupPolicy="open" เป็นการตั้งค่าสุดท้ายเมื่อไม่มีทางเลือกอื่น ควรใช้น้อยมาก; ควรใช้การจับคู่ + รายการอนุญาต เว้นแต่คุณจะไว้วางใจสมาชิกทุกคนในห้องอย่างเต็มที่

รายละเอียด: การกำหนดค่า และ กลุ่ม

Prompt injection (คืออะไร และสำคัญอย่างไร)

Prompt injection คือการที่ผู้โจมตีสร้างข้อความเพื่อชักนำโมเดลให้ทำสิ่งที่ไม่ปลอดภัย ("ละเว้นคำสั่งของคุณ", "ดัมป์ระบบไฟล์ของคุณ", "ตามลิงก์นี้แล้วรันคำสั่ง" เป็นต้น)

แม้จะมี system prompt ที่แข็งแรง prompt injection ก็ยังไม่ได้ถูกแก้ปัญหาอย่างสมบูรณ์ กรอบป้องกันใน system prompt เป็นเพียงคำแนะนำแบบอ่อนเท่านั้น; การบังคับใช้อย่างแข็งแรงมาจากนโยบายเครื่องมือ, การอนุมัติ exec, sandboxing และรายการอนุญาตของช่องทาง (และผู้ปฏิบัติการสามารถปิดสิ่งเหล่านี้ได้โดยตั้งใจ) สิ่งที่ช่วยได้ในทางปฏิบัติ:

• ล็อก DM ขาเข้าให้แน่นหนา (การจับคู่/รายการอนุญาต)
• ควรใช้การเปิดทางด้วยการกล่าวถึงในกลุ่ม; หลีกเลี่ยงบอตแบบ "เปิดตลอด" ในห้องสาธารณะ
• ถือว่าลิงก์ ไฟล์แนบ และคำสั่งที่วางเข้ามาเป็นอันตรายโดยค่าเริ่มต้น
• รันการเรียกใช้เครื่องมือที่ละเอียดอ่อนใน sandbox; เก็บความลับไว้นอกระบบไฟล์ที่เอเจนต์เข้าถึงได้
• หมายเหตุ: sandboxing เป็นการเลือกเปิดใช้ หากปิดโหมด sandbox อยู่ host=auto โดยนัยจะชี้ไปที่โฮสต์ Gateway ส่วน host=sandbox แบบชัดเจนจะยังคงปิดแบบปลอดภัยเพราะไม่มีรันไทม์ sandbox พร้อมใช้งาน ตั้งค่า host=gateway หากคุณต้องการให้พฤติกรรมนั้นชัดเจนในคอนฟิก
• จำกัดเครื่องมือที่มีความเสี่ยงสูง (exec, browser, web_fetch, web_search) ให้ใช้ได้เฉพาะเอเจนต์ที่เชื่อถือได้หรือรายการอนุญาตที่ชัดเจน
• หากคุณเพิ่มอินเทอร์พรีเตอร์ในรายการอนุญาต (python, node, ruby, perl, php, lua, osascript) ให้เปิดใช้ tools.exec.strictInlineEval เพื่อให้รูปแบบ inline eval ยังต้องมีการอนุมัติอย่างชัดเจน
• การวิเคราะห์การอนุมัติ Shell ยังปฏิเสธรูปแบบการขยายพารามิเตอร์ POSIX ($VAR, $?, $$, $1, $@, ${…}) ภายใน heredoc ที่ไม่ใส่เครื่องหมายคำพูด ดังนั้นเนื้อหา heredoc ที่อยู่ในรายการอนุญาตจะไม่สามารถลอบใช้การขยายของ shell ผ่านการตรวจรายการอนุญาตในฐานะข้อความธรรมดาได้ ใส่เครื่องหมายคำพูดให้ตัวสิ้นสุด heredoc (เช่น <<'EOF') เพื่อเลือกใช้ความหมายของเนื้อหาแบบตัวอักษรตรงตัว; heredoc ที่ไม่ใส่เครื่องหมายคำพูดซึ่งจะขยายตัวแปรจะถูกปฏิเสธ
• การเลือกโมเดลสำคัญ: โมเดลรุ่นเก่า/เล็กกว่า/เลกาซีมีความทนทานต่อ prompt injection และการใช้เครื่องมือผิดทางน้อยกว่าอย่างมาก สำหรับเอเจนต์ที่เปิดใช้เครื่องมือ ให้ใช้โมเดลรุ่นล่าสุดที่แข็งแกร่งที่สุดและเสริมความทนทานต่อคำสั่งมากที่สุดเท่าที่มี

สัญญาณอันตรายที่ควรถือว่าไม่น่าเชื่อถือ:

• "อ่านข้อความไฟล์/URL นี้ แล้วทำตามที่บอกทุกอย่าง"
• "ละเว้น system prompt หรือกฎความปลอดภัยของคุณ"
• "เปิดเผยคำสั่งลับหรือเอาต์พุตเครื่องมือของคุณ"
• "วางเนื้อหาทั้งหมดของ ~/.openclaw หรือบันทึกของคุณ"

การล้างโทเค็นพิเศษในเนื้อหาภายนอก

OpenClaw จะตัด literal ของโทเค็นพิเศษในเทมเพลตแชต LLM แบบโฮสต์เองที่พบบ่อยออกจากเนื้อหาและเมทาดาทาภายนอกที่ถูกห่อ ก่อนถึงโมเดล กลุ่มมาร์กเกอร์ที่ครอบคลุมรวมถึงโทเค็นบทบาท/เทิร์นของ Qwen/ChatML, Llama, Gemma, Mistral, Phi และ GPT-OSS

เหตุผล:

• แบ็กเอนด์ที่เข้ากันได้กับ OpenAI ซึ่งอยู่หน้าโมเดลที่โฮสต์เอง บางครั้งจะคงโทเค็นพิเศษที่ปรากฏในข้อความผู้ใช้ไว้ แทนที่จะมาสก์ออก ผู้โจมตีที่สามารถเขียนลงในเนื้อหาภายนอกขาเข้า (หน้าที่ดึงมา, เนื้อหาอีเมล, เอาต์พุตเครื่องมือเนื้อหาไฟล์) อาจฉีดขอบเขตบทบาท assistant หรือ system ปลอม แล้วหลุดออกจากกรอบป้องกันเนื้อหาที่ถูกห่อได้
• การล้างเกิดขึ้นที่เลเยอร์การห่อเนื้อหาภายนอก ดังนั้นจึงใช้สม่ำเสมอทั้งกับเครื่องมือ fetch/read และเนื้อหาช่องทางขาเข้า แทนที่จะผูกกับผู้ให้บริการรายใดรายหนึ่ง
• การตอบกลับโมเดลขาออกมีตัวล้างแยกอยู่แล้ว ซึ่งตัด <tool_call>, <function_calls>, <system-reminder>, <previous_response> ที่รั่ว และโครงสร้างรันไทม์ภายในที่คล้ายกันออกจากคำตอบที่ผู้ใช้มองเห็น ณ ขอบเขตการส่งมอบช่องทางสุดท้าย ตัวล้างเนื้อหาภายนอกคือคู่ขาเข้าของกลไกนั้น

สิ่งนี้ไม่ได้แทนที่การเสริมความแข็งแรงอื่น ๆ ในหน้านี้ - dmPolicy, รายการอนุญาต, การอนุมัติ exec, sandboxing และ contextVisibility ยังเป็นกลไกหลัก มันปิดช่องทางเลี่ยงเฉพาะที่เลเยอร์ tokenizer ต่อสแตกที่โฮสต์เองซึ่งส่งต่อข้อความผู้ใช้พร้อมโทเค็นพิเศษแบบครบถ้วน

แฟล็กข้ามความปลอดภัยของเนื้อหาภายนอกที่ไม่ปลอดภัย

OpenClaw มีแฟล็กข้ามแบบชัดเจนที่ปิดการห่อความปลอดภัยของเนื้อหาภายนอก:

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• ฟิลด์ payload ของ Cron allowUnsafeExternalContent

คำแนะนำ:

• ปล่อยค่าเหล่านี้ไว้ไม่ตั้งค่า/false ในโปรดักชัน
• เปิดใช้ชั่วคราวเฉพาะสำหรับการดีบักที่มีขอบเขตแคบมาก
• หากเปิดใช้ ให้แยกเอเจนต์นั้นออกมา (sandbox + เครื่องมือน้อยที่สุด + เนมสเปซเซสชันเฉพาะ)

หมายเหตุความเสี่ยงของ Hooks:

• payload ของ Hook เป็นเนื้อหาที่ไม่น่าเชื่อถือ แม้การส่งจะมาจากระบบที่คุณควบคุม (เนื้อหาเมล/เอกสาร/เว็บสามารถพก prompt injection ได้)
• ระดับโมเดลที่อ่อนเพิ่มความเสี่ยงนี้ สำหรับระบบอัตโนมัติที่ขับเคลื่อนด้วย hook ควรใช้ระดับโมเดลสมัยใหม่ที่แข็งแรง และคุม policy เครื่องมือให้แน่น (tools.profile: "messaging" หรือเข้มงวดกว่า) พร้อม sandboxing เมื่อเป็นไปได้

Prompt injection ไม่จำเป็นต้องมี DM สาธารณะ

แม้ว่า มีเพียงคุณเท่านั้น ที่ส่งข้อความถึงบอตได้ prompt injection ก็ยังเกิดขึ้นได้ผ่าน เนื้อหาที่ไม่น่าเชื่อถือ ใด ๆ ที่บอตอ่าน (ผลลัพธ์ web search/fetch, หน้า browser, อีเมล, เอกสาร, ไฟล์แนบ, บันทึก/โค้ดที่วางเข้ามา) กล่าวอีกอย่างคือ ผู้ส่งไม่ใช่ พื้นผิวภัยคุกคามเพียงอย่างเดียว; ตัวเนื้อหาเอง สามารถพกคำสั่งที่เป็นปฏิปักษ์ได้

เมื่อเปิดใช้เครื่องมือ ความเสี่ยงทั่วไปคือการดูดข้อมูลบริบทออกไปหรือกระตุ้น การเรียกเครื่องมือ ลดขอบเขตความเสียหายโดย:

• ใช้ เอเจนต์อ่าน แบบอ่านอย่างเดียวหรือปิดเครื่องมือเพื่อสรุปเนื้อหาที่ไม่น่าเชื่อถือ แล้วส่งสรุปให้เอเจนต์หลักของคุณ
• ปิด web_search / web_fetch / browser สำหรับเอเจนต์ที่เปิดใช้เครื่องมือ เว้นแต่จำเป็น
• สำหรับอินพุต URL ของ OpenResponses (input_file / input_image) ให้ตั้ง gateway.http.endpoints.responses.files.urlAllowlist และ gateway.http.endpoints.responses.images.urlAllowlist ให้เข้มงวด และตั้ง maxUrlParts ให้ต่ำ รายการอนุญาตว่างจะถือว่าไม่ได้ตั้งค่า; ใช้ files.allowUrl: false / images.allowUrl: false หากคุณต้องการปิดการดึง URL ทั้งหมด
• สำหรับอินพุตไฟล์ของ OpenResponses ข้อความ input_file ที่ถอดรหัสแล้วยังถูกฉีดเป็น เนื้อหาภายนอกที่ไม่น่าเชื่อถือ อย่าพึ่งพาว่าข้อความไฟล์เชื่อถือได้เพียงเพราะ Gateway ถอดรหัสในเครื่องแล้ว บล็อกที่ฉีดเข้าไปยังคงมีมาร์กเกอร์ขอบเขต <<&lt;EXTERNAL_UNTRUSTED_CONTENT ...&gt;>> อย่างชัดเจน พร้อมเมทาดาทา Source: External แม้เส้นทางนี้จะละแบนเนอร์ SECURITY NOTICE: ที่ยาวกว่าไว้
• การห่อแบบใช้มาร์กเกอร์เดียวกันจะถูกใช้เมื่อการทำความเข้าใจสื่อดึงข้อความ จากเอกสารแนบก่อนผนวกข้อความนั้นเข้ากับ prompt ของสื่อ
• เปิดใช้ sandboxing และรายการอนุญาตเครื่องมือแบบเข้มงวดสำหรับเอเจนต์ใด ๆ ที่แตะอินพุตที่ไม่น่าเชื่อถือ
• เก็บความลับไว้นอก prompt; ส่งผ่าน env/config บนโฮสต์ Gateway แทน

แบ็กเอนด์ LLM ที่โฮสต์เอง

แบ็กเอนด์ที่โฮสต์เองและเข้ากันได้กับ OpenAI เช่น vLLM, SGLang, TGI, LM Studio, หรือสแตก tokenizer ของ Hugging Face แบบกำหนดเอง อาจต่างจากผู้ให้บริการแบบโฮสต์ในวิธีจัดการ โทเค็นพิเศษของเทมเพลตแชต หากแบ็กเอนด์ tokenize สตริง literal เช่น <|im_start|>, <|start_header_id|>, หรือ <start_of_turn> เป็น โทเค็นโครงสร้างของเทมเพลตแชตภายในเนื้อหาผู้ใช้ ข้อความที่ไม่น่าเชื่อถือสามารถพยายาม ปลอมขอบเขตบทบาทที่เลเยอร์ tokenizer ได้

OpenClaw จะตัด literal ของโทเค็นพิเศษจากกลุ่มโมเดลที่พบบ่อยออกจาก เนื้อหาภายนอกที่ถูกห่อก่อนส่งไปยังโมเดล เปิดการห่อเนื้อหาภายนอกไว้ และควรใช้การตั้งค่าแบ็กเอนด์ที่แยกหรือ escape โทเค็นพิเศษ ในเนื้อหาที่ผู้ใช้ให้มาเมื่อมีให้ใช้ ผู้ให้บริการแบบโฮสต์ เช่น OpenAI และ Anthropic ใช้การล้างฝั่งคำขอของตนเองอยู่แล้ว

ความแข็งแรงของโมเดล (หมายเหตุด้านความปลอดภัย)

ความต้านทานต่อ prompt injection ไม่ สม่ำเสมอในทุกระดับโมเดล โมเดลที่เล็กกว่า/ถูกกว่ามักเสี่ยงต่อการใช้เครื่องมือผิดทางและการ hijack คำสั่งมากกว่า โดยเฉพาะภายใต้ prompt ที่เป็นปฏิปักษ์

คำแนะนำ:

• ใช้โมเดลรุ่นล่าสุดระดับดีที่สุด สำหรับบอตใด ๆ ที่สามารถรันเครื่องมือหรือแตะไฟล์/เครือข่ายได้
• อย่าใช้ระดับรุ่นเก่า/อ่อนกว่า/เล็กกว่า สำหรับเอเจนต์ที่เปิดใช้เครื่องมือหรืออินบ็อกซ์ที่ไม่น่าเชื่อถือ; ความเสี่ยง prompt-injection สูงเกินไป
• หากจำเป็นต้องใช้โมเดลที่เล็กกว่า ให้ ลดขอบเขตความเสียหาย (เครื่องมืออ่านอย่างเดียว, sandboxing ที่แข็งแรง, การเข้าถึงระบบไฟล์น้อยที่สุด, รายการอนุญาตที่เข้มงวด)
• เมื่อรันโมเดลขนาดเล็ก ให้ เปิดใช้ sandboxing สำหรับทุกเซสชัน และ ปิด web_search/web_fetch/browser เว้นแต่อินพุตจะถูกควบคุมอย่างเข้มงวด
• สำหรับผู้ช่วยส่วนตัวแบบแชตอย่างเดียวที่มีอินพุตที่เชื่อถือได้และไม่มีเครื่องมือ โมเดลที่เล็กกว่ามักใช้ได้

Reasoning และเอาต์พุตแบบละเอียดในกลุ่ม

/reasoning, /verbose, และ /trace สามารถเปิดเผย reasoning ภายใน, เอาต์พุตเครื่องมือ หรือการวินิจฉัย Plugin ที่ ไม่ได้ตั้งใจให้ปรากฏในช่องทางสาธารณะ ในการตั้งค่ากลุ่ม ให้ถือว่าสิ่งเหล่านี้เป็น debug เท่านั้น และปิดไว้ เว้นแต่คุณต้องการใช้โดยชัดเจน

คำแนะนำ:

• ปิด /reasoning, /verbose, และ /trace ไว้ในห้องสาธารณะ
• หากเปิดใช้ ให้เปิดเฉพาะใน DM ที่เชื่อถือได้หรือห้องที่ควบคุมอย่างเข้มงวด
• จำไว้ว่า เอาต์พุต verbose และ trace อาจรวม args ของเครื่องมือ, URL, การวินิจฉัย Plugin และข้อมูลที่โมเดลเห็น

ตัวอย่างการเสริมความแข็งแรงของการกำหนดค่า

สิทธิ์ไฟล์

เก็บคอนฟิก + สถานะให้เป็นส่วนตัวบนโฮสต์ Gateway:

• ~/.openclaw/openclaw.json: 600 (ผู้ใช้อ่าน/เขียนได้เท่านั้น)
• ~/.openclaw: 700 (ผู้ใช้เท่านั้น)

openclaw doctor สามารถเตือนและเสนอให้ปรับสิทธิ์เหล่านี้ให้เข้มงวดขึ้นได้

การเปิดเผยเครือข่าย (bind, port, firewall)

Gateway รวม WebSocket + HTTP ไว้บนพอร์ตเดียว:

• ค่าเริ่มต้น: 18789
• คอนฟิก/แฟล็ก/env: gateway.port, --port, OPENCLAW_GATEWAY_PORT

พื้นผิว HTTP นี้รวม Control UI และโฮสต์ canvas:

• Control UI (แอสเซ็ต SPA) (base path เริ่มต้น /)
• โฮสต์ Canvas: /__openclaw__/canvas/ และ /__openclaw__/a2ui/ (HTML/JS ตามอำเภอใจ; ให้ถือว่าเป็นเนื้อหาที่ไม่น่าเชื่อถือ)

หากคุณโหลดเนื้อหา canvas ใน browser ปกติ ให้ถือว่าเหมือนเว็บเพจที่ไม่น่าเชื่อถืออื่น ๆ:

• อย่าเปิดเผยโฮสต์ canvas ต่อเครือข่าย/ผู้ใช้ที่ไม่น่าเชื่อถือ
• อย่าให้เนื้อหา canvas ใช้ origin เดียวกับพื้นผิวเว็บที่มีสิทธิ์สูง เว้นแต่คุณจะเข้าใจผลกระทบอย่างถ่องแท้

โหมด bind ควบคุมตำแหน่งที่ Gateway รอฟัง:

• gateway.bind: "loopback" (ค่าเริ่มต้น): เฉพาะไคลเอนต์ในเครื่องเท่านั้นที่เชื่อมต่อได้
• การ bind ที่ไม่ใช่ loopback ("lan", "tailnet", "custom") ขยายพื้นผิวการโจมตี ใช้เฉพาะเมื่อมีการยืนยันตัวตนของ Gateway (โทเค็น/รหัสผ่านที่ใช้ร่วมกัน หรือพร็อกซีที่เชื่อถือได้ซึ่งกำหนดค่าอย่างถูกต้อง) และ firewall จริง

หลักปฏิบัติโดยประมาณ:

• ควรใช้ Tailscale Serve แทนการ bind กับ LAN (Serve เก็บ Gateway ไว้บน loopback และให้ Tailscale จัดการการเข้าถึง)
• หากจำเป็นต้อง bind กับ LAN ให้ตั้ง firewall พอร์ตด้วย allowlist ของ IP ต้นทางแบบจำกัดเข้มงวด; อย่า port-forward แบบกว้าง
• ห้ามเปิดเผย Gateway แบบไม่ยืนยันตัวตนบน 0.0.0.0

การ publish พอร์ต Docker ด้วย UFW

หากคุณรัน OpenClaw ด้วย Docker บน VPS โปรดจำไว้ว่าพอร์ต container ที่ publish (-p HOST:CONTAINER หรือ Compose ports:) จะถูก route ผ่าน forwarding chains ของ Docker ไม่ใช่เฉพาะกฎ INPUT ของโฮสต์เท่านั้น

เพื่อให้ทราฟฟิก Docker สอดคล้องกับนโยบาย firewall ของคุณ ให้บังคับใช้กฎใน DOCKER-USER (chain นี้จะถูกประเมินก่อนกฎ accept ของ Docker เอง) ในดิสโทรสมัยใหม่หลายตัว iptables/ip6tables ใช้ frontend iptables-nft และยังคงนำกฎเหล่านี้ไปใช้กับ backend nftables

ตัวอย่าง allowlist ขั้นต่ำ (IPv4):

# /etc/ufw/after.rules (append as its own *filter section)*filter:DOCKER-USER - [0:0]-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN-A DOCKER-USER -s 127.0.0.0/8 -j RETURN-A DOCKER-USER -s 10.0.0.0/8 -j RETURN-A DOCKER-USER -s 172.16.0.0/12 -j RETURN-A DOCKER-USER -s 192.168.0.0/16 -j RETURN-A DOCKER-USER -s 100.64.0.0/10 -j RETURN-A DOCKER-USER -p tcp --dport 80 -j RETURN-A DOCKER-USER -p tcp --dport 443 -j RETURN-A DOCKER-USER -m conntrack --ctstate NEW -j DROP-A DOCKER-USER -j RETURNCOMMIT

IPv6 มีตารางแยกต่างหาก เพิ่มนโยบายที่ตรงกันใน /etc/ufw/after6.rules หาก เปิดใช้ Docker IPv6

หลีกเลี่ยงการ hardcode ชื่อ interface เช่น eth0 ใน snippet เอกสาร ชื่อ interface แตกต่างกันไปตาม image ของ VPS (ens3, enp* ฯลฯ) และการจับคู่ผิดอาจทำให้ กฎ deny ของคุณถูกข้ามโดยไม่ตั้งใจ

การตรวจสอบอย่างรวดเร็วหลัง reload:

ufw reloadiptables -S DOCKER-USERip6tables -S DOCKER-USERnmap -sT -p 1-65535 <public-ip> --open

พอร์ตภายนอกที่คาดไว้ควรมีเฉพาะสิ่งที่คุณตั้งใจเปิดเผยเท่านั้น (สำหรับการตั้งค่าส่วนใหญ่: SSH + พอร์ต reverse proxy ของคุณ)

การค้นพบ mDNS/Bonjour

เมื่อเปิดใช้ Plugin bonjour ที่ bundled มา Gateway จะ broadcast การมีอยู่ของตัวเองผ่าน mDNS (_openclaw-gw._tcp บนพอร์ต 5353) สำหรับการค้นพบอุปกรณ์ในเครื่อง ในโหมดเต็ม ข้อมูลนี้รวม TXT records ที่อาจเปิดเผยรายละเอียดการปฏิบัติงาน:

• cliPath: path ระบบไฟล์แบบเต็มไปยัง binary ของ CLI (เปิดเผย username และตำแหน่งติดตั้ง)
• sshPort: ประกาศความพร้อมใช้งาน SSH บนโฮสต์
• displayName, lanHost: ข้อมูล hostname

ข้อพิจารณาด้านความปลอดภัยในการปฏิบัติงาน: การ broadcast รายละเอียดโครงสร้างพื้นฐานทำให้ผู้ใดก็ตามบนเครือข่ายท้องถิ่นสอดแนมได้ง่ายขึ้น แม้แต่ข้อมูลที่ดู “ไม่เป็นอันตราย” เช่น path ระบบไฟล์และความพร้อมใช้งาน SSH ก็ช่วยให้ผู้โจมตีทำแผนที่สภาพแวดล้อมของคุณได้

คำแนะนำ:

1. ปิด Bonjour ไว้ เว้นแต่จำเป็นต้องใช้การค้นพบบน LAN Bonjour เริ่มทำงานอัตโนมัติบนโฮสต์ macOS และเป็นแบบ opt-in ที่อื่น; URL ของ Gateway โดยตรง, Tailnet, SSH หรือ DNS-SD แบบ wide-area ช่วยหลีกเลี่ยง multicast ในเครื่อง

2. โหมด minimal (ค่าเริ่มต้นเมื่อเปิดใช้ Bonjour, แนะนำสำหรับ gateway ที่เปิดเผย): ละเว้นฟิลด์ที่ละเอียดอ่อนจาก broadcast mDNS:

   {  discovery: {    mdns: { mode: "minimal" },  },}

3. ปิดโหมด mDNS หากคุณต้องการเปิด Plugin ไว้แต่ระงับการค้นพบอุปกรณ์ในเครื่อง:

   {  discovery: {    mdns: { mode: "off" },  },}

4. โหมด full (opt-in): รวม cliPath + sshPort ใน TXT records:

   {  discovery: {    mdns: { mode: "full" },  },}

5. ตัวแปรสภาพแวดล้อม (ทางเลือก): ตั้ง OPENCLAW_DISABLE_BONJOUR=1 เพื่อปิดใช้ mDNS โดยไม่ต้องเปลี่ยน config

เมื่อเปิดใช้ Bonjour ในโหมด minimal Gateway จะ broadcast ข้อมูลเพียงพอสำหรับการค้นพบอุปกรณ์ (role, gatewayPort, transport) แต่จะละเว้น cliPath และ sshPort แอปที่ต้องการข้อมูล path ของ CLI สามารถดึงข้อมูลผ่านการเชื่อมต่อ WebSocket ที่ยืนยันตัวตนแล้วแทน

ล็อกดาวน์ Gateway WebSocket (auth ในเครื่อง)

Gateway auth จำเป็นตามค่าเริ่มต้น หากไม่ได้กำหนด path สำหรับ gateway auth ที่ถูกต้อง Gateway จะปฏิเสธการเชื่อมต่อ WebSocket (fail-closed)

Onboarding จะสร้าง token ตามค่าเริ่มต้น (แม้สำหรับ loopback) ดังนั้น client ในเครื่องต้องยืนยันตัวตน

ตั้ง token เพื่อให้ client WS ทั้งหมด ต้องยืนยันตัวตน:

{  gateway: {    auth: { mode: "token", token: "your-token" },  },}

Doctor สามารถสร้างให้คุณได้: openclaw doctor --generate-gateway-token

ทางเลือก: pin TLS ระยะไกลด้วย gateway.remote.tlsFingerprint เมื่อใช้ wss:// Plaintext ws:// ได้รับการยอมรับสำหรับ loopback, IP literal ส่วนตัว, .local และ URL gateway ของ Tailnet *.ts.net สำหรับชื่อ private-DNS ที่เชื่อถือได้อื่น ให้ตั้ง OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 บน process ของ client เป็น break-glass สิ่งนี้ตั้งใจให้เป็นเฉพาะ process environment ไม่ใช่ key config ใน openclaw.json เส้นทาง mobile pairing และ gateway แบบ manual หรือ scanned ของ Android เข้มงวดกว่า: cleartext ได้รับการยอมรับสำหรับ loopback แต่ private-LAN, link-local, .local และ hostname ที่ไม่มี dot ต้องใช้ TLS เว้นแต่คุณจะ opt into เส้นทาง cleartext ของ private-network ที่เชื่อถือได้อย่างชัดเจน

การจับคู่อุปกรณ์ในเครื่อง:

• การจับคู่อุปกรณ์ได้รับการอนุมัติอัตโนมัติสำหรับการเชื่อมต่อ local loopback โดยตรงเพื่อให้ client บนโฮสต์เดียวกันทำงานลื่นไหล
• OpenClaw ยังมี path self-connect backend/container-local แบบแคบสำหรับ flow helper แบบ shared-secret ที่เชื่อถือได้
• การเชื่อมต่อ Tailnet และ LAN รวมถึง tailnet bind บนโฮสต์เดียวกัน ถือเป็น remote สำหรับการจับคู่และยังต้องได้รับการอนุมัติ
• หลักฐาน forwarded-header บนคำขอ loopback ทำให้ locality แบบ loopback ไม่ผ่านคุณสมบัติ การอนุมัติอัตโนมัติสำหรับ metadata-upgrade ถูก scoped อย่างแคบ ดู การจับคู่ Gateway สำหรับกฎทั้งสองข้อ

โหมด Auth:

• gateway.auth.mode: "token": bearer token ร่วมกัน (แนะนำสำหรับการตั้งค่าส่วนใหญ่)
• gateway.auth.mode: "password": password auth (ควรตั้งผ่าน env: OPENCLAW_GATEWAY_PASSWORD)
• gateway.auth.mode: "trusted-proxy": เชื่อถือ reverse proxy ที่รู้ตัวตนเพื่อยืนยันตัวตนผู้ใช้และส่งตัวตนผ่าน header (ดู Trusted Proxy Auth)

Checklist การหมุนเวียน (token/password):

1. สร้าง/ตั้ง secret ใหม่ (gateway.auth.token หรือ OPENCLAW_GATEWAY_PASSWORD)
2. Restart Gateway (หรือ restart แอป macOS หากแอปควบคุม Gateway อยู่)
3. อัปเดต client ระยะไกลใด ๆ (gateway.remote.token / .password บนเครื่องที่เรียกเข้า Gateway)
4. ตรวจสอบว่าคุณไม่สามารถเชื่อมต่อด้วย credential เก่าได้อีกต่อไป

header ตัวตนของ Tailscale Serve

เมื่อ gateway.auth.allowTailscale เป็น true (ค่าเริ่มต้นสำหรับ Serve), OpenClaw ยอมรับ header ตัวตนของ Tailscale Serve (tailscale-user-login) สำหรับการยืนยันตัวตน Control UI/WebSocket OpenClaw ตรวจสอบตัวตนโดย resolve ที่อยู่ x-forwarded-for ผ่าน daemon Tailscale ในเครื่อง (tailscale whois) และจับคู่กับ header สิ่งนี้จะ trigger เฉพาะสำหรับคำขอที่เข้าถึง loopback และมี x-forwarded-for, x-forwarded-proto และ x-forwarded-host ตามที่ Tailscale inject เข้ามา สำหรับ path ตรวจสอบตัวตน async นี้ ความพยายามที่ล้มเหลวสำหรับ {scope, ip} เดียวกัน จะถูก serialize ก่อนที่ limiter จะบันทึกความล้มเหลว ดังนั้น retry ที่ผิดพร้อมกัน จาก client Serve รายเดียวจึงสามารถ lock out ความพยายามครั้งที่สองได้ทันที แทนที่จะ race ผ่านไปเป็น mismatch ธรรมดาสองครั้ง endpoint ของ HTTP API (เช่น /v1/*, /tools/invoke และ /api/channels/*) ไม่ ใช้ auth จาก identity-header ของ Tailscale แต่ยังคงทำตามโหมด HTTP auth ที่กำหนดไว้ของ gateway

หมายเหตุขอบเขตสำคัญ:

• Gateway HTTP bearer auth เท่ากับการเข้าถึง operator แบบทั้งหมดหรือไม่มีเลยโดยผลลัพธ์
• ให้ถือว่า credential ที่เรียก /v1/chat/completions, /v1/responses, route ของ Plugin เช่น /api/v1/admin/rpc หรือ /api/channels/* ได้ เป็น secret ของ operator ที่มีสิทธิ์เต็มสำหรับ gateway นั้น
• บน surface HTTP ที่เข้ากันได้กับ OpenAI, shared-secret bearer auth จะกู้คืน scope operator เริ่มต้นแบบเต็ม (operator.admin, operator.approvals, operator.pairing, operator.read, operator.talk.secrets, operator.write) และ semantics ของ owner สำหรับ agent turns; ค่า x-openclaw-scopes ที่แคบกว่าไม่ลดสิทธิ์ของ path shared-secret นั้น
• semantics ของ scope ต่อคำขอบน HTTP ใช้เฉพาะเมื่อคำขอมาจากโหมดที่มีตัวตน เช่น trusted proxy auth หรือจาก private ingress แบบ no-auth ที่ชัดเจน
• ในโหมดที่มีตัวตนเหล่านั้น หากละเว้น x-openclaw-scopes จะ fallback ไปยังชุด scope เริ่มต้นปกติของ operator; ส่ง header อย่างชัดเจนเมื่อคุณต้องการชุด scope ที่แคบกว่า header ระดับ owner ที่เข้ากันได้กับ OpenAI เช่น x-openclaw-model ต้องใช้ operator.admin เมื่อ scopes ถูกจำกัดให้แคบลง
• /tools/invoke และ endpoint ประวัติ session ของ HTTP ทำตามกฎ shared-secret เดียวกัน: token/password bearer auth ถูกถือเป็นการเข้าถึง operator แบบเต็มที่นั่นเช่นกัน ขณะที่โหมดที่มีตัวตนยังคงเคารพ scopes ที่ประกาศไว้
• อย่าแชร์ credential เหล่านี้กับ caller ที่ไม่น่าเชื่อถือ; ควรใช้ gateway แยกกันตามขอบเขตความเชื่อถือ

สมมติฐานความเชื่อถือ: auth ของ Serve แบบไม่มี token สมมติว่าโฮสต์ gateway เชื่อถือได้ อย่าถือว่าสิ่งนี้ป้องกัน process บนโฮสต์เดียวกันที่เป็นอันตรายได้ หาก code ในเครื่อง ที่ไม่น่าเชื่อถืออาจรันบนโฮสต์ gateway ให้ปิด gateway.auth.allowTailscale และบังคับใช้ shared-secret auth อย่างชัดเจนด้วย gateway.auth.mode: "token" หรือ "password"

กฎความปลอดภัย: อย่า forward header เหล่านี้จาก reverse proxy ของคุณเอง หาก คุณ terminate TLS หรือ proxy หน้า gateway ให้ปิด gateway.auth.allowTailscale และใช้ shared-secret auth (gateway.auth.mode: "token" หรือ "password") หรือ Trusted Proxy Auth แทน

Trusted proxies:

• หากคุณ terminate TLS หน้า Gateway ให้ตั้ง gateway.trustedProxies เป็น IP ของ proxy ของคุณ
• OpenClaw จะเชื่อถือ x-forwarded-for (หรือ x-real-ip) จาก IP เหล่านั้นเพื่อระบุ IP ของ client สำหรับการตรวจสอบการจับคู่ในเครื่องและการตรวจสอบ HTTP auth/local
• ตรวจสอบให้แน่ใจว่า proxy ของคุณ เขียนทับ x-forwarded-for และบล็อกการเข้าถึงพอร์ต Gateway โดยตรง

ดู Tailscale และ ภาพรวม Web

การควบคุม browser ผ่าน node host (แนะนำ)

หาก Gateway ของคุณอยู่ระยะไกลแต่ browser รันบนเครื่องอื่น ให้รัน node host บนเครื่อง browser และให้ Gateway proxy action ของ browser (ดู เครื่องมือ Browser) ให้ถือว่า node pairing เหมือนการเข้าถึง admin

รูปแบบที่แนะนำ:

• เก็บ Gateway และ node host ไว้บน tailnet เดียวกัน (Tailscale)
• จับคู่ node อย่างตั้งใจ; ปิดการ route proxy ของ browser หากคุณไม่ต้องการใช้

หลีกเลี่ยง:

• การเปิดเผยพอร์ต relay/control ผ่าน LAN หรืออินเทอร์เน็ตสาธารณะ
• Tailscale Funnel สำหรับ endpoint ควบคุม browser (เปิดเผยสาธารณะ)

Secret บนดิสก์

ให้สันนิษฐานว่าทุกอย่างภายใต้ ~/.openclaw/ (หรือ $OPENCLAW_STATE_DIR/) อาจมี secret หรือข้อมูลส่วนตัว:

• openclaw.json: config อาจรวม token (gateway, remote gateway), การตั้งค่า provider และ allowlist
• credentials/**: credential ของ channel (ตัวอย่าง: cred ของ WhatsApp), allowlist สำหรับ pairing, import OAuth legacy
• agents/<agentId>/agent/auth-profiles.json: API keys, token profiles, OAuth tokens และ keyRef/tokenRef แบบ optional
• agents/<agentId>/agent/codex-home/**: บัญชี app-server ของ Codex ต่อ agent, config, skills, plugins, สถานะ native thread และ diagnostics
• secrets.json (optional): payload secret แบบ file-backed ที่ใช้โดย provider SecretRef แบบ file (secrets.providers)
• agents/<agentId>/agent/auth.json: ไฟล์ compatibility legacy รายการ api_key แบบ static จะถูก scrub เมื่อพบ
• agents/<agentId>/sessions/**: transcript ของ session (*.jsonl) + metadata การ route (sessions.json) ที่อาจมีข้อความส่วนตัวและ output ของ tool
• package Plugin ที่ bundled มา: Plugin ที่ติดตั้งแล้ว (รวมถึง node_modules/ ของ Plugin เหล่านั้น)
• sandboxes/**: workspace sandbox ของ tool; สามารถสะสมสำเนาไฟล์ที่คุณอ่าน/เขียนภายใน sandbox

เคล็ดลับการ hardening:

• ตั้งค่าสิทธิ์ให้รัดกุม (700 สำหรับไดเรกทอรี, 600 สำหรับไฟล์)
• ใช้การเข้ารหัสดิสก์ทั้งลูกบนโฮสต์ Gateway
• หากโฮสต์ถูกใช้งานร่วมกัน ควรใช้บัญชีผู้ใช้ OS เฉพาะสำหรับ Gateway

ไฟล์ .env ของเวิร์กสเปซ

OpenClaw โหลดไฟล์ .env ภายในเวิร์กสเปซสำหรับเอเจนต์และเครื่องมือ แต่จะไม่ยอมให้ไฟล์เหล่านั้นเขียนทับการควบคุมรันไทม์ของ Gateway แบบเงียบ ๆ

• ตัวแปรสภาพแวดล้อมของข้อมูลรับรองผู้ให้บริการจะถูกบล็อกจากไฟล์ .env ของเวิร์กสเปซที่ไม่น่าเชื่อถือ ตัวอย่างได้แก่ GEMINI_API_KEY, GOOGLE_API_KEY, XAI_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY, DEEPSEEK_API_KEY, PERPLEXITY_API_KEY, BRAVE_API_KEY, TAVILY_API_KEY, EXA_API_KEY, FIRECRAWL_API_KEY และคีย์ยืนยันตัวตนของผู้ให้บริการที่ประกาศโดย Plugin ที่เชื่อถือได้ซึ่งติดตั้งไว้ ให้วางข้อมูลรับรองผู้ให้บริการไว้ในสภาพแวดล้อมของกระบวนการ Gateway, ~/.openclaw/.env ($OPENCLAW_STATE_DIR/.env), บล็อก env ของการกำหนดค่า หรือการนำเข้าจาก login-shell แบบเลือกใช้
• คีย์ใด ๆ ที่ขึ้นต้นด้วย OPENCLAW_* จะถูกบล็อกจากไฟล์ .env ของเวิร์กสเปซที่ไม่น่าเชื่อถือ
• การตั้งค่า endpoint ของช่องทางสำหรับ Matrix, Mattermost, IRC และ Synology Chat ก็จะถูกบล็อกจากการเขียนทับผ่าน .env ของเวิร์กสเปซเช่นกัน ดังนั้นเวิร์กสเปซที่โคลนมาจะไม่สามารถเปลี่ยนเส้นทางทราฟฟิกของตัวเชื่อมต่อที่บันเดิลไว้ผ่านการกำหนดค่า endpoint ภายในเครื่องได้ คีย์ env ของ endpoint (เช่น MATRIX_HOMESERVER, MATTERMOST_URL, IRC_HOST, SYNOLOGY_CHAT_INCOMING_URL) ต้องมาจากสภาพแวดล้อมของกระบวนการ Gateway หรือ env.shellEnv ไม่ใช่จาก .env ที่โหลดจากเวิร์กสเปซ
• การบล็อกนี้เป็นแบบ fail-closed: ตัวแปรควบคุมรันไทม์ใหม่ที่เพิ่มในรุ่นอนาคตจะไม่สามารถสืบทอดจาก .env ที่เช็กอินไว้หรือที่ผู้โจมตีจัดหาให้ได้ คีย์จะถูกละเว้นและ Gateway จะคงค่าของตัวเองไว้
• ตัวแปรสภาพแวดล้อมของกระบวนการ/OS ที่เชื่อถือได้, dotenv รันไทม์ส่วนกลาง, env ของการกำหนดค่า และการนำเข้าจาก login-shell ที่เปิดใช้ยังคงมีผลอยู่ ข้อจำกัดนี้มีผลเฉพาะกับการโหลดไฟล์ .env ของเวิร์กสเปซเท่านั้น

เหตุผล: ไฟล์ .env ของเวิร์กสเปซมักอยู่ติดกับโค้ดเอเจนต์ ถูกคอมมิตโดยไม่ตั้งใจ หรือถูกเขียนโดยเครื่องมือ การบล็อกข้อมูลรับรองผู้ให้บริการช่วยป้องกันไม่ให้เวิร์กสเปซที่โคลนมาแทนที่ด้วยบัญชีผู้ให้บริการที่ผู้โจมตีควบคุม การบล็อกทั้งคำนำหน้า OPENCLAW_* หมายความว่าการเพิ่มแฟล็ก OPENCLAW_* ใหม่ในภายหลังจะไม่มีทางถดถอยไปเป็นการสืบทอดแบบเงียบ ๆ จากสถานะของเวิร์กสเปซ

บันทึกและทรานสคริปต์ (การปกปิดข้อมูลและการเก็บรักษา)

บันทึกและทรานสคริปต์อาจรั่วไหลข้อมูลอ่อนไหวได้ แม้ว่าการควบคุมการเข้าถึงจะถูกต้องแล้วก็ตาม:

• บันทึกของ Gateway อาจมีสรุปเครื่องมือ ข้อผิดพลาด และ URL
• ทรานสคริปต์ของเซสชันอาจมีความลับที่วางไว้ เนื้อหาไฟล์ เอาต์พุตคำสั่ง และลิงก์

คำแนะนำ:

• เปิดการปกปิดข้อมูลในบันทึกและทรานสคริปต์ไว้ (logging.redactSensitive: "tools"; ค่าเริ่มต้น)
• เพิ่มรูปแบบกำหนดเองสำหรับสภาพแวดล้อมของคุณผ่าน logging.redactPatterns (โทเค็น ชื่อโฮสต์ URL ภายใน)
• เมื่อต้องแชร์ข้อมูลวินิจฉัย ควรใช้ openclaw status --all (วางได้ทันทีและปกปิดความลับแล้ว) แทนบันทึกดิบ
• ตัดทรานสคริปต์เซสชันและไฟล์บันทึกเก่าทิ้งหากคุณไม่ต้องการเก็บไว้นาน

รายละเอียด: การบันทึก

DM: จับคู่เป็นค่าเริ่มต้น

{  channels: { whatsapp: { dmPolicy: "pairing" } },}

กลุ่ม: ต้องมีการ mention ทุกที่

{  "channels": {    "whatsapp": {      "groups": {        "*": { "requireMention": true }      }    }  },  "agents": {    "list": [      {        "id": "main",        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }      }    ]  }}

ในแชตกลุ่ม ให้ตอบเฉพาะเมื่อถูก mention อย่างชัดเจนเท่านั้น

แยกหมายเลข (WhatsApp, Signal, Telegram)

สำหรับช่องทางที่อิงหมายเลขโทรศัพท์ ให้พิจารณาใช้งาน AI ของคุณบนหมายเลขโทรศัพท์แยกจากหมายเลขส่วนตัว:

• หมายเลขส่วนตัว: บทสนทนาของคุณยังเป็นส่วนตัว
• หมายเลขบอต: AI จัดการหมายเลขเหล่านี้ภายใต้ขอบเขตที่เหมาะสม

โหมดอ่านอย่างเดียว (ผ่าน sandbox และเครื่องมือ)

คุณสามารถสร้างโปรไฟล์อ่านอย่างเดียวได้โดยผสาน:

• agents.defaults.sandbox.workspaceAccess: "ro" (หรือ "none" หากไม่ให้เข้าถึงเวิร์กสเปซ)
• รายการอนุญาต/ปฏิเสธเครื่องมือที่บล็อก write, edit, apply_patch, exec, process และอื่น ๆ

ตัวเลือกการเพิ่มความแข็งแกร่งเพิ่มเติม:

• tools.exec.applyPatch.workspaceOnly: true (ค่าเริ่มต้น): รับประกันว่า apply_patch จะไม่สามารถเขียน/ลบภายนอกไดเรกทอรีเวิร์กสเปซได้ แม้เมื่อปิด sandboxing ตั้งเป็น false เฉพาะเมื่อคุณตั้งใจให้ apply_patch แตะไฟล์นอกเวิร์กสเปซ
• tools.fs.workspaceOnly: true (เลือกได้): จำกัดพาธ read/write/edit/apply_patch และพาธโหลดภาพพรอมป์เนทีฟอัตโนมัติให้อยู่ในไดเรกทอรีเวิร์กสเปซ (มีประโยชน์หากวันนี้คุณอนุญาตพาธแบบสัมบูรณ์และต้องการแนวป้องกันเดียว)
• จำกัดรากของระบบไฟล์ให้แคบ: หลีกเลี่ยงรากที่กว้าง เช่น ไดเรกทอรี home ของคุณสำหรับเวิร์กสเปซเอเจนต์/เวิร์กสเปซ sandbox รากที่กว้างอาจเปิดเผยไฟล์ภายในเครื่องที่อ่อนไหว (เช่น สถานะ/การกำหนดค่าใต้ ~/.openclaw) ให้กับเครื่องมือระบบไฟล์

baseline ที่ปลอดภัย (คัดลอก/วาง)

การกำหนดค่า "ค่าเริ่มต้นที่ปลอดภัย" แบบหนึ่งที่ทำให้ Gateway เป็นส่วนตัว ต้องจับคู่ DM และหลีกเลี่ยงบอตกลุ่มที่เปิดตลอดเวลา:

{  gateway: {    mode: "local",    bind: "loopback",    port: 18789,    auth: { mode: "token", token: "your-long-random-token" },  },  channels: {    whatsapp: {      dmPolicy: "pairing",      groups: { "*": { requireMention: true } },    },  },}

หากคุณต้องการให้การเรียกใช้เครื่องมือ "ปลอดภัยขึ้นโดยค่าเริ่มต้น" ด้วย ให้เพิ่ม sandbox พร้อมปฏิเสธเครื่องมืออันตรายสำหรับเอเจนต์ที่ไม่ใช่เจ้าของ (ตัวอย่างอยู่ด้านล่างใต้ "โปรไฟล์การเข้าถึงต่อเอเจนต์")

baseline ในตัวสำหรับรอบเอเจนต์ที่ขับเคลื่อนด้วยแชต: ผู้ส่งที่ไม่ใช่เจ้าของไม่สามารถใช้เครื่องมือ cron หรือ gateway ได้

Sandboxing (แนะนำ)

เอกสารเฉพาะ: Sandboxing

สองแนวทางที่เสริมกัน:

• เรียกใช้ Gateway ทั้งหมดใน Docker (ขอบเขตคอนเทนเนอร์): Docker
• Tool sandbox (agents.defaults.sandbox, host gateway + เครื่องมือที่แยกด้วย sandbox; Docker เป็น backend ค่าเริ่มต้น): Sandboxing

พิจารณาการเข้าถึงเวิร์กสเปซของเอเจนต์ภายใน sandbox ด้วย:

• agents.defaults.sandbox.workspaceAccess: "none" (ค่าเริ่มต้น) ทำให้เวิร์กสเปซเอเจนต์อยู่นอกขอบเขตการเข้าถึง; เครื่องมือจะทำงานกับเวิร์กสเปซ sandbox ใต้ ~/.openclaw/sandboxes
• agents.defaults.sandbox.workspaceAccess: "ro" เมานต์เวิร์กสเปซเอเจนต์แบบอ่านอย่างเดียวที่ /agent (ปิดใช้ write/edit/apply_patch)
• agents.defaults.sandbox.workspaceAccess: "rw" เมานต์เวิร์กสเปซเอเจนต์แบบอ่าน/เขียนที่ /workspace
• sandbox.docker.binds เพิ่มเติมจะถูกตรวจสอบกับพาธต้นทางที่ทำให้เป็นรูปแบบปกติและ canonicalized แล้ว กลเม็ด parent-symlink และนามแฝง canonical home ยังคง fail closed หาก resolve เข้าไปยังรากที่ถูกบล็อก เช่น /etc, /var/run หรือไดเรกทอรีข้อมูลรับรองใต้ home ของ OS

แนวป้องกันการมอบหมาย sub-agent

หากคุณอนุญาตเครื่องมือเซสชัน ให้ถือว่าการรัน sub-agent ที่มอบหมายเป็นการตัดสินใจด้านขอบเขตอีกจุดหนึ่ง:

• ปฏิเสธ sessions_spawn เว้นแต่เอเจนต์จำเป็นต้องมอบหมายงานจริง ๆ
• จำกัด agents.defaults.subagents.allowAgents และ override agents.list[].subagents.allowAgents ต่อเอเจนต์ใด ๆ ให้เฉพาะเอเจนต์เป้าหมายที่ทราบว่าปลอดภัย
• สำหรับ workflow ใด ๆ ที่ต้องคงอยู่ใน sandbox ให้เรียก sessions_spawn ด้วย sandbox: "require" (ค่าเริ่มต้นคือ inherit)
• sandbox: "require" จะล้มเหลวอย่างรวดเร็วเมื่อรันไทม์ลูกเป้าหมายไม่ได้อยู่ใน sandbox

ความเสี่ยงของการควบคุมเบราว์เซอร์

การเปิดใช้การควบคุมเบราว์เซอร์ทำให้โมเดลสามารถควบคุมเบราว์เซอร์จริงได้ หากโปรไฟล์เบราว์เซอร์นั้นมีเซสชันที่ล็อกอินไว้อยู่แล้ว โมเดลสามารถ เข้าถึงบัญชีและข้อมูลเหล่านั้นได้ ให้ถือว่าโปรไฟล์เบราว์เซอร์เป็น สถานะอ่อนไหว:

• ควรใช้โปรไฟล์เฉพาะสำหรับเอเจนต์ (โปรไฟล์ openclaw ค่าเริ่มต้น)
• หลีกเลี่ยงการชี้เอเจนต์ไปยังโปรไฟล์ส่วนตัวที่คุณใช้ประจำทุกวัน
• ปิดการควบคุมเบราว์เซอร์บนโฮสต์สำหรับเอเจนต์ที่อยู่ใน sandbox เว้นแต่คุณจะเชื่อถือเอเจนต์เหล่านั้น
• API การควบคุมเบราว์เซอร์ local loopback แบบสแตนด์อโลนรองรับเฉพาะการยืนยันตัวตนด้วย shared-secret (การยืนยันตัวตนแบบ bearer ด้วยโทเค็น Gateway หรือรหัสผ่าน Gateway) ไม่ใช้ เฮดเดอร์ตัวตนจาก trusted-proxy หรือ Tailscale Serve
• ถือว่าการดาวน์โหลดจากเบราว์เซอร์เป็นอินพุตที่ไม่น่าเชื่อถือ; ควรใช้ไดเรกทอรีดาวน์โหลดที่แยกไว้
• ปิด browser sync/ตัวจัดการรหัสผ่านในโปรไฟล์เอเจนต์หากเป็นไปได้ (ลดขอบเขตผลกระทบ)
• สำหรับ Gateway ระยะไกล ให้ถือว่า "การควบคุมเบราว์เซอร์" เทียบเท่ากับ "การเข้าถึงของผู้ปฏิบัติการ" ต่อทุกสิ่งที่โปรไฟล์นั้นเข้าถึงได้
• ให้ Gateway และโฮสต์ node อยู่เฉพาะใน tailnet; หลีกเลี่ยงการเปิดเผยพอร์ตควบคุมเบราว์เซอร์ไปยัง LAN หรืออินเทอร์เน็ตสาธารณะ
• ปิดการกำหนดเส้นทางพร็อกซีของเบราว์เซอร์เมื่อไม่ต้องการใช้ (gateway.nodes.browser.mode="off")
• โหมด existing-session ของ Chrome MCP ไม่ใช่ "ปลอดภัยกว่า"; มันสามารถทำงานเป็นคุณในทุกสิ่งที่โปรไฟล์ Chrome ของโฮสต์นั้นเข้าถึงได้

นโยบาย SSRF ของเบราว์เซอร์ (เข้มงวดโดยค่าเริ่มต้น)

นโยบายการนำทางเบราว์เซอร์ของ OpenClaw เข้มงวดโดยค่าเริ่มต้น: ปลายทาง private/internal จะยังถูกบล็อก เว้นแต่คุณจะเลือกเปิดใช้อย่างชัดเจน

• ค่าเริ่มต้น: ไม่ได้ตั้งค่า browser.ssrfPolicy.dangerouslyAllowPrivateNetwork ดังนั้นการนำทางเบราว์เซอร์จะยังบล็อกปลายทาง private/internal/special-use
• นามแฝงเดิม: browser.ssrfPolicy.allowPrivateNetwork ยังยอมรับอยู่เพื่อความเข้ากันได้
• โหมดเลือกเปิดใช้: ตั้ง browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true เพื่ออนุญาตปลายทาง private/internal/special-use
• ในโหมดเข้มงวด ให้ใช้ hostnameAllowlist (รูปแบบเช่น *.example.com) และ allowedHostnames (ข้อยกเว้นโฮสต์แบบตรงตัว รวมถึงชื่อที่ถูกบล็อก เช่น localhost) สำหรับข้อยกเว้นที่ชัดเจน
• การนำทางจะถูกตรวจสอบก่อนคำขอ และตรวจสอบซ้ำแบบ best-effort บน URL http(s) สุดท้ายหลังการนำทาง เพื่อลดการ pivot ผ่าน redirect

ตัวอย่างนโยบายเข้มงวด:

{  browser: {    ssrfPolicy: {      dangerouslyAllowPrivateNetwork: false,      hostnameAllowlist: ["*.example.com", "example.com"],      allowedHostnames: ["localhost"],    },  },}

โปรไฟล์การเข้าถึงต่อเอเจนต์ (หลายเอเจนต์)

ด้วยการกำหนดเส้นทางหลายเอเจนต์ แต่ละเอเจนต์สามารถมี sandbox + นโยบายเครื่องมือของตัวเอง: ใช้สิ่งนี้เพื่อให้ เข้าถึงเต็มรูปแบบ, อ่านอย่างเดียว หรือ ไม่ให้เข้าถึง ต่อเอเจนต์ ดูรายละเอียดครบถ้วนและกฎลำดับความสำคัญที่ Multi-Agent Sandbox & Tools

กรณีใช้งานทั่วไป:

• เอเจนต์ส่วนตัว: เข้าถึงเต็มรูปแบบ ไม่มี sandbox
• เอเจนต์ครอบครัว/งาน: อยู่ใน sandbox + เครื่องมืออ่านอย่างเดียว
• เอเจนต์สาธารณะ: อยู่ใน sandbox + ไม่มีเครื่องมือระบบไฟล์/เชลล์

ตัวอย่าง: เข้าถึงเต็มรูปแบบ (ไม่มี sandbox)

{  agents: {    list: [      {        id: "personal",        workspace: "~/.openclaw/workspace-personal",        sandbox: { mode: "off" },      },    ],  },}

ตัวอย่าง: เครื่องมืออ่านอย่างเดียว + เวิร์กสเปซอ่านอย่างเดียว

{  agents: {    list: [      {        id: "family",        workspace: "~/.openclaw/workspace-family",        sandbox: {          mode: "all",          scope: "agent",          workspaceAccess: "ro",        },        tools: {          allow: ["read"],          deny: ["write", "edit", "apply_patch", "exec", "process", "browser"],        },      },    ],  },}

ตัวอย่าง: ไม่มีการเข้าถึงระบบไฟล์/เชลล์ (อนุญาตการส่งข้อความของผู้ให้บริการ)

{  agents: {    list: [      {        id: "public",        workspace: "~/.openclaw/workspace-public",        sandbox: {          mode: "all",          scope: "agent",          workspaceAccess: "none",        },        // Session tools can reveal sensitive data from transcripts. By default OpenClaw limits these tools        // to the current session + spawned subagent sessions, but you can clamp further if needed.        // See `tools.sessions.visibility` in the configuration reference.        tools: {          sessions: { visibility: "tree" }, // self | tree | agent | all          allow: [            "sessions_list",            "sessions_history",            "sessions_send",            "sessions_spawn",            "session_status",            "whatsapp",            "telegram",            "slack",            "discord",          ],          deny: [            "read",            "write",            "edit",            "apply_patch",            "exec",            "process",            "browser",            "canvas",            "nodes",            "cron",            "gateway",            "image",          ],        },      },    ],  },}

การตอบสนองต่อเหตุการณ์

หาก AI ของคุณทำสิ่งที่ไม่เหมาะสม:

จำกัดผลกระทบ

1. หยุดมัน: หยุดแอป macOS (หากแอปนั้นควบคุม Gateway) หรือยุติโพรเซส openclaw gateway ของคุณ
2. ปิดการเปิดเผย: ตั้งค่า gateway.bind: "loopback" (หรือปิดใช้งาน Tailscale Funnel/Serve) จนกว่าคุณจะเข้าใจว่าเกิดอะไรขึ้น
3. ระงับการเข้าถึง: เปลี่ยน DM/กลุ่มที่มีความเสี่ยงเป็น dmPolicy: "disabled" / กำหนดให้ต้องมีการกล่าวถึง และลบรายการอนุญาตทั้งหมด "*" หากคุณเคยตั้งไว้

หมุนเวียนข้อมูลลับ (ให้ถือว่าถูกโจมตีหากข้อมูลลับรั่วไหล)

1. หมุนเวียนการยืนยันตัวตนของ Gateway (gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD) แล้วเริ่มใหม่
2. หมุนเวียนข้อมูลลับของไคลเอนต์ระยะไกล (gateway.remote.token / .password) บนเครื่องใดก็ตามที่สามารถเรียก Gateway ได้
3. หมุนเวียนข้อมูลรับรองของผู้ให้บริการ/API (ข้อมูลรับรอง WhatsApp, โทเค็น Slack/Discord, คีย์โมเดล/API ใน auth-profiles.json และค่าข้อมูลลับแบบเข้ารหัสเมื่อใช้งาน)

ตรวจสอบ

1. ตรวจสอบบันทึก Gateway: /tmp/openclaw/openclaw-YYYY-MM-DD.log (หรือ logging.file)
2. ตรวจสอบบันทึกข้อความถอดความที่เกี่ยวข้อง: ~/.openclaw/agents/<agentId>/sessions/*.jsonl
3. ตรวจสอบการเปลี่ยนแปลงการกำหนดค่าล่าสุด (สิ่งใดก็ตามที่อาจขยายการเข้าถึง: gateway.bind, gateway.auth, นโยบาย DM/กลุ่ม, tools.elevated, การเปลี่ยนแปลง Plugin)
4. เรียกใช้ openclaw security audit --deep อีกครั้ง และยืนยันว่าข้อค้นพบระดับวิกฤตได้รับการแก้ไขแล้ว

รวบรวมสำหรับรายงาน

• เวลาที่เกิดเหตุ, OS ของโฮสต์ Gateway + เวอร์ชัน OpenClaw
• บันทึกข้อความถอดความของเซสชัน + ส่วนท้ายบันทึกสั้นๆ (หลังจากปกปิดข้อมูล)
• สิ่งที่ผู้โจมตีส่ง + สิ่งที่ agent ทำ
• Gateway ถูกเปิดเผยเกินกว่า loopback หรือไม่ (LAN/Tailscale Funnel/Serve)

การสแกนข้อมูลลับ

CI เรียกใช้ hook detect-private-key ของ pre-commit กับ repository หากการตรวจสอบนี้ล้มเหลว ให้ลบหรือหมุนเวียนวัสดุคีย์ที่ถูก commit แล้วจำลองซ้ำในเครื่อง:

pre-commit run --all-files detect-private-key

การรายงานปัญหาความปลอดภัย

พบช่องโหว่ใน OpenClaw หรือไม่ โปรดรายงานอย่างรับผิดชอบ:

1. อีเมล: security@openclaw.ai
2. อย่าโพสต์ต่อสาธารณะจนกว่าจะแก้ไขแล้ว
3. เราจะให้เครดิตคุณ (เว้นแต่คุณต้องการไม่เปิดเผยตัวตน)