Non-Human Identity (NHI): ความปลอดภัยของ API Key และ AI Agent ที่ SME ไทยต้องจัดการ

Non-Human Identity (NHI) คือตัวตนของ API Key, Service Account, OAuth Token และ Secret อื่น ๆ ที่ AI Agent ใช้เข้าไปทำงานใน n8n, Odoo, LINE OA หรือคลาวด์แทนมนุษย์ สำหรับ SME ไทย เรื่องนี้ไม่ใช่ศัพท์เทคนิคไกลตัว เพราะเมื่อใดที่คุณให้ AI เชื่อมต่อกับบัญชี LINE หรือให้ Agent ดึงข้อมูลลูกค้าจาก Odoo คุณได้สร้าง "พนักงานดิจิทัล" ที่ไม่ใช่มนุษย์ขึ้นมาแล้ว ถ้าไม่มีระบบจัดการสิทธิ์ คนร้ายอาจใช้ตัวตนนี้เข้าถึงข้อมูล หรือ AI Agent อาจทำงานผิดพลาดจนค่าใช้จ่ายคลาวด์พุ่งโดยไม่มีใครรู้ตัว บทความนี้จะพาเจ้าของธุรกิจและผู้จัดการ IT ไปดูว่า NHI คืออะไร ความเสี่ยงอยู่ตรงไหน และจะเริ่มจัดการอย่างไรโดยไม่ต้องใช้งบประมาณมหาศาล

NHI คืออะไร และทำไม SME ไทยต้องใส่ใจ

เวลาพูดถึงความปลอดภัยในระบบ IT เรามักนึกถึงชื่อผู้ใช้ รหัสผ่าน และการยืนยันตัวตนของมนุษย์ เช่น พนักงานคนหนึ่งที่เข้าใช้งาน LINE OA หรือพนักงานบัญชีที่ล็อกอิน Odoo แต่ NHI กลับเป็นบัญชีที่ไม่มีมนุษย์นั่งอยู่หน้าจอ ตัวอย่างใกล้ตัวที่สุดคือ API Key ที่ให้ n8n ส่งข้อความ LINE แทนร้านค้า Service Account ที่ให้ AI Agent อ่านอีเมลจาก Gmail เพื่อสรุปออเดอร์ หรือ Personal Access Token ของนักพัฒนาที่เก็บไว้ใน CI/CD เพื่อ deploy โค้ดขึ้นระบบคลาวด์

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

ในบริบท SME ไทย สิ่งที่เห็นจริงคือการเชื่อมต่อระหว่างเครื่องมือมากมาย เช่น เจ้าของร้านค้าออนไลน์ใช้ LINE OA รับออเดอร์ ใช้ Google Sheets เก็บข้อมูลลูกค้า และใช้ n8n ดึงข้อมูลจากอีเมลไปกรอก Odoo แต่ละการเชื่อมต่อต้องสร้าง API Key หรือ Token อย่างน้อยหนึ่งตัว ถ้าไม่มีทะเบียนกลาง เราจะไม่รู้ว่าระบบใดใช้คีย์อะไร มีสิทธิ์แค่ไหน สร้างไว้เมื่อใด และใครเป็นคนรับผิดชอบ อาจมีคีย์เก่าที่ถูกลืมฝังอยู่ใน .env เป็นเวลาหลายปี

ที่สำคัญ NHI ไม่ได้มีแค่ API Key แต่รวมถึง OAuth Token ที่ออกโดยผู้ให้บริการ เช่น Google, LINE หรือ Meta และรวมถึง Credential ของ AI Agent ผ่าน MCP หรือ Model Context Protocol ที่ให้ Agent เข้าถึงเครื่องมือภายนอกได้แบบไดนามิก เมื่อเครื่องมือเชื่อมต่อกันมากขึ้น จำนวน NHI จะโตเร็วกว่าจำนวนพนักงาน และการจัดการแบบเดิมที่พึ่ง "ผู้ดูแลคนเดียวจำว่าคีย์ไหนใช้กับอะไร" จะไม่เพียงพออีกต่อไป

ทำไมปี 2025 ถึงเป็นจุดเปลี่ยนของการแพร่หลายของ NHI

ช่วงหลายปีก่อน AI ในองค์กรไทยยังเป็นแค่ Chatbot สำหรับตอบคำถามลูกค้า แต่ปี 2025 เริ่มเห็นการเปลี่ยนผ่านจาก Chatbot ไปเป็น AI Agent ที่ลงมือทำงานจริง ตัวแทน AI ไม่ได้แค่พิมพ์ข้อความตอบกลับ แต่มันอ่านอีเมล สร้างใบสั่งซื้อ ปรับสต็อกใน Odoo ส่งข้อความหาลูกค้าใน LINE และเรียกใช้เครื่องมือภายนอกผ่าน Function Calling หรือ MCP เพื่อทำงานให้เสร็จ

ลองนับ NHI จากระบบจริงของ SME ร้านค้าแห่งหนึ่ง: Token ของ LINE OA สำหรับส่งข้อความ 1 ตัว, API Key ของ Odoo สำหรับสร้างออเดอร์ 1 ตัว, API Key ของ OpenAI สำหรับให้ Agent คิดและวางแผน 1 ตัว, Service Account ของ Google สำหรับอ่าน Gmail 1 ตัว, PAT ของ GitHub สำหรับเก็บ workflow 1 ตัว และยังมี Credential ของ n8n ที่ใช้เก็บของทั้งหมด สมมติฐานนี้ยังไม่นับ Key สำหรับการชำระเงินหรือการเชื่อมต่อกับสต็อกของ supplier ถ้า AI Agent มีหลายบทบาทหรือหลาย workflow จำนวน NHI จะทะลุหลักสิบหรือหลักร้อยอย่างรวดเร็วโดยไม่มีใครตั้งตัว

ปี 2025 ถือเป็นจุดเปลี่ยน เพราะเครื่องมือ Automation อย่าง n8n, Make, Odoo และ LINE OA เปิดให้คนที่ไม่ใช่นักพัฒนาสร้างระบบเชื่อมต่อได้เอง พนักงานการตลาดอาจสร้าง workflow ให้ AI อ่านข้อความลูกค้าและตอบกลับโดยใช้คีย์ส่วนตัวของบริษัท โดยไม่รู้ว่าคีย์นั้นถูกเก็บไว้อย่างไรและมีสิทธิ์เข้าถึงข้อมูลใดบ้าง

อีกปัจจัยคือการมาของ MCP Credential ซึ่งทำให้ AI Agent สามารถขอสิทธิ์เข้าถึงระบบใหม่ขณะทำงานได้ทันที การอนุญาตแบบพลวัตนี้ช่วยให้ Agent ทำงานได้ลื่นไหล แต่ก็ทำให้การควบคุมสิทธิ์ยากขึ้น เพราะสิทธิ์อาจถูกสร้างและยกเลิกระหว่าง conversation ความเสี่ยงจึงไม่ใช่แค่ "คีย์หลุด" แต่คือการที่ NHI ถูกสร้างขึ้นมานอกกระบวนการ Governance เดิมของธุรกิจ

ความเสี่ยงจริงของ NHI ที่เห็นในธุรกิจ SME ไทย

ความเสี่ยงจาก NHI ไม่ใช่เรื่องทฤษฎี สำหรับ SME ไทยที่ใช้ n8n, Odoo และ LINE OA ร่วมกัน มีปัญหาที่พบจริงหลายรูปแบบ

คีย์หลุดใน Git คืออุบัติเหตุที่เกิดบ่อยที่สุด นักพัฒนาหรือผู้รับเหมาอาจเผลอ push ไฟล์ .env ขึ้น GitHub หรือ GitLab สาธารณะ ภายในไม่กี่นาที Bot ที่สแกน GitHub จะเจอคีย์และนำไปใช้ส่งสแปม หรือเรียก API ของบริษัทจนค่าใช้จ่ายพุ่ง ธุรกิจหลายรายรู้ตัวอีกทีตอนที่ได้รับบิลค่า OpenAI หรือ LINE สูงผิดปกติ

Service Account ไม่มีวันหมดอายุทำให้ซากความเสี่ยงยังทำงานต่อไป เมื่อพนักงานออกจากบริษัท ระบบบัญชีมนุษย์ของ Google หรือ Odoo อาจถูกปิด แต่ Service Account ที่พนักงานสร้างไว้เพื่อให้ n8n เชื่อมต่อกับคลาวด์ยังคงทำงานต่อไป ไม่มีใครคิดจะ revoke เพราะไม่รู้ว่ามันมีอยู่ และถ้า Service Account ตัวนั้นเป็น Owner ของ Project ในคลาวด์ ผลกระทบจะร้ายแรงมาก

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

ขาด Audit Log ว่าใครสั่งให้ระบบทำอะไร ในระบบ LINE OA และ Odoo จะมี Log ว่า API ถูกเรียกเมื่อใดและจาก IP ใด แต่ Log เหล่านั้นไม่ได้บอกว่าคำสั่งมาจากผู้ใช้ปลายทางคนไหน หรือ AI Agent ใช้ Prompt แบบใดถึงตัดสินใจลบข้อมูล หากลูกค้าทวงถามว่าใครสั่งให้ Agent ส่งข้อมูลส่วนบุคคลไปให้บุคคลที่สาม ธุรกิจจะไม่สามารถตอบได้

ค่าใช้จ่ายที่พุ่งสูงจาก Agent Loop AI Agent ที่ทำงานผิดพลาดอาจวน loop เรียก API ซ้ำ เช่น n8n workflow ลอง retry ทุก 5 นาทีตลอดคืน หรือ Agent ใช้เครื่องมือค้นหาหรือสร้างภาพซ้ำ ๆ โดยไม่มีขีดจำกัด ค่าใช้จ่ายรายเดือนที่เคยอยู่หลักพันอาจกลายเป็นหลักหมื่นหรือหลักแสนในไม่กี่วันโดยไม่มีการตั้ง Budget Alert

จะเริ่มจัดการ NHI แบบประหยัดได้อย่างไร

สำหรับ SME ที่ยังไม่มีทีม Security หรือไม่มีงบประมาณสำหรับ Enterprise Vault การเริ่มต้นไม่จำเป็นต้องซื้อเครื่องมือแพง ๆ ขอแค่ทำตามลำดับที่ถูกต้อง

ขั้นแรก ทำ Inventory ของ Secrets ทั้งหมดที่เกี่ยวข้องกับ AI Agent ไม่ต้องใช้เครื่องมือซับซ้อน เริ่มจากเปิด n8n แล้วเขียนรายการ Credential แต่ละตัวว่าต่อกับระบบใด ใครเป็นเจ้าของ และมีสิทธิ์อะไร จากนั้นไล่ส่อง GitHub Repository หรือไฟล์ .env ในเครื่อง developers เพื่อลบคีย์ที่ถูก hardcode

ขั้นที่สอง ให้ใช้หลัก Least Privilege กับ NHI ทุกตัว หลักคิดง่าย ๆ คือ "ถ้า Agent งานนี้ไม่ต้องใช้สิทธิ์ ก็อย่าให้สิทธิ์นั้น" ยกตัวอย่างร้านค้าที่ให้ AI อ่านอีเมลสั่งซื้อและสร้างออเดอร์ใน Odoo ควรสร้างผู้ใช้เฉพาะใน Odoo ที่มีสิทธิ์อ่าน Email และสร้าง Sale Order แต่ไม่มีสิทธิ์แก้ไขคู่ค้า ปรับราคา หรือลบข้อมูล ใน LINE OA ควรสร้าง Channel แยกสำหรับการส่งข้อความและรับ Webhook แทนการใช้บัญชีเดียวกันกับทีมดูแลลูกค้า

ขั้นที่สาม ทำเรื่องอายุและหมุนเวียนคีย์ ตั้งนโยบายให้ API Key ทุกตัวมีวันหมดอายุไม่เกิน 90 วัน และถ้าระบบรองรับการขอ Token ใหม่ผ่าน OAuth Flow ควรใช้วิธีนี้แทนการวาง Static Key ให้ Agent ใช้ตลอดไป สำหรับ GitHub PAT หรือ GitLab PAT ควรกำหนดวันที่หมดอายุในการสร้างทุกครั้ง และใช้ Secret Scanning เพื่อตรวจสอบการรั่วไหล

ขั้นที่สี่ ย้ายการเก็บ Secrets ไปไว้ในที่ปลอดภัย หากใช้ n8n ควรใช้ Credential Store ของ n8n ที่เข้ารหัสข้อมูล ถ้า workflow รันบนคลาวด์ให้ใช้ Secret Manager ของผู้ให้บริการคลาวด์โดยตรง เช่น Google Cloud Secret Manager หรือ AWS Secrets Manager ถ้าองค์กรยังเล็กมาก ให้ใช้ Password Manager ที่รองรับการแชร์เฉพาะผู้ดูแล และห้ามเก็บ Key ลงใน Notion, Google Docs, หรือแชตกลุ่มโดยเด็ดขาด

ขั้นสุดท้าย เปิด Audit Log และตั้ง Alert แม้แต่ SME ควรเปิด Log ของ Cloud Platform และ Odoo เพื่อให้เห็นประวัติการเรียก API จาก n8n หรือ AI Agent ตั้ง Alert ของค่าใช้จ่ายรายวัน และตั้งกฎว่าคีย์ใดเข้าถึงข้อมูลลูกค้าได้บ้าง เมื่อพบ Key ที่ไม่คุ้นเคยให้ Revoke ทันทีและดูว่า Workflow ใดพังเพื่อค้นหาต้นตอ

ยกระดับสู่ Zero Trust: เฝ้าระวัง Machine Identity อย่างไร

Zero Trust มีหลักการง่าย ๆ คือ "ไม่เชื่อใจอะไรง่าย ๆ แม้แต่ระบบที่อยู่ภายในองค์กร" สำหรับ NHI หลักการนี้หมายความว่าไม่มี API Key ใดควรมีสิทธิ์เต็มรูปแบบตลอดเวลาโดยไม่ถูกตรวจสอบ ทุกครั้งที่เครื่องจักรเรียกใช้ข้อมูล ระบบต้องยืนยันทั้งตัวตน อุปกรณ์ บริบท และความจำเป็นของคำขอนั้น

ธุรกิจที่เริ่มใช้ AI Agent ในระดับจริงควรพิจารณาเรื่อง Dynamic Authorization แทนการให้สิทธิ์ถาวร เช่น ใช้ Short-Lived Token ที่หมดอายุในไม่กี่นาที เพื่อให้ Agent ขอ Token ใหม่เมื่อได้รับคำสั่งจากมนุษย์อีกครั้งหนึ่ง วิธีนี้ช่วยลดผลกระทบถ้าคีย์รั่วไหล เพราะผู้ไม่หวังดีจะใช้คีย์ได้เพียงช่วงเวลาสั้น ๆ

นอกจากนี้ต้องเฝ้าระวังพฤติกรรมของ NHI ด้วยการดู Baseline การใช้งานปกติ ถ้า Service Account ของ Odoo ที่ปกติเรียก API วันละ 200 ครั้ง จู่ ๆ เรียก 50,000 ครั้งในหนึ่งชั่วโมง หรือถ้า Token ของ LINE OA เข้าถึงจากประเทศที่ไม่มีการทำธุรกิจ ระบบควรส่ง Alert ไปยังผู้ดูแลทันที บน Cloud Platform มี Cloud Logging และ Budget Alert อยู่แล้ว เพียงแต่ SME หลายรายยังไม่ได้ตั้งค่าหรือเปิดใช้งาน

Zero Trust ยังหมายถึงการ Revoke ทันทีเมื่อ NHI ไม่ได้ใช้งานอีกต่อไป เมื่อเลิกใช้ Workflow ใด ควรปิดการเชื่อมต่อและลบ Credential นั้นจาก n8n รวมถึงไปยกเลิก Token ที่ระบบปลายทางด้วย อย่าปล่อยให้ผู้รับเหมาที่ลาออกไปแล้วยังมี Token ใช้งานได้เป็นปี

สำหรับ AI Agent ที่เข้าถึงข้อมูลลูกค้าตาม PDPA การเฝ้าระวังนี้ไม่ใช่แค่เรื่องเทคนิค ธุรกิจต้องมีบันทึกว่า Agent ได้ข้อมูลส่วนบุคคลจากแหล่งใด นำไปประมวลผลอะไร และจัดเก็บไว้ที่ไหน หากไม่มี Audit Log ที่เชื่อมโยง "คำสั่งของมนุษย์" กับ "การกระทำของ Agent" จะถือว่าองค์กรไม่สามารถแสดงความรับผิดชอบตามกฎหมายได้

สรุป: เริ่มจัดการ NHI วันนี้ไม่ใช่เรื่องของอนาคต

Non-Human Identity กำลังเติบโตพร้อมกับ AI Agent และ Workflow Automation ใน SME ไทย ไม่ว่าคุณจะใช้ n8n เชื่อม LINE OA, Odoo หรือระบบคลาวด์ของ Google และ AWS ความเสี่ยงจะไม่หายไปถ้ายังปล่อยให้ API Key เป็นขยะที่ไม่มีใครดูแล

สิ่งสำคัญที่สุดคือการเปลี่ยนมุมมองว่า API Key หรือ Service Account เป็น "บัญชีคนทำงาน" ที่ต้องมีเจ้าของ มีขอบเขตสิทธิ์ มีอายุการใช้งาน และมีบันทึกการใช้งาน เริ่มจาก Small Steps: ทำ Inventory, ลบคีย์เก่า, ปรับสิทธิ์ให้เหลือเท่าที่จำเป็น, ย้าย Secret ไปไว้ในที่ปลอดภัย และตั้ง Alert สำหรับพฤติกรรมผิดปกติ

เมื่อนั้น SMEs ไทยจะใช้ AI Agent ได้อย่างมั่นใจ โดยไม่ต้องกลัวว่าเครื่องจักรที่ช่วยเพิ่มประสิทธิภาพจะกลายเป็นประตูให้ผู้ไม่หวังดีเข้ามาทำลายธุรกิจ และไม่ต้องตกใจเมื่อค่าใช้จ่ายคลาวด์พุ่งสูงโดยไม่มีใครอธิบายได้ การจัดการ NHI ไม่ใช่ภาระของฝ่ายไอทีเพียงฝ่ายเดียว แต่คือวินัยขององค์กรที่ต้องเริ่มตั้งแต่วันนี้ ก่อนที่ "พนักงานดิจิทัล" จะมีจำนวนมากเกินกว่าที่เราจะรู้ว่ามันทำอะไรอยู่