คู่มือความปลอดภัยของ Claude Code: Permissions, MCP, Sandboxing

แชตบ็อตแบบดั้งเดิมทำงานอยู่หลัง API ดังนั้นแย่ที่สุดที่ทำได้ก็แค่เพ้อเจ้อ แต่เอเจนต์เขียนโค้ดด้วย AI อยู่ในรีโป เทอร์มินัล และ (บ่อยครั้ง) ข้อมูลรับรองคลาวด์ของคุณ ซึ่งทำให้มันเข้าใกล้สภาพแวดล้อมนักพัฒนาที่มีสิทธิพิเศษมากกว่าสิ่งที่เราเคยเรียกว่าแชตบ็อต

คำถามคือจะใช้ Claude Code อย่างปลอดภัยโดยไม่ชะลอตัวได้อย่างไร การกำหนดสิทธิ์ การควบคุม MCP และการทำ sandbox ด้วยการปรับแต่งที่พอดีจะพาคุณไปถึงจุดนั้น

ในบทความนี้ ฉันจะพาคุณทำความเข้าใจว่าโมเดลความปลอดภัยของ Claude Code ทำงานจริงอย่างไร จุดไหนที่ต้องใส่ใจ และแนวทางปฏิบัติที่ช่วยให้ใช้งานได้ผลโดยไม่ให้สิทธิ์เข้าถึงมากกว่าที่ตั้งใจ

หากเป็นมือใหม่กับ Claude และ Claude Code แนะนำให้ลงทะเบียนคอร์ส Claude Code 101 แบบฟรีเพื่อปูพื้นให้ครบในบ่ายเดียว

ทำความเข้าใจโมเดลความปลอดภัยของ Claude Code

ก่อนจะไปจูนกฎข้อใดข้อหนึ่ง ควรมีโมเดลความคิดก่อนว่า Claude Code ควบคุมอะไรได้บ้าง

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

ระบบสิทธิ์ (Permissions system)

ระบบสิทธิ์คือชั้นที่เป็นแบบคงที่

คุณกำหนดว่า Claude ทำอะไรได้บ้างใน settings.json โดยใช้สามรายการ: allow, ask, และ deny การประเมินกฎจะทำตามลำดับ deny ก่อน จากนั้น ask แล้วค่อย allow และใช้กฎที่ตรงเป็นอันแรก กฎ deny จะบล็อกการเรียกแม้จะมีกฎ allow ที่กว้างกว่าตรงด้วยก็ตาม

หากไม่มีกฎใดตรง Claude จะย้อนกลับไปใช้ defaultMode ของเซสชัน (พูดถึงโหมดในหัวข้อถัดไป)

การควบคุมการเข้าถึงเครื่องมือ (Tool access controls)

สิทธิ์ผูกกับเครื่องมือ ไม่ใช่กับเอเจนต์ทั้งก้อน

Claude Code มีเครื่องมือในตัว เช่น Bash สำหรับคำสั่งเชลล์ Read Edit และ Write สำหรับการทำงานกับไฟล์ระบบ WebFetch สำหรับคำขอ HTTPS WebSearch สำหรับค้นหา และอื่น ๆ แต่ละกฎจะระบุชื่อเครื่องมือและ (อาจ) ตัวกำหนดในวงเล็บ เช่น Bash(git commit:*) หรือ Read(./.env)

นี่คือสิ่งที่ทำให้หลักการสิทธิ์น้อยที่สุดใช้งานได้ คุณสามารถอนุญาต Bash(npm run:*) เพื่อรันเทสต์โดยไม่ต้องให้สิทธิ์เชลล์เต็มรูปแบบแก่ Claude

สิทธิ์ MCP

เซิร์ฟเวอร์ MCP ต่อขยาย Claude Code ด้วยเครื่องมือที่มันไม่ได้ถูกออกแบบมารองรับตั้งแต่แรก

แต่ละเซิร์ฟเวอร์นำเครื่องมือชุดของมันมาเอง (เช่น เซิร์ฟเวอร์ GitHub เพิ่มเครื่องมือ pull request เซิร์ฟเวอร์ฐานข้อมูลเพิ่มเครื่องมือ query เป็นต้น) ระบบสิทธิ์ครอบคลุมส่วนนี้ด้วย แต่ใช้ไวยากรณ์ต่างกัน คือใช้รูปแบบ mcp__servername__toolname แทนตัวกำหนดในวงเล็บ

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

Sandboxing

Sandboxing คือความปลอดภัยระดับระบบปฏิบัติการภายใต้เครื่องมือ Bash

กฎสิทธิ์บอก Claude ว่าควรทำอะไร ส่วน sandboxing บังคับว่าทำอะไรได้ โดยจำกัดการเข้าถึงไฟล์ระบบและการออกเน็ตระดับระบบปฏิบัติการ บน macOS ใช้ได้ทันทีผ่าน Seatbelt บน Linux และ WSL2 ต้องติดตั้ง bubblewrap และ socat ก่อน

ทั้งสองชั้นทำงานคล้ายกันแต่ครอบคลุมสถานการณ์ต่างกัน สิทธิ์หยุดไม่ให้ Claude พยายามทำบางอย่าง ส่วน sandboxing จะหยุดไม่ให้ความพยายามนั้นสำเร็จ หากมีการฉีดคำสั่งผ่านพรอมต์จนทำให้ Claude ลองทำอยู่ดี

การตรวจสอบย้อนหลัง (Auditability)

ชิ้นส่วนสุดท้ายคือความสามารถในการเห็นว่าเกิดอะไรขึ้น

คำสั่ง /permissions แสดงรายการกฎที่ใช้งานทั้งหมดและไฟล์ตั้งค่าที่แต่ละกฎมาจาก เพื่อให้ตอบได้ว่า "ทำไม Claude ถึงรันสิ่งนั้น?" ฮุค (PreToolUse, PostToolUse และอื่น ๆ) ให้คุณล็อกการเรียกใช้เครื่องมือทุกครั้งไปยังระบบของคุณเอง สำหรับทีม สามารถส่งข้อมูลการใช้งานและการเรียกใช้เครื่องมือผ่าน OpenTelemetry ไปยังสแตก observability ที่คุณใช้อยู่แล้ว

สิทธิ์และการควบคุมการเข้าถึงใน Claude Code

ความปลอดภัยส่วนใหญ่เกิดจากการตั้งค่าสิทธิ์ ดังนั้นคุณจะใช้เวลาปรับแต่งส่วนนี้มากที่สุด

การเข้าถึงไฟล์

โดยปริยาย Claude สามารถอ่านและแก้ไขไฟล์ในไดเรกทอรีที่คุณเปิดใช้งาน

การอ่านควบคุมโดยเครื่องมือ Read และการแก้ไขโดย Edit และ Write แต่ละอย่างรับรูปแบบพาธในวงเล็บโดยใช้ไวยากรณ์แบบ gitignore เช่น Read(**/.env) จะตรงกับไฟล์ .env ทุกไฟล์ในทุกระดับ และ Edit(src/**) จะตรงกับทุกอย่างภายใต้ src/

การ deny ที่ Read ครอบคลุมเครื่องมือไฟล์ของ Claude Code เอง (Read, Grep, Glob, LS) แต่เป็นความพยายามแบบ best-effort สคริปต์ Python หรือ Node ที่รันผ่าน Bash ยังเปิดไฟล์ได้อยู่ เพราะเป็นการอ่านผ่านเชลล์ไม่ใช่ผ่านเครื่องมือ Read ของ Claude หากความลับสำคัญ ควรผสาน deny ของ Read เข้ากับ deny ของ Bash สำหรับ cat, head, และ tail บนพาธเหล่านั้น

หากต้องการขยายการเข้าถึงเกินไดเรกทอรีทำงาน ให้ใช้ additionalDirectories ใน settings.json นี่คือวิธีให้ Claude เข้าถึงไลบรารีที่ใช้ร่วมกันนอกรีโปหรือไฟล์คอนฟิกในโฮมไดเรกทอรี โดยไม่ต้องยกเลิกขอบเขตไดเรกทอรีทำงานทั้งหมด

การรันคำสั่ง

เครื่องมือ Bash เป็นตัวที่ต้องกำหนดขอบเขตอย่างรอบคอบที่สุด

กฎ Bash เปลือย ๆ จะอนุญาตทุกคำสั่ง กฎแบบจำกัดขอบเขตอย่าง Bash(npm run:*) จะอนุญาตเฉพาะคำสั่งที่ตรงรูปแบบ ต้องใช้รูปแบบ colon-star ที่นี่ และ Claude Code เข้าใจตัวดำเนินการเชลล์ ดังนั้นกฎอย่าง Bash(safe-cmd:*) จะไม่ตรงกับ safe-cmd && rm -rf /

บางคำสั่งจะรันได้โดยไม่ต้องถามในทุกโหมด เพราะถือว่าเป็นแบบอ่านอย่างเดียวโดยปริยาย รายการครอบคลุม ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd และรูปแบบอ่านอย่างเดียวของ git คุณไม่สามารถย่อลิสต์นี้ด้วยตนเอง แต่สามารถเพิ่มกฎ ask หรือ deny สำหรับคำสั่งใด ๆ เพื่อแทนที่ค่าเริ่มต้นได้

สำหรับสิ่งที่ไม่ได้รับอนุมัติล่วงหน้า Claude จะถามยืนยันในโหมดเริ่มต้น หน้าต่างพรอมต์จะแสดงคำสั่งที่แน่นอนและให้อนุมัติครั้งเดียว อนุมัติทั้งหมดที่ตรงแพทเทิร์น หรือปฏิเสธ

โหมดสิทธิ์ (Permission modes)

กฎสิทธิ์เป็นแบบคงที่ แต่โหมดสิทธิ์เปลี่ยนพฤติกรรมของการเรียกที่ไม่ตรงกับกฎ

มีห้าโหมด:

• default: ถามยืนยันเมื่อใช้เครื่องมือครั้งแรก

• acceptEdits: อนุมัติการแก้ไขไฟล์ในไดเรกทอรีทำงานโดยอัตโนมัติ แต่ยังควบคุมคำสั่งเชลล์ มีประโยชน์เมื่อไว้ใจการแก้ไขไฟล์แต่ยังไม่ไว้ใจเชลล์

• plan: Claude อ่านและวิเคราะห์ได้ แต่แก้ไขไฟล์หรือรันคำสั่งไม่ได้ เหมาะสำหรับรีวิวโค้ดหรือวางแผน

• dontAsk: ปฏิเสธโดยอัตโนมัติสำหรับทุกอย่างที่ไม่ได้อยู่ในรายการ allow อย่างชัดเจน

• bypassPermissions: ข้ามพรอมต์ทั้งหมด ใช้ได้เฉพาะในสภาพแวดล้อมที่แยกอย่างสมบูรณ์ เช่น คอนเทนเนอร์หรือ VM

สามารถสลับสามโหมดหลักด้วย Shift+Tab ระหว่างเซสชัน หรือเลือกเป็นค่าเริ่มต้นใน settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

สำหรับทีม การตั้งค่าแบบจัดการให้ชั้นที่ผู้ใช้ไม่สามารถแทนที่ได้ ไฟล์ใช้รูปแบบ JSON เดียวกันและอยู่ที่พาธระบบ:

• /Library/Application Support/ClaudeCode/managed-settings.json บน macOS

• /etc/claude-code/managed-settings.json บน Linux

• C:\ProgramData\ClaudeCode\managed-settings.json บน Windows

กฎ deny ในการตั้งค่าแบบจัดการมีผลครอบคลุมทุกโปรเจ็กต์บนเครื่อง ซึ่งเป็นวิธีบังคับใช้กฎอย่างเช่น "ห้ามใครอ่านไฟล์ .env" หรือ "ห้ามใครใช้ bypassPermissions" ทั่วทั้งองค์กร

หลักการเบื้องหลังทั้งหมดนี้คือสิทธิ์น้อยที่สุด เหมือนกับที่คุณใช้กับบัญชีบริการใด ๆ

ควรเริ่มจากสิทธิ์ชุดเล็กที่สุดที่ทำให้งานเดินได้ และขยายเฉพาะเมื่อเจอข้อจำกัด คำแนะนำของ Anthropic ก็ไปในทางเดียวกัน — ทบทวนการเปลี่ยนแปลงที่ Claude ทำ ตรวจสอบกฎด้วย /permissions และเก็บการตั้งค่าเฉพาะโปรเจ็กต์ไว้ในระบบควบคุมเวอร์ชันเพื่อให้ทีมเห็นพ้องตรงกันว่า Claude ทำงานกับอะไรได้บ้าง

Claude Code Sandboxing

ยิ่งอนุญาตให้ Claude ทำงานอัตโนมัติมากเท่าไร การทำ sandbox ก็ยิ่งมีเหตุผลมากขึ้นเท่านั้น

เครื่องมือ Bash เปิดรับความเสี่ยงกว้างที่สุด เพราะคำสั่งเชลล์สามารถอ่านไฟล์ใด ๆ ที่คุณอ่านได้ และแก้ไขสิ่งที่มีสิทธิ์เขียนได้ การทำ sandbox บังคับขอบเขตระดับระบบปฏิบัติการกับทุกคำสั่ง Bash และโปรเซสลูก ทำให้ Claude ทำงานได้อิสระขึ้นภายในขอบเขตโดยที่คุณไม่ต้องอนุมัติทุกคำสั่ง Anthropic สร้างสิ่งนี้มาโดยเฉพาะเพื่อรองรับการรันอัตโนมัติที่ปลอดภัยยิ่งขึ้น

รายละเอียดที่ควรเข้าใจคือ sandbox ครอบคลุมเฉพาะ Bash และโปรเซสลูกเท่านั้น มันไม่ได้จำกัดเครื่องมือ Read, Edit หรือ Write ซึ่งยังผ่านระบบสิทธิ์เช่นเดิม

การทำ sandbox แบบเนทีฟ

Sandbox แบบเนทีฟถูกฝังอยู่ใน Claude Code และเปิดใช้งานด้วย /sandbox

บน macOS ใช้เฟรมเวิร์ก Seatbelt ที่มีมาให้ ไม่ต้องติดตั้งอะไรเพิ่มเติม บน Linux และ WSL2 ให้ติดตั้ง bubblewrap เพื่อแยกไฟล์ระบบ และ socat สำหรับพร็อกซีเครือข่าย Windows แบบเนทีฟยังไม่รองรับ จึงควรรัน Claude Code ภายในดิสทริบิวชัน WSL2

ขอบเขตไฟล์ระบบเข้าใจง่าย: อ่านได้ทุกที่ยกเว้นพาธที่ถูกปฏิเสธ และเขียนได้เฉพาะภายในไดเรกทอรีทำงานและพาธเพิ่มเติมที่คุณอนุญาต หากพยายามเขียนไปยัง ~/.bashrc จากใน sandbox จะได้ข้อความ "Operation not permitted" ก่อนที่ Claude จะรู้ด้วยซ้ำว่าล้มเหลว

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

การตั้งค่าที่ใช้งานได้จะมีหน้าตาประมาณนี้:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

จากการใช้งานภายในของ Anthropic การทำ sandbox ช่วยลดพรอมต์ขออนุญาตลงได้ 84%

คอนเทนเนอร์สำหรับพัฒนา (Development containers)

Dev container เป็นขั้นต่อไปของการแยกสภาพแวดล้อม

Anthropic มี devcontainer อ้างอิงสำหรับ Claude Code ที่ตั้งค่า Ubuntu เมาท์รีโปของคุณ และให้เชลล์สำหรับเอเจนต์ ข้อดีเหนือ sandbox แบบเนทีฟคือความสามารถในการทำซ้ำได้ เพราะทุกคนในทีมได้สภาพแวดล้อม เครื่องมือ และการตั้งค่าเหมือนกัน

แต่ข้อเสียคือภาระเพิ่มขึ้น

เมื่อใช้คอนเทนเนอร์ คุณจะมีขั้นตอน build การเมาท์ไฟล์ และ (บางครั้ง) วงจรป้อนกลับที่ช้าลง สำหรับนักพัฒนาคนเดียว sandbox แบบเนทีฟมักเพียงพอ สำหรับทีมหรือ CI การตั้งค่านี้คุ้มค่า

การแยกด้วย Docker

สำหรับเซสชันเอเจนต์อัตโนมัติที่รันยาวนาน Docker สามารถขยายขอบเขต sandbox ได้อีก

การตั้งค่ามักจะมีลักษณะดังนี้:

• อิมเมจฐานแบบมินิมอล: ตัดตัวจัดการแพ็กเกจและเครื่องมือเครือข่ายที่งานไม่ต้องการออก
• ผู้ใช้ที่ไม่ใช่ root: Claude ไม่ควรรันด้วยสิทธิ์ root เพื่อไม่ให้แก้ไขไฟล์ระบบหรือยกตั้งแพ็กเกจแบบ global
• ระบบไฟล์ root แบบอ่านอย่างเดียว: เมาท์ root ของคอนเทนเนอร์เป็นแบบอ่านอย่างเดียว และอนุญาตให้เขียนเฉพาะไดเรกทอรีเอาต์พุตที่กำหนด
• พร็อกซีขาออก: ส่งทราฟฟิกขาออกผ่านพร็อกซีที่อนุญาตเรจิสทรีแพ็กเกจ (npm, PyPI) และบล็อกอย่างอื่น เพื่อให้คำสั่งอย่าง npm install ใช้ได้ แต่ curl ตามอำเภอใจใช้ไม่ได้
• จำกัดทรัพยากร: ตั้งลิมิต CPU หน่วยความจำ และ I/O เพื่อไม่ให้โปรเซสทำให้โฮสต์ล่ม

Docker Sandboxes ให้แต่ละ sandbox มี microVM และ Docker daemon ส่วนตัว daemon ของโฮสต์จะไม่เห็น sandbox เหล่านี้ใน docker ps ขอบเขตจึงใกล้เคียง VM มากกว่าคอนเทนเนอร์ ปิดช่องทางหนีออกจากคอนเทนเนอร์ที่นักพัฒนากังวลส่วนใหญ่

กลยุทธ์ sandboxing สำหรับองค์กร

สำหรับองค์กร คำถามคือจะซ้อนเทคนิค sandbox อย่างไร ไม่ใช่จะใช้หรือไม่ใช้

ส่วนใหญ่จะเข้าหาแบบนี้:

• กฎสิทธิ์อยู่ใน managed-settings.json และนักพัฒนาแทนที่ไม่ได้

• มี sandbox แบบเนทีฟซ้อนอยู่ใต้ชั้นสิทธิ์

• Dev container หรือ Docker ซ้อนอยู่ใต้ชั้นนั้นอีกที

• สำหรับสถานการณ์ความเชื่อถือสูงสุด (เข้าถึงโปรดักชัน จัดการความลับ) ให้ใช้ VM เฉพาะโดยไม่เมาท์ไฟล์ระบบของโฮสต์ เป็นชั้นสุดท้าย

Claude Code บนเว็บคือเวอร์ชันที่จัดการแล้วของแนวคิดเดียวกัน แต่ละเซสชันรันใน VM ที่ Anthropic จัดการ ข้อมูลรับรองที่อ่อนไหวอย่างโทเคน git อยู่ภายนอก sandbox ในพร็อกซี และขอบเขตถูกบังคับใช้โดยอินฟราสตรักเชอร์

ความปลอดภัยของ MCP ใน Claude Code

MCP เป็นส่วนที่เติบโตเร็วที่สุดของ Claude Code

ทุกเซิร์ฟเวอร์ MCP ที่คุณเชื่อมต่อเพิ่มศักยภาพให้ Claude ได้มาก แต่ก็เพิ่มพื้นผิวที่การฉีดพรอมต์หรือการพึ่งพาที่ถูกเจาะจะเข้าถึงได้มากขึ้นด้วย

เช่น:

• เซิร์ฟเวอร์ MCP ของ GitHub ให้ Claude เข้าถึง pull request
• เซิร์ฟเวอร์ MCP ของฐานข้อมูลให้สคีมาและการคิวรี
• เซิร์ฟเวอร์ Slack ให้เข้าถึงช่องแชตของคุณ

สิ่งเหล่านี้ไม่ใช่ปัญหาในตัวเอง แต่หมายความว่า MCP ต้องมีธรรมาภิบาลของมันเอง เนื้อหาที่ดึงมาผ่านเครื่องมือ MCP (หน้าเว็บหรือการตอบ API) อาจมีคำสั่งฉีดที่ Claude ทำตามราวกับคุณพิมพ์เอง นอกจากนี้แต่ละเซิร์ฟเวอร์ยังเพิ่มข้อมูลรับรองและเส้นทางยืนยันตัวตนที่ต้องจัดการแยกต่างหาก

สิทธิ์ของเครื่องมือ

เครื่องมือ MCP ใช้การตั้งชื่อที่ต่างจากเครื่องมือในตัว

รูปแบบกฎคือ mcp__servername__toolname โดยไม่มีตัวกำหนดในวงเล็บ เช่น mcp__github__create_pull_request ให้อนุญาต Claude เรียกใช้เครื่องมือนั้นได้พอดี และการ deny ที่ mcp__github__delete_repo จะบล็อกเครื่องมือที่อันตราย รายการ allow, ask และ deny ทำงานเหมือนกับ Bash หรือ Read

ลำดับความสำคัญก็เหมือนกัน — deny ก่อน จากนั้น ask แล้ว allow การ deny ใน managed-settings ที่ mcp__github__delete_* ใช้ได้กับทุกโปรเจ็กต์บนเครื่อง

สิทธิ์ของทรัพยากร

เซิร์ฟเวอร์ MCP อาจเปิดเผยทรัพยากรร่วมกับเครื่องมือได้

ทรัพยากรคือข้อมูลที่เซิร์ฟเวอร์ทำให้ Claude อ่านได้ (ไฟล์ในเซิร์ฟเวอร์จัดการโปรเจ็กต์ หรือเรคคอร์ดในเซิร์ฟเวอร์ฐานข้อมูล) การเข้าถึงทรัพยากรไหลผ่านการตรวจสอบความไว้วางใจแบบเดียวกับการเรียกเครื่องมือ และการเชื่อมต่อเซิร์ฟเวอร์ MCP ครั้งแรกจะมีขั้นตอนยืนยันความไว้วางใจก่อนที่เครื่องมือหรือทรัพยากรใด ๆ จะเข้าถึงได้

ค่าตั้งต้นที่เหมาะสมคือมองทรัพยากรเสมือนเป็นเครื่องมืออีกชิ้น หากคุณไม่ให้ข้อมูลรับรอง ก็อย่าให้สิทธิ์ทรัพยากรนั้น

เซิร์ฟเวอร์ MCP ที่อนุมัติแล้ว

Anthropic Directory แสดงคอนเน็กเตอร์ที่ Anthropic ตรวจสอบตามเกณฑ์การขึ้นทะเบียนแล้ว

สำหรับองค์กร รูปแบบที่ดีคือการใช้อินเทอร์นัล allowlist มีการตั้งค่าสองอย่างที่ให้คุณควบคุมได้:

• allowedMcpServers: แพทเทิร์น glob ของเซิร์ฟเวอร์ที่นักพัฒนาสามารถเพิ่มในโปรเจ็กต์ได้ (เช่น company-* เพื่ออนุญาตเฉพาะเซิร์ฟเวอร์ที่ดูแลภายใน)

• deniedMcpServers: แพทเทิร์นของเซิร์ฟเวอร์ที่ห้ามเพิ่ม แม้นักพัฒนาจะพยายามก็ตาม

สำหรับเซิร์ฟเวอร์ที่ต้องมีในทุกเซสชัน ให้จัดส่งผ่านไฟล์ managed-mcp.json ที่อยู่ในการตั้งค่าแบบจัดการ นักพัฒนาไม่สามารถลบหรือแก้ไขได้

การตั้งค่าหนึ่งที่ควรหลีกเลี่ยงในรีโปที่แชร์คือ enableAllProjectMcpServers ซึ่งอนุมัติเซิร์ฟเวอร์ MCP ทุกตัวใน .mcp.json โดยอัตโนมัติ สะดวกสำหรับงานเดี่ยวแต่เสี่ยงสำหรับสิ่งที่ถูกเช็คอิน เพราะ PR อันตรายอาจเพิ่มเซิร์ฟเวอร์ใหม่ใน .mcp.json และให้มันรันโดยไม่ถามได้

การเข้าถึงเครื่องมือแบบสิทธิ์น้อยที่สุด

หลักการเดียวกับสิทธิ์ Bash แค่ย้ายมาใช้กับ MCP

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

ซับเอเจนต์เป็นอีกวิธีในการกำหนดขอบเขตการเข้าถึง MCP ไฟล์กำหนดซับเอเจนต์ใน .claude/agents/ สามารถระบุได้ชัดเจนว่ามีสิทธิ์ใช้เครื่องมือใดบ้าง (ใช้ไวยากรณ์ mcp:<server>:<tool>) เช่น "deploy-agent" ได้เซิร์ฟเวอร์โครงสร้างพื้นฐาน ส่วน "review-agent" ได้เพียง Read, Grep, และ Glob เอเจนต์จะเรียกเครื่องมือที่ไม่ได้รับสิทธิ์ไม่ได้

ธรรมาภิบาลของ MCP

สำหรับทีมหรือองค์กรที่ใช้งาน Claude Code ในระดับสเกล MCP ต้องมีรูปแบบธรรมาภิบาลเหมือนกับอินทิเกรชันโปรดักชันอื่น ๆ

นั่นหมายถึงรีจิสทรีของเซิร์ฟเวอร์ที่อนุมัติพร้อมเจ้าของที่ระบุชัด เส้นทางการตรวจสอบแบบ end-to-end ของการเรียกเครื่องมือ (เครื่องมือ MCP ใดถูกเรียก โดยใคร ด้วยพารามิเตอร์อะไร) และการทบทวนรายการอนุมัติเป็นระยะ OpenTelemetry exporters ใน Claude Code ให้ข้อมูลตรวจสอบในรูปแบบที่นำไปใส่สแต็ก observability ที่คุณใช้อยู่แล้วได้ทันที

สำหรับองค์กรขนาดใหญ่ เกตเวย์ MCP ส่วนกลางคือเวอร์ชันที่สะอาดที่สุด

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

การจัดการความลับและข้อมูลอ่อนไหว

Claude Code อ่านได้ทุกอย่างที่คุณอ่านได้ ซึ่งทำให้ความลับถูกเข้าถึงได้

โดยปริยาย Claude Code อ่านไฟล์ได้ทุกไฟล์ที่บัญชีผู้ใช้ของคุณอ่านได้ รวมถึงไฟล์ .env ในโปรเจ็กต์ ข้อมูลรับรอง AWS ใน ~/.aws/ คีย์ส่วนตัว SSH ใน ~/.ssh/ โทเคน GitHub ในไฟล์ rc ของเชลล์ และตัวแปรสภาพแวดล้อมในโปรเซสย่อยใด ๆ ที่ Claude สร้างขึ้น นั่นเป็นพฤติกรรมปกติและออกแบบมาเช่นนั้น

เก็บความลับไว้นอกพื้นที่ทำงาน

ก้าวแรกคือทำให้แน่ใจว่าความลับไม่อยู่ในไดเรกทอรีที่ Claude อ่านอยู่

.env เป็นไฟล์ที่พบมากที่สุด อยู่ที่รูทของโปรเจ็กต์ ถูกโหลดโดยเครื่องมือพัฒนาทุกตัว และมีค่าที่คุณไม่อยากอยู่ในบริบทของ Claude (เช่น URL ฐานข้อมูลและ API key)

มีรูปแบบให้ใช้ได้สองสามแบบ:

• ย้ายความลับไปยังไดเรกทอรีนอกต้นไม้ทำงาน เช่น ~/.config/myapp/secrets.env และโหลดผ่านตัวจัดการสภาพแวดล้อมหรือการตั้งค่า direnv ที่ชี้ไปไฟล์ภายนอก

• สำหรับงานที่ใช้คอนเทนเนอร์ ให้เก็บโฟลเดอร์ .secrets/ ไว้นอก bind mount เพื่อให้ไฟล์มองไม่เห็นจากในคอนเทนเนอร์

• เพิ่ม Read(**/.env) และ Read(**/.env.*) ในรายการ permissions.deny และจับคู่กับการ deny Bash(cat:*/.env) เพื่อไม่ให้สคริปต์เชลล์อ่านสิ่งที่เครื่องมือ Read อ่านไม่ได้

ใช้ตัวจัดการความลับ

สำหรับงานเกินกว่าระดับเดโม ที่เก็บความลับที่เหมาะสมคือตัวจัดการความลับ

รูปแบบจะเหมือนกันไม่ว่าผู้ให้บริการจะเป็นใคร (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical) เก็บความลับไว้ในตัวจัดการ เชลล์หรือรันไทม์จะดึงมาเมื่อจำเป็นและเปิดเผยเฉพาะกับโปรเซสที่ต้องใช้ Claude จะไม่เห็นค่าจริง

สำหรับ Claude Code โดยเฉพาะ ให้ตั้งค่า CLAUDE_CODE_SUBPROCESS_ENV_SCRUB เพื่อลอกข้อมูลรับรองของ Anthropic และผู้ให้บริการคลาวด์ออกจากโปรเซสย่อย หรือใช้ sandbox.credentials เพื่อตัดตัวแปรเฉพาะออกสำหรับคำสั่งใน sandbox ค่าแรกหยุดไม่ให้ Claude ส่งต่อ ANTHROPIC_API_KEY ของคุณเข้าไปในสคริปต์ build และค่าสุดท้ายครอบคลุมกรณีกว้างกว่าที่ตัวแปรสภาพแวดล้อมที่อ่อนไหวใด ๆ หลุดไปยังคำสั่งเชลล์

จำกัดการเข้าถึงรีโป

ทางเลือกที่สามคือระดับรีโป

ถ้านักพัฒนาไม่จำเป็นต้องมีสิทธิ์เขียนบนคอนฟิกเฉพาะโปรดักชัน เซสชัน Claude Code ของเขาก็ไม่จำเป็นเช่นกัน ฟังดูชัดเจน แต่ค่าเริ่มต้นของหลายทีมคือนักพัฒนามีสิทธิ์กว้างกว่าที่ใช้เป็นประจำ และ Claude ก็รับสิทธิเหล่านั้นมาทั้งหมด

มีสองขั้นตอนที่ทำได้:

• แยกคอนฟิกโปรดักชันออกเป็นรีโปแยกต่างหากที่มีสิทธิ์เข้มงวดกว่า เพื่อให้สภาพแวดล้อมพัฒนาที่ Claude ทำงานไม่มีความลับของโปรดักชันตั้งแต่แรก

• ใช้โทเคนแบบกำหนดขอบเขตสำหรับบริการใด ๆ ที่ Claude โต้ตอบ เช่น โทเคน GitHub สำหรับงานรีวิวโค้ดไม่จำเป็นต้องมี repo:delete

ความปลอดภัยของ Claude Code สำหรับทีม

นักพัฒนาคนเดียวปรับ settings.json อย่างไรก็ได้ แต่ทีมทำไม่ได้ เพราะความปลอดภัยโดยรวมดีได้เท่ากับการตั้งค่าที่อ่อนที่สุดบนเครื่องที่อ่อนที่สุด สำหรับการใช้งานระดับทีมและองค์กร Claude Code มีชั้นควบคุมแยกที่แอดมินผลักลงมา และผู้ใช้แต่ละคนแทนที่ไม่ได้

การตั้งค่าแบบจัดการ (Managed settings)

การตั้งค่าแบบจัดการคือรากฐาน

ไฟล์อยู่ในพาธระบบที่ต้องใช้สิทธิ์แอดมินในการเขียน:

• /Library/Application Support/ClaudeCode/managed-settings.json บน macOS

• /etc/claude-code/managed-settings.json บน Linux

• C:\ProgramData\ClaudeCode\managed-settings.json บน Windows

การตั้งค่าในไฟล์นี้มีลำดับความสำคัญเหนือการตั้งค่าระดับผู้ใช้และระดับโปรเจ็กต์ กฎ deny ที่วางไว้ที่นี่จะมีผลกับทุกโปรเจ็กต์บนเครื่อง และนักพัฒนาเอาออกไม่ได้ด้วยการแก้ settings.json ของตนเอง องค์กรส่วนใหญกระจายไฟล์ผ่าน MDM (Mobile Device Management) หรือช่องทางคอนฟิกเดียวกับที่ใช้กับเครื่องมือพัฒนาอื่น

การตั้งค่าบางอย่างที่ควรรู้ในชั้นแบบจัดการ:

• permissions.deny สำหรับพาธที่อ่อนไหวและคำสั่งที่อันตราย

• defaultMode ตั้งเป็น default หรือ plan (ไม่ใช้ bypassPermissions เด็ดขาด)

• allowManagedPermissionRulesOnly: true เพื่อยึดชุดกฎสิทธิ์ให้ตายตัว

• enableAllProjectMcpServers: false เพื่อบังคับให้ต้องอนุมัติ MCP อย่างชัดเจน

• การตั้งค่า OpenTelemetry exporter สำหรับการล็อก

นโยบายสิทธิ์ที่แชร์ร่วมกัน

เมื่อทีมเห็นพ้องว่า Claude ทำอะไรได้บ้าง ก็ควรคุมเวอร์ชันข้อตกลงนั้น

การตั้งค่าระดับโปรเจ็กต์อยู่ที่ .claude/settings.json ที่รูทรีโป อะไรก็ตามที่เช็คอินไว้ที่นี่มีผลกับทุกคนที่รัน Claude ในรีโปนั้น ไฟล์นี้เหมาะสำหรับ allow/deny เฉพาะโปรเจ็กต์

โดยคำนึงถึงสิ่งนั้น มีการแยกระหว่างการตั้งค่าแบบจัดการและแบบโปรเจ็กต์ที่ควรรู้:

• การตั้งค่าแบบจัดการบรรจุนโยบายองค์กร (ไม่มีใครใช้ bypassPermissions ไม่มีใครอ่าน .env)

• การตั้งค่าโปรเจ็กต์บรรจุธรรมเนียมการทำงาน (รีโปนี้รันเทสต์ด้วย npm test; สคริปต์ deploy ของรีโปนี้ห้ามแตะ)

ธรรมาภิบาลของทีม

สำหรับการปล่อยใช้งานระดับทีม เลเยอร์นโยบายต้องมีเจ้าของ

ทีมที่ใช้ Claude Code ในสเกลมักลงเอยด้วยกลุ่มเล็ก ๆ โดยทั่วไปคือฝ่ายความปลอดภัยและวิศวกรรมแพลตฟอร์ม ซึ่งเป็นเจ้าของการตั้งค่าแบบจัดการ รายการอนุญาต MCP สคริปต์ฮุค และท่อ OpenTelemetry กลุ่มเดียวกันจะรีวิวคำขอยกเว้นและปรับนโยบายเมื่อมีเคสใช้งานใหม่ ๆ

ควรมีเอกสารที่ชัดเจนดังนี้:

• รีโปใดอยู่ในขอบเขตและรีโปใดไม่อยู่ พร้อมโหมดตามระดับความเสี่ยง (รีโปที่เกี่ยวกับข้อมูลที่ถูกกำกับดูแลควรให้ Claude รันในโหมด plan ขณะที่รีโปเว็บไซต์การตลาดอาจรันในโหมด acceptEdits)
• ใครมีสิทธิ์ให้ข้อยกเว้นและติดตามอย่างไร
• รอบการทบทวน (รายไตรมาสพบได้บ่อย) ที่ทีมกลับมาตรวจดูกฎสิทธิ์ เซิร์ฟเวอร์ MCP และข้อมูลเหตุการณ์

บันทึกการตรวจสอบ (Audit logging)

Claude Code ส่งอีเวนต์ OpenTelemetry สำหรับการตัดสินใจใช้เครื่องมือทุกครั้ง การเชื่อมต่อเซิร์ฟเวอร์ MCP การเปลี่ยนโหมดสิทธิ์ และคำขอ API จะไม่มีข้อมูลไหลจนกว่าแอดมินจะกำหนดค่า OTLP endpoint ในการตั้งค่าแบบจัดการ

นี่คือตัวอย่างบล็อกการตั้งค่าแบบจัดการขั้นต่ำสำหรับเทเลเมตริ:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

โดยปริยาย เนื้อหาพรอมต์และพารามิเตอร์ของเครื่องมือจะไม่ถูกส่งออก ดังนั้นอีเวนต์ที่คุณรวบรวมจึงเป็นเมตาดาต้า ไม่ใช่บทสนทนาทั้งหมด หากต้องรวมข้อความพรอมต์ ให้ตั้งค่า OTEL_LOG_USER_PROMPTS=1 หากต้องรวมอาร์กิวเมนต์ของเครื่องมือ (ซึ่งมักต้องการสำหรับการตรวจสอบ) ให้ตั้งค่า OTEL_LOG_TOOL_DETAILS=1 ทั้งสองการตัดสินใจมีนัยด้านความเป็นส่วนตัว ทีมส่วนใหญ่มองว่าเป็นนโยบายที่ต้องใคร่ครวญและกำหนดให้แบ็กเอนด์เทเลเมตริกรองหรือลบทิ้งก่อนจัดเก็บ

การมอนิเตอร์การใช้งาน

สตรีม OpenTelemetry เดียวกับที่ใช้สำหรับการตรวจสอบ ก็ใช้สำหรับการมอนิเตอร์การใช้งานเช่นกัน

Claude Code ส่งออกเมตริกสำหรับการใช้โทเคน ต้นทุนต่อคำขอ จำนวนเซสชัน และอัตราการตัดสินใจของเครื่องมือ เมื่อนำมารวมกัน จะช่วยให้รู้ว่าทีมใดได้คุณค่ามากที่สุด เวิร์กโฟลว์ใดสร้างการปฏิเสธมากที่สุด และโมเดลใดก่อให้เกิดต้นทุน แบ็กเอนด์อย่าง Datadog, Honeycomb, SigNoz, Elastic และ Splunk รองรับรูปแบบ OTLP มาตรฐาน

สไปค์ของอีเวนต์ permission_decision ที่มี decision=deny อาจหมายความว่า Claude พยายามมากเกินไป หรืออาจหมายความว่ากฎ allow ของทีมคับเกินไปก็ได้

ข้อผิดพลาดด้านความปลอดภัยของ Claude Code ที่พบบ่อย

การตั้งค่าที่คลาดเคลื่อนชุดเล็ก ๆ ปรากฏในเหตุการณ์ของ Claude Code ส่วนใหญ่ ต่อไปนี้คือสิ่งที่มักเกิดขึ้นและวิธีรับมือ

ให้สิทธิ์กว้างเกินไป

วิธีที่ทำให้ระบบสิทธิ์鈍ลงเร็วที่สุดคืออนุญาตมากเกินไป

พรอมต์ต่อคำสั่งเพิ่มแรงเสียดทาน และทางออกง่าย ๆ คืออนุญาตแบบกว้าง Bash(*) หรือกำหนด defaultMode: bypassPermissions ทั้งสองอย่างทำลายประสิทธิภาพของระบบสิทธิ์เกือบทั้งหมด

ควรกำหนดกฎ allow ให้พอดีกับเครื่องมือและคำสั่งที่ใช้งานจริง (เช่น Bash(npm test:*) และ Bash(git status)) และปล่อยให้ที่เหลือย้อนกลับไปถามยืนยัน คุณจะได้พรอมต์มากขึ้นช่วงแรก แต่ไม่กี่เซสชันต่อมาก็จะอนุญาตเฉพาะคำสั่งที่ใช้ และพรอมต์ส่วนใหญ่จะหายไป

การเข้าถึง MCP โดยไม่จำกัด

ความผิดพลาดที่สองคือเชื่อมต่อเซิร์ฟเวอร์ MCP โดยไม่ตรวจว่ามันใช้ข้อมูลรับรองอะไรหรือเข้าถึงอะไรได้บ้าง

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

วิธีแก้เหมือนกับสิทธิ์: ใช้ allowlist แบบชัดเจนผ่าน allowedMcpServers ใช้ managed-mcp.json ภายในสำหรับเซิร์ฟเวอร์ที่ทุกคนต้องมี และทบทวนรายการตามรอบเวลา

ไม่ทำ sandbox

หากปิด sandbox ระบบสิทธิ์จะเป็นสิ่งเดียวที่กั้นระหว่าง Claude กับไฟล์ระบบของคุณ

นั่นพอได้สำหรับเซสชันโต้ตอบสั้น ๆ ที่คุณอนุมัติทุกคำสั่งอยู่แล้ว แต่ไม่พอสำหรับการรันอัตโนมัติ การตั้งค่า allow ที่กว้างขึ้น หรือการทำงานที่แตะโค้ดจากแหล่งภายนอก

/sandbox ใช้เปิด หากยังไม่ได้ติดตั้งไลบรารีที่จำเป็น เมนูจะแจ้งว่าควรติดตั้งอะไรบนแพลตฟอร์มของคุณ เมื่อเปิดแล้ว พรอมต์ขออนุญาตจะลดลง และระบบปฏิบัติการจะดักกรณีที่กฎ allow ของคุณไม่ครอบคลุม

ยอมรับการเปลี่ยนแปลงโดยไม่ตรวจสอบ

acceptEdits ทั้งสะดวกและอันตราย

เมื่อ Claude เขียนฟังก์ชันใหม่และคุณคอยดูอยู่ การอนุมัติโดยอัตโนมัติก็โอเค แต่เมื่อ Claude ไต่แก้ไขไฟล์ 30 ไฟล์เป็นชั่วโมง ๆ คุณจะเริ่มหยุดอ่าน diff และเริ่มไว้ใจเอเจนต์ ตรงนั้นแหละที่ปัญหามักเกิด

ควรยึดสองนิสัยนี้:

• คอมมิตเสมอก่อนปล่อยให้ Claude รันอัตโนมัติ เพื่อให้การย้อนกลับอยู่แค่หนึ่งคำสั่ง git reset

• รีวิว diff ก่อนคอมมิตแต่ละครั้งที่ Claude เป็นผู้เขียน ไม่ใช่ดู diff สะสมตอนจบเซสชัน

มองข้ามเส้นทางการตรวจสอบ

ทีมที่รัน Claude Code โดยไม่มีเทเลเมตริจะไม่สามารถตอบคำถาม "เซสชันไหนทำสิ่งนั้น?" อีเวนต์จะสะสมอยู่ในเครื่องแต่ละเครื่องและคงอยู่ที่นั่น ครั้งแรกที่คุณต้องใช้เส้นทางการตรวจสอบก็มักเป็นช่วงเวลาที่เลวร้ายที่สุดที่จะพบว่ายังไม่ได้ตั้งค่า

บรรทัดฐานขั้นต่ำที่มีประโยชน์คือส่งออกอีเวนต์ tool_decision, permission_decision และ api_request ไปยังสแต็ก observability ที่ทีมใช้อยู่ จากนั้นค่อยสร้างแดชบอร์ดและการแจ้งเตือนตามเคสใช้งาน

สรุป

สถานการณ์เลวร้ายที่สุดของแชตบ็อตคือคำตอบที่ไม่ดี แต่สำหรับเอเจนต์เขียนโค้ด คือคำสั่งเชลล์ที่ไปรันบนโปรดักชันด้วยข้อมูลรับรองของคุณ

นั่นคือเหตุผลที่สามเสาหลักสำคัญ:

• สิทธิ์ (Permissions) ตัดสินว่า Claude ได้รับอนุญาตให้ทำอะไร
• การควบคุม MCP ตัดสินว่ามันเข้าถึงระบบภายนอกใดได้บ้าง
• Sandboxing ตัดสินว่าจะเกิดอะไรขึ้นเมื่อสองข้อแรกไม่เพียงพอ

แต่ละอย่างครอบคลุมโหมดความล้มเหลวที่อีกสองอย่างไม่ครอบคลุม เมื่อนำมารวมกัน จึงกำหนดขอบเขตการทำงานจริงที่ Claude อยู่ภายใน

หากต้องการสอบใบรับรองด้าน Generative AI โปรดดูการเปรียบเทียบ คอร์สเด่น เคล็ดลับเตรียมตัว และคำถามที่พบบ่อยสำหรับ สุดยอดใบรับรอง Generative AI ปี 2026.