แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ Claude Code สำหรับทีมในปี 2026

ปรับปรุงล่าสุด: July 26, 2026

ตัวแทนโค้ด AI ที่สามารถอ่าน repo ของคุณ รัน shell commands และเรียกใช้ external services นั้นมีประโยชน์อย่างยิ่งเพราะมันมีความสามารถในการเข้าถึงที่กว้างขวาง ความสามารถในการเข้าถึงเดียวกันนี้ก็คือความเสี่ยง Prompt ที่อ่านผิด, allowlist ที่หละหลวม, หรือ MCP server ที่ไม่น่าเชื่อถือตัวเดียว ก็สามารถทำให้ token รั่วไหลหรือลบ branch ได้ คู่มือนี้มีไว้สำหรับนักพัฒนาหรือหัวหน้าแพลตฟอร์มที่ต้องการใช้ Claude Code ในการทำงานประจำวันและใน CI โดยที่ไม่ต้องมอบกุญแจสู่ production ให้มัน

คำตอบสั้นๆ: ทีมต่างๆ จะรักษาความปลอดภัยของ Claude Code ได้อย่างไร?

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

• เริ่มต้นในโหมดสิทธิ์ที่จำกัดและให้เครื่องมือผ่านรายการอนุญาตที่แคบ ไม่ใช่การ "อนุญาตเสมอ" แบบครอบคลุม
• เก็บความลับให้อยู่นอกบริบทของโมเดล: ห้ามวางคีย์ที่นี่ และใช้กฎ deny บนไฟล์ .env และพาธความลับ
• ตรวจสอบเซิร์ฟเวอร์ MCP ทุกตัวก่อนเชื่อมต่อ เนื่องจากเซิร์ฟเวอร์ที่ไม่น่าเชื่อถือสามารถอ่านข้อมูลและดำเนินการในนามของคุณได้
• ถือว่าเนื้อหาเว็บที่ดึงมาเป็นอินพุตที่ไม่น่าเชื่อถือ ซึ่งอาจมีคำสั่ง prompt-injection ปนอยู่
• ใน CI ให้มอบโทเคนที่มีอายุสั้นและจำกัดขอบเขตการอ่านให้กับเอเจนต์ และห้ามเปิดเผยข้อมูลรับรองของ Production โดยเด็ดขาด

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

โหมดสิทธิ์การใช้งานและรายการอนุญาตทำงานอย่างไรกันแน่?

Claude Code จะสอบถามก่อนที่จะเรียกใช้เครื่องมือเป็นครั้งแรก คุณจะเป็นผู้กำหนดว่าการตัดสินใจนั้นจะถูกจดจำ (remembered), จำกัดขอบเขต (scoped) หรือข้ามไปเลย โหมดสิทธิ์การใช้งานจะกำหนดค่าพื้นฐานไว้ดังนี้:

• default จะแจ้งเตือนในการใช้งานเครื่องมือหรือคำสั่งแต่ละครั้งเป็นครั้งแรก
• plan เป็นแบบอ่านอย่างเดียว: ตัว agent สามารถอ่านไฟล์และเสนอแผนได้ แต่ไม่สามารถแก้ไขหรือรันคำสั่งได้ ใช้สำหรับการตรวจสอบเท่านั้น
• acceptEdits ยอมรับการแก้ไขไฟล์โดยอัตโนมัติ แต่ยังคงแจ้งเตือนสำหรับคำสั่ง shell
• bypassPermissions ข้ามการแจ้งเตือนทุกครั้ง ถือว่าใช้ในสภาพแวดล้อม sandbox เท่านั้น

การควบคุมที่ถาวรจะอยู่ในไฟล์ .claude/settings.json ภายใต้ permissions โดยมีกฎ allow, ask, และ deny กฎเหล่านี้ถูกจำกัดขอบเขตตามเครื่องมือและรูปแบบ (pattern) ดังนั้นคุณจึงให้สิทธิ์เฉพาะสิ่งที่งานนั้นต้องการเท่านั้น:

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

กฎ deny จะมีผลเหนือกว่ากฎ allow เสมอ ซึ่งเป็นสาเหตุที่พาธลับข้างต้นยังคงอ่านไม่ได้ แม้ว่าจะมีกฎ Read ที่กว้างก็ตาม Anthropic ได้จัดทำเอกสารไวยากรณ์และลำดับความสำคัญของกฎทั้งหมดไว้ใน identity and access management docs ของ Claude Code

หลีกเลี่ยงการใช้ --dangerously-skip-permissions นอกคอนเทนเนอร์ที่สามารถทิ้งได้ (disposable container) เพราะมันจะลบจุดตรวจสอบของมนุษย์เพียงจุดเดียวที่สามารถตรวจจับ rm ที่ผิดพลาดหรือการเรียกเครือข่ายที่ไม่คาดคิดได้ หากคุณต้องการความเร็วโดยไม่มีความเสี่ยงนั้น ควรใช้ allowlist ที่จำกัดอย่างเข้มงวด เพื่อให้คำสั่งประจำดำเนินการไปได้โดยอัตโนมัติ ในขณะที่สิ่งใหม่ๆ ยังคงหยุดรอการอนุมัติจากคุณ

ข้อมูลอ้างอิงความเสี่ยงและการบรรเทาผลกระทบ

เหตุการณ์ส่วนใหญ่มีที่มาจากรูปแบบเพียงไม่กี่อย่าง ให้จับคู่แต่ละรายการกับมาตรการควบคุมก่อนที่คุณจะขยายใช้งาน agent ไปทั่วทั้งทีม

การจัดกรอบในที่นี้อ้างอิงจาก OWASP Top 10 for LLM Applications ซึ่งระบุว่า prompt injection, insecure output handling และ excessive agency เป็นความเสี่ยงหลักของ agent

การอ้างอิงสิทธิ์และขอบเขต

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

การตรวจสอบเซิร์ฟเวอร์ MCP ก่อนการเชื่อมต่อ

เซิร์ฟเวอร์ MCP จะขยายความสามารถของ agent ด้วยเครื่องมือใหม่ๆ เช่น database client, การรวมระบบ ticketing และ browser แต่ละตัวที่คุณเพิ่มเข้าไปคือโค้ดที่สามารถอ่านบริบทและดำเนินการได้ เซิร์ฟเวอร์ที่ไม่น่าเชื่อถือเป็นวิธีที่เร็วที่สุดในการเปลี่ยน agent ที่มีประโยชน์ให้กลายเป็นช่องทางรั่วไหลของข้อมูล ดังนั้นเกณฑ์สำหรับการเชื่อมต่อเซิร์ฟเวอร์จึงควรเป็นมาตรฐานเดียวกับที่คุณใช้กับ dependency ใดๆ ที่มีการเข้าถึงเครือข่าย

ก่อนที่คุณจะเพิ่มเซิร์ฟเวอร์ ให้ตอบคำถามทั้งห้าข้อนี้:

1. ใครเป็นผู้เผยแพร่ และแหล่งที่มานั้นเป็นสาธารณะและมีการดูแลหรือไม่?
2. มันร้องขอขอบเขต (scopes) อะไรบ้าง: อ่านอย่างเดียว หรือเขียนและเครือข่ายด้วย?
3. เมื่อเชื่อมต่อแล้วมันสามารถเห็นข้อมูลอะไรได้บ้าง: แค่ repo นี้ หรือทั้งเครื่องของคุณ?
4. ข้อมูลรับรอง (credentials) ถูกจำกัดขอบเขตและมีอายุสั้น หรือเป็น admin token ที่มีอายุยาวนาน?
5. คุณสามารถกำหนดเวอร์ชัน (pin a version) ได้หรือไม่ เพื่อป้องกันไม่ให้การอัปเดตอัตโนมัติขยายการเข้าถึงอย่างเงียบๆ?

ให้เชื่อมต่อเซิร์ฟเวอร์ด้วยขอบเขตที่น้อยที่สุดเท่าที่จะทำได้เพื่อให้งานเสร็จ และให้เก็บเซิร์ฟเวอร์ที่มีความสามารถในการเขียนหรือเซิร์ฟเวอร์ที่เกี่ยวข้องกับ Production ออกจากไฟล์ config ที่ใช้ร่วมกันหรือ CI สำหรับกลไกการตั้งค่าและคำแนะนำเชิงลึก ให้ดูที่ Claude Code MCP integration guide บทความ Claude Code productivity tips จะครอบคลุมวิธีการรักษา footprint ให้เล็กโดยไม่ทำให้คุณช้าลง

การเก็บความลับให้ห่างจากขอบเขตของโมเดล

ความลับที่สะอาดที่สุดคือความลับที่โมเดลไม่เคยเห็น อย่าแปะ API keys ลงใน prompt และอย่าขอให้ agent "อ่าน key จาก config แล้วนำไปใช้" ให้ปล่อยให้ credentials อยู่ใน environment และอ้างถึงพวกมันด้วยชื่อ เพื่อให้ค่าเหล่านั้นอยู่นอก transcript

นิสัยสามข้อนี้ช่วยลดความเสี่ยงส่วนใหญ่:

• เพิ่มกฎ deny สำหรับ .env, *.pem, และไดเรกทอรี secrets/ ใด ๆ เพื่อป้องกันไม่ให้ agent อ่านพวกมันได้แม้จะโดยไม่ได้ตั้งใจ
• ใช้ secret scanner ก่อน commit (เช่น gitleaks หรือ git secrets) เพื่อให้แน่ใจว่าหาก key รั่ว จะทำให้การ commit ล้มเหลว ไม่ใช่การตรวจสอบ (audit)
• หมุนเวียนทุกอย่างที่ถูกเปิดเผยทันที จากนั้นตรวจสอบ log และ history การหมุนเวียนเป็นวิธีแก้ไขเดียวที่ปิดช่องโหว่นั้นได้จริง

หาก key ใด ๆ เข้าไปถึง transcript หรือ commit แล้ว ให้ถือว่ามันถูกบุกรุกและทำการหมุนเวียน (rotate) ทันที การค้นหา git history ด้วย git log -S จะช่วยให้คุณทราบว่ามันตกอยู่ในส่วนใด

Scenario: การเปิดใช้งาน Claude Code ใน CI โดยไม่มีสิทธิ์การเข้าถึง Production

ทีมงานต้องการให้ Claude Code ตรวจสอบ pull requests ใน GitHub Actions เป้าหมายคือการแสดงความคิดเห็นในการรีวิวโดยอัตโนมัติ โดยที่ไม่มีความสามารถในการ deploy, เขียนไปยัง main branch หรือแตะต้องฐานข้อมูล production ได้เลย

นี่คือการตั้งค่าที่ทำให้งานมีประโยชน์แต่ถูกจำกัดขอบเขต:

• รันแบบ headless ด้วย claude -p ในโหมด plan เพื่อให้ agent อ่าน diff และเขียน comment แต่ไม่เคยแก้ไขไฟล์หรือรัน build commands
• ให้สิทธิ์ workflow เฉพาะ contents: read และ pull-requests: write เท่านั้น ไม่มี job สำหรับ deploy และไม่มีขอบเขต infrastructure
• ใช้ GITHUB_TOKEN ที่มีอายุสั้นของ job ไม่ใช่ personal token และห้ามใส่ production keys ของฐานข้อมูลหรือ cloud ใน environment ของ job นั้นเด็ดขาด
• เพิ่มรายการ deny สำหรับ secret paths และ outbound curl เพื่อป้องกันไม่ให้การพยายาม prompt-injection ภายใน PR diff สามารถ exfiltrate ข้อมูลใดๆ ได้
• กำหนดเวอร์ชันของ action และ Claude Code ให้ตายตัว (pin) และจำกัดขั้นตอน deploy ใด ๆ ไว้หลัง environment แยกที่ต้องได้รับการอนุมัติจากมนุษย์

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

job การรีวิวจะเห็นโค้ดและโพสต์ feedback มันไม่สามารถเข้าถึง production ได้เพราะ credentials ของ production ไม่เคยอยู่ในขอบเขต (scope) ของมัน Anthropic's Claude Code security overview อธิบายถึงหลักการสิทธิ์ขั้นต่ำสุด (least-privilege posture) นี้สำหรับการรันแบบอัตโนมัติและ headless

อ่านเพิ่มเติม: AI ใน DevOps: ระบบอัตโนมัติ CI/CD, การจัดการ Incident และ Infrastructure

อะไรที่คุณไม่ควรวางลงใน AI coding agent?

ข้อมูลบางอย่างไม่ควรถูกส่งไปยัง transcript โดยเด็ดขาด เนื่องจากข้อมูลใด ๆ ใน context window อาจถูกสะท้อนกลับ บันทึก หรือนำไปดำเนินการได้:

• Live API keys, database URLs with passwords, หรือ cloud root credentials.
• ข้อมูล PII ของลูกค้า หรือข้อมูลที่ถูกควบคุมซึ่งคุณจะไม่ใส่ในตั๋วสนับสนุน (support ticket).
• Private signing keys, certificates, หรือไฟล์ .pem.
• Full production connection strings เมื่อใช้ read replica หรือ local fixture ก็เพียงพอแล้ว.

หาก agent ต้องการการเข้าถึง ให้ระบุพาธไปยัง credential ที่จำกัดขอบเขตผ่าน environment แทนที่จะให้ secret นั้นโดยตรง ผลลัพธ์ยังคงเดิม แต่ลดขนาดความเสี่ยง (blast radius) ได้มาก

การตรวจสอบ, hooks, และการทบทวนอย่างต่อเนื่อง

สิทธิ์ขั้นต่ำสุดกำหนดพื้นฐาน แต่การทบทวนคือสิ่งที่ทำให้คุณคงอยู่ตรงนั้น อ่านแผนของ agent ก่อนที่คุณจะอนุมัติขั้นตอนที่มีความเสี่ยง และอ่าน diff ก่อนที่คุณจะ commit สำหรับการเปลี่ยนแปลงที่ใหญ่ขึ้น วินัยเดียวกันที่ทำให้ AI-assisted refactoring ปลอดภัยก็สามารถนำมาใช้ได้ที่นี่: การทำทีละขั้นตอนเล็ก ๆ ที่สามารถทบทวนได้ ดีกว่าการรันครั้งเดียวขนาดใหญ่โดยไม่มีผู้ดูแล

เพิ่ม guardrails แบบกำหนดค่าด้วย hooks. hook ประเภท PreToolUse สามารถตรวจสอบคำสั่งและบล็อกมันก่อนที่จะทำงาน ซึ่งเป็นวิธีที่คุณบังคับใช้กฎที่ model ไม่ควรข้ามเด็ดขาด เช่น การปฏิเสธการเขียนไปยัง protected path คู่สิ่งนี้กับ audit trail เพื่อให้คุณสามารถตอบได้ว่า agent ทำอะไร เมื่อไหร่ และในนามของใคร

รายการตรวจสอบประจำสำหรับทีม:

• ทบทวน allow และ deny lists ใน .claude/settings.json ตามกำหนดเวลา ไม่ใช่แค่ตอนตั้งค่า
• ตรวจสอบ MCP servers อีกครั้งหลังจากการอัปเกรดเวอร์ชันหลัก
• ยืนยันว่า CI jobs ยังคงทำงานในโหมด plan และไม่มี production secrets ใด ๆ
• หมุนเวียน tokens เป็นระยะและหลังจากที่สงสัยว่าจะมีการเปิดเผยข้อมูลใด ๆ
• เก็บไฟล์ CLAUDE.md ที่ระบุสิ่งที่ห้ามละเลย: ห้าม force-push ไปยัง main, ห้ามเข้าถึง prod DB โดยตรง, และห้ามมี secrets ใน prompts

สำหรับขั้นตอนการทำงานโดยรวมทั้งหมดนี้ Claude Code ultimate guide จะแนะนำตั้งแต่การตั้งค่าจนจบกระบวนการ

ข้อสรุปที่สำคัญ

ความปลอดภัยสำหรับ AI coding agents คือแนวคิดแบบสิทธิ์น้อยที่สุด (least-privilege) ที่คุณใช้กับ service accounts อยู่แล้ว โดยเขียนออกมาในรูปแบบของกฎการอนุญาต (permission rules) เริ่มต้นด้วยการจำกัดอย่างเข้มงวด ขยายขอบเขตโดยใช้ allowlist ที่แคบ ให้ปฏิเสธ path ลับ ตรวจสอบ (vet) MCP servers เหมือนกับ dependencies ถือว่าเนื้อหาที่ดึงมาเป็นข้อมูลที่ไม่น่าเชื่อถือ และเก็บ production credentials ออกจากงานใด ๆ ที่ agent สามารถเข้าถึงได้ หากทำเช่นนั้น Claude Code ก็จะยังคงเป็นคู่มือที่รวดเร็ว ไม่ใช่ประตูที่เปิดทิ้งไว้