# วิศวกรรมความมั่นคงปลอดภัยใน AI-Native SDLC: ควบคุม AI Coding Agent ป้องกัน Context Poisoning และ Sandbox Evasion

Locale: `th`

Source: `/th/compliance/ai-native-sdlc/`

สารบัญ

1. [ภาพรวม](/th/compliance/ai-native-sdlc/#topic-overview)
2. [AI-Native SDLC เป็นแนวทางวิศวกรรม ไม่ใช่มาตรฐานกำกับ](/th/compliance/ai-native-sdlc/#ai-native-threat-landscape)
3. [จำกัดสิทธิ์และตรวจการเรียกใช้ Tool ก่อนดำเนินการ](/th/compliance/ai-native-sdlc/#agent-least-privilege-and-hooks)
4. [ตรวจขอบเขต Sandbox และเครือข่ายจากการทำงานจริง](/th/compliance/ai-native-sdlc/#os-sandboxing-and-evasion-defense)
5. [ทดสอบ Review และเก็บหลักฐานก่อนเผยแพร่](/th/compliance/ai-native-sdlc/#cicd-approval-gates-and-audit)
6. [ตารางเปรียบเทียบข้อกำหนด](/th/compliance/ai-native-sdlc/#compliance-matrix)
7. [ประเมินความพร้อม](/th/compliance/ai-native-sdlc/#compliance-readiness-checklist)
8. [คำถามที่พบบ่อย](/th/compliance/ai-native-sdlc/#compliance-faq)
9. [หัวข้อที่เกี่ยวข้อง](/th/compliance/ai-native-sdlc/#related-compliance-frameworks)

# วิศวกรรมความมั่นคงปลอดภัยใน AI-Native SDLC: ควบคุม AI Coding Agent ป้องกัน Context Poisoning และ Sandbox Evasion

คู่มือนี้อ้าง Anthropic AI-Native SDLC Playbook และเอกสารความปลอดภัยของเครื่องมือ AI Coding Agent เพื่อเสนอการควบคุมตามความเสี่ยง ไม่ใช่กฎหมายหรือการรับรองมาตรฐาน

สรุปภาพรวมข้อกำหนด

กลุ่มเป้าหมายที่บังคับใช้

ทีมพัฒนาและผู้รับผิดชอบความมั่นคงปลอดภัยที่ใช้ AI Coding Agent โดยเลือกมาตรการให้เหมาะกับผลิตภัณฑ์และสภาพแวดล้อม

ความถี่ในการทดสอบ

ตรวจพฤติกรรมและสิทธิ์เมื่อเริ่มใช้หรือเปลี่ยนเครื่องมือ เลือกการทดสอบและ Review ตามความเสี่ยงของแต่ละงาน เป็นข้อเสนอวิศวกรรมของ STH

ขอบเขตการทดสอบ

Permission, Approval, Hook, Sandbox, เครือข่าย Dependency และหลักฐานการเผยแพร่

ความเสี่ยงหากไม่ปฏิบัติตาม

Context Poisoning การขโมย Credential คำสั่งเกินขอบเขต และ Dependency ที่ไม่น่าเชื่อถือ

## AI-Native SDLC เป็นแนวทางวิศวกรรม ไม่ใช่มาตรฐานกำกับ

คู่มือนี้อ้าง Anthropic AI-Native SDLC Playbook และเอกสารความปลอดภัยของเครื่องมือ AI Coding Agent เพื่อเสนอการควบคุมตามความเสี่ยง ไม่ใช่กฎหมายหรือการรับรองมาตรฐาน

[![AI Coding Agent: 4 ด่านความปลอดภัย: จำกัดสิทธิ์, ตรวจคำสั่งก่อนรัน, แยกสภาพแวดล้อม, ตรวจสอบก่อนเผยแพร่](/assets/generated/compliance-refresh/guide-ai-native-sdlc-compliance-control-summary-th-v2.webp)](/assets/generated/compliance-refresh/guide-ai-native-sdlc-compliance-control-summary-th-v2.webp)

**AI Coding Agent: 4 ด่านความปลอดภัย**

เลือกการจำกัดสิทธิ์ Hook, Sandbox และ Review ตามความเสี่ยง โดยตรวจขอบเขตจริงและไม่ถือว่ามาตรการใดป้องกันการโจมตีได้ทั้งหมด

- **จำกัดสิทธิ์** — กำหนดขอบเขตไฟล์และคำสั่ง
- **ตรวจคำสั่งก่อนรัน** — Hook ช่วยลดความเสี่ยง ไม่ใช่เกราะสมบูรณ์
- **แยกสภาพแวดล้อม** — ใช้ Sandbox และควบคุมเครือข่าย
- **ตรวจสอบก่อนเผยแพร่** — ทดสอบ Review และเก็บหลักฐาน

- Playbook เชื่อมการวางแผน ออกแบบ พัฒนา ทดสอบ เผยแพร่ และบำรุงรักษา โดยใช้ข้อกำหนดที่ตรวจสอบได้และหลักฐานจากการทำงาน
- Context Poisoning อาจเกิดเมื่อ Agent อ่านข้อความไม่น่าเชื่อถือจาก Repository, Issue หรือ Pull Request แล้วนำไปตีความเป็นคำสั่ง
- สิทธิ์อ่านไฟล์ รันคำสั่ง และเชื่อมเครือข่ายที่กว้างเกินงานอาจทำให้ข้อมูลหรือ Credential รั่วไหล แม้ Agent จะทำงานใน Workspace ที่กำหนด
- ตรวจชื่อ ที่มา และเวอร์ชันของ Dependency ที่ Agent เสนอ ไม่ถือว่าการมี Lockfile เพียงอย่างเดียวพิสูจน์ว่าแพ็กเกจปลอดภัย

## จำกัดสิทธิ์และตรวจการเรียกใช้ Tool ก่อนดำเนินการ

ใช้ Permission, Approval และ Hook ที่เครื่องมือรองรับร่วมกัน โดยแยกข้อเสนอการควบคุมขององค์กรออกจากความสามารถจริงของแต่ละผลิตภัณฑ์

- กำหนดขอบเขตไฟล์ คำสั่ง และปลายทางเครือข่ายเท่าที่งานต้องใช้ พร้อมแยกข้อมูลลับออกจาก Context และสภาพแวดล้อมของ Agent
- Hook ช่วยตรวจพารามิเตอร์และยับยั้งการกระทำที่ไม่อนุญาต แต่ต้องครอบคลุม Tool ที่เกี่ยวข้องและทดสอบเส้นทางเลี่ยง ไม่ถือว่า Hook หรือ AST ตรวจพบ Prompt Injection ได้ทุกกรณี
- Context Fencing ช่วยระบุว่าข้อความใดเป็นข้อมูลที่ไม่น่าเชื่อถือ แต่ Delimiter และ Prompt Sanitizer ไม่ใช่ขอบเขตความปลอดภัยที่ป้องกันการโจมตีได้สมบูรณ์
- กำหนดผู้อนุมัติหรือ Policy Gate สำหรับการกระทำที่มีผลกระทบสูง พร้อมตรวจการขอรันนอก Sandbox และการใช้สิทธิ์เกินขอบเขต

## ตรวจขอบเขต Sandbox และเครือข่ายจากการทำงานจริง

ใช้กลไกที่เครื่องมือและระบบปฏิบัติการรองรับ และทดสอบขอบเขตจริง Container หรือชื่อโหมดไม่ใช่หลักฐานว่าป้องกันการเข้าถึง Host ได้ครบถ้วน

- จำกัดการอ่านและเขียนไฟล์ ตรวจ Mount, Symlink และไฟล์ Credential ที่กระบวนการยังเข้าถึงได้ เลือก Container หรือ MicroVM เมื่อเหมาะกับความเสี่ยง
- จำกัดเครือข่ายขาออกและอนุญาตเฉพาะปลายทางที่งานต้องใช้ พร้อมตรวจช่องทางที่ Tool ภายนอก Sandbox อาจเข้าถึงได้
- ตรวจโหมดที่ปิด Sandbox การขอสิทธิ์เพิ่มเติม และความต่างระหว่างเครื่องพัฒนา ระบบ Cloud และระบบปฏิบัติการที่รองรับ
- กำหนดการจำกัดทรัพยากรและการติดตามเหตุที่เหมาะสม โดยไม่อ้างว่า Sandbox ป้องกันการหลุดขอบเขตได้ทุกกรณี

## ทดสอบ Review และเก็บหลักฐานก่อนเผยแพร่

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

- ตรวจพฤติกรรมที่เปลี่ยนและกรณีปฏิเสธที่เกี่ยวข้อง ใช้ SAST, SCA และ Secret Scanning เมื่อเหมาะกับภาษา ขอบเขต และความเสี่ยง
- ใช้ Protected Branch และ Release Gate ตามนโยบาย ให้มนุษย์ Review การเปลี่ยนแปลงที่มีผลกระทบสูง ไม่อ้างว่า Anthropic กำหนด Two-Person Rule สำหรับทุกงาน
- ตรวจความถูกต้องและที่มาของ Dependency ร่วมกับ Lockfile และผลการทดสอบ ไม่อ้าง Subresource Integrity ว่าเป็นการตรวจ Dependency ทุกชนิด
- เก็บหลักฐานรุ่นเครื่องมือ ไฟล์ที่เปลี่ยน ผลทดสอบ และการอนุมัติเท่าที่จำเป็น พร้อมปกปิดข้อมูลลับและกำหนดอายุการเก็บ ไม่เก็บ Prompt และ Tool Parameter ทั้งหมดโดยไม่มีการคัดกรอง

## ตารางเปรียบเทียบข้อกำหนดและการทดสอบความปลอดภัย

สรุปรายละเอียดประกาศ บทบัญญัติ และขอบเขตการทดสอบความปลอดภัยที่จำเป็น

| ประกาศ และข้อกำหนด | สาระสำคัญ | ขอบเขตการทดสอบ | รอบเวลาทดสอบ |
| --- | --- | --- | --- |
| **Anthropic AI-Native SDLC Playbook** | AI-Native SDLC เป็นแนวทางวิศวกรรม ไม่ใช่มาตรฐานกำกับ | คู่มือนี้อ้าง Anthropic AI-Native SDLC Playbook และเอกสารความปลอดภัยของเครื่องมือ AI Coding Agent เพื่อเสนอการควบคุมตามความเสี่ยง ไม่ใช่กฎหมายหรือการรับรองมาตรฐาน | ตามขอบเขตมาตรฐานและความเสี่ยงของบริการ ไม่ใช่รอบทดสอบตายตัว |
| **เอกสาร Permission และ Hook ของผู้ผลิต** | จำกัดสิทธิ์และตรวจการเรียกใช้ Tool ก่อนดำเนินการ | ใช้ Permission, Approval และ Hook ที่เครื่องมือรองรับร่วมกัน โดยแยกข้อเสนอการควบคุมขององค์กรออกจากความสามารถจริงของแต่ละผลิตภัณฑ์ | ตามขอบเขตมาตรฐานและความเสี่ยงของบริการ ไม่ใช่รอบทดสอบตายตัว |
| **เอกสาร Sandbox ของผู้ผลิต** | ตรวจขอบเขต Sandbox และเครือข่ายจากการทำงานจริง | ใช้กลไกที่เครื่องมือและระบบปฏิบัติการรองรับ และทดสอบขอบเขตจริง Container หรือชื่อโหมดไม่ใช่หลักฐานว่าป้องกันการเข้าถึง Host ได้ครบถ้วน | ตามขอบเขตมาตรฐานและความเสี่ยงของบริการ ไม่ใช่รอบทดสอบตายตัว |
| **ข้อเสนอ Release Gate ของ STH** | ทดสอบ Review และเก็บหลักฐานก่อนเผยแพร่ | เลือกการทดสอบและระดับ Review ตามความเสี่ยงของการเปลี่ยนแปลง โดยให้ระบบ CI และผู้รับผิดชอบควบคุมการเผยแพร่ตามนโยบายองค์กร | ตามขอบเขตมาตรฐานและความเสี่ยงของบริการ ไม่ใช่รอบทดสอบตายตัว |

### เครื่องมือประเมินความพร้อม

คลิกเลือกรายการที่องค์กรของท่านได้ดำเนินการแล้ว เพื่อคำนวณระดับความพร้อมเบื้องต้น

0%

บันทึกขอบเขตงาน สิทธิ์ Agent และเกณฑ์รับงาน พร้อมแยกข้อมูลลับออกจาก Context
          
          
            
            ทดสอบ Hook และนโยบายอนุญาตคำสั่ง รวมทั้งกรณีปฏิเสธคำสั่งนอกขอบเขตและ Context ที่ไม่น่าเชื่อถือ
          
          
            
            ตรวจสิทธิ์ไฟล์ Mount, Credential และเครือข่ายใน Sandbox พร้อมทดสอบข้อจำกัดที่เลือกใช้
          
          
            
            ตรวจโค้ดและ Dependency ทดสอบพฤติกรรมที่เปลี่ยน และเก็บหลักฐานการอนุมัติ Merge และ Deploy ตามความเสี่ยง

ประเมินความพร้อม

เลือกรายการด้านบนเพื่อประเมินผล

[ปรึกษาผู้เชี่ยวชาญ และขอใบเสนอราคา](/th/#contact)

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

คำถามและข้อสงสัยสำคัญเกี่ยวกับข้อกำหนดและการตรวจประเมินตามมาตรฐาน

### Context Poisoning เกิดขึ้นได้อย่างไร?

Context Poisoning อาจเกิดเมื่อ Agent อ่านข้อความไม่น่าเชื่อถือจาก Repository, Issue หรือ Pull Request แล้วนำไปตีความเป็นคำสั่ง

### Hook และ Context Fencing ป้องกัน Prompt Injection ได้ทั้งหมดหรือไม่?

Hook ช่วยตรวจพารามิเตอร์และยับยั้งการกระทำที่ไม่อนุญาต แต่ต้องครอบคลุม Tool ที่เกี่ยวข้องและทดสอบเส้นทางเลี่ยง ไม่ถือว่า Hook หรือ AST ตรวจพบ Prompt Injection ได้ทุกกรณี Context Fencing ช่วยระบุว่าข้อความใดเป็นข้อมูลที่ไม่น่าเชื่อถือ แต่ Delimiter และ Prompt Sanitizer ไม่ใช่ขอบเขตความปลอดภัยที่ป้องกันการโจมตีได้สมบูรณ์

### Container หรือ Sandbox ป้องกันความเสี่ยงทั้งหมดหรือไม่?

ใช้กลไกที่เครื่องมือและระบบปฏิบัติการรองรับ และทดสอบขอบเขตจริง Container หรือชื่อโหมดไม่ใช่หลักฐานว่าป้องกันการเข้าถึง Host ได้ครบถ้วน จำกัดเครือข่ายขาออกและอนุญาตเฉพาะปลายทางที่งานต้องใช้ พร้อมตรวจช่องทางที่ Tool ภายนอก Sandbox อาจเข้าถึงได้

## หัวข้อและกฎหมายกำกับดูแลที่เกี่ยวข้อง

- [
                กรอบธรรมาภิบาล AI ของไทย: ธปท., ETDA, สกมช. สู่ AI Pentest
                
              ](/th/compliance/thai-ai-governance/)
- [
                OWASP Top 10: เว็บ มือถือ API LLM และ Agentic
                
              ](/th/compliance/owasp-top-10/)
- [
                ISO/IEC 42001:2023 คืออะไร และ AI Pentest ช่วย AIMS อย่างไร
                
              ](/th/compliance/iso-42001-ai-management/)
- [
                Google SAIF 2.0 คืออะไร และป้องกัน AI Agent อย่างไร
                
              ](/th/compliance/google-saif/)

เปิดภาพขนาดเต็มเพื่อซูม

## เอกสารต้นทางฉบับทางการ

Anthropic AI-Native SDLC Playbook และเอกสารความปลอดภัยของเครื่องมือ

[ไปยังแหล่งทางการ ](https://claude.com/blog/the-ai-native-sdlc-playbook)

- [ความปลอดภัยของ Claude Code](https://code.claude.com/docs/en/security)
- [Sandbox ของ Claude Code](https://code.claude.com/docs/en/sandboxing)

## ต้องการทำ Pentest ให้สอดคล้องกับข้อกำหนดเหล่านี้?

เล่าขอบเขตระบบและข้อกำหนดที่ต้องปฏิบัติตามให้เราฟัง ทีม STH จะช่วยประเมินแนวทางและจัดทำใบเสนอราคาให้

[ขอใบเสนอราคา Pentest](/th/#contact)

อัปเดตล่าสุด 6 ตุลาคม 2569