วิธีป้องกัน AI เอเจนต์ไม่ให้ API ที่ใช้งานได้พัง

หากคุณให้สิทธิ์การเขียน (write access) แก่ตัวแทน AI ในโปรเจกต์ API ของคุณ มันสามารถสร้างความเสียหายที่แท้จริงได้ ไม่ใช่เพราะมีเจตนาร้าย แต่เพราะมันทำตามคำสั่งอย่างตรงไปตรงมา ตัวอย่างเช่น คำสั่งว่า “ทำความสะอาด endpoint ของผู้ใช้” อาจทำให้มันลบ route ที่ยังถูกใช้งานอยู่ หรือคำสั่งว่า “อัปเดต schema” อาจทำให้มันเขียนทับโมเดลข้อมูลที่ endpoint อื่นอ้างอิงอยู่ ตัวแทน AI ไม่รู้ว่าอะไรถูกใช้งานจริงใน production มันเห็นเฉพาะทรัพยากรที่ได้รับอนุญาตให้แก้ไข และมันก็จะแก้ไขทรัพยากรนั้น

ลองใช้ Apidog วันนี้

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

วิธีแก้ไม่ใช่การห้ามใช้ตัวแทน AI แต่คือการให้ sandbox ที่มันออกไปแตะ branch สำคัญไม่ได้ AI Branch ของ Apidog แยกการแก้ไขที่ขับเคลื่อนโดย AI ไปยัง branch เฉพาะ โดย source branch และ main จะไม่ถูกแตะต้องจนกว่ามนุษย์จะตรวจสอบ diff และตัดสินใจ merge

บทความนี้อธิบาย workflow ผ่าน CLI ตั้งแต่สร้าง branch ไปจนถึง merge request พร้อมแนวทางลดความเสี่ยงในการทำงานกับ AI agent สำหรับแนวคิดและเหตุผลเบื้องหลังฟีเจอร์นี้ ดูบทความเรื่อง AI Branch และการเปลี่ยนแปลงที่ขับเคลื่อนด้วยตัวแทน AI ที่ปลอดภัยยิ่งขึ้น

เหตุใดการให้สิทธิ์การเขียนแก่ตัวแทน AI จึงเสี่ยงโดยค่าเริ่มต้น

เครื่องมือจำนวนมากให้ AI agent เข้าถึงทั้งโปรเจกต์ในระดับเดียวกัน นั่นหมายความว่า agent ที่สร้าง endpoint ได้ ก็ลบ endpoint ได้เช่นกัน และ agent ที่แก้ไข schema ได้ ก็แทนที่ด้วย schema ที่ไม่เข้ากันได้เช่นกัน

ไม่มีช่องว่างระหว่าง:

1. AI agent เสนอการเปลี่ยนแปลง
2. การเปลี่ยนแปลงถูกเขียนลงแหล่งความจริงของโปรเจกต์

รูปแบบความผิดพลาดที่พบบ่อยมี 3 แบบ:

• เขียนทับ (overwrite) — AI สร้าง schema จากความเข้าใจ API เพียงบางส่วน แล้วลบฟิลด์ที่ endpoint อื่นต้องใช้
• ลบ (delete) — AI “รวม” endpoint และลบ route ที่ client ใน production ยังเรียกใช้งาน
• เบี่ยงเบนอย่างเงียบ ๆ (silent drift) — AI ทำการแก้ไขเล็กน้อยจำนวนมากใน session เดียว แต่ผลรวมของการแก้ไขเริ่มต่างจาก API ที่ใช้งานจริง

ปัญหาไม่ได้อยู่ที่ AI ทำงานเร็วเกินไป แต่คือมันทำงานอยู่บน branch ที่ผิด เป้าหมายคือทำให้ AI agent เข้าถึง branch สำคัญโดยตรงไม่ได้

วิธีแก้: ใช้ AI Branch ที่แยกออกมา

AI Branch คือ branch สำหรับงาน AI ภายนอกและงานผ่าน CLI โดยเฉพาะ เมื่อสร้าง branch นี้แล้ว AI agent จะทำการแก้ไขภายใน branch นั้นเท่านั้น

ผลลัพธ์คือ:

• main ไม่ถูกแก้ไขโดยตรง
• source branch ไม่ถูกกระทบ
• การเปลี่ยนแปลงต้องผ่านการตรวจสอบก่อน merge
• งานที่ผิดพลาดสามารถทิ้งได้ โดยไม่ต้อง rollback production

เริ่มจากติดตั้งและยืนยันตัวตนด้วย Apidog CLI:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

จากนั้นสร้าง AI branch โดยตั้งชื่อให้ระบุวันที่, source branch และวัตถุประสงค์ของงาน:

apidog branch create --type ai \
  --name "ai/20260708-from-main-user-register" \
  --from main \
  --project <PROJECT_ID>

ข้อควรเข้าใจสำคัญ:

• branch นี้สร้างจาก main แต่ไม่ได้แก้ไข main
• AI Branch เริ่มต้นแบบว่างเปล่า
• ระบบจะไม่คัดลอกทุก endpoint และ schema จาก source branch ให้อัตโนมัติ
• AI agent จะแก้ไขได้เฉพาะทรัพยากรที่คุณนำเข้าไปใน branch นี้

การเริ่มจาก branch ว่างช่วยลดขอบเขตผลกระทบ (blast radius) เพราะ AI agent ไม่สามารถแก้ไขทรัพยากรทั้งโปรเจกต์ได้โดยไม่ได้รับอนุญาต

ดู flag ทั้งหมดของคำสั่ง branch ได้ด้วย -h:

apidog branch create -h

นำเข้าทรัพยากรที่ต้องแก้ไขก่อน

เนื่องจาก AI Branch เริ่มต้นว่าง งานแรกคือการนำเข้า endpoint, schema หรือเอกสารเฉพาะส่วนที่ agent ต้องใช้

ตัวอย่าง: นำเข้า endpoint ID 1, 2 และ data schema ID 3 จาก main ไปยัง AI branch

apidog branch pick-to \
  --type ai \
  --from main \
  --to "ai/20260708-from-main-user-register" \
  --endpoint-ids 1,2 \
  --data-schema-ids 3 \
  --project <PROJECT_ID>

หลังจากคำสั่งนี้:

• AI branch มีสำเนาของ endpoint 1 และ 2
• AI branch มีสำเนาของ schema 3
• main ยังคงไม่เปลี่ยนแปลง
• การลบหรือแก้ไขใน AI branch จะกระทบเฉพาะสำเนา

ตัวอย่างเช่น หาก agent ลบ endpoint ใน branch นี้ มันจะลบเฉพาะ endpoint สำเนา ไม่ใช่ route จริงบน main

หากคุณใช้งานผ่าน coding agent คำสั่งเดียวกันสามารถอยู่ใน agent loop ได้ Apidog CLI จะคืนค่า JSON ที่มีโครงสร้าง พร้อม agentHints.nextSteps เพื่อให้ agent อ่านผลลัพธ์ของคำสั่งก่อนหน้าและตัดสินใจขั้นตอนถัดไปได้

ดูตัวอย่างการใช้ CLI ร่วมกับ editor ได้ในคู่มือ apidog-cli ใน Cursor

ให้ AI แก้ไขใน branch แล้วตรวจสอบ diff

หลังนำเข้าทรัพยากรแล้ว ให้ AI agent ทำงานภายใน AI branch ได้ เช่น:

• สร้างหรืออัปเดต endpoint
• แก้ไข schema
• ปรับเอกสาร API
• เพิ่มหรือแก้ไข test scenario
• ลบทรัพยากรที่ไม่ต้องการภายใน branch

การเขียนทั้งหมดจะถูกจำกัดอยู่ใน branch นี้

เมื่อ agent ทำงานเสร็จ อย่า merge ทันที ให้ตรวจสอบ diff ก่อนเสมอ โดยตรวจจาก CLI หรือ Apidog client และตรวจอย่างน้อยเรื่องต่อไปนี้:

• endpoint ที่ถูกเพิ่ม แก้ไข หรือลบ
• method และ path ของ endpoint
• request/response schema ที่เปลี่ยนแปลง
• ฟิลด์ required ที่หายไปหรือเพิ่มขึ้น
• ความเข้ากันได้กับ client เดิม
• ทรัพยากรที่ AI แก้ไขเกินจากขอบเขตงานหรือไม่

ขั้นตอนนี้คือ human review gate หาก AI ทำผิด คุณสามารถทิ้ง branch ได้เลย แทนที่จะต้อง rollback การเปลี่ยนแปลงใน production

การแยก branch จะมีประโยชน์ก็ต่อเมื่อมีคนตรวจ diff จริง ๆ การข้าม review ทำให้ isolation แทบไม่มีความหมาย

นำการเปลี่ยนแปลงเข้าสู่ระบบด้วย merge request

วิธี merge ขึ้นอยู่กับว่า target branch ได้รับการป้องกันหรือไม่

กรณี target branch ไม่ได้รับการป้องกัน

คุณสามารถ merge ทรัพยากรที่เลือกได้โดยตรง:

apidog branch merge \
  --type ai \
  --from "ai/20260708-from-main-user-register" \
  --to main \
  --endpoint-ids 1,2 \
  --data-schema-ids 3 \
  --project <PROJECT_ID>

อย่างไรก็ตาม สำหรับ main ที่ใช้ในงานจริง ควรเปิดการป้องกัน branch เพื่อบังคับให้ทุกการเปลี่ยนแปลงผ่าน review

กรณี main ได้รับการป้องกัน

เมื่อ main protected การ merge โดยตรงจะถูกบล็อก ให้สร้าง merge request แทน:

apidog merge-request create \
  --from "ai/20260708-from-main-user-register" \
  --to main \
  --endpoint-ids 1,2 \
  --data-schema-ids 3 \
  --reviewer-ids <REVIEWER_USER_IDS> \
  --description "AI branch: user register changes" \
  --project <PROJECT_ID>

Merge request เป็นแนวทางที่เหมาะกับงานที่สร้างโดย AI agent เพราะทำให้การเปลี่ยนแปลงผ่านกระบวนการเดียวกับงานจากผู้ร่วมพัฒนาที่เป็นมนุษย์:

1. AI agent แก้ไขงานใน branch ที่แยกออกมา
2. ผู้พัฒนาตรวจสอบ diff
3. Reviewer อนุมัติหรือขอแก้ไข
4. จึง merge เข้า main

โปรดสังเกตว่า merge จะนำเข้าเฉพาะ resource ID ที่ระบุเท่านั้น หาก AI agent แก้ไขทรัพยากรที่อยู่นอกขอบเขต คุณสามารถไม่ระบุ ID นั้นในการ merge ได้

แนวคิดนี้เหมือนกับ เวิร์กโฟลว์ API แบบ Git-native: สร้าง branch, เสนอการเปลี่ยนแปลง, ตรวจสอบ, แล้วจึง merge

เก็บถาวร branch ที่ merge แล้วหรือไม่ใช้แล้ว

เมื่อ merge งานเสร็จ หรือเมื่อตัดสินใจไม่ใช้การเปลี่ยนแปลงนั้นแล้ว ให้เก็บถาวร AI branch เพื่อให้รายการ branch อ่านง่ายและลดความสับสน

apidog branch archive "ai/20260708-from-main-user-register" \
  --type ai \
  --project <PROJECT_ID>

แนวทางที่แนะนำคือ หนึ่ง AI branch ต่องานหนึ่งงาน:

• สร้าง branch สำหรับงานเฉพาะ
• นำเข้าเฉพาะทรัพยากรที่จำเป็น
• ให้ AI ทำงาน
• ตรวจสอบ
• merge หรือทิ้ง
• เก็บถาวร branch

รูปแบบนี้ช่วยให้แต่ละ branch มีขอบเขตชัดเจน และไม่ต้องตรวจสอบการเปลี่ยนแปลงที่สะสมจากหลาย session ที่ไม่เกี่ยวข้องกัน

สุขอนามัยสำหรับ AI agent ที่ปลอดภัย

AI Branch จัดการเรื่อง isolation แต่ควรใช้ร่วมกับแนวปฏิบัติด้านความปลอดภัยต่อไปนี้

1. ใช้ access token แบบ least privilege

token ที่ส่งให้คำสั่งนี้เป็นตัวกำหนดขอบเขตสิ่งที่ agent ทำได้:

apidog login --with-token <YOUR_ACCESS_TOKEN>

ให้ token เข้าถึงเฉพาะโปรเจกต์ที่จำเป็น และหลีกเลี่ยงการส่ง token ของ owner ให้ agent เพียงเพราะสะดวก

หาก token รั่วไหล หรือ agent ทำคำสั่งผิดพลาด ผลกระทบควรถูกจำกัดอยู่ในขอบเขตสิทธิ์ของ token

2. ป้องกัน main branch

การป้องกัน main เปลี่ยนคำแนะนำ “ตรวจสอบก่อน merge” ให้กลายเป็นกฎบังคับ

เมื่อ main ถูกป้องกัน:

• agent merge โดยตรงไม่ได้
• ต้องสร้าง merge request
• ต้องมี reviewer ตรวจสอบก่อนนำการเปลี่ยนแปลงไปใช้

3. ตรวจสอบ diff ทุกครั้ง

แม้ agent จะทำงานได้ถูกต้องต่อเนื่องหลายครั้ง ก็อาจตีความคำสั่งผิดในครั้งถัดไปได้

ก่อน merge ให้ตรวจสอบว่า:

• route ที่ถูกลบไม่มี client ใช้งานอยู่
• schema ที่แก้ไขไม่ทำให้ consumer เดิมพัง
• ไม่มีฟิลด์สำคัญถูกลบ
• ไม่มี resource นอกขอบเขตถูกเพิ่มเข้า merge request
• การเปลี่ยนแปลงตรงตาม task ที่มอบหมาย

4. มอบหมายงาน แต่เก็บการตัดสินใจไว้กับมนุษย์

รูปแบบที่ปลอดภัยคือ:

1. มอบหมายงานที่กำหนดขอบเขตชัดเจนให้ AI
2. ให้ AI ทำงานใน branch ที่แยกออกมา
3. ตรวจสอบผลลัพธ์
4. ให้มนุษย์ตัดสินใจยอมรับหรือปฏิเสธ

หลักการเดียวกันนี้ใช้กับการทดสอบได้เช่นกัน: ให้ agent รัน test suite แต่ให้มนุษย์ตรวจผลจาก test harness และ exit code ก่อนเชื่อถือผลลัพธ์

หากคุณจัดการ API spec ใน Git ด้วย ควรใช้ workflow สำหรับ การควบคุมเวอร์ชัน OpenAPI เพื่อมีประวัติอีกชั้นสำหรับเปรียบเทียบ diff เมื่อพบการเปลี่ยนแปลงผิดปกติ

Workflow แบบครบวงจร

นำ workflow นี้ไปใช้กับ AI agent หรือรันด้วยตัวเองได้ตามลำดับ:

1. สร้าง AI branch จาก main

   apidog branch create --type ai \
     --name "ai/20260708-from-main-user-register" \
     --from main \
     --project <PROJECT_ID>

1. นำเข้าเฉพาะ endpoint และ schema ที่จำเป็น

   apidog branch pick-to \
     --type ai \
     --from main \
     --to "ai/20260708-from-main-user-register" \
     --endpoint-ids 1,2 \
     --data-schema-ids 3 \
     --project <PROJECT_ID>

1. ให้ AI agent แก้ไขทรัพยากรภายใน AI branch

2. ตรวจสอบ diff และยืนยันว่าการเปลี่ยนแปลงตรงตามความต้องการ

3. สร้าง merge request ไปยัง main ที่ได้รับการป้องกัน
   

   apidog merge-request create \
     --from "ai/20260708-from-main-user-register" \
     --to main \
     --endpoint-ids 1,2 \
     --data-schema-ids 3 \
     --reviewer-ids <REVIEWER_USER_IDS> \
     --description "AI branch: user register changes" \
     --project <PROJECT_ID>

1. หลัง merge หรือเมื่อตัดสินใจทิ้งงาน ให้ archive branch

   apidog branch archive "ai/20260708-from-main-user-register" \
     --type ai \
     --project <PROJECT_ID>

ด้วย workflow นี้ AI agent จะไม่สามารถเขียนทับหรือลบ endpoint ที่ใช้งานจริงบน main ได้โดยตรง สิ่งที่แย่ที่สุดที่เกิดขึ้นได้คือมันสร้างการเปลี่ยนแปลงที่ไม่ถูกต้องบนสำเนาชั่วคราว ซึ่งคุณสามารถปฏิเสธและทิ้งได้

ให้ AI ทำงานได้ โดยไม่ต้องมอบกุญแจของ production

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

คำตอบไม่ใช่การทำให้ AI ช้าลง แต่คือการย้ายการเขียนที่รวดเร็วของมันไปอยู่ในพื้นที่ปลอดภัย:

• AI branch ที่แยกออกมา
• main branch ที่ได้รับการป้องกัน
• access token แบบ least privilege
• human review ก่อน merge

เมื่อใช้ร่วมกัน คุณจะเปลี่ยนเหตุการณ์จาก “AI ทำ API พัง” ให้กลายเป็น “มี diff ที่ไม่ถูกต้อง และทีมเลือกไม่ merge มัน”

Apidog มี workflow นี้ให้พร้อมใช้งานผ่าน Apidog CLI สร้าง AI branch แล้วให้ agent แก้ไขสำเนาแทนของจริง

ดาวน์โหลด Apidog เพื่อทดลอง workflow ของ AI Branch และดู เอกสาร AI Branch สำหรับรายละเอียดคำสั่งทั้งหมดก่อนนำไปใช้กับ workflow สำหรับ production