ການອອກແບບສິດທິຂອງ AI Agent (Least Privilege) — ຄູ່ມືການຈັດຕັ້ງປະຕິບັດສິດທິຂັ້ນຕໍ່າສຳລັບການໃຊ້ງານ Tool ແລະການເອີ້ນໃຊ້ API

"ຫຼັກການສິດທິພິເສດຂັ້ນຕໍ່າ (Least Privilege)" ຂອງ AI agent ແມ່ນຫຼັກການອອກແບບທີ່ໃຫ້ສິດທິໃນການໃຊ້ງານເຄື່ອງມື ແລະ API scope ພຽງແຕ່ຂັ້ນຕໍ່າສຸດທີ່ຈຳເປັນເພື່ອໃຫ້ agent ສາມາດບັນລຸເປົ້າໝາຍໄດ້ເທົ່ານັ້ນ ແລະ ຈະປິດກັ້ນສ່ວນທີ່ເຫຼືອທັງໝົດ.

ບົດຄວາມນີ້ມີຈຸດປະສົງສຳລັບວິສະວະກອນທີ່ກຳລັງຈະນຳໃຊ້ LLM-based agent ເຂົ້າສູ່ສະພາບແວດລ້ອມການເຮັດວຽກຈິງ (Production) ແລະ ສະຖາປະນິກທີ່ຕ້ອງການຊຸກຍູ້ການເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງເປັນອິດສະຫຼະ ໂດຍຍັງຄົງຮັກສາຄວາມຕ້ອງການດ້ານຄວາມປອດໄພ. ບົດຄວາມນີ້ຈະອະທິບາຍຂັ້ນຕອນການປະຕິບັດງານຕາມລຳດັບ ເລີ່ມຕັ້ງແຕ່ການອອກແບບ Tool Whitelist, ການຫຼຸດ API scope ໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດ, ການລວມເອົາຂະບວນການອະນຸມັດແບບ HITL (Human-in-the-Loop), ໄປຈົນເຖິງການຈັດຕັ້ງປະຕິບັດ Audit Log ແລະ ການກວດຈັບຄວາມຜິດປົກກະຕິ.

ເມື່ອອ່ານບົດຄວາມນີ້ຈົບ, ທ່ານຈະສາມາດຄວບຄຸມຄວາມສ່ຽງທີ່ເກີດຈາກການໃຫ້ສິດທິແກ່ agent ຫຼາຍເກີນໄປ (Excessive Agency) ໄດ້ຢ່າງເປັນລະບົບ ແລະ ສາມາດນຳເອົາການອອກແບບສິດທິການເຂົ້າເຖິງທີ່ສອດຄ່ອງກັບມາດຕະຖານ NIST SP 800-53 AC-6 ເຂົ້າໄປໃນຂະບວນການພັດທະນາຂອງບໍລິສັດທ່ານໄດ້.

ການອອກແບບສິດທິ (Permission design) ຄວນເລີ່ມຕົ້ນຈາກການກຳນົດໃຫ້ຊັດເຈນວ່າ "ຈະໃຫ້ເຮັດຫຍັງ". ຖ້າຫາກດຳເນີນການໂດຍທີ່ຈຸດປະສົງຍັງບໍ່ຈະແຈ້ງ ກໍມັກຈະເກີດບັນຫາການໃຫ້ສິດເກີນຄວາມຈຳເປັນ ຫຼື ການອອກແບບທີ່ຕົກຫຼົ່ນ. ກ່ອນທີ່ຈະນຳໃຊ້ສິດທິຂັ້ນຕໍ່າສຸດ (Least privilege) ສຳລັບການປະຕິບັດງານຂອງເຄື່ອງມື ຫຼື ການເອີ້ນໃຊ້ API, ຈຳເປັນຕ້ອງຈັດລະບຽບ 3 ຢ່າງຄື: ຄວາມຮັບຜິດຊອບຂອງ Agent, ການຈັດປະເພດຄວາມສ່ຽງຂອງເຄື່ອງມືທີ່ມີຢູ່, ແລະ ຂໍ້ກຳນົດດ້ານການກວດສອບ. ການດຳເນີນການແບບ "ໃຫ້ສິດກວ້າງໆໄວ້ກ່ອນເພື່ອໃຫ້ເຮັດວຽກໄດ້" ມັກຈະກາຍເປັນບ່ອນເພາະພັນຂອງບັນຫາສິດທິຂອງ Agent ທີ່ເກີນຄວາມຈຳເປັນ (Excessive Agency). ຕໍ່ໄປນີ້ຈະອະທິບາຍຂັ້ນຕອນການຈັດລະບຽບແຕ່ລະຢ່າງ.

ສະຫຼຸບ: ກ່ອນທີ່ຈະມອບສິດໃຫ້ແກ່ Agent, ການກຳນົດຂອບເຂດຄວາມຮັບຜິດຊອບໃຫ້ຊັດເຈນຈົນສາມາດອະທິບາຍໄດ້ໃນປະໂຫຍກດຽວວ່າ "Agent ນີ້ເຮັດໜ້າທີ່ຫຍັງ" ຄືຈຸດເລີ່ມຕົ້ນຂອງການອອກແບບສິດທິຂັ້ນຕໍ່າສຸດ (Least Privilege).

ຖ້າຫາກປ່ອຍໃຫ້ຄວາມຮັບຜິດຊອບບໍ່ຊັດເຈນ ແລ້ວຕັດສິນໃຈວ່າ "ເບິ່ງແລ້ວສະດວກດີ ສະນັ້ນມອບເຄື່ອງມືໃຫ້ທັງໝົດເລີຍ" ນັ້ນຈະກາຍເປັນບ່ອນເພາະພັນຂອງການມີສິດທິເກີນຄວາມຈຳເປັນ (Excessive Agency). ການກຳນົດຄວາມຮັບຜິດຊອບຄວນລະບຸໃຫ້ຊັດເຈນດັ່ງນີ້:

• ຈຸດປະສົງ (What): ຂຽນເປົ້າໝາຍທາງທຸລະກິດເປັນປະໂຫຍກດຽວ (ຕົວຢ່າງ: "ຕອບຄຳຖາມສຳລັບ FAQ ພາຍໃນບໍລິສັດ")
• ຂອບເຂດ (Boundary): ລາຍຊື່ລະບົບ ແລະ ຂໍ້ມູນທີ່ສາມາດເຂົ້າເຖິງ ຫຼື ຈັດການໄດ້
• ເງື່ອນໄຂ (When): ກຳນົດເງື່ອນໄຂໃນການເລີ່ມຕົ້ນ ແລະ ສິ້ນສຸດການເຮັດວຽກ

ຄວາມຮັບຜິດຊອບຈະຖືກປ່ຽນເປັນ "ກຸ່ມຂອງເຄື່ອງມື ແລະ API ທີ່ສາມາດເອີ້ນໃຊ້ໄດ້" ເຊິ່ງກໍຄື Scope. scope parameter ໃນ RFC 6749 (OAuth 2.0) ແມ່ນຕົວຢ່າງຂອງການຈັດຕັ້ງປະຕິບັດທີ່ສາມາດກຳນົດຄວາມລະອຽດໄດ້ເຊັ່ນ read:faq. ໃຫ້ກວດສອບວ່າການເອີ້ນໃຊ້ແຕ່ລະເຄື່ອງມືນັ້ນມີຄວາມຈຳເປັນໂດຍກົງຕໍ່ການບັນລຸເປົ້າໝາຍຫຼືບໍ່ ໂດຍອີງຕາມຫຼັກການ "ມອບສິດທິພຽງເທົ່າທີ່ຈຳເປັນຕໍ່ການປະຕິບັດວຽກງານ" ຂອງ NIST SP 800-53 AC-6.

ໃຫ້ລະບຸເຄື່ອງມື ແລະ API ທັງໝົດທີ່ Agent ອາດຈະເຂົ້າເຖິງໄດ້, ຈາກນັ້ນຈັດປະເພດຄວາມສ່ຽງໂດຍອີງໃສ່ 2 ແກນຫຼັກ ຄື: ຂອບເຂດຜົນກະທົບ ແລະ ຄວາມສາມາດໃນການຍົກເລີກ (Reversibility).

ຕົວຢ່າງການຈັດປະເພດລະດັບຄວາມສ່ຽງ

• ຄວາມສ່ຽງສູງ (ຕ້ອງໄດ້ຮັບການອະນຸມັດ): API ປະເພດລຶບຂໍ້ມູນ/ຂຽນຂໍ້ມູນ, ການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ພາຍນອກ, ການດຳເນີນການກ່ຽວກັບການເງິນ, ການເຂົ້າເຖິງຂໍ້ມູນການຢືນຢັນຕົວຕົນ
• ຄວາມສ່ຽງປານກາງ (ຕ້ອງບັນທຶກ Log): API ປະເພດອ່ານຂໍ້ມູນ/ຄົ້ນຫາ, ການຮຽກໃຊ້ບໍລິການພາຍໃນ, ການສ້າງໄຟລ໌
• ຄວາມສ່ຽງຕໍ່າ (ອະນຸຍາດຕາມປົກກະຕິ): ການອ້າງອີງຂໍ້ມູນຄົງທີ່, ເຄື່ອງມືຄຳນວນ/ແປງຂໍ້ມູນ, ການດຶງຂໍ້ມູນ Metadata ແບບອ່ານຢ່າງດຽວ

NIST SP 800-53 Rev.5 ຂອງ AC-6 (Least Privilege) ໄດ້ສະແດງໃຫ້ເຫັນເຖິງວິທີການ "ເລີ່ມຕົ້ນຈາກສິດທິທີ່ຖືກຈຳກັດຫຼາຍທີ່ສຸດ ແລະ ຂະຫຍາຍອອກເມື່ອມີຄວາມຈຳເປັນທາງທຸລະກິດທີ່ພິສູດໄດ້ເທົ່ານັ້ນ". ໃຫ້ຖືວ່າ ຄ່າເລີ່ມຕົ້ນແມ່ນຄວາມສ່ຽງສູງ ແລະ ຈະຫຼຸດລະດັບລົງກໍຕໍ່ເມື່ອມີຫຼັກຖານຄົບຖ້ວນເທົ່ານັ້ນ. ເຖິງແມ່ນວ່າຈະເປັນເຄື່ອງມືດຽວກັນ ແຕ່ລະ Endpoint ກໍອາດມີຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນ (ການອ່ານແມ່ນປານກາງ, ການລຶບແມ່ນສູງ ເປັນຕົ້ນ). ໃຫ້ຈັດປະເພດໂດຍ ອີງຕາມ Method ແລະ Endpoint, ຈາກນັ້ນນຳຜົນທີ່ໄດ້ໄປຈັດການໃນຮູບແບບ YAML ຫຼື ສະເປຣດຊີດ ເພື່ອນຳໄປໃຊ້ເປັນຂໍ້ມູນຂາເຂົ້າສຳລັບການອອກແບບ Whitelist ແລະ ການອອກແບບ Audit Log ຕໍ່ໄປ.

ກ່ອນທີ່ຈະກຳນົດການອອກແບບສິດທິ, ຕ້ອງຕັດສິນໃຈວ່າ "ຈະບັນທຶກຫຍັງ, ບັນທຶກເຖິງຂະໜາດໃດ ແລະ ຈະຮັກສາໄວ້ດົນປານໃດ". ກໍລະນີທີ່ບໍ່ມີຫຼັກຖານປະໄວ້ຫຼັງຈາກເກີດເຫດການ (Incident) ເຮັດໃຫ້ການສືບສວນຕ້ອງຢຸດສະງັກນັ້ນ ບໍ່ແມ່ນເລື່ອງທີ່ຫາຍາກ.

ມາດຕະຖານທີ່ໃຊ້ໃນການອ້າງອີງແມ່ນ NIST SP 800-53 Rev.5 ຫົວຂໍ້ AU-2 (ການກຳນົດເຫດການກວດສອບ) ແລະ AU-6 (ການທົບທວນບັນທຶກການກວດສອບ). ບັນທຶກການເຮັດວຽກຂອງເຄື່ອງມື Agent ກໍຈະຖືກອອກແບບພາຍໃຕ້ຂອບເຂດນີ້ເຊັ່ນກັນ.

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

ເພື່ອປ້ອງກັນການປອມແປງຂໍ້ມູນ, ຈະບໍ່ໃຫ້ສິດໃນການຂຽນຂໍ້ມູນລົງໃນ Log Storage ແກ່ຕົວ Agent ເອງ. ໂດຍຈະນຳໃຊ້ບ່ອນຈັດເກັບຂໍ້ມູນແບບ Append-only ຫຼື Log ທີ່ມີລາຍເຊັນດິຈິຕອນ, ແລະ ດຳເນີນການໂດຍການປະສົມປະສານລະຫວ່າງລະບົບແຈ້ງເຕືອນອັດຕະໂນມັດຕາມມາດຕະຖານ AU-6 ກັບການສຸ່ມກວດສອບໂດຍມະນຸດ.

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

ຍິ່ງມີເຄື່ອງມືທີ່ໄດ້ຮັບອະນຸຍາດຫຼາຍເທົ່າໃດ ພື້ນທີ່ໃນການຖືກໂຈມຕີກໍຍິ່ງກວ້າງຂຶ້ນເທົ່ານັ້ນ, ດັ່ງນັ້ນແນວຄິດ "ເອົາທຸກເຄື່ອງມືມາໃຊ້ໄວ້ກ່ອນ" ຈຶ່ງບໍ່ສາມາດນຳໃຊ້ໃນສະພາບແວດລ້ອມການເຮັດວຽກຈິງ (Production) ໄດ້. ໃນພາກນີ້, ພວກເຮົາຈະອະທິບາຍກ່ຽວກັບການກຳນົດຊຸດເຄື່ອງມືຂັ້ນຕ່ຳທີ່ໄດ້ຮັບອະນຸຍາດ, ການເລືອກໃຊ້ລະຫວ່າງການແກ້ໄຂແບບ Dynamic ແລະ Static Whitelist, ລວມເຖິງການອອກແບບ Rate limiting.

ສະຫຼຸບ: ເຄື່ອງມືອະນຸຍາດ (Permission tools) ຕ້ອງໄດ້ຮັບການຄັດເລືອກໂດຍຄິດໄລ່ຍ້ອນກັບຈາກໜ້າທີ່ຮັບຜິດຊອບ, ໂດຍໃຫ້ເກັບໄວ້ສະເພາະເຄື່ອງມືທີ່ "ຖ້າບໍ່ໃຊ້ກໍບໍ່ສາມາດປະຕິບັດໜ້າທີ່ໄດ້" ເທົ່ານັ້ນ, ບໍ່ແມ່ນເຄື່ອງມືທີ່ "ອາດຈະໄດ້ໃຊ້".

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

• ຂຽນຖະແຫຼງການຄວາມຮັບຜິດຊອບ (Responsibility statement) ໃຫ້ເປັນ 1 ປະໂຫຍກ: ເຊັ່ນ "ແຈ້ງເຕືອນຂໍ້ມູນການສັ່ງຊື້ໄປຍັງ Slack". ການປະຕິບັດງານໃດໆທີ່ບໍ່ປາກົດຢູ່ໃນປະໂຫຍກນີ້ ແມ່ນເປັນຜູ້ສະໝັກທີ່ຈະຖືກຕັດອອກ.
• ຈັດປະເພດເຄື່ອງມືເປັນ "ຈຳເປັນ / ທົດແທນໄດ້ / ບໍ່ຈຳເປັນ": ພິຈາລະນາວ່າ HTTP client ແບບທົ່ວໄປສາມາດທົດແທນດ້ວຍ API ທີ່ອ່ານຂໍ້ມູນສະເພາະທາງໄດ້ຫຼືບໍ່.
• ໃຫ້ເຫດຜົນສຳລັບການຂຽນຂໍ້ມູນ (Write operations) ເປັນລາຍກໍລະນີ: ຖ້າສາມາດປະຕິບັດໜ້າທີ່ໄດ້ດ້ວຍການອ່ານຂໍ້ມູນພຽງຢ່າງດຽວ ກໍບໍ່ຄວນໃຫ້ສິດໃນການຂຽນຂໍ້ມູນ (NIST SP 800-53 AC-6).

ຖ້າເປັນຕົວແທນຝ່າຍບໍລິການລູກຄ້າ (Customer support agent) ແລະ ພຽງພໍແລ້ວກັບ 3 ເຄື່ອງມືຄື "ອ້າງອີງປີ້ (Ticket reference)", "ຄົ້ນຫາ FAQ", ແລະ "ສົ່ງຄຳຕອບ", ກໍໃຫ້ຕັດເຄື່ອງມື "ລຶບປີ້" ແລະ "ອັບເດດຂໍ້ມູນຜູ້ໃຊ້" ອອກ. ເມື່ອກຳນົດຊຸດເຄື່ອງມືຂັ້ນຕໍ່າສຸດໄດ້ແລ້ວ, ໃຫ້ກຳນົດກົດລະບຽບທີ່ຕ້ອງມີການໃຫ້ເຫດຜົນປະກອບທຸກຄັ້ງທີ່ມີການເພີ່ມເຄື່ອງມືໃໝ່ ເພື່ອປ້ອງກັນການເພີ່ມສິດທິເກີນຄວາມຈຳເປັນ (Permission creep).

ຖ້າບໍ່ວາງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໂດຍອີງໃສ່ Static Whitelist, ຂອບເຂດຂອງສິດທິອຳນາດຈະມີຄວາມບໍ່ຊັດເຈນໄດ້ງ່າຍ.

Static Whitelist ແມ່ນວິທີການກຳນົດເຄື່ອງມືທີ່ສາມາດເອີ້ນໃຊ້ໄດ້ໃນເວລາ Deploy. ການປ່ຽນແປງຈະຕ້ອງຜ່ານຂະບວນການ Code Review ແລະຂັ້ນຕອນການອະນຸມັດ, ເຊິ່ງສາມາດກຳຈັດຄວາມສ່ຽງໃນການເພີ່ມເຄື່ອງມືທີ່ບໍ່ຮູ້ຈັກໃນເວລາປະຕິບັດງານໄດ້ ແລະ ສອດຄ່ອງກັບ NIST SP 800-53 AC-6.

Dynamic Tool Resolution ແມ່ນວິທີການອ້າງອີງ Catalog ໃນເວລາປະຕິບັດງານ, ເຊິ່ງມີປະສິດທິຜົນໃນໄລຍະທີ່ມີການເພີ່ມເຄື່ອງມືໃໝ່ໆເລື້ອຍໆ, ແຕ່ຖ້າອະນຸຍາດແບບບໍ່ຈຳກັດຈະເຮັດໃຫ້ຄວາມສ່ຽງຂອງສິດທິ Agent ຫຼາຍເກີນໄປ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ການນຳໃຊ້ໃນພາກປະຕິບັດ:

• ສະພາບແວດລ້ອມການຜະລິດ (Production): ຍຶດຖື Static Whitelist ເປັນຫຼັກ, ການເພີ່ມ ຫຼື ລຶບຕ້ອງຜ່ານປະຕູການອະນຸມັດຂອງ CI/CD.
• Staging/PoC: ອະນຸຍາດໃຫ້ໃຊ້ Dynamic Resolution ໃນຂະນະທີ່ຈຳກັດຕົວ Catalog ເອງດ້ວຍ Whitelist.
• Multi-agent: ກຳນົດ Static Whitelist ໃຫ້ກັບແຕ່ລະ Sub-agent ແລະໃຫ້ຊັ້ນ Orchestrator ເປັນຜູ້ຈັດສັນແບບ Dynamic.

ໃນກໍລະນີທີ່ນຳໃຊ້ Dynamic Resolution, ຄວນກຳນົດກົດລະບຽບວ່າ "ຫ້າມອອກນອກ Catalog ຢ່າງເດັດຂາດ", ພ້ອມທັງຄວບຄຸມເວີຊັນຂອງ Catalog ແລະບັນທຶກຄວາມແຕກຕ່າງຂອງການປ່ຽນແປງໄວ້ໃນ Audit Log.

ເຖິງແມ່ນວ່າຈະຈຳກັດເຄື່ອງມືທີ່ອະນຸຍາດດ້ວຍ Whitelist ແລ້ວ ແຕ່ຖ້າບໍ່ຈຳກັດຄວາມຖີ່ໃນການເອີ້ນໃຊ້ກໍຈະບໍ່ມີຄວາມໝາຍ. ຖ້າເກີດການເຮັດວຽກແບບ Indirect Injection ຫຼື Loop execution, ການເອີ້ນໃຊ້ແບບບໍ່ຈຳກັດຈະນຳໄປສູ່ລະບົບຂັດຂ້ອງ ຫຼື ຄ່າໃຊ້ຈ່າຍທີ່ເພີ່ມຂຶ້ນຢ່າງມະຫາສານ.

ການຈຳກັດອັດຕາ (Rate limit) ແລະ ຈຳກັດຈຳນວນຄັ້ງ ໃຫ້ປະສົມປະສານ 3 ແກນຫຼັກ ດັ່ງນີ້:

• Rate Limit: ຕັ້ງຄ່າ "N ຄັ້ງຕໍ່ 1 ນາທີ" ສຳລັບແຕ່ລະເຄື່ອງມື. ໂດຍສະເພາະ API ພາຍນອກ ຕ້ອງຈຳກັດໃຫ້ເຂັ້ມງວດ
• Budget Limit: ຈຳກັດຈຳນວນການເອີ້ນໃຊ້ລວມພາຍໃນ 1 Session ແລະ ຢຸດການເຮັດວຽກຂອງ Task ເມື່ອຮອດຂີດຈຳກັດ
• Cost Budget: ຕັ້ງຄ່າຂີດຈຳກັດໂດຍອີງຕາມງົບປະມານສຳລັບ API ທີ່ມີຄ່າໃຊ້ຈ່າຍ. NIST AI 600-1 ກໍໄດ້ລະບຸວ່າການໃຊ້ຊັບພະຍາກອນແບບບໍ່ຈຳກັດ (Unbounded Consumption) ເປັນລາຍການທີ່ມີຄວາມສ່ຽງ

ຕົວຢ່າງການນຳໄປໃຊ້ງານ: ການຂຽນໄຟລ໌ໃຫ້ຕັ້ງເປັນ "20 ຄັ້ງຕໍ່ Session, 5 ຄັ້ງຕໍ່ 1 ນາທີ", ສ່ວນ HTTP ພາຍນອກໃຫ້ຕັ້ງເປັນ "10 ຄັ້ງຕໍ່ Session, 2 ຄັ້ງຕໍ່ 1 ນາທີ" ໂດຍປັບປ່ຽນຕາມການຈັດປະເພດຄວາມສ່ຽງ. ເມື່ອເກີນຂີດຈຳກັດ ບໍ່ຄວນໃຫ້ເກີດ Silent failure ແຕ່ໃຫ້ບັນທຶກ Log ແບບມີໂຄງສ້າງ ແລະ ແຈ້ງເຕືອນຄູ່ກັນໄປ, ສ່ວນການເຮັດ Throttling ໃຫ້ບໍລິຫານຈັດການແບບລວມສູນທີ່ Middleware ຝັ່ງ Agent.

ສະຫຼຸບ: ການຈຳກັດຂອບເຂດ (Scope) ທີ່ໃຫ້ກັບ API Key ໃຫ້ໜ້ອຍທີ່ສຸດ ຄືວິທີການທີ່ໂດຍກົງທີ່ສຸດໃນການຫຼຸດຜ່ອນຂອບເຂດຄວາມເສຍຫາຍເມື່ອເກີດການລະເມີດຕໍ່ Agent.

ເຖິງແມ່ນວ່າຈະຈຳກັດ "ສິ່ງທີ່ສາມາດເອີ້ນໃຊ້ໄດ້" ດ້ວຍ Whitelist ແລ້ວ ແຕ່ຖ້າຕົວ API Key ເອງມີສິດທິຫຼາຍເກີນໄປ ຜົນກະທົບເມື່ອເກີດການລະເມີດກໍຈະກວ້າງຂວາງ. ການອອກແບບ Scope ຂອງ RFC 6749 (OAuth 2.0) ເປັນວິທີແກ້ໄຂບັນຫາທີ່ເປັນແບບຢ່າງ ເຊິ່ງຈະແບ່ງ Credential ທີ່ສົ່ງໃຫ້ Agent ອອກເປັນສ່ວນໆຕາມການນຳໃຊ້. ໃນພາກນີ້ ຈະອະທິບາຍເຖິງການອອກແບບຂອບເຂດຂອງການແຍກການອ່ານ/ການຂຽນ, ການແຍກ Tenant, ແລະ ການໃສ່ Secret.

ສະຫຼຸບ: API Key ຄວນຍຶດຖືຫຼັກການ "ອ່ານຢ່າງດຽວ (read-only)" ເປັນພື້ນຖານ, ສ່ວນສິດໃນການຂຽນໃຫ້ມອບໃຫ້ສະເພາະເຄື່ອງມືທີ່ສາມາດພິສູດຄວາມຈຳເປັນໄດ້ເທົ່ານັ້ນ.

ກໍລະນີການນຳໃຊ້ທີ່ສິ້ນສຸດລົງດ້ວຍການອ່ານພຽງຢ່າງດຽວນັ້ນ ມີຫຼາຍກວ່າທີ່ເຮົາຄິດໄວ້.

• ຄ່າເລີ່ມຕົ້ນແມ່ນ read-only: ວຽກງານຫຼັກສ່ວນໃຫຍ່ ເຊັ່ນ: ການເກັບກຳຂໍ້ມູນ, ການສະຫຼຸບເນື້ອຫາ, ແລະ ການສ້າງລາຍງານ ແມ່ນເຮັດວຽກໄດ້ດ້ວຍການອ່ານເທົ່ານັ້ນ.
• ການຂຽນຕ້ອງມີການພິສູດສະເພາະ: ຕ້ອງລະບຸ "ເຫດຜົນທີ່ເຄື່ອງມືນີ້ຈຳເປັນຕ້ອງມີສິດໃນການຂຽນ" ໃຫ້ຊັດເຈນ ແລະ ມອບສິດໃຫ້ຫຼັງຈາກຜ່ານການກວດສອບແລ້ວ.
• ຫຼຸດລະດັບຄວາມລະອຽດຂອງສິດ (Granularity): ຖ້າເປັນ GitHub API ໃຫ້ກຳນົດເປັນລາຍການປະຕິບັດງານ ເຊັ່ນ contents:read ຫຼື pull_requests:write ແທນທີ່ຈະໃຊ້ repo.

ພາຣາມິເຕີ scope ໃນ RFC 6749 (OAuth 2.0) ແມ່ນວິທີການມາດຕະຖານສຳລັບການແຍກສິດເຫຼົ່ານີ້, ແລະ NIST SP 800-53 AC-6 ກໍໄດ້ຮຽກຮ້ອງໃຫ້ຈຳກັດການເຂົ້າເຖິງໄວ້ສະເພາະການອະນຸມັດທີ່ລະບຸໄວ້ຢ່າງຊັດເຈນເທົ່ານັ້ນ.

ໃນດ້ານການປະຕິບັດງານ, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ມີ 3 ປະການຄື: ອອກ Key ຕາມຈຸດປະສົງການນຳໃຊ້ (ສຳລັບ Agent ໃຫ້ໃສ່ພຽງສິດອ່ານເປັນຄ່າເລີ່ມຕົ້ນ), Key ສຳລັບການຂຽນຈະຖືກອອກໃຫ້ຊົ່ວຄາວໃນຮູບແບບ Token ທີ່ມີອາຍຸສັ້ນຫຼັງຈາກໄດ້ຮັບການອະນຸມັດແບບ HITL, ແລະ ຕ້ອງມີການກວດສອບສິດທີ່ບໍ່ຈຳເປັນເພື່ອຍົກເລີກການນຳໃຊ້ທັນທີຢ່າງສະໝໍ່າສະເໝີ.

ສະຫຼຸບ: ໃນສະພາບແວດລ້ອມ Multi-tenant, ຂໍ້ມູນ API Key, Scope ແລະຂໍ້ມູນລະຫວ່າງ Tenant ຈະຕ້ອງຖືກແຍກອອກຈາກກັນຢ່າງເຂັ້ມງວດ ຖ້າບໍ່ດັ່ງນັ້ນຈະເກີດ "ການຮົ່ວໄຫຼຂ້າມລະບົບ" (Cross-tenant leakage).

ອຸບັດຕິເຫດສ່ວນໃຫຍ່ມີສາເຫດມາຈາກການນຳໃຊ້ Tenant Identifier ທີ່ບໍ່ໄດ້ຜູກມັດກັບ Credential ແລະມີການນຳໃຊ້ຊ້ຳ.

• ການອອກ API Key ແບບແຍກຕາມ Tenant: ຫ້າມໃຊ້ Key ຮ່ວມກັນ ແລະໃຫ້ອອກ API Key ແຍກຕ່າງຫາກ. ໃຫ້ເພີ່ມ tenant_id ເຂົ້າໃນ Metadata ແລະດຳເນີນການກວດສອບ
• ການຜູກມັດຂອບເຂດ (Scope) ເຂົ້າກັບ Tenant: ໃຫ້ລວມ Identifier ເຊັ່ນ tenant:{id}:read ເຂົ້າໃນ Scope ຂອງ OAuth 2.0 (RFC 6749, Section 3.3)
• ການບັງຄັບກວດສອບ Request Header: ກຳນົດໃຫ້ X-Tenant-ID ເປັນສິ່ງທີ່ຈຳເປັນ ແລະຕ້ອງກວດສອບໃຫ້ກົງກັບ Claim ຂອງ Token ຖ້າກວດສອບບໍ່ຜ່ານ ໃຫ້ປະຕິເສດທັນທີ
• ການແຍກ Namespace ຂອງ Storage ແລະ Cache: ໃຫ້ເພີ່ມ tenant_id prefix ເຂົ້າໃນ Vector DB ຫຼື Cache Key

ຈຳເປັນຕ້ອງມີການແຍກສ່ວນຢ່າງເປັນອິດສະຫຼະໃນແຕ່ລະ Layer ຂອງ API Gateway, Storage ແລະ Log. ໂດຍມີພື້ນຖານມາຈາກ "ການຢືນຢັນຕົວຕົນ ແລະ ການອະນຸຍາດສິດໃນແຕ່ລະຊັບພະຍາກອນ" ຕາມມາດຕະຖານ NIST SP 800-207 (Zero Trust).

ຄວາມລັບ (API Keys ຫຼື ຂໍ້ມູນການຢືນຢັນຕົວຕົນ) ບໍ່ຄວນຖືກສົ່ງໂດຍກົງເຂົ້າໄປໃນ context window ຂອງ Agent, ແຕ່ຄວນອອກແບບໂດຍການສີດ (Inject) ເຂົ້າໄປໃນຂອບເຂດທີ່ນ້ອຍທີ່ສຸດກ່ອນການປະຕິບັດງານທັນທີ.

ການຝັງ API Keys ຫຼື OAuth tokens ໄວ້ໃນ system prompt ມີຄວາມສ່ຽງທີ່ຈະເຮັດໃຫ້ຂໍ້ມູນຮົ່ວໄຫຼຜ່ານການເຮັດ Prompt Leaking ຫຼື Indirect Injection. ຄວາມລັບຄວນຖືກຈັດການເປັນ "ສິ່ງທີ່ Agent ບໍ່ຈຳເປັນຕ້ອງຮູ້".

ວິທີການສີດຂໍ້ມູນມີ 3 ແບບ: ການສີດຜ່ານ Environment Variables (ແນະນຳ) ແມ່ນວິທີການດຶງຂໍ້ມູນຈາກ AWS Secrets Manager ຫຼື HashiCorp Vault ໃນຂະນະທີ່ Container ເລີ່ມເຮັດວຽກ ແລະ ສົ່ງຜ່ານເປັນ Environment Variables, ເຊິ່ງຈະບໍ່ຖືກລວມຢູ່ໃນ LLM context. ວິທີ Sidecar ແມ່ນການໃຫ້ Tool execution wrapper ເປັນຜູ້ຖືຄວາມລັບໄວ້, ສ່ວນ LLM ຈະໄດ້ຮັບພຽງແຕ່ຊື່ Tool ແລະ Arguments ເທົ່ານັ້ນ. ການຂຽນໂດຍກົງໃນ System Prompt ແມ່ນວິທີທີ່ບໍ່ແນະນຳ.

ຈຸດສຳຄັນໃນການອອກແບບຂອບເຂດມີ 3 ປະການຄື: ການແບ່ງຂອບເຂດຕາມແຕ່ລະ Tool ແລະ ບໍ່ໃຊ້ Key ຊ້ຳກັນ, ການກຳນົດອາຍຸການໃຊ້ງານຂອງ Token ໃຫ້ສັ້ນລົງ ແລະ ອອກ Token ທີ່ມີອາຍຸສັ້ນ (ການໃຊ້ຮ່ວມກັບ RFC 6749 ຈະມີປະສິດທິພາບ), ແລະ ການລວມລະບົບການປິດບັງຄວາມລັບ (Secret Masking) ເມື່ອມີການສະແດງຜົນ Log ເຂົ້າໄປໃນຊັ້ນການສີດຂໍ້ມູນ (Injection layer).

ເຖິງວ່າຈະມີການຈຳກັດສິດທິພິເສດແລ້ວ ແຕ່ຄວາມສ່ຽງທີ່ Agent ຈະ "ຕັດສິນໃຈຜິດພາດພາຍໃນຂອບເຂດທີ່ໄດ້ຮັບອະນຸຍາດ" ກໍຍັງບໍ່ສາມາດຫຼຸດລົງເປັນສູນໄດ້. ສຳລັບການກະທຳທີ່ຍາກຈະຍົກເລີກໄດ້ ເຊັ່ນ: ການລຶບໄຟລ໌, ການສົ່ງຂໍ້ມູນອອກໄປພາຍນອກ, ຫຼື ການດຳເນີນການຊຳລະເງິນ, ທ່ານສາມາດຮັບປະກັນຄວາມປອດໄພຂັ້ນສຸດທ້າຍໄດ້ໂດຍການລວມເອົາຂະບວນການອະນຸມັດແບບ HITL (Human-in-the-loop) ເຂົ້າໄປ. ຕໍ່ໄປນີ້, ພວກເຮົາຈະອະທິບາຍຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດຢ່າງລະອຽດ ໂດຍເລີ່ມຈາກການອອກແບບຕົວກະຕຸ້ນການອະນຸມັດ (Approval Trigger), ການຈັດການກັບ UI ແລະ Time-out, ໄປຈົນເຖິງການສົ່ງຕໍ່ຂໍ້ມູນຕໍ່ໃຫ້ (Escalation) ໂດຍອັດຕະໂນມັດ.

ຖ້າຫາກໃຫ້ມະນຸດເປັນຜູ້ອະນຸມັດທຸກການກະທຳ ກໍຈະບໍ່ມີຄວາມໝາຍຂອງການເຮັດວຽກແບບອັດຕະໂນມັດ. ການອອກແບບຕົວກະຕຸ້ນ (Trigger) ຕາມລະດັບຄວາມສ່ຽງຈະເປັນຕົວຕັດສິນຄວາມສົມດຸນລະຫວ່າງຄວາມໄວ ແລະ ຄວາມປອດໄພ.

ການທີ່ "ທຸກການດຳເນີນການຕ້ອງຜ່ານການອະນຸມັດ" ຈະເຮັດໃຫ້ເກີດຄວາມເມື່ອຍລ້າໃນການອະນຸມັດ (approval fatigue) ເຊິ່ງຈະສົ່ງຜົນໃຫ້ຜູ້ຮັບຜິດຊອບກົດອະນຸມັດໂດຍບໍ່ໄດ້ກວດສອບເນື້ອໃນ.

ສຳລັບການຕັດສິນໃຈ, ການໃຫ້ຄະແນນ (Scoring) ໂດຍອີງໃສ່ 3 ແກນຫຼັກ ຄື: ຄວາມບໍ່ສາມາດກັບຄືນໄດ້ (Irreversibility), ຂອບເຂດຜົນກະທົບ (Impact scope), ແລະ ການຍົກລະດັບສິດທິ (Privilege escalation) ແມ່ນມີປະສິດທິພາບ. ຄວາມບໍ່ສາມາດກັບຄືນໄດ້ ໝາຍເຖິງການດຳເນີນການທີ່ຍາກຈະຍົກເລີກໄດ້ ເຊັ່ນ: ການລຶບຂໍ້ມູນ ຫຼື ການສົ່ງອີເມລ, ຂອບເຂດຜົນກະທົບ ໝາຍເຖິງການກວດສອບວ່າເປັນພຽງການບັນທຶກຂໍ້ມູນດຽວ ຫຼື ມີຜົນກະທົບຕໍ່ຫຼາຍ Tenant, ສ່ວນການຍົກລະດັບສິດທິ ໝາຍເຖິງການກວດສອບວ່າມີການເຂົ້າເຖິງນອກເໜືອຈາກຂອບເຂດປົກກະຕິຫຼືບໍ່. ຖ້າຫາກມີຂໍ້ໃດຂໍ້ໜຶ່ງສູງ, ໃຫ້ກະຕຸ້ນການອະນຸມັດແບບ HITL (Human-in-the-loop).

ຕົວຢ່າງທີ່ຊັດເຈນຄື: ການຮຽກໃຊ້ງານທີ່ທຳລາຍຂໍ້ມູນເຊັ່ນ DELETE /users/{id}, ການສົ່ງອີເມລຈຳນວນຫຼາຍກວ່າ 100 ສະບັບ, ຫຼື ການໃຊ້ OAuth token ນອກເໜືອຈາກຂອບເຂດທີ່ອ່ານໄດ້ຢ່າງດຽວ (read-only) ແມ່ນຈຳເປັນຕ້ອງໄດ້ຮັບການອະນຸມັດ. ຖ້າມີການຮຽກໃຊ້ API ດຽວກັນຕິດຕໍ່ກັນຫຼາຍກວ່າ 10 ຄັ້ງ ໃຫ້ຕັ້ງຄ່າ Flag ອັດຕະໂນມັດ.

NIST SP 800-53 ຂໍ້ AC-6(1) ແມ່ນພື້ນຖານຂອງການອະນຸມັດໂດຍມະນຸດ. ເງື່ອນໄຂຂອງຕົວກະຕຸ້ນ (Trigger) ຄວນຖືກແຍກອອກໄປໄວ້ພາຍນອກ ເຊັ່ນໃນໄຟລ໌ YAML.

ສະຫຼຸບ: UI ການອະນຸມັດຕ້ອງເຮັດໃຫ້ "ຈະອະນຸມັດຫຍັງ ແລະ ເພື່ອຫຍັງ" ຈົບລົງໃນໜ້າຈໍດຽວ, ແລະ ເວລາໝົດກຳນົດ (Timeout) ຈະຕ້ອງຕັ້ງຄ່າເປັນການປະຕິເສດສະເໝີ.

ອົງປະກອບທີ່ຕ້ອງມີໃນໜ້າຈໍການອະນຸມັດມີ 4 ຢ່າງ:

• ສະຫຼຸບການກະທຳ: ລະບຸປະທານ, ຈຸດປະສົງ ແລະ ເປົ້າໝາຍໃຫ້ຊັດເຈນ (ຕົວຢ່າງ: "ສົ່ງຂໍ້ມູນຄຳສັ່ງຊື້ຂອງລູກຄ້າ ID ×××× ໄປຍັງ API ພາຍນອກ")
• ຂອບເຂດຜົນກະທົບ: ແຍກສີລະຫວ່າງການອ່ານ/ການຂຽນ/ການລຶບ (ການດຳເນີນການທີ່ສົ່ງຜົນເສຍຫາຍໃຫ້ໃຊ້ປ້າຍສີແດງ)
• ແຫຼ່ງທີ່ມາຂອງຄຳຮ້ອງຂໍ: Trace ID ທີ່ລະບຸວ່າ Agent ຫຼື Task ໃດເປັນຈຸດເລີ່ມຕົ້ນ
• ວັນໝົດອາຍຸ: ສະແດງເວລາທີ່ເຫຼືອຂອງຊ່ອງທາງການອະນຸມັດໃຫ້ເຫັນຢ່າງຊັດເຈນ

ຫຼັກການຂອງ Timeout ແມ່ນ "ປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ (Default Deny)".

ເຖິງຈະມີການໃຊ້ງານຮ່ວມກັນລະຫວ່າງການແຈ້ງເຕືອນໃນມືຖື ແລະ Web UI, ແຕ່ເນື່ອງຈາກການແຈ້ງເຕືອນຫຼາຍເກີນໄປຈະເຮັດໃຫ້ເກີດ "ຄວາມເມື່ອຍລ້າຈາກການແຈ້ງເຕືອນ (Notification Fatigue)" ຈົນເຮັດໃຫ້ເບິ່ງຂ້າມໄປໄດ້, ສະນັ້ນຈຶ່ງຄວນຈຳກັດໄວ້ສະເພາະການກະທຳທີ່ມີຄວາມສ່ຽງສູງເທົ່ານັ້ນ.

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

ເງື່ອນໄຂໃນການກະຕຸ້ນ (Trigger) ການຍົກລະດັບອັດຕະໂນມັດມີ 3 ຢ່າງດັ່ງນີ້:

• ເກີນກຳນົດເວລາ (Timeout): ໃນກໍລະນີທີ່ຜູ້ອະນຸມັດຂັ້ນຕົ້ນບໍ່ຕອບສະໜອງພາຍໃນເວລາທີ່ກຳນົດ (ຕົວຢ່າງ: 15 ນາທີ), ລະບົບຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ບົດບາດ (Role) ທີ່ສູງກວ່າໂດຍອັດຕະໂນມັດ.
• ຄະແນນຄວາມສ່ຽງເພີ່ມຂຶ້ນ: ໃນກໍລະນີທີ່ຄະແນນຄວາມສ່ຽງກ່ອນການປະຕິບັດງານເກີນຄ່າທີ່ກຳນົດໄວ້ (Threshold), ລະບົບຈະຮຽກຮ້ອງສິດການອະນຸມັດທີ່ສູງກວ່າ.
• ຄວາມຜິດພາດຕໍ່ເນື່ອງ: ຖ້າຫາກເກີດການປະຕິເສດການອະນຸມັດ 2 ຄັ້ງຂຶ້ນໄປພາຍໃນເຊດຊັນດຽວກັນ, ລະບົບຈະຢຸດເຊດຊັນນັ້ນໄວ້ຊົ່ວຄາວ ແລະ ບັນທຶກເປັນອຸບັດຕິເຫດ (Incident).

ປາຍທາງຂອງການຍົກລະດັບຈະຖືກຈັດການຜ່ານໄຟລ໌ການຕັ້ງຄ່າ (Configuration file) ໂດຍກຳນົດໄວ້ສູງສຸດ 3 ຂັ້ນຕອນ ເຊັ່ນ: "ຜູ້ອະນຸມັດຂັ້ນຕົ້ນ → ຫົວໜ້າທີມ → ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພ". ຖ້າຍັງບໍ່ໄດ້ຮັບການອະນຸມັດໃນຂັ້ນຕອນສຸດທ້າຍ, ລະບົບຈະບລັອກການໃຊ້ງານເຄື່ອງມືດັ່ງກ່າວໂດຍອັດຕະໂນມັດ.

ເມື່ອເກີດເຫດການ, ລະບົບຈະບັນທຶກເຫດຜົນ, ເວລາ (Timestamp) ແລະ ການກະທຳທີ່ກ່ຽວຂ້ອງລົງໃນບັນທຶກທີ່ມີໂຄງສ້າງ (Structured log) ເພື່ອຮັບປະກັນຫຼັກຖານການກວດສອບ (Audit trail) ຕາມທີ່ NIST SP 800-53 ຂອງ AU-2 ໄດ້ກຳນົດໄວ້. ປະຫວັດເຫຼົ່ານີ້ຈະຖືກສະສົມໄວ້ເປັນຂໍ້ມູນ ເພື່ອນຳໄປໃຊ້ປະໂຫຍດໃນການທົບທວນການອອກແບບສິດທິໃນອະນາຄົດ.

ເຖິງແມ່ນວ່າຈະມີການອອກແບບ Tool Whitelist ຫຼື API Scope ຢ່າງລະອຽດແລ້ວ ແຕ່ຖ້າບໍ່ມີການບັນທຶກ ແລະ ຕິດຕາມການຮຽກໃຊ້ງານຕົວຈິງ ກໍຈະບໍ່ສາມາດກວດພົບການນຳໃຊ້ທີ່ຜິດປົກກະຕິໄດ້. ການອອກແບບສິດທິການເຂົ້າເຖິງບໍ່ແມ່ນ "ອອກແບບແລ້ວຈົບໄປ" ແຕ່ຈະສາມາດໃຊ້ງານໄດ້ຢ່າງມີປະສິດທິພາບກໍຕໍ່ເມື່ອມີການຕິດຕາມ Log ການເຮັດວຽກຢ່າງຕໍ່ເນື່ອງເທົ່ານັ້ນ. NIST SP 800-53 ຂອງ AU-2 ແລະ AU-6 ຍັງໄດ້ລະບຸຢ່າງຈະແຈ້ງວ່າ ການກຳນົດເຫດການກວດສອບ (Audit Event) ແລະ ການທົບທວນຄືນຢ່າງສະໝໍ່າສະເໝີ ແມ່ນຂໍ້ກຳນົດໃນການຄວບຄຸມ. ໃນພາກນີ້ ຈະອະທິບາຍຕາມລຳດັບກ່ຽວກັບການອອກແບບ Schema ຂອງ Structured Log, ກົດເກນການກວດພົບການໃຊ້ສິດທິເກີນຂອບເຂດ ແລະ ການນຳໃຊ້ Kill switch.

ຟິວຂອງບັນທຶກການກວດສອບ (Audit log) ມີດັ່ງນີ້ (ສອດຄ່ອງກັບ NIST SP 800-53 AU-2/AU-6):

• timestamp: ປະທັບເວລາ UTC ໃນຮູບແບບ ISO 8601
• agent_id: ຕົວລະບຸເອກະລັກຂອງອິນສະແຕນສ໌ຂອງເອເຈນ (Agent instance)
• tool_name: ຊື່ຂອງເຄື່ອງມື ຫຼື API endpoint ທີ່ຖືກປະຕິບັດ
• action_type: ການຈຳແນກລະຫວ່າງ read / write / delete / invoke
• requested_scope: ຂອບເຂດທີ່ຮ້ອງຂໍ
• granted_scope: ຂອບເຂດທີ່ໄດ້ຮັບການອະນຸມັດຕົວຈິງ
• resource_id: ຕົວລະບຸຂອງຊັບພະຍາກອນທີ່ຖືກດຳເນີນການ
• result_status: success / denied / error
• session_id: ຄີສຳລັບເຊື່ອມຕໍ່ກັບຂະບວນການອະນຸມັດແບບ HITL

ທ່ານສາມາດກວດພົບສັນຍານຂອງການລະເມີດສິດທິໂດຍອັດຕະໂນມັດຈາກຄວາມແຕກຕ່າງລະຫວ່າງ requested_scope ແລະ granted_scope. ແນະນຳໃຫ້ໃຊ້ຮູບແບບຜົນລວມເປັນ JSON Lines ແລະ ເມື່ອບັນທຶກຂໍ້ມູນ ໃຫ້ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ບ່ອນຈັດເກັບຂໍ້ມູນແບບ Write-once (ຂຽນໄດ້ຄັ້ງດຽວ).

ສະຫຼຸບ: ການກວດຈັບການລະເມີດສິດທິພິເສດແມ່ນມີປະສິດທິຜົນເມື່ອໃຊ້ການປະສົມປະສານລະຫວ່າງກົດເກນ (Rule-based) ແລະ ການກວດຈັບຄວາມຜິດປົກກະຕິທາງສະຖິຕິ. ການໃຊ້ພຽງວິທີດຽວອາດເຮັດໃຫ້ເກີດການກວດຈັບພາດໄດ້ງ່າຍ ຈຶ່ງຈຳເປັນຕ້ອງມີການຕິດຕາມກວດກາຫຼາຍຊັ້ນ.

ຮູບແບບຫຼັກຂອງການກວດຈັບແບບກົດເກນ (Rule-based detection)

• ການຮ້ອງຂໍ API ນອກຂອບເຂດ (Out-of-scope API calls): ສະກັດກັ້ນ ຫຼື ແຈ້ງເຕືອນທັນທີເມື່ອມີການຮ້ອງຂໍໄປຍັງ Endpoint ທີ່ບໍ່ຢູ່ໃນບັນຊີຂາວ (Whitelist).
• ການເກີນອັດຕາທີ່ກຳນົດ (Rate limit exceeded): ຕິດທຸງທັນທີຫາກຈຳນວນການຮ້ອງຂໍຕໍ່ຫົວໜ່ວຍເວລາເກີນຄ່າທີ່ກຳນົດໄວ້ (Threshold).
• ຄວາມພະຍາຍາມຍົກລະດັບສິດທິ (Privilege escalation attempts): ກວດຈັບດ້ວຍການຈັບຄູ່ຮູບແບບ (Pattern matching) ເມື່ອມີການຂຽນຂໍ້ມູນດ້ວຍ Key ປະເພດ read-only ຫຼື ການຮ້ອງຂໍໄປຍັງ API ຂອງຜູ້ເບິ່ງແຍງລະບົບ (Administrator API).
• ການເຂົ້າເຖິງໃນຊ່ວງເວລາທີ່ຜິດປົກກະຕິ: ຈັດປະເພດການປະຕິບັດງານນອກເວລາເຮັດວຽກປົກກະຕິໃຫ້ເປັນບັນທຶກ (Log) ທີ່ຕ້ອງເຝົ້າລະວັງ.

ການກວດຈັບຄວາມຜິດປົກກະຕິທາງສະຖິຕິ (Statistical anomaly detection)

ການໃຊ້ພຽງແຕ່ກົດເກນອາດເຮັດໃຫ້ຍາກໃນການກວດຈັບກໍລະນີທີ່ "ເບິ່ງຄືວ່າປົກກະຕິ ແຕ່ມີປະລິມານຜິດປົກກະຕິ". ໂດຍການຄຳນວນຄ່າພື້ນຖານ (Baseline) ຈາກປະຫວັດໃນອະດີດ ແລະ ສົ່ງສັນຍານເຕືອນຫາກຄ່າດັ່ງກ່າວເກີນຄ່າຜັນຜວນມາດຕະຖານ (Standard deviation) ຕາມທີ່ກຳນົດໄວ້ (NIST SP 800-53 AU-6 ຮຽກຮ້ອງໃຫ້ມີການວິເຄາະຢ່າງຕໍ່ເນື່ອງ). ຫາກຄວາມຖືກຕ້ອງຕ່ຳເກີນໄປ ທີມງານປະຕິບັດການອາດຈະເລີ່ມລະເລີຍການແຈ້ງເຕືອນ ດັ່ງນັ້ນໃນໄລຍະເລີ່ມຕົ້ນຄວນຕັ້ງຄ່າເປັນການແຈ້ງເຕືອນເທົ່ານັ້ນເພື່ອວັດແທກອັດຕາການກວດຈັບທີ່ຜິດພາດ (False positive) ກ່ອນທີ່ຈະປ່ຽນໄປສູ່ການສະກັດກັ້ນ (Block).

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

ການຍົກເລີກ API key ພຽງຢ່າງດຽວຈະເຮັດໃຫ້ການຮຽກໃຊ້ທີ່ກຳລັງດຳເນີນຢູ່ສຳເລັດຜົນ ເຊິ່ງອາດສົ່ງຜົນໃຫ້ເກີດການຂຽນຂໍ້ມູນທີ່ບໍ່ໄດ້ຕັ້ງໃຈ ຫຼື ການສົ່ງຂໍ້ມູນອອກໄປພາຍນອກ. kill switch ຄວນອອກແບບເປັນ 3 ຊັ້ນ:

• ຊັ້ນທີ 1 — ການຢຸດເຊດຊັນ (Session): ໃຊ້ທຸງ (Flag) ຢຸດການຮຽກໃຊ້ໃໝ່ ແລະ ສົ່ງສັນຍານຍົກເລີກທັນທີໃຫ້ກັບການຮຽກໃຊ້ທີ່ກຳລັງດຳເນີນຢູ່.
• ຊັ້ນທີ 2 — ການຍົກເລີກການຢືນຢັນຕົວຕົນ: ເຮັດການໝູນວຽນ (Rotation) ຫຼື ຍົກເລີກ OAuth token ແລະ API key (ຕາມຂອບເຂດຂອງ RFC 6749).
• ຊັ້ນທີ 3 — ການຕັດການເຊື່ອມຕໍ່ເຄືອຂ່າຍ: ປະຕິເສດການສົ່ງຂໍ້ມູນທັນທີດ້ວຍນະໂຍບາຍ ZTNA.

ຄວນອອກແບບໃຫ້ເປັນການດຳເນີນງານແບບ Idempotent ເພື່ອບໍ່ໃຫ້ເກີດຜົນຂ້າງຄຽງເຖິງແມ່ນວ່າຈະມີການເປີດໃຊ້ງານຊ້ຳສອງ, ແລະ ຫຼັງຈາກຢຸດແລ້ວ ໃຫ້ປ່ຽນໂໝດການເກັບຮັກສາ Log ໂດຍອີງຕາມມາດຕະຖານ NIST SP 800-53 AU-6. ການເປີດໃຊ້ງານອັດຕະໂນມັດຈະໃຊ້ການກວດພົບການລະເມີດສິດທິ ຫຼື HITL timeout ເປັນຕົວຊີ້ວັດ (Trigger), ແລະ ຄວນກຽມ Endpoint ສຳລັບການເປີດໃຊ້ງານດ້ວຍຕົນເອງແຍກຕ່າງຫາກໄວ້ດ້ວຍ.

ສະຫຼຸບ: ຄວາມຜິດພາດສ່ວນໃຫຍ່ເກີດຈາກການຕັດສິນໃຈໃນເບື້ອງຕົ້ນທີ່ວ່າ "ໃຫ້ສິດກວ້າງໆໄວ້ກ່ອນ".

ຄວາມຜິດພາດ 1: ອະນຸຍາດໃຫ້ໃຊ້ທຸກເຄື່ອງມືພ້ອມກັນ ກໍລະນີທີ່ນຳເອົາ PoC ໄປໃຊ້ໃນລະບົບຈິງໂດຍບໍ່ມີການປັບປ່ຽນ. ຄວນສ້າງຂະບວນການໃນການຈຳກັດສິດໃຫ້ລະອຽດກ່ອນການນຳໃຊ້ຈິງ.

ຄວາມຜິດພາດ 2: ບໍ່ແຍກ read/write ເພື່ອປ້ອງກັນຄວາມເສຍຫາຍທີ່ອາດຈະຂະຫຍາຍວົງກວ້າງເມື່ອເກີດການໂຈມຕີແບບ Prompt Injection, ຄວນຍຶດຖືຫຼັກການໃຊ້ read-only key ເປັນຫຼັກ.

ຄວາມຜິດພາດ 3: ການຂ້າມຂັ້ນຕອນການອະນຸມັດແບບ HITL ການຈັດການຂໍ້ຍົກເວັ້ນ ຫຼື ການລອງໃໝ່ (Retry) ອາດເຮັດໃຫ້ຂັ້ນຕອນການອະນຸມັດຖືກຂ້າມໄປ. ຄວນວາງລະບົບກວດສອບການອະນຸມັດໄວ້ນອກເໜືອຈາກການຈັດການຂໍ້ຍົກເວັ້ນ.

ຄວາມຜິດພາດ 4: ການເກັບບັນທຶກ Audit log ພຽງຢ່າງດຽວ ຖ້າບໍ່ມີກົດລະບຽບໃນການແຈ້ງເຕືອນ (Alert rule), ຄວາມຜິດປົກກະຕິຕ່າງໆກໍຈະຖືກລະເລີຍ. ຄວນຈັດຕັ້ງປະຕິບັດການເກັບບັນທຶກຂໍ້ມູນຄູ່ກັບກົດລະບຽບໃນການກວດຈັບ.

ຄວາມຜິດພາດ 5: ການຝັງ Secret ໄວ້ໃນໂຄ້ດ (Hardcode) ຄວນນຳໃຊ້ບໍລິການຈັດການ Secret ຈາກພາຍນອກ ແລະ ປະສົມປະສານກັບການສະແກນອັດຕະໂນມັດໃນຂະນະກວດສອບໂຄ້ດ (Code review).

ສິ່ງເຫຼົ່ານີ້ສາມາດຈັດການໄດ້ຢ່າງເປັນລະບົບ ເມື່ອນຳໄປປະສົມປະສານກັບແນວທາງ "ການປ້ອງກັນດ້ວຍໂຄງສ້າງ" ຈາກບົດຄວາມ Harness Engineering ແມ່ນຫຍັງ? ວິທີການອອກແບບເພື່ອປ້ອງກັນຄວາມຜິດພາດຂອງ AI Agent ດ້ວຍໂຄງສ້າງ.

Q1. ການຈຳກັດສິດທິພິເສດເກີນໄປຈະເຮັດໃຫ້ຟັງຊັນການເຮັດວຽກຖືກຈຳກັດນຳຫຼືບໍ່? ການອອກແບບຂອບເຂດ (Scope) ທີ່ເໝາະສົມສາມາດເຮັດໃຫ້ຟັງຊັນການເຮັດວຽກ ແລະ ຄວາມປອດໄພໄປຄຽງຄູ່ກັນໄດ້. ການ "ເລີ່ມຕົ້ນຈາກວົງແຄບແລ້ວຂະຫຍາຍອອກຕາມຄວາມຈຳເປັນ" ຈະຊ່ວຍຫຼຸດຄວາມສ່ຽງໃນການພົບເຫັນບັນຫາໃນພາຍຫຼັງໄດ້.

Q2. ການໃຊ້ HITL ຈະເຮັດໃຫ້ຄວາມໄວໃນການປະມວນຜົນຫຼຸດລົງຫຼືບໍ່? ຖ້າຈຳກັດໄວ້ສະເພາະການກະທຳທີ່ມີຄວາມສ່ຽງສູງ, ການປະຕິບັດງານທີ່ມີຄວາມສ່ຽງຕ່ຳໃນຊີວິດປະຈຳວັນກໍສາມາດປະມວນຜົນແບບອັດຕະໂນມັດໄດ້. ນອກຈາກນີ້, ການໃຊ້ Timeout ແລະ ການຍົກລະດັບອັດຕະໂນມັດ (Automatic Escalation) ຍັງສາມາດຫຼຸດຜ່ອນຄວາມຊັກຊ້າໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດໄດ້.

Q3. ບັນທຶກການກວດສອບ (Audit Log) ຄວນເກັບຮັກສາໄວ້ດົນປານໃດ? ມາດຕະຖານ NIST SP 800-53 ຂໍ້ AU-2 ແລະ AU-6 ກຳນົດໃຫ້ມີການຕັ້ງຄ່າໄລຍະເວລາການເກັບຮັກສາຕາມໂປຣໄຟລ໌ຄວາມສ່ຽງຂອງອົງກອນ. ເຖິງແມ່ນວ່າກົດລະບຽບຂອງແຕ່ລະອຸດສາຫະກຳຈະມີຄວາມສຳຄັນກວ່າ, ແຕ່ແນະນຳໃຫ້ເກັບຮັກສາໄວ້ຢ່າງໜ້ອຍ 90 ວັນຂຶ້ນໄປ.

Q4. ໃນໂຄງສ້າງ Multi-agent, ການອອກແບບສິດທິຈະປ່ຽນແປງໄປແນວໃດ? ຫຼັກການພື້ນຖານຄື "ການແບ່ງສິດທິໃຫ້" (Delegated Authority) ໂດຍການມອບສະເພາະສິດທິທີ່ຈຳເປັນສຳລັບແຕ່ລະວຽກເທົ່ານັ້ນ, ແທນທີ່ຈະມອບສິດທິທັງໝົດຂອງ Parent Agent ໃຫ້. ກະລຸນາອ້າງອີງເພີ່ມເຕີມທີ່ Multi-agent AI ແມ່ນຫຍັງ? ຈາກຮູບແບບການອອກແບບໄປສູ່ຈຸດສຳຄັນໃນການນຳໄປໃຊ້ງານ.

ສະຫຼຸບ: ອອກແບບໂດຍໃຊ້ເກນ "ສາມາດເຮັດວຽກໄດ້ຫຼືບໍ່" ແຕ່ໃຫ້ຍຶດຖື "ສາມາດເຮັດວຽກໄດ້ຢ່າງປອດໄພຫຼືບໍ່" ເປັນຫຼັກ.

ທົບທວນຈຸດສຳຄັນຂອງແຕ່ລະຂັ້ນຕອນ:

• ເງື່ອນໄຂເບື້ອງຕົ້ນ: ລະບຸຄວາມຮັບຜິດຊອບ ແລະ ຂອບເຂດໃຫ້ຊັດເຈນ, ພ້ອມທັງຈັດປະເພດຄວາມສ່ຽງຂອງເຄື່ອງມື ແລະ API
• ຂັ້ນຕອນທີ 1: ກຳນົດຊຸດເຄື່ອງມືທີ່ອະນຸຍາດໃຫ້ໃຊ້ໄດ້ໜ້ອຍທີ່ສຸດແບບ Static, ໂດຍປະສົມປະສານການຈຳກັດອັດຕາ (Rate limit) ແລະ ການຈຳກັດຈຳນວນຄັ້ງ
• ຂັ້ນຕອນທີ 2: ໃຫ້ຄວາມສຳຄັນກັບຄີ (Key) ປະເພດອ່ານຢ່າງດຽວ (Read-only), ພ້ອມທັງກຳນົດຂອບເຂດການແຍກ Tenant ແລະ ການໃສ່ Secret ໃຫ້ຊັດເຈນ
• ຂັ້ນຕອນທີ 3: ກຳນົດໃຫ້ມີການອະນຸມັດຈາກມະນຸດສຳລັບການກະທຳທີ່ມີຄວາມສ່ຽງສູງ, ພ້ອມທັງລວມເອົາການກຳນົດເວລາ (Timeout) ແລະ ການຍົກລະດັບອັດຕະໂນມັດ (Auto-escalation) ເຂົ້າໄປນຳ
• ຂັ້ນຕອນທີ 4: ກວດຈັບການລະເມີດສິດທິດ້ວຍບັນທຶກທີ່ມີໂຄງສ້າງ (Structured log) ແລະ ຄວບຄຸມສະຖານະການດ້ວຍ Kill switch

ໃນເບື້ອງຕົ້ນ, ວິທີການທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດຄືການເລີ່ມຕົ້ນດ້ວຍການນຳໃຊ້ Whitelist ແລະ ຂອບເຂດການອ່ານຢ່າງດຽວໃນ PoC, ໂດຍໃຊ້ການຕັ້ງຄ່າຂັ້ນຕອນຕ່ຳສຸດທີ່ເພີ່ມ HITL (Human-in-the-loop) ເຂົ້າໄປ. ສຳລັບການອອກແບບຄວາມປອດໄພຂອງ AI Agent ໂດຍລວມ, ກະລຸນາອ້າງອີງຈາກ AI Governance ແມ່ນຫຍັງ? ຄູ່ມືການປະຕິບັດງານຕັ້ງແຕ່ການຮອງຮັບ EU AI Act ຈົນເຖິງການຈັດຕັ້ງກົດລະບຽບພາຍໃນບໍລິສັດ ເພີ່ມເຕີມ.