# Repository ของคนอื่นอาจยึด Claude Code ได้อย่างไร: 7 กฎป้องกัน

> สี่เส้นทาง indirect prompt injection ที่มีเอกสารผ่าน repository เนื้อหา GitHub เหตุการณ์ Sentry และ metadata MCP พร้อมวิจัยปฐมภูมิกับขอบเขตการจำกัดความเสียหายจริง

Source: https://ailoot.ai/blog/th/malicious-repository-claude-code/
Canonical: https://ailoot.ai/blog/th/malicious-repository-claude-code/
Language: th
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-148
Revision: sha256-bfe6451eedeab2f2256a0d22f0e4e954f472e89df2f82f3438667d6219b43e48


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

งานวิจัยที่เผยแพร่แสดงเส้นทาง indirect injection สี่แบบ: คำแนะนำติดตั้ง เนื้อหา GitHub telemetry และ metadata เครื่องมือ MCP รายงานออกต่างวันและเกี่ยวกับไคลเอนต์กับการตั้งสิทธิ์ต่างกัน ด้านล่างเป็นแหล่งปฐมภูมิกับการจำกัดความเสียหายเชิงปฏิบัติ ไม่มีไฟล์ตั้งค่าใดรับประกันภูมิคุ้มกัน

</div>

[เอกสาร Ailoot: API, คีย์ และการตั้งค่า](https://ailoot.ai/docs/).

## สี่เส้นทางที่มีเอกสารจากข้อความไม่น่าเชื่อถือสู่การกระทำเอเจนต์

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

คำเรียกอย่างเป็นทางการคือ indirect prompt injection: คำสั่งอันตรายไม่ได้มาจากคุณโดยตรง แต่มาจากข้อมูลที่ agent ประมวลผลระหว่างทำงาน เช่น README จากแหล่งอื่น ข้อความแสดงข้อผิดพลาด ความคิดเห็นใน GitHub หรือคำตอบจากบริการภายนอก คุณจะลืมคำศัพท์นี้ไปหลังอ่านย่อหน้านี้ก็ได้ จากนี้ฉันจะอธิบายด้วยภาษาง่าย ๆ

ตัวอย่างวิจัยสี่เรื่องที่จะกล่าวถึง:

1.  repository ที่ดูไม่มีพิษภัยสามารถกลายเป็น reverse shell ได้
2.  ชื่อ Pull Request ถูกแสดงให้เห็นว่าสามารถยึด AI agent สามตัวพร้อมกันได้
3.  มีการแสดงให้เห็นว่า agent ยอมรับรายงานข้อผิดพลาดปลอมจาก Sentry แทนรายงานจริง
4.  คำอธิบายเครื่องมือ MCP ถูกแสดงให้เห็นว่าสามารถควบคุม agent ได้อย่างมีประสิทธิภาพพอ ๆ กับ system prompt



## README ของ repository ที่ดูไม่มีพิษภัยกลายเป็น reverse shell ได้อย่างไร

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

[proof of concept ของ 0DIN วันที่ 25 มิถุนายน 2026](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine) แสดงว่า: คุณโคลน repository ที่ดูปกติ แล้วขอให้ Claude Code รันโปรเจกต์—มันก็ทำตามคำแนะนำการติดตั้งอย่างว่าง่าย เมื่อการรันครั้งแรกเกิดข้อผิดพลาด ข้อความนั้นจะแนะนำคำสั่ง “แก้ไข” ซึ่งแท้จริงแล้วใช้ค้นหา DNS record ของผู้โจมตีและเปิด reverse shell แหล่งที่อ้างสาธิตเทคนิค ไม่ได้ยืนยันว่าใช้ในเหตุจริงบ่อยเพียงใด

</div>

กลไกเหล่านี้ถูกออกแบบมาให้ไม่มีชั้นใดชั้นหนึ่งดูน่าสงสัย:

1.  คุณโคลน repository ที่ดูปกติ แล้วขอให้ Claude Code รันโปรเจกต์
2.  repository ติดตั้งแพ็กเกจ Python ที่ออกแบบมาให้ทำงานล้มเหลวเมื่อใช้งานครั้งแรก
3.  ข้อความแสดงข้อผิดพลาดแนะนำคำสั่ง “แก้ไข” อย่างสุภาพ: `python3 -m axiom init`
4.  คำสั่ง `init` เรียกใช้ `setup.sh`
5.  สคริปต์ค้นหา DNS TXT record (ปกติใช้สำหรับบันทึกข้อมูลเกี่ยวกับโดเมน แต่ช่องนี้รับข้อความใดก็ได้) ผู้โจมตีใส่คำสั่งที่เข้ารหัส base64 ไว้ที่นั่น (วิธีแปลงข้อมูลเป็นข้อความธรรมดาโดยไม่มีช่องว่างหรืออักขระพิเศษ) แล้วส่งตรงเข้า bash
6.  สามารถเปลี่ยนค่าใน DNS record ได้ทุกเมื่อ—ทำให้ผู้โจมตีมี reverse shell แบบโต้ตอบได้ โดยใช้สิทธิ์ผู้ใช้ของคุณและเข้าถึงความลับทั้งหมดในเครื่อง



payload ในตัวอย่างดึงจาก DNS ตอน runtime จึงสแกนเฉพาะ bytes repository ไม่พบ payload สุดท้าย ไม่ได้พิสูจน์ว่า scanner หรือ runtime control ทุกชนิดไร้ผล การตรวจเนื้อหาที่ดึง process monitoring และข้อจำกัดเครือข่ายอาจเปิดเผยหรือขัด chain ได้ แหล่งนี้เป็น proof of concept ไม่ใช่การวัดความแพร่หลายเหตุจริง

## ชื่อ Pull Request ใช้ยึด AI agent 3 ตัวที่ต่างกันได้อย่างไร

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

[รายงาน Comment and Control ว่าด้วย prompt injection และการขโมย credentials ผ่าน GitHub](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/) เผยแพร่ 15 เมษายน 2026 อัปเดต 4 พฤษภาคม อธิบายเส้นทาง GitHub-text injection ต่างกันใน Claude Code Security Review, Gemini CLI Action และ Copilot Agent การลดระดับความรุนแรงไม่พิสูจน์ว่าแก้ injection ทั้งประเภทครบ รายงานบันทึกคำตอบผู้ให้บริการและข้อจำกัดเครื่องมือ Claude เฉพาะอย่าง

</div>





ผู้วิจัยอธิบายเส้นทางและการตอบสนองเหล่านี้ เป็นรายงานย้อนหลัง ไม่ใช่การตรวจผลิตภัณฑ์ปัจจุบันทุกรุ่น:

| Agent | การโจมตีเข้ามาได้อย่างไร | ข้อมูลที่รั่วไหล | สถานะปัจจุบัน |
|----|----|----|----|
| Claude Code Security Review | ชื่อ PR ถูกแทรกเข้า system prompt โดยตรงโดยไม่มีการกรอง | `ANTHROPIC_API_KEY`, `GITHUB_TOKEN` | ผู้วิจัยรายงานข้อจำกัด ps กับการเปลี่ยนเอกสาร ระดับความรุนแรงเปลี่ยนเป็น None เมื่อ 20 เมษายน 2026 |
| Gemini CLI Action | ส่วน “Trusted Content” ปลอมในความคิดเห็นหลบเลี่ยงคำแนะนำด้านความปลอดภัย | `GEMINI_API_KEY` | Google เพิ่ม guardrail prompt แยกต่างหากเข้า system prompt |
| GitHub Copilot Agent | ซ่อน payload ไว้ใน HTML comment ที่มองไม่เห็นใน Markdown | `GITHUB_COPILOT_API_TOKEN`, `COPILOT_JOB_NONCE` | GitHub มองว่าเป็นข้อจำกัดทางสถาปัตยกรรม ไม่ใช่บั๊ก |

เกือบห้าเดือนผ่านไประหว่างรายงานแรกกับรายงานสุดท้ายในรอบการเปิดเผยนี้ (รายงาน Claude Code ฉบับแรกลงวันที่ 17 ตุลาคม 2025; การแก้บั๊ก GitHub Copilot ครั้งสุดท้ายคือวันที่ 9 มีนาคม 2026) การเปลี่ยนระดับความรุนแรงกับมาตรการบรรเทาไม่ยืนยันว่าปิดทุก payload ที่เป็นไปได้ [repository PoC ของผู้วิจัย](https://github.com/0dd/Claude-review-poc) บันทึกเส้นทาง Claude ที่สาธิต ห้ามรัน payload โจมตีกับระบบจริง สิ่งที่เป็นประโยชน์สำหรับคุณคือรูปแบบการโจมตี: ข้อมูลที่ยังไม่ผ่านการตรวจสอบจาก GitHub เข้าสู่ agent, agent เรียกใช้คำสั่ง และความลับรั่วไหลผ่าน GitHub เดียวกัน—ผู้โจมตีไม่จำเป็นต้องใช้เซิร์ฟเวอร์ภายนอก

การวิเคราะห์เพียงสองเรื่องก็เพียงพอให้เห็นรูปแบบนี้: การแก้ไขข้อค้นพบใหม่ทีละรายการไม่ใช่วิธีที่ทำได้จริง เพราะช่องโหว่ประเภทนี้ปรากฏขึ้นทุกสองสัปดาห์ การเขียนกฎความปลอดภัยไว้อย่างชัดเจนใน CLAUDE.md และ settings.json แทนการจำไว้ในหัว เป็นส่วนหนึ่งของ context engineering: ตั้งค่าเพียงครั้งเดียว แล้วกฎจะทำงานโดยอัตโนมัติใน Claude Code ทุกเซสชันใหม่ โดยไม่ต้องเตือนซ้ำ

## รายงานข้อผิดพลาดปลอมจาก Sentry ยึด agent ของคุณได้หรือไม่

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

เทคนิคหนึ่งทำงานดังนี้: ผู้โจมตีส่งเหตุการณ์ข้อผิดพลาดปลอมไปยัง Sentry; agent ขอรายการ issue ผ่าน MCP ได้รับเหตุการณ์อันตรายปะปนกับเหตุการณ์จริง และเรียกใช้คำสั่งที่ฝังอยู่ในนั้นเป็น “ขั้นตอนแก้ไข” [รายงาน Agentjacking ของ Tenet](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/) อัปเดต 17 มิถุนายน 2026 รายงานสำเร็จ 85% รวมจาก controlled validation หลายรอบและการรันเอเจนต์มากกว่า 100 ครั้ง รวม Claude Code, Cursor และ Codex ระบุ capture Claude Code 2-1-161 วันที่ 2 มิถุนายน แต่ไม่เผยรายชื่อโมเดลครบ harness ทำซ้ำ ตัวหารจำนวนทดลองตรง หรือผลแยกไคลเอนต์ ต้องถือ 85% เป็นข้อสังเกตรวมผู้วิจัย ไม่ใช่โอกาสที่การติดตั้งปัจจุบันใด ๆ จะถูกเจาะ

</div>

การโจมตีต้องการเพียงคีย์ Sentry DSN—ตัวระบุสาธารณะที่หลายโปรเจกต์ใส่ไว้ในโค้ดฝั่งไคลเอนต์โดยตรง:



กลไกไม่ซับซ้อน: นักพัฒนาขอให้ agent ตรวจสอบข้อผิดพลาดที่ยังเปิดอยู่ใน Sentry; agent ขอข้อมูลผ่านเซิร์ฟเวอร์ MCP ได้เหตุการณ์อันตรายปะปนกับเหตุการณ์จริง แล้วอ่านข้อความคำสั่งที่ฝังอยู่ในนั้นเป็นคำสั่งที่เชื่อถือได้สำหรับแก้ข้อผิดพลาด—เพราะในทางรูปแบบแล้ว นั่นคือสิ่งที่ได้รับมอบหมายให้ทำพอดี



Tenet รายงานว่าตัวควบคุมเดิมไม่แจ้งเตือนใน environment ที่ทดสอบ ไม่ยืนยันว่ารันไร้ร่องรอยในทุก deployment logs เอเจนต์/เครื่องมือ endpoint telemetry และบันทึกเครือข่ายจับการกระทำภายหลังได้ การโจมตีเริ่มจาก telemetry ภายนอกแล้วขึ้นกับเครื่องมือกับสิทธิ์จริงของเอเจนต์

## ทำไมคำอธิบายเครื่องมือ MCP จึงอันตรายพอ ๆ กับ system prompt

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

metadata เครื่องมือมีคำสั่งชี้นำโมเดลได้ แต่ไม่ได้มีอำนาจเท่า system prompt อัตโนมัติ [MCPTox](https://arxiv.org/abs/2508.14925) ส่งครั้งแรก 19 สิงหาคม 2025 ประเมิน tool poisoning ผ่านเครื่องมือ MCP สมจริง และพบความไวต่างตามโมเดลกับการตั้ง ข้อสังเกตว่าโมเดลเก่งกว่าอาจไวกว่าเป็นผลในเบนช์มาร์กนั้น ไม่ใช่กฎสากล

</div>

ถ้อยคำของ Microsoft ชัดเจนที่สุดเท่าที่ฉันพบในหัวข้อนี้:



เทคนิคนี้เรียกว่า tool poisoning: คำสั่งที่ซ่อนอยู่ในคำอธิบายของเครื่องมือที่ดูไม่มีพิษภัยทำให้ agent ลงมือทำตามคำสั่งนั้น



Claude 3.7 Sonnet ทนทานได้ดีที่สุดในการทดสอบนี้ แต่แม้แต่โมเดลนี้ก็ปฏิเสธคำสั่งที่ถูกวางยาพิษในน้อยกว่า 3% ของกรณี—แม้แต่โมเดลที่ดีที่สุดก็ยังต้องพึ่งโชคมากกว่าการป้องกัน ข้อสรุปที่สวนทางกับสามัญสำนึกของ benchmark คือ ยิ่งโมเดลทำตามคำสั่งได้แม่นยำเท่าไร ก็ยิ่งแยกคำสั่งที่ถูกต้องออกจากคำสั่งที่ซ่อนอยู่ใน metadata ได้ยากขึ้นเท่านั้น—จุดแข็งของโมเดลกลับกลายเป็นผลเสีย

## การโจมตีเหล่านี้เหมือนกันอย่างไร และการตรวจจับอาจพลาดอะไร?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

ข้อค้นพบทั้งสี่เรื่องใช้ประโยชน์จากจุดบอดเดียวกัน: agent ไม่แยก “ข้อมูลที่ต้องวิเคราะห์” ออกจาก “คำสั่งที่ต้องทำตาม” การสแกนเฉพาะ repository อาจพลาด payload ที่มาตอนหลังผ่านเครื่องมือหรือเครือข่าย การตรวจจับยังมีประโยชน์แต่ต้องดูเส้นทางรันทั้งหมด ใช้ร่วมกับขอบเขตไฟล์ credentials เครื่องมือ และเครือข่าย แทนพึ่งให้เอเจนต์รู้ทันคำสั่ง

</div>







ข้อสรุปนี้ใช้ได้กับข้อค้นพบทั้งสี่เรื่อง: อย่าพึ่งพาว่า “โค้ดดูปกติ”—แต่ละขั้นตอนของการโจมตีดูไม่มีพิษภัยจริง ๆ เมื่อมองแยกกัน จำกัดความสามารถที่มีจริงและตรวจการกระทำที่เสนอ การตรวจจับกับการจำกัดความเสียหายจัดการคนละส่วนของการโจมตี

## Claude Code มีการป้องกันอะไรอยู่แล้ว—และทำไมจึงยังไม่พอ

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

Claude Code มีระบบป้องกันในตัว: วิเคราะห์ prompt ทั้งหมดเพื่อหาคำสั่งที่น่าสงสัย ใช้ context window ที่แยกต่างหากสำหรับเนื้อหาจากเว็บ ตรวจสอบความน่าเชื่อถือเมื่อเปิดโฟลเดอร์ใหม่ครั้งแรก และเมื่อเชื่อมต่อเซิร์ฟเวอร์ MCP แต่ flag `--dangerously-skip-permissions` ซึ่งหลายคนใช้เพื่อปิดคำถามขออนุญาตที่น่ารำคาญ จะปิดการป้องกันทั้งหมดนี้พร้อมกัน

</div>

Anthropic ยอมรับปัญหานี้โดยตรงใน [เอกสารของตน](https://code.claude.com/docs/en/security) แทนที่จะปกปิด:

<figure>
<blockquote>
<p>Prompt injection คือเทคนิคที่ผู้โจมตีพยายามลบล้างหรือเปลี่ยนคำสั่งของ AI assistant ด้วยการแทรกข้อความอันตราย Claude Code มีการป้องกันการโจมตีเหล่านี้หลายวิธี</p>
</blockquote>
<figcaption>— เอกสาร Claude Code, https://code.claude.com/docs/en/security</figcaption>
</figure>

ตามเอกสาร agent วิเคราะห์ prompt ทั้งหมดเพื่อหาคำสั่งที่น่าสงสัย ไม่อนุมัติ `curl` และ `wget` โดยอัตโนมัติ เก็บเนื้อหาเว็บไว้ใน context window แยกเพื่อไม่ให้ปะปนกับบริบทหลัก และขอให้ยืนยันความน่าเชื่อถือเมื่อเปิด codebase ใหม่หรือเชื่อมต่อเซิร์ฟเวอร์ MCP ใหม่เป็นครั้งแรก

แต่มีข้อควรระวังเด็ดขาดที่ Anthropic ระบุไว้อย่างตรงไปตรงมา:

<figure>
<blockquote>
<p>โหมด bypassPermissions ไม่ได้ให้การป้องกัน prompt injection หรือการกระทำที่ไม่ตั้งใจ</p>
</blockquote>
<figcaption>— เอกสาร Claude Code, https://code.claude.com/docs/en/permission-modes</figcaption>
</figure>

หากคุณเคยเปิด Claude Code ด้วย `--dangerously-skip-permissions` ด้วยความหงุดหงิดเพื่อให้มัน “เลิกถามจุกจิกเสียที” นั่นคือจังหวะที่คุณปิดกลไกทั้งหมดซึ่งอาจหยุดการโจมตีทั้งสี่แบบข้างต้นได้ ฉันตั้งใจปิด flag นี้ไว้เสมอ แม้ Claude Code จะถามซ้ำเป็นครั้งที่สิบในเซสชันเดียวกัน—มันน่ารำคาญ แต่คำถามเหล่านั้นคือเส้นแบ่งระหว่าง “agent อ่านข้อความน่าสงสัย” กับ “agent เรียกใช้ข้อความนั้น” การตั้งค่าที่เหมาะสมสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์คือใช้โหมดสิทธิ์มาตรฐาน (`default` หรือ `acceptEdits`) พร้อมเปิด sandbox: การแก้ไขไฟล์ทั่วไปทำได้โดยไม่ต้องถามเพิ่ม ส่วนคำสั่ง terminal จะออกนอก sandbox ไม่ได้ แม้ agent จะถูกหลอกแล้วก็ตาม

## เปิดโหมด sandbox และปิดช่องโหว่ที่ยังเปิดอยู่โดยปริยายได้อย่างไร

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

คำสั่ง `/sandbox` ในเซสชัน Claude Code จำกัดตำแหน่งที่ agent เขียนได้และโดเมนที่เชื่อมต่อได้ บน macOS ใช้งานได้ทันที; Linux และ WSL2 ต้องติดตั้งแพ็กเกจ `bubblewrap` และ `socat` มีรายละเอียดสำคัญอย่างหนึ่ง: โดยปริยาย sandbox ไม่ได้บล็อกการอ่านไฟล์อย่าง `~/.ssh`—คุณต้องเปิดการป้องกันส่วนนี้แยกต่างหาก

</div>

หากต้องการเปิดใช้อย่างถาวรสำหรับทุกโปรเจกต์ ให้แก้ไข `~/.claude/settings.json` เพียงจุดเดียว:

```json
{
  "sandbox": { "enabled": true }
}
```

โดยปริยาย คำสั่งใน sandbox เขียนได้เฉพาะในไดเรกทอรีทำงานของโปรเจกต์และไดเรกทอรีชั่วคราวของเซสชัน การเข้าถึงเครือข่ายจะผ่าน proxy—ไม่มีโดเมนใดได้รับอนุญาตไว้ล่วงหน้า และ Claude Code จะขอการยืนยันเมื่อเชื่อมต่อโดเมนใหม่ครั้งแรก [Anthropic ระบุ](https://www.anthropic.com/engineering/claude-code-sandboxing) ว่าวิธีนี้ช่วยลดคำขออนุญาตได้มาก—84% จากการวัดภายในบริษัท—เพราะ sandbox จัดการกรณีที่ปลอดภัยบางส่วนเอง แทนที่จะถามคุณทุกครั้ง

ช่องโหว่ที่การตั้งค่ามาตรฐานยังเปิดไว้: โดยปริยาย sandbox จำกัด *การเขียน* แต่ไม่ได้ป้องกัน *การอ่าน* ไฟล์อย่าง `~/.aws/credentials` และ `~/.ssh` ซึ่งเป็นไฟล์และตัวแปรสภาพแวดล้อมที่การโจมตีข้างต้นมุ่งเป้าโดยตรง ปิดช่องนี้ด้วยบล็อกแยกในไฟล์เดียวกัน:

```json
{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}
```

ประเด็นคือ ต่อให้ reverse shell จากการวิเคราะห์แรกเปิดขึ้นภายใน sandbox ตัวแปรและไฟล์เหล่านี้ก็ถูกนำออกจากสภาพแวดล้อมของโปรเซสก่อนเริ่มทำงาน—จึงไม่มีอะไรเหลือให้ขโมย

## ควรเพิ่มกฎ permissions.deny ข้อใดในวันนี้

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

`permissions.deny` ใน settings.json บล็อกการกระทำเฉพาะในระดับกฎ แทนการวิเคราะห์เจตนา—และ Anthropic รับรองอย่างชัดเจนว่ากฎ deny จะมีผลเหนือกฎ allow เสมอ deny rules จำกัด tool actions ที่ตรง แต่ไม่ใช่ขอบเขตสิทธิ์ระดับ OS คำสั่งอ้อมกับเครื่องมืออื่นต้องมีตัวควบคุมของตน

</div>

ชุดกฎขั้นต่ำสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์ ซึ่งครอบคลุมเป้าหมายหลักของการโจมตีทั้งสี่แบบพร้อมกัน:

```json
{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}
```

ตาม[เอกสาร Claude Code](https://code.claude.com/docs/en/permissions) กฎ deny มีลำดับความสำคัญเหนือกว่ากฎ allow เสมอ ดังนั้นแม้คุณ (หรือ agent เอง) จะอนุญาตการเข้าถึงที่กว้างกว่าโดยไม่ตั้งใจในที่อื่น กฎ deny ที่เจาะจงก็ยังมีผลก่อน ลำดับกฎนี้ใช้กับคำขอเครื่องมือที่ตรง ไม่พิสูจน์ว่าข้อมูลลับเข้าถึงไม่ได้ผ่านทุก subprocess หรือเครื่องมือ ต้องมีข้อจำกัดระบบไฟล์และสภาพแวดล้อมที่บังคับด้วย

Claude Code ยังมีโหมด `auto` ซึ่งใช้โมเดลตัวจัดประเภทอีกตัวตรวจสอบการกระทำก่อนเรียกใช้—ไม่ใช่โมเดลเดียวกับที่สนทนากับคุณ โดยปริยายโหมดนี้บล็อกสิ่งต่าง ๆ รวมถึงรูปแบบ “ดาวน์โหลดโค้ดแล้วเรียกใช้ทันที” (`curl | bash`) ซึ่งเป็นจุดจบของการโจมตีแรกข้างต้น Anthropic เตือนอย่างชัดเจนว่านี่เป็นโหมดวิจัยที่ช่วยลดจำนวน prompt แต่ไม่รับประกันความปลอดภัยด้วยตัวเอง—ให้ใช้เป็นชั้นเสริม ไม่ใช่ใช้แทน sandbox และ permissions.deny

## ตรวจสอบ repository และเซิร์ฟเวอร์ MCP ก่อนให้ agent เชื่อถือได้อย่างไร

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

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

</div>

สำหรับ repository นี่คือรายการตรวจสอบสั้น ๆ ก่อนส่งให้ agent:

1.  อย่าเริ่มติดตั้งทันทีจากลิงก์ในอีเมล โพสต์ หรือรีวิวจากแหล่งที่ไม่รู้จัก—repository เหล่านี้เผยแพร่ได้หลายช่องทาง
2.  หากการติดตั้งแสดงข้อผิดพลาดพร้อมคำแนะนำให้ “เรียกใช้คำสั่ง X เพื่อแก้ไข” ให้อ่านก่อนว่า X ทำอะไรจริง ๆ แล้วจึงอนุญาตให้ Claude Code เรียกใช้ คำแนะนำในบทวิเคราะห์ข้างต้นดูเป็นเรื่องปกติอย่างสมบูรณ์—นั่นคือจุดประสงค์
3.  ตรวจสอบอายุ repository และประวัติ commit ไม่ใช่ดูแค่จำนวนดาว—ผู้โจมตีสามารถเพิ่มดาวปลอมให้ repository ที่เพิ่งสร้างได้ง่าย โดยเฉพาะเพื่อการโจมตีประเภทนี้
4.  หากไม่คุ้นเคยกับ repository ให้ติดตั้งในเครื่องเสมือน ไม่ใช่เครื่องทำงานที่มีคีย์จริง นี่คือ[คำแนะนำโดยตรงของ Anthropic เอง](https://code.claude.com/docs/en/security) สำหรับการทำงานกับบริการภายนอก

[จุดยืนของ Anthropic เกี่ยวกับเซิร์ฟเวอร์ MCP ระบุไว้อย่างเปิดเผย](https://code.claude.com/docs/en/security):

<figure>
<blockquote>
<p>เราแนะนำให้เขียนเซิร์ฟเวอร์ MCP ของคุณเอง หรือใช้เซิร์ฟเวอร์จากผู้ให้บริการที่คุณเชื่อถือ Anthropic ตรวจสอบ connector ตามเกณฑ์การลงรายการก่อนเพิ่มเข้าไดเรกทอรี แต่ไม่ได้ตรวจประเมินความปลอดภัยหรือดำเนินการเซิร์ฟเวอร์ MCP ใด ๆ</p>
</blockquote>
<figcaption>— เอกสาร Claude Code, https://code.claude.com/docs/en/security</figcaption>
</figure>

นั่นหมายความว่าคุณต้องรับผิดชอบตรวจสอบเซิร์ฟเวอร์ MCP จากบุคคลที่สาม ไม่ใช่แพลตฟอร์มที่คุณติดตั้งไว้ บางทีม—ส่วนใหญ่เป็น startup ด้านความปลอดภัย—กำลังสร้างเครื่องมือสำหรับเรื่องนี้อยู่แล้ว เช่น เครื่องสแกนการตั้งค่า MCP ที่ค้นหาคำอธิบายที่ถูกวางยาพิษ และการ “pin” เครื่องมือ ซึ่งบันทึก hash ของคำอธิบายเมื่อติดตั้งครั้งแรกและแจ้งเตือนเมื่อมีการเปลี่ยนแปลงภายหลัง เทคโนโลยีเหล่านี้ยังใหม่ จึงเร็วเกินไปที่จะพึ่งพาเป็นการป้องกันเพียงอย่างเดียว—แต่ควรติดตามไว้ โดยเฉพาะเมื่อเชื่อมต่อเซิร์ฟเวอร์ MCP เข้ากับระบบ production สำหรับการเชื่อมต่อเหล่านั้น คุณสามารถ pin เวอร์ชันของแต่ละแพ็กเกจและบันทึกลายนิ้วมือของคำอธิบายเครื่องมือไว้ใน audit log

## 7 กฎเพื่อการป้องกัน: รายการตรวจสอบสำหรับวันนี้

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="ประเด็นสำคัญในส่วนนี้">

ประเด็นสำคัญ

คู่มือนี้สรุปเป็นการกระทำที่ชัดเจน 7 ข้อ: แก้ไขไฟล์ settings.json เดียว 3 จุด (sandbox, credentials, permissions.deny) และปรับพฤติกรรมการทำงานกับโค้ด ข้อผิดพลาด และเซิร์ฟเวอร์ MCP ของผู้อื่น 4 ข้อ ไม่มีข้อใดต้องใช้ความรู้พิเศษ—ใช้เวลาทำรายการตรวจสอบทั้งหมดไม่ถึง 20 นาที

</div>

1.  เปิดโหมด sandbox (`/sandbox` หรือ `"sandbox": {"enabled": true}` ใน `~/.claude/settings.json`) และเพิ่มบล็อก `credentials` เพื่อป้องกันการอ่าน `~/.ssh` และ `~/.aws/credentials`
2.  เพิ่มกฎ `permissions.deny` เพื่อห้ามอ่านไฟล์ลับและเรียกใช้คำสั่ง bash ที่อันตราย (`curl`, `wget`, `sudo`)—กฎ deny มีผลเหนือกว่ากฎ allow เสมอ
3.  อย่าเรียกใช้ `--dangerously-skip-permissions` กับโค้ดจากแหล่งอื่นหรือโค้ดที่ยังไม่ได้ตรวจสอบ—flag นี้ปิดการป้องกันทั้งหมดพร้อมกัน รวมถึงกลไกที่อาจหยุดการโจมตีเหล่านี้ได้โดยตรง
4.  อย่าปล่อยให้ Claude Code เรียกใช้คำสั่ง “แก้ไข” จากข้อความแสดงข้อผิดพลาดโดยอัตโนมัติ—ให้อ่านก่อนว่าคำสั่งทำอะไรจริง ๆ
5.  ติดตั้งเซิร์ฟเวอร์ MCP จากแหล่งที่คุณเชื่อถือเท่านั้น และจำไว้ว่า Anthropic ไม่ได้ตรวจสอบความปลอดภัยให้คุณ
6.  แยกเซสชันตามสิทธิ์: เซสชันหนึ่งทำงานกับข้อมูลส่วนตัวและไม่เห็นข้อมูลภายนอก; เซสชันที่สองตรวจอีเมล repository และ ticket ของคนอื่น แต่ไม่มีสิทธิ์เข้าถึงความลับ; เซสชันที่สามเผยแพร่ข้อมูลออกไป—และเผยแพร่เฉพาะสิ่งที่คุณอนุมัติเป็นการส่วนตัวเท่านั้น ในโปรเจกต์ของฉัน ฉันแยกบทบาทเหล่านี้อย่างเคร่งครัด: เซสชันที่เข้าถึงคีย์สำหรับการชำระเงินจะไม่อ่าน ticket หรือ repository ภายนอกแบบไม่เจาะจง และเซสชันที่วิเคราะห์โค้ดของคนอื่นจะไม่เห็นความลับเลย อย่ารวมบทบาทเหล่านี้ไว้ในแชตเดียว
7.  อัปเดต Claude Code และสคริปต์อัตโนมัติที่เชื่อมต่ออยู่ให้เป็นปัจจุบัน—ช่องโหว่ส่วนใหญ่ที่กล่าวถึงในที่นี้ได้รับการแก้ไขด้วย patch แล้วก่อนเผยแพร่คู่มือนี้ และช่องโหว่ใหม่ก็ได้รับการแก้ไขในลักษณะเดียวกัน

## จากนี้ไป

ไม่มีชั้นใดในมาตรการเหล่านี้รับประกันความปลอดภัย—Anthropic เองก็กล่าวอย่างตรงไปตรงมาว่าไม่มีการป้องกันใดให้ภูมิคุ้มกันได้อย่างสมบูรณ์ ฉันไม่คาดหวังให้ Claude Code ระบุกลโกงในข้อความแสดงข้อผิดพลาดหรือความคิดเห็นใน issue ได้ด้วยตัวเอง สำหรับฉัน sandbox และ `permissions.deny` เป็นส่วนหนึ่งของการจัดการบริบทของโปรเจกต์: agent เห็นอะไร เชื่ออะไรโดยปริยาย และจะเกิดอะไรขึ้นเมื่อมันทำผิดพลาด

<div class="section" role="doc-bibliography" aria-label="แหล่งที่มา">

### แหล่งที่มา

- [0DIN: Clone This Repo and I Own Your Machine (25 มิถุนายน 2026)](https://0din.ai/blog/clone-this-repo-and-i-own-your-machine)
- [Comment and Control: รายงานการแทรกคำสั่งและขโมย credentials ผ่าน GitHub (15 เมษายน 2026; อัปเดต 4 พฤษภาคม)](https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/)
- [Tenet Threat Labs: Agentjacking (อัปเดต 17 มิถุนายน 2026)](https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/)
- [MCPTox: เบนช์มาร์ก tool poisoning ปฐมภูมิ](https://arxiv.org/abs/2508.14925)
- [เอกสาร Claude Code - โหมดสิทธิ์](https://code.claude.com/docs/en/permission-modes)
- [Anthropic Engineering - Sandbox ของ Claude Code](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [เอกสาร Claude Code - สิทธิ์](https://code.claude.com/docs/en/permissions)
- [เอกสาร Claude Code - แนวทางปฏิบัติที่ดีด้านความปลอดภัย](https://code.claude.com/docs/en/security)
- [เอกสาร Claude Code - Model Context Protocol (MCP)](https://code.claude.com/docs/en/mcp)
- [การวิเคราะห์ช่องโหว่ที่เกี่ยวข้องใน GitHub Action ของ Claude Code](https://ailoot.ai/blog/th/claude-code-github-action-security/)
- [วิธีกำหนดค่า Claude Code ไม่ให้ทำโปรเจกต์ของคุณพังข้ามคืน](https://ailoot.ai/blog/th/claude-code-safe-overnight-setup/)
- [เซิร์ฟเวอร์ MCP ของ Claude Code: 7 การตั้งค่าพร้อมใช้และขั้นตอนติดตั้งทีละขั้น](https://ailoot.ai/blog/th/mcp-servers-claude-code/)
- [ความปลอดภัยในการทำ Vibe-coding: วิธีป้องกันไม่ให้แอปที่สร้างด้วย AI ถูกแฮ็ก](https://ailoot.ai/blog/th/vibe-coding-security/)

</div>



หากต้องการเข้าถึง neural network ผ่าน Ailoot ลองดูที่ [Ailoot](https://ailoot.ai/).

## คำถามที่พบบ่อย

### อัตราสำเร็จ 85% ที่รายงานทำนายความเสี่ยงระบบปัจจุบันของฉันหรือไม่?

ไม่ทำนาย เป็นยอดรวม Tenet จาก controlled validation โดยไม่มีรายชื่อโมเดลสาธารณะครบ harness ทำซ้ำ หรือตัวหารทดลองตรง เครื่องมือ การอนุมัติ credentials และเครือข่ายของคุณกำหนดว่าทำอะไรได้

### ทำไมสแกนเฉพาะ repository ที่ clone ไม่พอ?

payload สุดท้ายอาจมาตอนหลังผ่านรายงานผิดพลาด metadata เครื่องมือ หรือข้อมูล DNS ที่ดึง ต้องตรวจเส้นทางรันครบและจำกัด credentials ไฟล์ เครื่องมือ เครือข่าย scanner กับ deny rules อย่างเดียวไม่พิสูจน์การกักครบ


## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท

Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง

บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน.

Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ
