AI coding agents คืออะไร และทำไมจึงกลายเป็นดาบสองคมด้านความปลอดภัย
AI coding agents คือระบบปัญญาประดิษฐ์ที่ใช้สร้าง แก้ และปรับปรุงโค้ดแบบอัตโนมัติ สามารถรับคำสั่งเป็นภาษามนุษย์แล้วแปลงเป็นโค้ด ทำรีแฟกเตอร์ เขียนเทสต์ และส่ง pull request ได้ภายในเวลาไม่กี่นาที ช่วยให้ทีมพัฒนาเขียนโค้ดได้เร็วกว่าเดิมมาก แต่ความเร็วที่เพิ่มขึ้นก็มาพร้อมความเสี่ยงด้านความปลอดภัยที่เพิ่มขึ้นตามไปด้วย เพราะตัว AI จะเลือกเส้นทางที่สั้นที่สุดเพื่อให้โค้ดทำงาน ไม่ใช่เส้นทางที่ปลอดภัยที่สุดเสมอไป
เรากำลังอยู่ในยุคที่โค้ดถูกผลิตด้วยความเร็วที่มนุษย์คนเดียวตามไม่ทัน วิศวกรหลายคนใช้เวลาส่วนใหญ่ไปกับการสั่งการ AI coding agents ให้สร้างฟีเจอร์ทั้งชุดแทนการพิมพ์โค้ดเอง แต่ทันทีที่ความเร็วเพิ่มขึ้นสองปัญหาก็โตตามมาคือ dependencies ที่ไม่มีใครอ่านครบ และ secrets อย่างเช่น API key ที่หลุดเข้าไปอยู่ในซอร์สโค้ดแบบไม่รู้ตัว ความจริงที่น่ากลัวคือ “The AI wrote it” ไม่ใช่ข้ออ้างที่ใช้ป้องกันตัวได้ใน postmortem เพราะคนที่ต้องรับผิดชอบต่อโค้ดคือคุณไม่ใช่ AI ดังนั้นคำถามสำคัญไม่ใช่ว่าควรใช้ AI หรือไม่ แต่คือคุณจะควบคุมความเสี่ยงจากมันอย่างไร
รูรั่วยอดฮิตจาก AI: จาก API key ในโค้ดไปจนถึง dependencies ที่ไม่มีใครตรวจ
ปัญหาใหญ่ที่สุดของ AI coding agents security ไม่ได้มาจากความชั่วร้ายของ AI แต่มาจากนิสัย “ทางลัด” ของมัน AI จะเลือกวิธีที่สั้นที่สุดในการทำให้ฟีเจอร์ทำงาน เช่น เมื่อเราสั่งให้มันเขียน integration อย่างรวดเร็ว มีโอกาสสูงที่มันจะฝัง API key ลงในซอร์สโค้ดโดยตรงแทนการอ่านค่าจาก environment variable หรือ secrets manager โค้ดทำงาน เทสต์ผ่าน commit ถูก push ขึ้น repo และ API key นั้นจะอยู่ในประวัติ Git ไปตลอดแม้ว่าคุณจะแก้ไขบรรทัดนั้นใน commit ถัดไป git rm ไม่ใช่เครื่องย้อนเวลา นี่คือแก่นของปัญหา API key exposure prevention
อีกด้านหนึ่งคือ code generation vulnerabilities จาก dependencies ที่ซ้อนกันเป็นชั้น Python โปรเจกต์หนึ่งอาจมีแพ็กเกจหลักไม่กี่ตัวแต่แต่ละตัวมี dependencies ของตัวเองรวมกันเป็นหลายสิบตัว และแทบไม่มีใครอ่านทั้งหมดได้ครบ ช่องโหว่ความปลอดภัยจึงสามารถซ่อนอยู่ใน dependency ใด dependency หนึ่งเป็นเดือนโดยไม่มีใครรู้จนกว่าจะมีคนอื่นพบก่อน AI ไม่ใช่ตัวร้าย มันเพียงทำตามคำสั่งและเลือกเส้นทางที่สั้นที่สุด ความผิดอยู่ที่ทีมพัฒนาซึ่งปล่อยให้โค้ดเหล่านี้ผ่านไปโดยไม่มีการรีวิวและไม่มีเกณฑ์ความปลอดภัยที่ชัดเจน การป้องกันโค้ดที่ AI สร้างจึงเริ่มจากการยอมรับว่าการรีวิวของมนุษย์และเครื่องมือสแกนคือด่านบังคับ ไม่ใช่ทางเลือก
เมื่อเทสต์คือประตูเหล็ก: กรณีศึกษา live-trading ที่รอดเพราะ automated testing frameworks
มีตัวอย่างจริงที่ชัดมากจากระบบ live-trading ที่ใช้เงินจริงของเจ้าของระบบเอง AI agents เขียนโค้ดส่วนใหญ่ของระบบนี้ผ่าน pull request ประมาณ 1,600 ครั้งภายใน 21 เดือน ซึ่งมากกว่าที่วิศวกรคนเดียวจะเขียนเองได้ถึงสามเท่า เจ้าของระบบยอมรับตรงๆ ว่ามีสองทางเลือกคืออ่านทุกบรรทัดแล้วทำงานช้ากว่าเขียนเอง หรือ skim แล้ว merge ให้ไวแล้วปล่อยให้โค้ดที่ “ดูเหมือนถูก” สะสมในระบบที่สั่งซื้อขายเงินจริง ทางเลือกทั้งสองอย่างนี้เสี่ยงเกินไป เขาจึงเลือกทางที่สาม คือใช้ automated testing frameworks เป็นประตูตัดสินว่าอะไรจะได้ไป production
เขาตั้งกฎชัดเจนว่า “Tests became the gate” ไม่มีอะไร merge หรือ deploy ได้หาก build ยังไม่เป็นสีเขียว ทุก pull request ต้องผ่าน lint ด้วย ruff ตรวจ type ด้วย mypy เทสต์ประมาณ 7,500 เคสจาก 331 โมดูล ตรวจว่า test database ต้องว่างหลังรันทดสอบ และทดสอบ migration rollback แล้ว apply ใหม่ตั้งแต่ฐานข้อมูลแรกจนถึงปัจจุบัน รวมถึง terraform validate ทั้งสองบัญชี AWS หากอย่างใดอย่างหนึ่งล้มเหลว การ merge จะถูกปฏิเสธทันที นี่คือตัวอย่างของ automated testing frameworks ที่ไม่ใช่คำแนะนำแต่เป็น gate จริง เขายังเสริมด้วยเทสต์หนักแบบรันทุกสัปดาห์ เช่น การรัน rebalancing แบบ end-to-end กับ mock broker สองครั้ง การรัน integration test เดิมซ้ำ 100 ครั้งเพื่อหาปัญหา race condition และเทสต์ snapshot การเทรนโมเดลแบบ deterministic รวมเก้าเคสภายใน Docker พร้อมเทสต์ leakage สองชุดบน pipeline
ทำให้ AI เข้าใจสิ่งที่มันกำลังสร้าง: product surface graph และการทดสอบอย่างเป็นระบบ
แม้เราจะมีเทสต์เป็น gate แล้ว แต่ปัญหาใหม่ของการใช้ AI coding agents คือมันไม่เข้าใจผลิตภัณฑ์ของเราลึกเท่าทีมงาน มันมักต้องเปิดหน้าใหม่ ถ่ายภาพหน้าจอ กดทีละปุ่มเพื่อ “ค้นพบ” การทำงานของแต่ละหน้าเหมือนเห็นครั้งแรกทุกครั้ง ส่งผลให้เปลือง token และเวลา ไม่ต่างกับมี QA ใหม่ที่ต้องเรียนรู้แอปทุกครั้งที่ทดสอบ ทางออกหนึ่งคือการสร้าง product surface graph หรือ knowledge graph ที่บันทึกว่าผลิตภัณฑ์ทำงานอย่างไร หน้าไหนเชื่อมกับหน้าไหน ผู้ใช้แต่ละประเภทเดินทางอย่างไร และ workflow สำคัญคืออะไร
ในกราฟนี้แต่ละ node คือ surface จุดที่ผู้ใช้หรือ AI agent อยู่และลงมือทำบางอย่างได้ เช่น หน้า modal sheet drawer หรือ region ในหน้าเดียวกัน เมื่อ AI มี “แผนที่” แบบนี้ มันจะไม่ต้องเดาทางเองทุกครั้ง แต่สามารถค้นหาเส้นทางในกราฟ วางแผนการทดสอบ แล้วใช้ browser agent ดำเนินการตามขั้นตอนที่ชัดเจน งานวิจัยต่างๆ แสดงตรงกันว่าการนำทางผลิตภัณฑ์ที่ซับซ้อนต้องใช้มากกว่าความฉลาดของ agent มันต้องการแผนที่ที่ใช้วางเส้นทางและชุดการกระทำด้วย ทีมหนึ่งรายงานว่าการให้แผนที่ลักษณะนี้กับ AI ทำให้เวลาทดสอบบางฟีเจอร์ลดจาก 25 นาทีเหลือประมาณ 15 นาทีโดยยังคงคุณภาพการทดสอบใกล้เคียงเดิม แสดงให้เห็นว่าการลงทุนสร้าง surface graph และเอกสาร verification skill ช่วยลดเวลาทดสอบและลดการค้นพบซ้ำอย่างสิ้นเปลือง
สิ่งที่คุณควรทำตั้งแต่วันนี้: สแกน secrets ใส่เทสต์ใน CI และให้เทสต์เป็น gate จริง
คำถามสำคัญไม่ใช่ว่า AI ปลอดภัยหรือไม่ แต่คือวันนี้คุณมีเกราะป้องกันแค่ไหน สิ่งแรกคือ API key exposure prevention คุณต้องมีเครื่องมือที่ค้นหา secrets ทั้งในไฟล์ปัจจุบันและใน Git history มีแพตเทิร์นมากกว่าหกสิบแบบครอบคลุม cloud payments CI AI APIs และอื่นๆ พร้อม heuristic ตรวจค่า entropy และสามารถเช็กได้ว่า secret ยังใช้งานอยู่หรือถูกเพิกถอนแล้ว เพราะคีย์ที่รั่วแต่ถูกเพิกถอนแล้วกับคีย์ที่ยังใช้ได้ไม่ใช่เหตุฉุกเฉินระดับเดียวกัน เครื่องมือแบบนี้ควรมี pre-commit hook และ workflow ใน GitHub Actions เพื่อหยุดปัญหาก่อนที่จะเข้า repo และควรตั้งค่าให้ข้ามไฟล์ .env ตามค่าเริ่มต้นเพราะที่นั่นคือที่เก็บ secrets ที่ควรอยู่ โดยมุ่งหา secrets ที่โผล่ในที่อื่นแทน
จุดต่อมาคือการตั้ง automated testing frameworks ใน CI ให้เป็นบังคับ ไม่ใช่ทางเลือก คุณควรถามคำถามด้านความปลอดภัยทุกครั้งที่โค้ดเปลี่ยน และวิธีที่น่าเชื่อถือที่สุดคือทำให้คำถามนั้นถูกรันแบบอัตโนมัติใน pipeline หากต้องรอให้ใครสักคนนึกขึ้นได้ มันจะไม่เกิดขึ้น ควรมีการสแกน dependencies ด้วยเครื่องมือสร้าง SBOM และเช็คฐานข้อมูลช่องโหว่ เช่น OSV GitHub Advisory Database และ NVD เพื่อให้ CI ล้มเหลวทันทีหากมี vulnerability ระดับ HIGH หรือ CRITICAL ปรากฏ และกำหนดให้การ ignore ช่องโหว่ทำได้เฉพาะระดับ advisory ID เพื่อบังคับให้การยกเว้นทุกครั้งต้องผ่านการทบทวน ที่สำคัญ เครื่องมือความปลอดภัยขั้นพื้นฐานควรติดตั้งง่าย ใช้มาตรฐาน Python library อย่างเดียว ไม่ต้องมีโครงสร้างพื้นฐานเสริมให้ยุ่งยาก คุณ clone มา รัน แล้วอ่านรายงานได้ทันที สุดท้ายต้องยอมรับว่าการอ่านโค้ดแล้วรู้สึกว่า “ดูถูกแล้ว” เป็นสัญญาณที่ไม่น่าเชื่อถือที่สุดเมื่อโค้ดถูกสร้างโดย AI ความปลอดภัยในยุค AI จึงไม่ใช่เรื่องของสัญชาตญาณ แต่เป็นเรื่องของเกณฑ์ที่ชัดและระบบทดสอบที่บังคับใช้ได้จริง
