AI Agent กับ Cybersecurity: ผู้ช่วยที่ดี หรือ Attack Surface แบบใหม่

ช่วงหลังคำว่า AI agent เริ่มถูกพูดถึงเยอะมาก เพราะมันไม่ได้เป็นแค่ chatbot ที่รอให้เราถามแล้วตอบกลับ แต่เป็นระบบที่สามารถวางแผน เรียกใช้เครื่องมือ อ่านข้อมูลจากหลายแหล่ง และทำงานหลายขั้นตอนแทนคนได้ เช่น เปิด ticket, สรุป incident, ค้นเอกสาร, เรียก API, สร้าง draft report หรือช่วยไล่ลำดับเหตุการณ์จาก log หลายระบบ

ถ้ามองในมุม productivity นี่เป็นเรื่องน่าสนใจมาก โดยเฉพาะทีม security ที่มีงานซ้ำ ๆ เยอะและคนมักไม่พอ แต่ถ้ามองในมุมความเสี่ยง AI agent ก็ทำให้โจทย์เปลี่ยนไปเหมือนกัน เพราะเมื่อระบบหนึ่งเริ่ม "ลงมือทำ" แทนคนได้ มันไม่ได้เป็นแค่เครื่องมือช่วยคิดอีกต่อไป มันกลายเป็น actor ตัวหนึ่งใน workflow ที่ต้องมีสิทธิ์ มีขอบเขต มี log และมี accountability

แก่นของปัญหา

ถ้าสรุปจากแหล่งข้อมูลที่ใช้เป็นฐาน บทเรียนหลักมีอยู่ไม่กี่ข้อ

1. AI agent มีประโยชน์กับงานที่มี pattern ชัดและตรวจทานได้ เช่น triage, summarisation, enrichment และ report drafting
2. ความเสี่ยงเพิ่มขึ้นทันทีเมื่อ agent มีสิทธิ์อ่านข้อมูลอ่อนไหว เขียนข้อมูล หรือเรียกใช้เครื่องมือจริง
3. ความเสี่ยงไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ tool, connector, memory, external content, identity และ workflow ที่ล้อมรอบ model
4. หลักพื้นฐานอย่าง least privilege, logging, monitoring, secure design และ human approval ยังสำคัญมาก และอาจสำคัญกว่าเดิม
5. การเริ่มจากงานเล็ก ความเสี่ยงต่ำ และมี rollback ง่าย จะปลอดภัยกว่าการให้ agent แตะระบบสำคัญตั้งแต่วันแรก

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

AI agent ช่วยงาน security ได้จริงตรงไหน

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

1. สรุป alert หลายรายการให้เป็น incident timeline เบื้องต้น
2. ดึงข้อมูล asset owner, system criticality และ recent change มาประกอบ ticket
3. ช่วยร่าง incident report ฉบับแรกจาก log และ note ที่มีอยู่
4. ช่วยแปลง finding เชิงเทคนิคให้เป็นภาษาที่ผู้บริหารอ่านเข้าใจ
5. ช่วยตรวจว่า runbook ขั้นตอนไหนยังขาดข้อมูลก่อนส่งต่อให้ analyst

ประโยชน์ของ agent ไม่ใช่การแทน judgement ของคน แต่คือการลดเวลาที่คนต้องเสียไปกับงานรวบรวมข้อมูล ถ้า analyst ใช้เวลาครึ่งชั่วโมงหาข้อมูลพื้นฐานก่อนเริ่มวิเคราะห์ Agent อาจช่วยให้ช่วงนั้นสั้นลงเหลือไม่กี่นาทีได้ แต่การตัดสินใจว่า incident นี้ต้อง isolate เครื่องหรือไม่ ต้องแจ้งลูกค้าหรือไม่ หรือควร escalate เมื่อไร ยังควรอยู่กับคนที่รับผิดชอบจริง

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

Attack surface ใหม่อยู่ตรงไหน

OWASP Top 10 for Agentic Applications 2026 อธิบายภาพรวมว่า agentic system มีความเสี่ยงเฉพาะเพราะมันสามารถวางแผน ตัดสินใจ และลงมือทำข้าม workflow ได้ ส่วน guidance เรื่อง careful adoption of agentic AI services ที่เผยแพร่วันที่ 1 พฤษภาคม 2026 โดย Australian Signals Directorate ร่วมกับพันธมิตรระหว่างประเทศ ก็ชี้ชัดว่า agentic AI เพิ่มความเสี่ยงจาก autonomy, interconnected architecture และการพึ่งพา LLM

ถ้าแปลเป็นภาษาปฏิบัติ attack surface ใหม่มักอยู่ตรงนี้

1. Tool และ connector

Agent ที่ต่อกับ email, ticketing, file storage, browser, CI/CD, cloud console หรือ SIEM ไม่ได้มีความเสี่ยงเท่ากับ chatbot ธรรมดา เพราะ tool เหล่านี้มีสิทธิ์อ่านหรือแก้ข้อมูลจริง ถ้า agent ถูกหลอกให้ใช้ tool ผิด หรือ tool description ถูกออกแบบไม่ดี ความเสียหายจะขยายจาก "ตอบผิด" เป็น "ทำผิด"

2. Permission ที่กว้างเกินไป

ปัญหาคลาสสิกของ automation คือให้ service account กว้างเกินจำเป็น เพราะทำให้ setup ง่าย แต่กับ AI agent ความเสี่ยงสูงขึ้นอีก เพราะ agent อาจตัดสินใจผิดจาก prompt injection, context ผิด, memory ผิด หรือ tool output ที่ไม่น่าเชื่อถือ หลัก least privilege จึงต้องใช้จริง ไม่ใช่เขียนไว้ใน policy เฉย ๆ

3. Memory และ context

Agent หลายระบบมี memory หรือใช้ RAG เพื่อดึงข้อมูลเก่ามาประกอบการตัดสินใจ ถ้าข้อมูลใน memory ถูกปนเปื้อน หรือแหล่งข้อมูลที่ agent อ่านมีคำสั่งแฝง Agent อาจเอาข้อมูลนั้นไปใช้ต่ออย่างมั่นใจ ทั้งที่ต้นทางไม่น่าเชื่อถือ

4. External content และ prompt injection

ความเสี่ยง prompt injection จะหนักขึ้นเมื่อ agent อ่าน email, web page, PDF, ticket หรือ document จากภายนอก เพราะคำสั่งแฝงอาจซ่อนอยู่ในเนื้อหาที่ดูเหมือนข้อมูลปกติ ถ้า agent มีสิทธิ์ทำ action ต่อ ความเสียหายก็ไม่หยุดที่คำตอบผิด

สิ่งที่ควรถามก่อนเปิดใช้ agent

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

งานนี้ผิดแล้วเสียหายแค่ไหน

ถ้า agent สรุป ticket ผิด อาจเสียเวลาตรวจใหม่ แต่ถ้า agent ปิด incident ผิด ส่ง email ผิดคน แก้ข้อมูลลูกค้าผิด หรือรันคำสั่งบน production ผิด ความเสียหายคนละระดับ ดังนั้นงานอ่านข้อมูลกับงานเขียนข้อมูลควรถูกแยกชัดเจน

Agent ต้องมีสิทธิ์อะไรจริง ๆ

เริ่มจากสิทธิ์อ่านอย่างจำกัดก่อน แล้วค่อยเพิ่มสิทธิ์เมื่อมีเหตุผล ไม่ควรเริ่มจาก admin token หรือ service account ที่เข้าถึงทุก project ได้เพราะสะดวก การให้ agent เห็นทุกอย่างเท่ากับเพิ่ม blast radius ถ้า agent ถูกหลอกหรือทำงานผิด

Action ไหนต้องมีคนกดอนุมัติ

งานที่กระทบเงิน ลูกค้า production, identity, secret, legal document หรือข้อมูลส่วนบุคคล ควรมี human approval เป็น default โดยเฉพาะ action ที่ย้อนกลับยาก Agent อาจเตรียม recommendation ได้ แต่ไม่ควรเป็นคนตัดสินใจขั้นสุดท้ายในงานเสี่ยงสูง

จะรู้ได้อย่างไรว่า agent ทำอะไรไปแล้ว

ถ้าไม่มี log ที่อ่านย้อนกลับได้ เราจะไม่รู้ว่า agent ตัดสินใจจากข้อมูลอะไร เรียก tool ไหน ใช้ credential ไหน และ action ไหนเกิดจากผู้ใช้หรือ agent เรื่องนี้เกี่ยวกับ incident response โดยตรง เพราะเมื่อเกิดปัญหา คำถามแรกจะไม่ใช่ "model ตัวไหนเก่งกว่า" แต่คือ "เกิดอะไรขึ้น ใครสั่ง และย้อนกลับได้ไหม"

วิธีเริ่มแบบ practical

ถ้าทีมยังไม่เคยใช้ AI agent ในงาน security ผมจะเริ่มจากงานที่แคบและย้อนกลับง่ายก่อน เช่น

1. ให้ agent สรุป ticket แต่ไม่ให้ปิด ticket
2. ให้ agent enrich alert ด้วยข้อมูล asset แต่ไม่ให้เปลี่ยน severity เอง
3. ให้ agent ร่าง report แต่ต้องให้ analyst ตรวจและส่งเอง
4. ให้ agent อ่าน runbook และเช็กข้อมูลที่ขาด แต่ไม่ให้รันคำสั่ง remediation
5. ให้ agent ทำงานใน sandbox หรือข้อมูล sample ก่อนแตะ production data

จากนั้นค่อยเพิ่ม control ทีละชั้น เช่น identity แยกเฉพาะ agent, permission แยกตาม use case, allowlist ของ tool, audit log, approval gate, rate limit, monitoring และ rollback plan

NCSC Guidelines for secure AI system development แบ่งแนวคิดออกเป็น secure design, secure development, secure deployment และ secure operation and maintenance ซึ่งใช้กับ agent ได้ดีมาก เพราะ agent ไม่ใช่ feature เล็ก ๆ ที่ใส่เข้าไปแล้วจบ แต่มันคือระบบหนึ่งที่ต้องดูแลตลอด lifecycle

อย่าใช้ agent เพื่อกลบพื้นฐานที่ยังอ่อน

ข้อผิดพลาดที่ผมอยากเตือนคือการเอา AI agent ไปวางทับระบบพื้นฐานที่ยังไม่พร้อม เช่น asset inventory ยังไม่ชัด log ยังไม่ครบ owner ของระบบยังไม่แน่น permission ยังหลวม หรือ incident process ยังไม่มีคนรับผิดชอบชัดเจน

Agent อาจช่วยให้ดูเหมือน workflow ฉลาดขึ้น แต่ถ้าข้อมูลฐานไม่ดี มันก็แค่สรุปความไม่ชัดเจนให้ดูเป็นระเบียบขึ้นเท่านั้น CISA และพันธมิตรในเอกสาร AI Data Security ปี 2025 ย้ำว่าความปลอดภัยของข้อมูลมีผลต่อ accuracy, integrity และ trustworthiness ของผลลัพธ์ AI ตลอด lifecycle นั่นแปลว่า data governance ไม่ใช่เรื่องเสริม แต่เป็นเงื่อนไขพื้นฐาน

พูดง่าย ๆ คือ ถ้าข้อมูลที่ agent อ่านมั่ว สิทธิ์ที่ agent ใช้กว้างเกินไป และ log ที่ agent ทิ้งไว้ไม่พอ ต่อให้ model ฉลาดก็ยังเสี่ยงอยู่ดี

สรุป

AI agent เป็นผู้ช่วยที่ดีได้จริงในงาน cybersecurity โดยเฉพาะงานที่ต้องรวบรวมข้อมูล สรุปบริบท จัดลำดับงาน และลดภาระงานซ้ำ ๆ ให้ทีม แต่ทันทีที่ agent เริ่มเชื่อมต่อ tool, memory, connector และ action จริง มันก็กลายเป็น attack surface ใหม่ที่ต้องออกแบบเหมือนระบบ production ไม่ใช่แค่ทดลองเล่นกับ chatbot

แนวทางที่ practical คือเริ่มเล็ก ใช้กับงานความเสี่ยงต่ำ จำกัดสิทธิ์ให้แคบที่สุด มี human approval สำหรับ action สำคัญ เก็บ log ให้ตรวจสอบได้ และทบทวน permission เป็นรอบ ๆ ถ้าทำแบบนี้ Agent จะช่วยเพิ่มคุณภาพงานได้โดยไม่ทำให้ความเสี่ยงโตเร็วกว่าความสามารถในการควบคุมของทีม

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

อ่านต่อที่เกี่ยวข้อง

• ถ้าอยากมองภาพรวมของความเสี่ยง AI ใน workflow องค์กร อ่าน ความเสี่ยงจากการใช้ AI: ตั้งแต่ Deepfake, Prompt Injection ไปจนถึง Agent ที่มีสิทธิ์เกินจำเป็น
• ถ้าอยากต่อยอดเรื่องการใช้ AI ในงาน security โดยไม่ขายฝัน อ่าน สิ่งที่ควรคิดก่อนนำ AI มาใช้ในงาน Cybersecurity
• ถ้าอยากเข้าใจปัญหา Shadow AI และข้อมูลรั่วจากเครื่องมือ AI อ่าน ภัยเงียบจาก Shadow AI: เมื่อพนักงานใช้เครื่องมือ AI โดยที่ฝ่าย IT ไม่รู้ตัว

แหล่งอ้างอิง

• OWASP Top 10 for Agentic Applications 2026
• Careful adoption of agentic AI services, Australian Cyber Security Centre, เผยแพร่วันที่ 1 พฤษภาคม 2026
• NIST Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• NCSC Guidelines for secure AI system development
• CISA AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems