ຄູ່ມືປ້ອງກັນການໂຈມຕີ Supply Chain ສໍາລັບ AI Agent — ການຈັດຕັ້ງປະຕິບັດການປ້ອງກັນເສັ້ນທາງການສົ່ງ MCP/Skill

ການໂຈມຕີ Supply Chain ຂອງ AI Agent ແມ່ນການໂຈມຕີທີ່ບຸກລຸກເສັ້ນທາງການສົ່ງມອບ Component ພາຍນອກ ເຊັ່ນ: MCP Server, Skill, ຫຼື ປລັກອິນ (Plugin) ທີ່ Agent ນຳມາໃຊ້ໃນຂະນະປະຕິບັດງານ ເພື່ອຝັງໂຄ້ດອັນຕະລາຍ ຫຼື ຄຳສັ່ງທີ່ບໍ່ຫວັງດີເຂົ້າໄປໃນສະພາບແວດລ້ອມການເຮັດວຽກຂອງ AI.

ໃນຂະນະທີ່ການໂຈມຕີ Supply Chain ແບບດັ້ງເດີມຈະແນເປົ້າໝາຍໄປທີ່ "Library" ຫຼື "Container Image", ແຕ່ໃນຍຸກຂອງ AI Agent ພື້ນທີ່ການໂຈມຕີໄດ້ຂະຫຍາຍຕົວໄປສູ່ "MCP / Skill ທີ່ໂຫຼດແບບເຄື່ອນໄຫວໃນຂະນະປະຕິບັດງານ". ເຈດຕະນາການອອກແບບທີ່ Anthropic ຍອມຮັບເອງ ບວກກັບຄວາມເປັນຈິງທີ່ມີການ ເປີດຕົວ ຫຼື Launch MCP Server ສາທາລະນະເປັນຈຳນວນຫຼາຍ ແມ່ນປັດໄຈທີ່ເຮັດໃຫ້ບັນຫານີ້ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ຄູ່ມືສະບັບນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຂໍ້ມູນແກ່ພະນັກງານໄອທີ, SRE, ແລະ ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພ ໂດຍອະທິບາຍຂັ້ນຕອນການອອກແບບ ການປ້ອງກັນ 3 ຊັ້ນ ໃນ 3 ຂັ້ນຕອນ ຄື: (1) ການເຮັດ Allowlist ຂອງແຫຼ່ງທີ່ເຊື່ອຖືໄດ້, (2) ການກຳນົດສິດຂັ້ນຕ່ຳ ແລະ Sandbox, ແລະ (3) ການກວດສອບ Input/Output ແລະ ບັນທຶກການກວດສອບ (Audit Log). ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດຕັດສິນໃຈໄດ້ທັນທີວ່າ "ຄວນຈຳກັດສິ່ງໃດກ່ອນ ແລະ ຄວນຕິດຕາມກວດສອບສິ່ງໃດ" ໃນສະພາບແວດລ້ອມການດຳເນີນງານ Agent ຂອງບໍລິສັດທ່ານ.

ໃນຂະນະທີ່ການໂຈມຕີລະບົບ Supply Chain ແບບດັ້ງເດີມແນເປົ້າໝາຍໄປທີ່ "Library/Container", ແຕ່ໃນຍຸກຂອງ AI Agent ພື້ນທີ່ການໂຈມຕີໄດ້ຂະຫຍາຍໄປສູ່ MCP Server, Skill ແລະ Plugin ທີ່ຖືກໂຫຼດແບບໄດນາມິກໃນຂະນະປະຕິບັດງານ. ເນື່ອງຈາກສິ່ງເຫຼົ່ານີ້ຮັບຄຳສັ່ງຈາກພາຍນອກເພື່ອປະຕິບັດຄຳສັ່ງ, ຈັດການໄຟລ໌ ແລະ ເອີ້ນໃຊ້ API ຢູ່ເທິງຄອມພິວເຕີຂອງອົງກອນ, ມັນຈຶ່ງ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ລະບົບການເຮັດວຽກຂອງບໍລິສັດໄດ້ໃນທັນທີ.

ໃນພາກນີ້, ພວກເຮົາຈະມາສະຫຼຸບເຫດຜົນທາງໂຄງສ້າງທີ່ເຮັດໃຫ້ພື້ນທີ່ການໂຈມຕີຂະຫຍາຍຕົວ ແລະ ຕົວຢ່າງທີ່ເກີດຂຶ້ນຈິງ.

MCP (Model Context Protocol) ແມ່ນໂປຣໂຕຄອນທົ່ວໄປສຳລັບໃຫ້ Agent ເອີ້ນໃຊ້ເຄື່ອງມື, ແຫຼ່ງຂໍ້ມູນ, ແລະ Code ພາຍນອກ. ພື້ນຖານໄດ້ຖືກກ່າວເຖິງໃນ AI Agent Protocol (MCP/A2A) Introduction. Skill ໄດ້ຖືກພັດທະນາຂຶ້ນເພື່ອຂະຫຍາຍຄວາມສາມາດນີ້, ເປັນກົນໄກໃນການແຈກຢາຍ Workflow ທີ່ສາມາດນຳກັບມາໃຊ້ໃໝ່ໄດ້ໃນຮູບແບບຂອງ "Skill".

ຮູບແບບການເຮັດວຽກປະກອບດ້ວຍ 3 ຊັ້ນ (Layer) ດັ່ງນີ້:

ໂດຍສະເພາະ MCP Server ທີ່ຢູ່ໃນຊັ້ນລຸ່ມສຸດ, ຕາມການອອກແບບແລ້ວມັນມີຄຸນສົມບັດ "ສາມາດປະຕິບັດຄຳສັ່ງ OS ໄດ້ຕາມຄຳຮ້ອງຂໍທີ່ສົ່ງມາຈາກ Client". ຄວາມສາມາດໃນການປະຕິບັດງານນີ້ເອງທີ່ກາຍເປັນປະຕູສູ່ການໂຈມຕີແບບ Supply Chain.

ມີການລາຍງານກ່ຽວກັບບັນຫາດ້ານ Supply Chain ຂອງ AI Agent ຈາກຫຼາຍແຫຼ່ງຂໍ້ມູນທີ່ເປີດຕົວ ຫຼື Launch. ໂດຍມີ 3 ຕົວຢ່າງທີ່ເປັນຕົວແທນດັ່ງນີ້:

• ຊ່ອງໂຫວ່ RCE ແບບ "by design" ຂອງ Anthropic MCP: ໃນບົດລາຍງານທີ່ OX Security ໄດ້ເປີດຕົວ ຫຼື Launch ໃນວັນທີ 15 ເມສາ 2026, ໄດ້ຊີ້ໃຫ້ເຫັນວ່າການນຳໃຊ້ Model Context Protocol ແບບອ້າງອີງນັ້ນ ມີການອອກແບບທີ່ອະນຸຍາດໃຫ້ສາມາດສັ່ງງານຄຳສັ່ງໃດກໍໄດ້ (Arbitrary Command Execution). Anthropic ໄດ້ສະແດງທ່າທີວ່າຈະບໍ່ປ່ຽນແປງຮູບແບບການປະມວນຜົນ STDIO ຢ່າງຫຼວງຫຼາຍ ເນື່ອງຈາກຖືວ່າເປັນ "ຄ່າເລີ່ມຕົ້ນທີ່ປອດໄພຕາມການອອກແບບ" ແລະໃຫ້ຜູ້ໃຊ້ເປັນຜູ້ຮັບຜິດຊອບໃນການກວດສອບຄວາມປອດໄພ (ທີ່ມາ: OX Security / SecurityWeek). ເຊິ່ງຂອບເຂດຜົນກະທົບມີການດາວໂຫຼດລວມຫຼາຍກວ່າ 150 ລ້ານຄັ້ງ.
• ການເປີດເຜີຍ MCP Server ຕໍ່ສາທາລະນະເປັນຈຳນວນຫຼາຍ: BlueRock Security ໄດ້ວິເຄາະ MCP Server ຫຼາຍກວ່າ 7,000 ແຫ່ງ ແລະເປີດຕົວ ຫຼື Launch ຂໍ້ມູນວ່າພົບຄວາມສ່ຽງຕໍ່ຊ່ອງໂຫວ່ SSRF (Server-Side Request Forgery) ປະມານ 36.7%. ນອກຈາກນີ້ ຍັງມີການລາຍງານວ່າ MCP Server ຈຳນວນຫຼາຍຖືກເປີດໄວ້ໃນເຄືອຂ່າຍສາທາລະນະໂດຍບໍ່ມີການຢືນຢັນຕົວຕົນ.
• ການແຈກຢາຍ Skill ທີ່ເປັນອັນຕະລາຍຜ່ານ Marketplace: ມີນັກຄົ້ນຄວ້າດ້ານຄວາມປອດໄພຫຼາຍທ່ານໄດ້ເປີດຕົວ ຫຼື Launch ຂໍ້ມູນກ່ຽວກັບການກວດພົບການແຈກຢາຍ Skill ທີ່ເປັນອັນຕະລາຍຜ່ານ "Skill Market" ຂອງ AI Agent.

ສຳລັບຄວາມພ້ອມຂອງຝ່າຍປ້ອງກັນນັ້ນ, ລາຍງານ "State of AI Security 2026" ຂອງ Cisco ລະບຸວ່າ ມີພຽງ ປະມານ 29% ຂອງອົງກອນເທົ່ານັ້ນທີ່ມີຄວາມພ້ອມໃນການນຳໃຊ້ Agent AI ເຂົ້າສູ່ລະບົບການເຮັດວຽກຈິງ. ໃນຂະນະທີ່ພື້ນທີ່ການໂຈມຕີເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ແຕ່ການກຽມຄວາມພ້ອມຂອງຝ່າຍປ້ອງກັນຍັງຕາມບໍ່ທັນ.

ເສັ້ນປ້ອງກັນທຳອິດຄືການລະບຸຢ່າງຊັດເຈນວ່າ "ສາມາດປະຕິບັດ MCP server ຫຼື Skill ໃດໄດ້ແດ່" ໂດຍໃຊ້ລາຍການອະນຸຍາດ (allowlist). ການອະນຸຍາດທັງໝົດໂດຍຄ່າເລີ່ມຕົ້ນນັ້ນປຽບເໝືອນການບໍ່ມີການປ້ອງກັນຢ່າງແທ້ຈິງ ແລະ ເມື່ອຈຸດອ່ອນທາງການອອກແບບໄດ້ປາກົດຂຶ້ນມາແລ້ວ ກໍບໍ່ມີຈຸດເລີ່ມຕົ້ນໃດນອກເໜືອໄປຈາກການທີ່ຝ່າຍບໍລິສັດຕ້ອງຈຳກັດຄວາມເຊື່ອຖືຂອງເສັ້ນທາງການເຊື່ອມຕໍ່.

ເສັ້ນທາງການສົ່ງຂໍ້ມູນທີ່ຕ້ອງໄດ້ຮັບການກວດສອບສາມາດແບ່ງອອກເປັນ 3 ປະເພດຄື: (1) MCP server ທີ່ຢູ່ເທິງເຄືອຂ່າຍສາທາລະນະ, (2) Skill ທີ່ແຈກຢາຍຢູ່ໃນ Marketplace, ແລະ (3) MCP / Skill ທີ່ພັດທະນາພາຍໃນບໍລິສັດ. ເຊິ່ງແຕ່ລະປະເພດມີລັກສະນະຂອງຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນ.

ເມື່ອໃຊ້ງານ MCP server ທີ່ເປີດຕົວ ຫຼື Launch ໃຫ້ສາທາລະນະ, ໃຫ້ກວດສອບຢ່າງໜ້ອຍດັ່ງນີ້:

• ວິທີການ ການຢືນຢັນຕົວຕົນ (OAuth, API Key, mTLS) ຕ້ອງມີການບັນທຶກໄວ້ເປັນເອກະສານ ແລະ ບໍ່ມີ endpoint ທີ່ບໍ່ມີການຢືນຢັນຕົວຕົນ.
• ຕ້ອງລະບຸຂໍ້ມູນອົງກອນ, ຂໍ້ມູນຕິດຕໍ່ ແລະ ຊ່ອງທາງການລາຍງານຊ່ອງໂຫວ່ຂອງຜູ້ໃຫ້ບໍລິການຢ່າງຊັດເຈນ.
• ການສື່ສານຕ້ອງຖືກເຂົ້າລະຫັດດ້ວຍ TLS ແລະ ມີການປ້ອງກັນເພີ່ມເຕີມເຊັ່ນ: Certificate Pinning.
• ຕ້ອງມີການເປີດຕົວ ຫຼື Launch ຂໍ້ມູນ SBOM ແລະ ປະຫວັດການປ່ຽນແປງຂອງຜູ້ໃຫ້ບໍລິການ ເພື່ອໃຫ້ສາມາດຕິດຕາມຊ່ອງໂຫວ່ຂອງ Library ທີ່ນຳມາໃຊ້ງານໄດ້.

MCP ທີ່ເປີດຕົວ ຫຼື Launch ໃຫ້ສາທາລະນະໂດຍບໍ່ມີການຢືນຢັນຕົວຕົນ ແລະ ໃຜກໍສາມາດເຂົ້າເຖິງໄດ້ນັ້ນ ບໍ່ເໝາະສົມສຳລັບການນຳໃຊ້ໃນວຽກງານ. ໃນເບື້ອງຕົ້ນ, ຄວນຈຳກັດການໃຊ້ງານພຽງແຕ່ "MCP server ທີ່ປິດລ້ອມພາຍໃນເຄືອຂ່າຍຂອງບໍລິສັດ" ຫຼື "MCP ທີ່ເຊື່ອມຕໍ່ໂດຍກົງກັບຜູ້ໃຫ້ບໍລິການທີ່ມີການຢືນຢັນຕົວຕົນ" ເທົ່ານັ້ນ, ສ່ວນ MCP ທີ່ເປີດຕົວ ຫຼື Launch ໃຫ້ສາທາລະນະຈາກພາຍນອກນັ້ນ ຄວນມີການປະເມີນຜົນເປັນໄລຍະກ່ອນນຳມາໃຊ້ງານຈິງ.

Skill ຫຼື MCP ແພັກເກັດ ຄວນຖືກຈັດການໂດຍຕັ້ງສົມມຸດຕິຖານວ່າ "ສາມາດຖືກດັດແປງແກ້ໄຂໄດ້ ເຊັ່ນດຽວກັບ Container image ຫຼື npm ແພັກເກັດ".

• ການກວດສອບລາຍເຊັນ (Signature Verification): ຢືນຢັນວ່າສິ່ງທີ່ແຈກຢາຍມີລາຍເຊັນຂອງຜູ້ໃຫ້ບໍລິການ (ເຊັ່ນ: Sigstore / cosign) ຕິດມາດ້ວຍ ແລະ ໃຫ້ນຳເຂົ້າສະເພາະສິ່ງທີ່ຜ່ານການກວດສອບແລ້ວເທົ່ານັ້ນ
• SBOM: ດຶງຂໍ້ມູນລາຍການ Library ທີ່ເພິ່ງພາອາໄສ (Dependency) ເຊິ່ງຖືກນຳໃຊ້ພາຍໃນ Skill ແລະ ນຳໄປກວດສອບກັບ CVE ທີ່ຮູ້ຈັກ
• ການກຳນົດຄ່າ Hash ໃຫ້ຄົງທີ່ (Hash Pinning): ບັນທຶກຄ່າ Hash ໃນເວລາທີ່ນຳເຂົ້າ ແລະ ຄຳນວນໃໝ່ເປັນໄລຍະເພື່ອປຽບທຽບວ່າບໍ່ມີການດັດແປງແກ້ໄຂ

ສິ່ງທີ່ເໝາະສົມທີ່ສຸດຄືການມີ "Internal Mirror" ທີ່ບໍ່ອະນຸຍາດໃຫ້ອັບເດດອັດຕະໂນມັດຈາກ Marketplace ແລະ ແຈກຢາຍສະເພາະເວີຊັນທີ່ຜ່ານການກວດສອບພາຍໃນບໍລິສັດແລ້ວເທົ່ານັ້ນ. ການມີ Internal Mirror ອາດເບິ່ງຄືວ່າເປັນການລົງທຶນທີ່ເກີນຄວາມຈຳເປັນ, ແຕ່ເມື່ອພິຈາລະນາຈາກຂໍ້ມູນການສັງເກດການທີ່ມີ Skill ທີ່ບໍ່ຫວັງດີແຜ່ກະຈາຍຢູ່ແທ້ຈິງແລ້ວ, ນີ້ຖືເປັນທາງເລືອກທີ່ສົມເຫດສົມຜົນໃນຖານະຕົ້ນທຶນເພື່ອດຶງຂອບເຂດຂອງ Supply Chain ກັບມາຢູ່ຝັ່ງຂອງບໍລິສັດ.

ການຫຼຸດຜ່ອນສິດທິຂອງຄຳສັ່ງ ຫຼື API ທີ່ MCP / Skill ເອີ້ນໃຊ້ ແລະ ການເຮັດໃຫ້ການປະຕິບັດງານຂອງ Agent ເປັນແບບ Sandbox ທັງໃນລະດັບ OS ແລະ ເຄືອຂ່າຍ ຈະຊ່ວຍໃຫ້ສາມາດຈຳກັດຄວາມເສຍຫາຍໄດ້ຫາກມີເຄື່ອງມືທີ່ບໍ່ຫວັງດີປົນເຂົ້າມາ. ບົດບາດຂອງ Step 2 ຄືການຈຳກັດຂອບເຂດຄວາມເສຍຫາຍທາງກາຍະພາບ ໂດຍອີງໃສ່ພຶດຕິກຳທີ່ຊ່ອງໂຫວ່ແບບ "by design" ອະນຸຍາດໃຫ້ເກີດຂຶ້ນ.

ການແຍກສິດທິ (Privilege separation) ຈະຖືກອອກແບບທັງໃນລະດັບ OS ແລະ ລະດັບການສື່ສານ.

ໂດຍພື້ນຖານແລ້ວ, Agent, MCP Client ແລະ MCP Server ຄວນຖືກແຍກອອກຈາກກັນໃນແຕ່ລະ Execution Context.

ສະຖານະທີ່ວ່າ "ດຳເນີນການດ້ວຍ Docker ໄປກ່ອນ" ນັ້ນ ໃນຄວາມເປັນຈິງແລ້ວມີຫຼາຍກໍລະນີທີ່ການແຍກສ່ວນຍັງບໍ່ພຽງພໍ. ການຕັ້ງຄ່າເຊັ່ນ: ການດຳເນີນການດ້ວຍ root ພາຍໃນຄອນເທນເນີ, ການ Mount Docker socket ຂອງ Host, ຫຼື ການແບ່ງປັນ /var/run ນັ້ນ ບໍ່ສາມາດເອີ້ນໄດ້ວ່າເປັນ Sandbox. ນະໂຍບາຍທີ່ປອດໄພກວ່າຄືການຈຳກັດຊຸດຄຳສັ່ງທີ່ Skill ສາມາດດຳເນີນການໄດ້ ໃຫ້ເຫຼືອພຽງແຕ່ໄຟລ໌ທີ່ສາມາດປະຕິບັດງານໄດ້ (Executable files) ທີ່ຢູ່ໃນ Allowlist ເທົ່ານັ້ນ ແລະ ບລັອກ System call ອື່ນໆທີ່ເຫຼືອ.

ມີການຊີ້ໃຫ້ເຫັນວ່າ MCP server ເກືອບ 40% ອາດມີຊ່ອງໂຫວ່ SSRF (ອີງຕາມການວິເຄາະໂດຍ BlueRock Security). ນີ້ແມ່ນປະກົດການທີ່ MCP / Skill "ສາມາດສົ່ງຄຳຮ້ອງຂໍ HTTP ໄປຍັງເຄືອຂ່າຍພາຍໃນ ຫຼື endpoint ຂໍ້ມູນ metadata ຂອງຄລາວໄດ້ຕາມໃຈມັກ".

ການປ້ອງກັນຈະເນັ້ນໄປທີ່ການເຮັດ allowlist ໃຫ້ກັບ egress (ການສື່ສານອອກສູ່ພາຍນອກ).

• ບລັອກການສື່ສານທັງໝົດ ໄປຍັງ metadata endpoint 169.254.169.254 (ເຖິງແມ່ນວ່າຈະບັງຄັບໃຊ້ IMDSv2 ແລ້ວ ກໍຄວນເຮັດເພື່ອເປັນການປ້ອງກັນເພີ່ມເຕີມ)
• ບລັອກການສື່ສານໄປຍັງກຸ່ມ IP ສ່ວນຕົວ (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ແລະ ອື່ນໆ) ຍົກເວັ້ນປາຍທາງທີ່ຈຳເປັນຕໍ່ການເຮັດວຽກ
• ຈຳກັດການສື່ສານພາຍນອກໃຫ້ເປັນ HTTPS ແລະ ຜ່ານ allowlist ຂອງໂດເມນເທົ່ານັ້ນ
• ພິຈາລະນາການໂຈມຕີແບບ DNS Rebinding ໂດຍໃຫ້ມີການກວດສອບຊ້ຳຫຼັງຈາກແກ້ໄຂ IP ແລ້ວ

ສະພາບແວດລ້ອມການເຮັດວຽກຂອງ MCP / Skill ທີ່ບໍ່ໄດ້ຄວບຄຸມ egress ແມ່ນມີຄວາມສ່ຽງຕໍ່ການຖືກລັກເອົາ credential ຊົ່ວຄາວຈາກ IAM role ຂອງ AWS. ຖ້າຫາກດຳເນີນການເທິງຄລາວ, ຄວນຖືວ່າ egress filter ບໍ່ແມ່ນສິ່ງທີ່ "ມີໄວ້ກໍດີ" ແຕ່ເປັນສິ່ງທີ່ "ຖ້າບໍ່ມີ ກໍຖືວ່າຄວາມສ່ຽງໄດ້ເກີດຂຶ້ນແລ້ວ".

ການບັນທຶກ Prompt ປ້ອນຂໍ້ມູນ ແລະ Action ຜົນລັພຂອງ MCP / Skill ພ້ອມທັງກວດຫາຮູບແບບທີ່ຜິດປົກກະຕິ ຈະຊ່ວຍໃຫ້ສາມາດກວດພົບການໂຈມຕີໄດ້ໄວ ແລະ ຕອບສະໜອງຕໍ່ຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບ ເຊັ່ນ: PDPA ໄດ້ໃນເວລາດຽວກັນ. ຖ້າຫາກ Step 1 ແລະ 2 ແມ່ນການປ້ອງກັນແບບ "ຈຳກັດການບຸກລຸກ", Step 3 ກໍຖືເປັນຊັ້ນປ້ອງກັນສຳລັບ "ການກວດພົບຫຼັງຈາກຖືກບຸກລຸກ ແລະ ການປະຕິບັດໜ້າທີ່ໃນການສະແດງຄວາມຮັບຜິດຊອບ".

ການປ້ອງກັນການປ້ອນຂໍ້ມູນ ແລະ ຜົນລັພ (Input/Output Guard) ສາມາດຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນ ໂດຍຖືວ່າເປັນການຂະຫຍາຍຮູບແບບທີ່ໄດ້ສົນທະນາກັນໃນ ມາດຕະການປ້ອງກັນ Prompt Injection ແລະ ການຈັດຕັ້ງປະຕິບັດ AI Guardrails.

ເສັ້ນທາງການປ້ອນຂໍ້ມູນຂອງ MCP / Skill ມີ 3 ຊ່ອງທາງຄື: (1) ຄຳສັ່ງໂດຍກົງຈາກຜູ້ໃຊ້, (2) ຂໍ້ຄວາມທີ່ນຳເຂົ້າຈາກ RAG, ຖານຂໍ້ມູນ ຫຼື ໄຟລ໌, ແລະ (3) ການຕອບສະໜອງຈາກ MCP server ອື່ນ ຫຼື ເອເຈນອື່ນ.

ສິ່ງທີ່ຄວນລະວັງເປັນພິເສດແມ່ນຂໍ້ (2) ແລະ (3) ເຊິ່ງເປັນ "ການສັ່ງງານຜ່ານ Prompt ທາງອ້ອມ" (Indirect Prompt Injection) ທີ່ຜູ້ໃຊ້ບໍ່ໄດ້ຕັ້ງໃຈ ແຕ່ຖືກແຊກຊຶມຄຳສັ່ງໂຈມຕີຜ່ານທາງຂໍ້ມູນ.

ເນື່ອງຈາກ "ການກວດສອບທຸກຄຳຮ້ອງຂໍດ້ວຍ LLM" ມັກຈະບໍ່ສາມາດປະຕິບັດໄດ້ຈິງ, ດັ່ງນັ້ນການກຳນົດນະໂຍບາຍໃຫ້ ກວດສອບຢ່າງເຂັ້ມງວດສະເພາະການຮຽກໃຊ້ເຄື່ອງມືທີ່ມີການຂຽນ, ການລຶບ ແລະ ການສື່ສານກັບພາຍນອກ ຈຶ່ງເປັນວິທີທີ່ເໝາະສົມໃນການສ້າງຄວາມສົມດຸນລະຫວ່າງຕົ້ນທຶນ ແລະ ຄວາມສ່ຽງ.

ການຮຽກໃຊ້ MCP / Skill ຄວນມີພື້ນຖານໃນການບັນທຶກ "ເວລາໃດ, ໃຜ, ເອເຈນ (Agent) ໃດ, ໃຊ້ເຄື່ອງມືໃດ, ໃຊ້ພາຣາມິເຕີໃດ ແລະ ໄດ້ຜົນຕອບແທນຫຍັງ" ໄວ້ເປັນບັນທຶກທີ່ມີໂຄງສ້າງ (Structured log). ຕໍ່ໄປນີ້ແມ່ນລາຍການທີ່ຄວນມີໃນບັນທຶກຂັ້ນຕໍ່າສຸດ:

• Request ID (ສາມາດເຊື່ອມໂຍງກັບ Agent session ໄດ້)
• ID ຂອງ Agent ທີ່ຮຽກໃຊ້ ແລະ User ID (ໃນກໍລະນີ HITL ໃຫ້ລວມເຖິງຜູ້ອະນຸມັດ)
• ຊື່ເຄື່ອງມື ແລະ ພາຣາມິເຕີ (ໃຫ້ປິດບັງຂໍ້ມູນ PII)
• ຂະໜາດຂອງຄ່າທີ່ສົ່ງກັບຄືນ ແລະ ຈຸດໝາຍປາຍທາງການສື່ສານພາຍນອກ
• ການເກີດຂໍ້ຍົກເວັ້ນ (Exception) ຫຼື ໝົດເວລາ (Timeout)

ສັນຍານໃນການກວດຫາຄວາມຜິດປົກກະຕິທີ່ເປັນມາດຕະຖານໄດ້ແກ່: (a) ການຮຽກໃຊ້ເຄື່ອງມືຈຳນວນຫຼາຍໃນເວລາສັ້ນໆ, (b) ການສົ່ງຂໍ້ມູນອອກ (Egress) ໄປຍັງໂດເມນທີ່ບໍ່ຄ່ອຍໄດ້ໃຊ້, (c) ການອ່ານໄຟລ໌ຈຳນວນຫຼາຍ, (d) ການສົ່ງຂໍ້ມູນສ່ວນບຸກຄົນອອກໄປພາຍນອກ. ສິ່ງເຫຼົ່ານີ້ສາມາດເລີ່ມຕົ້ນໄດ້ດ້ວຍກົດລະບຽບງ່າຍໆທີ່ສາມາດນຳໄປລວມເຂົ້າກັບເຄື່ອງມື SIEM / SOC ທີ່ມີຢູ່ ເພື່ອໃຫ້ສາມາດເບິ່ງເຫັນພາບລວມໄດ້ໂດຍໃຊ້ຕົ້ນທຶນໃນການເລີ່ມຕົ້ນທີ່ຕໍ່າ.

ບັນທຶກການກວດສອບ (Audit log) ບໍ່ພຽງແຕ່ໃຊ້ໃນການກວດຫາການໂຈມຕີເທົ່ານັ້ນ ແຕ່ຍັງມີບົດບາດສຳຄັນໃນການ ຮັບປະກັນວ່າ "ສາມາດສະແດງປະຫວັດການເຂົ້າເຖິງຂໍ້ມູນສ່ວນບຸກຄົນໄດ້" ເພື່ອຮອງຮັບ PDPA ແລະ ການກວດສອບ. ຄວນນຳໄປປະຍຸກໃຊ້ຮ່ວມກັບ ການຈັດຕັ້ງປະຕິບັດການເຂົ້າລະຫັດ ເຊັ່ນ AES-256 ເພື່ອໃຫ້ໄດ້ທັງຄວາມລັບຂອງຂໍ້ມູນໃນຂະນະຈັດເກັບ ແລະ ຄວາມສາມາດໃນການຕິດຕາມ (Traceability).

ຄວາມເປັນຈິງໃນປັດຈຸບັນແມ່ນຂໍ້ສົມມຸດຕິຖານທີ່ວ່າ "ການຕັ້ງຄ່າເລີ່ມຕົ້ນກໍພຽງພໍແລ້ວ" ຫຼື "ເຄືອຂ່າຍພາຍໃນມີຄວາມປອດໄພ" ສຳລັບການປ້ອງກັນ MCP / Skill ນັ້ນໄດ້ພັງທະລາຍລົງແລ້ວ. ຄວາມຜິດພາດທີ່ພົບເຫັນຫຼາຍທີ່ສຸດແມ່ນມາຈາກການເຊື່ອໝັ້ນໃນໂຄງສ້າງຫຼາຍເກີນໄປ.

ໃນທີ່ນີ້, ພວກເຮົາຈະຍົກຕົວຢ່າງທີ່ພົບເຫັນເລື້ອຍໆ 2 ຢ່າງມາອະທິບາຍ.

ຄວາມເຂົ້າໃຈຜິດທີ່ພົບເລື້ອຍທີ່ສຸດແມ່ນແນວຄວາມຄິດທີ່ວ່າ "ເນື່ອງຈາກມັນເຮັດວຽກຢູ່ໃນເຄື່ອງທ້ອງຖິ່ນ (Local machine) ມັນຈຶ່ງບໍ່ອອກໄປສູ່ພາຍນອກ". ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງຊ່ອງໂຫວ່ໃນການນຳໃຊ້ MCP ຂອງ Anthropic ແມ່ນ ສາມາດປະຕິບັດຄຳສັ່ງໃດກໍໄດ້ເທິງເຄື່ອງຂອງຜູ້ໃຊ້ ເຖິງແມ່ນວ່າຈະເປັນການປະຕິບັດງານແບບທ້ອງຖິ່ນກໍຕາມ. ຂໍສະຫຼຸບສິ່ງທີ່ຈະເກີດຂຶ້ນຢ່າງລະອຽດດັ່ງນີ້:

• ການລັກຂະໂມຍ Cookie, ລະຫັດຜ່ານ ແລະ ກະແຈ SSH ທີ່ບັນທຶກໄວ້ໃນບຣາວເຊີ
• ການເຄື່ອນຍ້າຍທາງຂ້າງ (Lateral movement) ໄປສູ່ຄອນໂຊນການຈັດການຄລາວ (AWS / GCP) ທີ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກ PC ຂອງນັກພັດທະນາ
• ການດຶງຂໍ້ມູນ Source code ຂອງໂຄງການອື່ນໆ ຫຼື ຂໍ້ມູນລູກຄ້າທີ່ວາງໄວ້ພາຍໃນ IDE

"ທ້ອງຖິ່ນ" ບໍ່ແມ່ນ "ນອກຂອບເຂດຂອງບໍລິສັດ", ແຕ່ຄວນປະຕິບັດຕໍ່ມັນໃນຖານະ ໂຮສທີ່ມີສິດທິສູງອີກເຄື່ອງໜຶ່ງທີ່ສາມາດເຊື່ອມຕໍ່ກັບລະບົບການເຮັດວຽກໄດ້. ໃນແນວທາງປະຕິບັດຂອງບໍລິສັດ, ຄວນຈັດໂຄງສ້າງໃຫ້ PC ທີ່ໃຊ້ງານ MCP / Skill ບໍ່ມີການເຂົ້າເຖິງຖານຂໍ້ມູນຫຼັກ (Production DB) ໂດຍກົງ ແລະ ຖ້າຈຳເປັນ ໃຫ້ປ່ຽນໄປໃຊ້ວິທີຜ່ານເຄື່ອງແມ່ຂ່າຍຕົວແທນ (Jump server) + ຂໍ້ມູນຢືນຢັນຕົວຕົນທີ່ມີອາຍຸການໃຊ້ງານສັ້ນ (Short-lived credentials) ເພື່ອຫຼຸດຜ່ອນຂອບເຂດຂອງຄວາມເສຍຫາຍໃຫ້ໜ້ອຍລົງ.

ອີກຮູບແບບໜຶ່ງທີ່ພົບເຫັນໄດ້ເລື້ອຍໆ ຄື ການຕັ້ງຄ່າທີ່ສະດວກໃນຂະນະພັດທະນາ ຫຼຸດລອດເຂົ້າໄປໃນລະບົບທີ່ໃຊ້ງານຈິງ (Production).

• ເຊີບເວີ MCP ທີ່ບໍ່ມີການຢືນຢັນຕົວຕົນ ເຊິ່ງໃຊ້ໃນການພັດທະນາ ຍັງຄົງຄ້າງຢູ່ໃນ Docker image ທີ່ນຳໄປ Deploy ໃຊ້ງານຈິງ
• ຕົວແປສະພາບແວດລ້ອມ (Environment variable) MCP_ALLOW_ALL=true ຖືກຕັ້ງຄ່າໄວ້ໃນລະບົບທີ່ໃຊ້ງານຈິງເຊັ່ນກັນ
• API ທີ່ເປີດ CORS ໄວ້ທັງໝົດເພື່ອຈຸດປະສົງໃນການ Debug ຍັງຄົງເຮັດວຽກຢູ່ແບບນັ້ນໃນລະບົບທີ່ໃຊ້ງານຈິງ

ເຫຼົ່ານີ້ແມ່ນຄວາມຜິດພາດໃນການຕັ້ງຄ່າແບບຄລາສສິກ ແຕ່ໃນຍຸກຂອງ AI Agent ມັນສົ່ງຜົນກະທົບເປັນວົງກວ້າງ. ການ ແຍກໄຟລ໌ການຕັ້ງຄ່າ MCP / Skill ລະຫວ່າງ ການພັດທະນາ, ການທົດສອບ (Staging) ແລະ ການໃຊ້ງານຈິງ (Production) ໃຫ້ອອກຈາກກັນ, ພ້ອມທັງໃຊ້ກົນໄກໃນ CI/CD ຂະບວນການ ຫຼື Pipeline ເພື່ອປະຕິເສດ "ລາຍການ MCP ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ໃຊ້ໃນລະບົບຈິງ" ໃນຂະນະ Build ຈະຊ່ວຍໄດ້ຫຼາຍ. ການຈັດການໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ວຍລະຫັດ (Infrastructure as Code) ແລະ ການນຳມາລວມເຂົ້າໃນຂະບວນການກວດສອບ (Review) ຈະເຮັດໃຫ້ກວດພົບຂໍ້ຜິດພາດເຫຼົ່ານີ້ໄດ້ງ່າຍຂຶ້ນ.

ລຳດັບຄວາມສຳຄັນຂອງການປ້ອງກັນ MCP / Skill ແມ່ນໃຫ້ດຳເນີນການຕາມລຳດັບດັ່ງນີ້: "ການກວດສອບການນຳໃຊ້ໃນປັດຈຸບັນ → ການເຮັດ Allowlist → ການກຳນົດສິດຂັ້ນຕໍ່າສຸດ → ການກວດສອບ". ການພະຍາຍາມຈັດຕັ້ງປະຕິບັດທຸກຢ່າງພ້ອມກັນມັກຈະນຳໄປສູ່ຄວາມລົ້ມເຫຼວ. ໃນພາກນີ້, ພວກເຮົາຈະຕອບ 2 ຄຳຖາມທີ່ຖືກຖາມຫຼາຍທີ່ສຸດໃນການປະຕິບັດງານຕົວຈິງ.

Q. ບໍລິສັດທີ່ປະຕິບັດຕາມ PDPA ຂອງໄທ ຄວນເຮັດຫຍັງເພີ່ມເຕີມໃນການດຳເນີນງານ AI Agent?

ໃນບໍລິບົດຂອງ PDPA, ໃນກໍລະນີທີ່ AI Agent ມີການເຂົ້າເຖິງຂໍ້ມູນສ່ວນບຸກຄົນ, ຈຳເປັນຕ້ອງມີ 4 ຢ່າງເພີ່ມເຕີມຄື: (1) ການລະບຸຈຸດປະສົງໃນການປະມວນຜົນ, (2) ການບັນທຶກການເຂົ້າເຖິງ, (3) ການຈຳກັດການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ, ແລະ (4) ການຕອບສະໜອງຕໍ່ຄຳຮ້ອງຂໍຈາກເຈົ້າຂອງຂໍ້ມູນ.

ໃນດ້ານການຈັດຕັ້ງປະຕິບັດ, ການກະກຽມສິ່ງຕໍ່ໄປນີ້ແມ່ນມີຄວາມເປັນໄປໄດ້ໃນທາງປະຕິບັດ:

• ຕິດແທັກ "ປະເພດຂອງຂໍ້ມູນສ່ວນບຸກຄົນທີ່ໄດ້ປະມວນຜົນ" ໄວ້ໃນບັນທຶກການກວດສອບ (Audit Log) ຂອງ MCP / Skill
• ແຍກ Skill ທີ່ຈັດການກັບຂໍ້ມູນສ່ວນບຸກຄົນອອກເປັນກຸ່ມຕ່າງຫາກ, ໂດຍໃຫ້ສິດໃນການແຈກຢາຍສະເພາະພະນັກງານທີ່ຜ່ານການຝຶກອົບຮົມດ້ານ PDPA ເທົ່ານັ້ນ
• ສຳລັບ MCP ທີ່ມີການສົ່ງຂໍ້ມູນຂ້າມຊາຍແດນ (ເຊັ່ນ: ການເອີ້ນໃຊ້ API ຕ່າງປະເທດ), ໃຫ້ໃຊ້ການປະສົມປະສານລະຫວ່າງ Egress filter ແລະ ກົນໄກການຂໍຄວາມຍິນຍອມລ່ວງໜ້າ
• ກຳນົດໄລຍະເວລາການເກັບຮັກສາ Log ໃຫ້ຍາວພຽງພໍຕາມຄວາມຕ້ອງການຂອງທຸລະກິດ ເພື່ອໃຫ້ສາມາດຕອບສະໜອງຕໍ່ຄຳຮ້ອງຂໍເປີດເຜີຍປະຫວັດການເຂົ້າເຖິງຈາກເຈົ້າຂອງຂໍ້ມູນໄດ້

ເມື່ອນຳໄປປະສົມປະສານກັບຮູບແບບການຈັດການກຸນແຈ (Key Management Pattern) ທີ່ໄດ້ກ່າວໄວ້ໃນ ການຈັດຕັ້ງປະຕິບັດການເຂົ້າລະຫັດ AES-256 ເພື່ອຮອງຮັບ PDPA ຂອງໄທ, ຈະເຮັດໃຫ້ສາມາດຕອບໂຈດຄວາມຕ້ອງການດ້ານການກວດສອບໄດ້ງ່າຍຂຶ້ນ ທັງໃນສ່ວນຂອງການຈັດເກັບຂໍ້ມູນ ແລະ ການສື່ສານຂໍ້ມູນ.

ຄຳຖາມ: ຖ້າມີ SOC / SIEM ຢູ່ແລ້ວ, ຄວນລວມ ຫຼື Merge ການຕິດຕາມ AI Agent ເຂົ້າໄປແນວໃດ?

ແທນທີ່ຈະສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ການຕິດຕາມໃໝ່ທັງໝົດ, ວິທີທີ່ເປັນໄປໄດ້ຈິງຄືການນຳ "ການເອີ້ນໃຊ້ MCP / Skill" ເຂົ້າໄປເປັນແຫຼ່ງຂໍ້ມູນໃໝ່ໃນ SIEM ທີ່ມີຢູ່ແລ້ວ. ຂັ້ນຕອນທຳອິດທີ່ແນະນຳມີ 4 ຂໍ້ດັ່ງນີ້:

1. ມາດຕະຖານ ຫຼື Specification ຂອງ Log ຈາກ MCP / Skill ໃຫ້ຢູ່ໃນຮູບແບບ JSON Lines ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເຂົ້າສູ່ຊ່ອງທາງການຮັບຂໍ້ມູນຂອງ SIEM ທີ່ມີຢູ່
2. ນຳກົດລະບຽບການກວດຈັບການ Jailbreak ແລະການຮົ່ວໄຫຼຂອງຂໍ້ມູນທີ່ມີຢູ່ແລ້ວໄປໃຊ້ກັບ Event tool_call ດ້ວຍ
3. ລົງທະບຽນ Session ຂອງ AI Agent ໃຫ້ເປັນ Entity ທຽບເທົ່າ "User Session"
4. ຍົກລະດັບຄວາມສຳຄັນຂອງການເອີ້ນໃຊ້ເຄື່ອງມືທີ່ມີຄວາມສ່ຽງສູງ (ເຊັ່ນ: exec, http_post, ການລຶບໄຟລ໌) ໃຫ້ເປັນ Alert Class ແຍກຕ່າງຫາກ

ເປົ້າໝາຍຄືການໃຫ້ SOC ທີ່ມີຢູ່ສາມາດຈັດການ AI Agent ໃນຖານະ Workload ໃໝ່ອັນໜຶ່ງໄດ້ ໂດຍບໍ່ຕ້ອງຕັ້ງທີມຕິດຕາມສະເພາະ AI ຂຶ້ນໃໝ່, ເຊິ່ງຈະຊ່ວຍໃຫ້ການດຳເນີນງານຍືນຍົງໄດ້ທັງໃນດ້ານບຸກຄະລາກອນ ແລະ ການດຳເນີນງານ. ສຳລັບການຝຶກຊ້ອມໃນມຸມມອງຂອງຜູ້ໂຈມຕີ, ສາມາດເບິ່ງໄດ້ທີ່ ຄູ່ມືການປະຕິບັດ AI Red Teaming ແລະ ຄວນນຳໄປໃຊ້ຄຽງຄູ່ກັບການຝຶກຊ້ອມດ້ານການປ້ອງກັນ.

ການໂຈມຕີ Supply Chain ຂອງ AI Agent ໄດ້ນຳພາພື້ນທີ່ການໂຈມຕີທີ່ມາດຕະການຄວາມປອດໄພແບບດັ້ງເດີມບໍ່ໄດ້ຄາດຄິດໄວ້ເຂົ້າສູ່ອົງກອນ ອັນເນື່ອງມາຈາກການປາກົດຕົວຂອງຊ່ອງທາງການສົ່ງຂໍ້ມູນໃໝ່ຢ່າງ MCP ແລະ Skill ລວມທັງການຕັດສິນໃຈດ້ານການອອກແບບທີ່ Anthropic ເອງຍອມຮັບວ່າເປັນ "by design"

ການປ້ອງກັນບໍ່ແມ່ນເຄື່ອງມືດຽວ ແຕ່ຕ້ອງອອກແບບເປັນ 3 ຊັ້ນ:

• Step 1: ຈຳກັດ MCP / Skill ທີ່ຈະນຳໃຊ້ດ້ວຍ allowlist ແລະກວດສອບຊ່ອງທາງການສົ່ງຂໍ້ມູນດ້ວຍລາຍເຊັນ ແລະ SBOM
• Step 2: ດຳເນີນການໃນ sandbox ທີ່ມີສິດທິ໌ຕ່ຳສຸດ ແລະຕັດການເຊື່ອມຕໍ່ SSRF / egress ຢ່າງເດັດຂາດ
• Step 3: ບັນທຶກ audit log ການເອີ້ນໃຊ້ທັງໝົດ ແລະເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບລະບົບກວດຈັບຄວາມຜິດປົກກະຕິ ແລະຂໍ້ກຳນົດ PDPA / SOC

ການຈັດຕຽມທຸກຢ່າງພ້ອມກັນໃນຄັ້ງດຽວນັ້ນບໍ່ແມ່ນເລື່ອງທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດ. ໃຫ້ເລີ່ມຕົ້ນຈາກການສຳຫຼວດລາຍການ MCP / Skill ທີ່ໃຊ້ງານຢູ່ໃນປັດຈຸບັນ ແລ້ວຈຳກັດການໃຊ້ MCP ສາທາລະນະກ່ອນ ຊຶ່ງຖືເປັນຂັ້ນຕອນທຳອິດທີ່ຄຸ້ມຄ່າດ້ານຕົ້ນທຶນ.

ສຳລັບຄູ່ມືທີ່ກ່ຽວຂ້ອງ ສາມາດອ່ານ ຄູ່ມືເບື້ອງຕົ້ນກ່ຽວກັບ AI Agent Protocol (MCP·A2A) · ການຈັດຕັ້ງປະຕິບັດ AI Guardrails · AI Red Teaming · Claude Mythos ແລະ Project Glasswing ຄຽງຄູ່ກັນ ເພື່ອເສີມສ້າງແນວທາງການປ້ອງກັນການດຳເນີນງານ AI Agent ທັງຈາກຝ່າຍກວດຈັບ ແລະຝ່າຍໂຈມຕີໃຫ້ມີຄວາມເລິກຊຶ້ງຍິ່ງຂຶ້ນ.