Architecture Review ที่หยุดอยู่หน้าเส้นลูกศร
“Agent ใช้ตัวตนของใครเขียนเข้า ERP?”
บนจอมีแผนภาพที่ดูเรียบร้อย: อีเมล → AI Agent → ERP ลูกศรสามเส้นทำให้โครงการเหมือนเหลืองานเชื่อมระบบอีกไม่มาก
หัวหน้าความปลอดภัยถามว่า “กล่อง Agent นี้ล็อกอินเป็นใคร อ่านลูกค้าทั้งหมดได้ไหม เขียน Order จริงหรือแค่ Draft แล้วถ้าพนักงานคนหนึ่งไม่มีสิทธิ์เห็นเครดิต Agent ที่ทำงานแทนเขาควรเห็นหรือเปล่า?”
ห้องเงียบลง ไม่ใช่เพราะคำถามซับซ้อน แต่เพราะแผนภาพบอกว่าเชื่อมอะไรกับอะไร โดยยังไม่บอกว่า ใครทำอะไรกับข้อมูลชิ้นไหน ภายใต้สิทธิ์ใด
Architecture ของ Agent ที่ใช้งานได้จริงจึงไม่เริ่มจากการวางโมเดลไว้กลางภาพ แต่เริ่มจาก Trust Boundary, Identity และผลกระทบของการกระทำ แล้วค่อยเลือกเส้นทางเชื่อมต่อที่เล็กที่สุดซึ่งทำให้งานเดินได้
Architecture สำหรับ Agent ไม่ควรเริ่มจากกล่องโมเดล แต่เริ่มจาก Trust Boundary: ใครเรียกใช้ได้ ข้อมูลเดินทางไปไหน ระบบใดอนุญาตให้อ่านหรือเขียน และจะรู้ได้อย่างไรว่าเกิดอะไรขึ้น
แผนภาพที่ตอบคำถามตอนเกิดเหตุ
ลูกศรเส้นเดียวอาจซ่อนสิทธิ์สามระดับและความล้มเหลวห้าชนิด
คำว่า “เชื่อม ERP” อาจหมายถึงอ่าน Product Master, ค้นสถานะเครดิต, สร้าง Draft Order, ยืนยัน Order หรือยกเลิกรายการ แต่ละการกระทำมีผลกระทบและผู้รับผิดชอบต่างกัน หากรวมไว้เป็น Tool ชื่อกว้าง ๆ ว่า use_erp เราจะกำหนดสิทธิ์ ทดสอบ และสอบสวนเหตุการณ์ได้ยาก
NIST Zero Trust วางหลักว่าควรปกป้องทรัพยากร ไม่ใช่เชื่อใจเพียงเพราะผู้เรียกอยู่ “ในเครือข่ายบริษัท” [1] เมื่อนำมาใช้กับ Agent ความหมายตรงไปตรงมาคือ ทุกการเรียก Tool ต้องมีตัวตน ขอบเขต และเหตุผลที่ตรวจได้ ไม่ให้ Agent ได้สิทธิ์กว้างเพียงเพราะมันเป็นระบบภายใน
OWASP เรียกความเสี่ยงจากความสามารถ สิทธิ์ หรือความเป็นอิสระที่มากเกินจำเป็นว่า Excessive Agency และเสนอให้ลดสิทธิ์ ลดขอบเขตความสามารถ และเพิ่มการอนุมัติเมื่อผลกระทบสูง [2] OpenAI ก็เสนอให้ประเมิน Tool ตาม Read/Write, ความย้อนกลับได้, สิทธิ์บัญชี และผลกระทบทางการเงิน [3]
นี่ทำให้คำถาม Architecture เปลี่ยนจาก “ต่อ API ได้ไหม” เป็น “การกระทำต่ำสุดที่ Agent ต้องทำคืออะไร ใครอนุญาต และถ้าคำตอบจากระบบหายระหว่างทาง เราจะรู้สถานะจริงจากที่ใด”
สี่เสาหลักก่อนเลือกเทคโนโลยี
ออกแบบจากสิทธิ์และความจริงของธุรกิจ
IDENTITY
Agent ต้องมีตัวตนที่แยกจากคนและแยกตามหน้าที่
การใช้บัญชี Admin ร่วมทำให้ Prototype เดินเร็ว แต่เมื่อเกิดเหตุ เราไม่รู้ว่าใครหรือ Workflow ใดเป็นผู้กระทำ ตัวตนเฉพาะช่วยกำหนดสิทธิ์ หมดอายุ เพิกถอน และตรวจ Log ได้โดยไม่กระทบบัญชีอื่น แนวทางของ Microsoft สำหรับ Agent แนะนำให้มอง Agent เป็น Identity ชั้นหนึ่ง ใช้ RBAC แบบ Least Privilege, Allowlist การกระทำ และรองรับการเพิกถอน [4]
PERMISSION
แยก Read, Draft และ Commit ออกจากกัน
สิทธิ์อ่านข้อมูลสินค้าไม่ควรพ่วงสิทธิ์แก้ราคา สิทธิ์สร้าง Draft ไม่ควรพ่วงสิทธิ์ยืนยัน Order การแบ่งการกระทำให้เล็กช่วยจำกัด Blast Radius และทำให้ Human Approval มีความหมาย เพราะคนอนุมัติการเปลี่ยนสถานะที่ระบุได้จริง
SYSTEM OF RECORD
โมเดลเสนอได้ แต่ระบบหลักต้องเป็นแหล่งความจริง
Agent อาจสรุปว่า SKU มีสต็อก แต่ Inventory System เป็นผู้ยืนยันจำนวน ณ เวลาทำรายการ ผลลัพธ์ที่สำคัญต้องมี ID และสถานะในระบบหลัก ไม่ปล่อยให้ “คำตอบในหน้าต่างสนทนา” กลายเป็นหลักฐานเพียงชิ้นเดียว
OBSERVABILITY
เก็บร่องรอยให้ตอบว่าเกิดอะไร ไม่ใช่เก็บทุกอย่าง
Log ที่ดีเชื่อม Run ID, ผู้ร้องขอ, Tool, พารามิเตอร์ที่ไม่อ่อนไหว, ผลลัพธ์, Approval และ Business Object ID เข้าด้วยกัน ส่วนข้อมูลส่วนบุคคลหรือ Secret ไม่ควรถูกเทลง Log โดยไม่มีเหตุผลและระยะเวลาเก็บ
จากสิทธิ์ต่ำไปสูง
ให้ Agent ไต่บันได ไม่ใช่มอบกุญแจทั้งตึก
บันไดสิทธิ์ของ Order Agent
บันไดนี้ไม่ได้หมายความว่าทุกระบบต้องมีห้าชั้นพอดี จุดสำคัญคือแยกการกระทำที่ย้อนกลับง่ายออกจากการกระทำที่สร้างภาระจริง เช่น ส่งอีเมลภายนอก ตัดสต็อก อนุมัติเครดิต หรือโอนเงิน หากการกระทำย้อนกลับยาก มีผลทางกฎหมายหรือการเงินสูง ให้ใช้ Identity และ Approval ที่เข้มขึ้น
Trust Boundary คือเส้นที่คำตอบต้องเปลี่ยนจาก “เชื่อ” เป็น “ตรวจ”
เมื่อข้อมูลข้ามจากอีเมลภายนอกเข้าระบบองค์กร เราต้องถือว่าเนื้อหาอาจผิดหรือเป็นอันตราย เมื่อ Agent ขอเรียก Tool เราต้องตรวจสิทธิ์และ Schema เมื่อข้อมูลจะถูกเขียน ERP เราต้องตรวจ Business Rule อีกครั้ง และเมื่อข้อมูลไปยังผู้ให้บริการภายนอก ต้องรู้ว่า Field ใดออกไป วัตถุประสงค์อะไร และเก็บนานเท่าไร
ตรวจอะไร?
Identity, Authorization, Data Classification, Schema, Rate Limit และ Approval
ยืนยันอะไร?
Business Object ID, สถานะจริง, เวลา, ผู้กระทำ และร่องรอยที่ย้อนตรวจได้
การทำแผนภาพจึงควรใส่หมายเลข Data Flow และเขียนกำกับแต่ละเส้นว่าใครเป็นผู้เรียก ใช้ Credential ใด ส่ง Field อะไร อ่านหรือเขียน และเกิดอะไรเมื่อปลายทางไม่ตอบ ไม่ต้องเริ่มจากสัญลักษณ์ Architecture ที่สมบูรณ์แบบ เริ่มจากคำถามที่ทีม Security, Data Owner และ Process Owner ใช้คุยกันรู้เรื่อง
กรณีศึกษาต่อเนื่อง · สยามโฟลว์
วาดเส้นทางข้อมูลใหม่โดยให้ ERP ถือความจริง
จากบทก่อน ทีมรู้แล้วว่า Agent ควรเตรียม Draft Order และส่ง Exception ให้คน บทนี้จึงแปลงเส้นทางงานนั้นเป็น Integration Map โดยไม่เพิ่มระบบเกินจำเป็น
Integration Map ฉบับที่ตอบเรื่องสิทธิ์ได้
สแกนและกำหนด Message ID
Run ID + Stop Conditions
Commit โดยพนักงาน
ขอบเขตที่ทีมตกลงกัน
- Agent ใช้ Service Identity เฉพาะ Order Intake ไม่สวมบัญชีผู้ใช้และไม่ใช้บัญชี Administrator
- Customer, Product, Credit และ Stock ถูกเรียกผ่าน Read Service ที่คืนเฉพาะ Field จำเป็น
- การสร้างรายการใช้คำสั่ง Create Draft ซึ่งไม่จองสต็อก ไม่ส่งอีเมล และไม่ Commit Order
- ผู้อนุมัติเปิด Draft ใน ERP ด้วยบัญชีของตน ระบบจึงใช้สิทธิ์และวงเงินตามบทบาทจริง
- ทุก Run เชื่อม Message ID กับ Draft ID เพื่อค้นย้อนหลังได้ โดย Log ไม่เก็บเนื้อหาเอกสารทั้งฉบับถ้าไม่จำเป็น
FAILURE PATH ที่ต้องออกแบบก่อนวันจริง
ERP รับ Draft แล้ว แต่คำตอบกลับมาไม่ถึง Agent
สมมติ Agent ส่งคำขอสร้าง Draft เวลา 14:03:11 ERP สร้าง D-1048 สำเร็จ แต่เครือข่ายขาดก่อนคำตอบกลับ Agent มองเห็นเพียง Timeout หากมัน Retry ด้วยคำขอใหม่ทันที ERP อาจสร้าง D-1049 ซ้ำ และพนักงานอาจยืนยันทั้งสองรายการ
Agent ส่ง Create Draft พร้อม Idempotency Key ที่ผูกกับ Message ID + Revision
ERP สร้าง D-1048 และบันทึก Key
Agentไม่ได้รับ Response แต่ยังสรุปไม่ได้ว่ารายการล้มเหลว
ค้นสถานะด้วย Key เดิม พบ D-1048 จึงไม่สร้างซ้ำ
ออกแบบให้ความไม่แน่ใจไม่กลายเป็นรายการซ้ำ
Business Key
กำหนดตัวระบุซ้ำได้จาก Message ID, เวอร์ชันเอกสาร และประเภทคำสั่ง ไม่ใช้เลขสุ่มใหม่ทุกครั้งที่ Retry
Idempotent Command
หากระบบได้รับ Key เดิม ให้คืนผลเดิมหรือปฏิเสธการสร้างซ้ำ แทนการสร้าง Business Object ใหม่
Read-after-timeout
หลัง Timeout ให้สอบถามสถานะจาก System of Record ก่อน Retry เพราะ Timeout บอกเพียงว่า “ไม่ได้รับคำตอบ” ไม่ได้บอกว่า “ปลายทางไม่ทำงาน”
Unknown State Queue
ถ้ายังยืนยันไม่ได้ ให้หยุด Run และเปิด Work Item พร้อม Request ID ห้าม Agent เดาหรือทำคำสั่งผลกระทบสูงซ้ำไปเรื่อย ๆ
| Tool | Identity / สิทธิ์ | Input ที่จำเป็น | Output / Evidence | เมื่อผิดพลาด |
|---|---|---|---|---|
| Find Customer | Order Agent · Read scoped fields | เลขผู้เสียภาษี ชื่อ ที่อยู่ | Candidate ID + Match factors | หลายรายการ → Human Match |
| Get Credit | Order Agent · Read status only | Customer ID | สถานะ วงเงิน วันที่ข้อมูล | ข้อมูลเก่า → Finance Review |
| Create Draft | Draft Service · Create only | Validated lines + Idempotency Key | Draft ID + status | Timeout → Reconcile ก่อน Retry |
| Commit Order | ไม่มีให้ Agent เรียก | พนักงานทำผ่าน ERP | Order ID + User ID | ERP workflow จัดการ |
สิ่งที่ Architecture Map ต้องทำให้เห็น: Identity, ขอบเขตข้อมูล, Read/Write, Business Object ที่เปลี่ยน, หลักฐาน และ Failure Path หากยังตอบไม่ได้ครบ แผนภาพนั้นเหมาะกับการอธิบายแนวคิด แต่ยังไม่พร้อมใช้เป็นข้อตกลงสำหรับสร้างระบบ
TRY IT WITH YOUR ORGANIZATION
เลือกหนึ่งเส้นที่มีผลจริง แล้วไล่ถามจนสุดทาง
- ทำ Inventory ของ User, Data, Model, Tool และ System of Record
- ระบุการไหลของข้อมูลและ Trust Boundary ทุกจุด
- กำหนด Read/Write Permission, Secret Owner, Log และ Retention
- เขียน Failure Path เมื่อ Model, API หรือข้อมูลไม่พร้อม
Agent ตรวจเอกสารผู้ขายกับระบบจัดซื้อ
- Input Boundary
- เอกสารจากผู้ขายเป็นข้อมูลภายนอก ไม่ถือว่าข้อความในไฟล์เป็นคำสั่งให้ Agent ปฏิบัติ
- Identity
- Vendor Review Agent อ่าน Case ที่ได้รับมอบหมายเท่านั้น ไม่เห็นผู้ขายทุกบริษัท
- Tools
- อ่าน Vendor Master, ตรวจรูปแบบบัญชี, สร้าง Review Note; ไม่มี Tool แก้บัญชีหรืออนุมัติผู้ขาย
- System of Record
- Procurement Platform ถือ Case, เอกสาร, สถานะ และผู้อนุมัติ
- Approval
- Finance ยืนยันบัญชีธนาคารผ่านช่องทางแยก ไม่ใช้ข้อมูลที่พิมพ์ในอีเมลอย่างเดียว
- Failure
- ระบบตรวจสอบภายนอกไม่ตอบ → สถานะ Pending Verification ไม่ตีความว่า “ผ่าน”
- Logs
- เก็บ Case ID, Tool, ผลตรวจและผู้อนุมัติ แต่ Mask เลขบัญชีใน Operational Log
แผนที่ที่ใช้ตัดสินใจและส่งต่อได้
ทุกลูกศรต้องมีเจ้าของ สิทธิ์ และทางกลับเมื่อพลาด
Integration Map ครอบคลุมข้อมูล ระบบ API, Identity, Logging และ Failure Path
- Integration Map
- Permission Matrix
- Data Flow
- Logging/Fallback Requirement
สำหรับแต่ละ Integration เพิ่ม Identity, Allowed Action, Data Fields, Authentication Owner, System of Record, Log, Timeout, Retry และ Fallback ไม่ต้องระบุผลิตภัณฑ์ทุกชิ้นในรอบแรก แต่ห้ามเว้นคำถามว่าใครทำอะไรกับข้อมูลใด
ใช้ Vendor Evaluation เมื่อต้องเลือกแพลตฟอร์ม →ก่อนอนุมัติ Architecture
อ่านแผนภาพเหมือนคนที่ต้องรับโทรศัพท์ตอนตีสาม
- ถ้า Credential รั่วหรือ Agent ถูกหลอก การกระทำรุนแรงที่สุดที่ทำได้คืออะไร และตัดสิทธิ์ได้เร็วแค่ไหน?
- ถ้าปลายทางทำงานสำเร็จแต่ Response หาย เราจะยืนยันสถานะและป้องกันการทำซ้ำได้อย่างไร?
- Log ที่มีอยู่เชื่อมผู้ร้องขอ Agent Run, Tool Call, Approval และ Business Object ได้หรือไม่ โดยไม่เก็บข้อมูลอ่อนไหวเกินจำเป็น?
Architecture ที่ปลอดภัยไม่ใช่กล่องจำนวนมาก แต่คือขอบเขตที่ชัด: Agent มีตัวตนของตัวเอง ได้สิทธิ์น้อยที่สุด การกระทำสำคัญแยกจากการอ่าน ระบบหลักยืนยันความจริง และทุกความล้มเหลวมีทางคืนสู่การควบคุม
จุดที่ควรหยุดตรวจ
- ใช้บัญชี Admin เพื่อให้ Prototype ทำงานง่าย
- ไม่แยกข้อมูลสำหรับทดสอบกับ Production
- มี Log แต่ไม่มีเจ้าของตรวจ
- วาด Model ไว้กลางภาพ แต่ไม่ระบุ Identity และ Trust Boundary ของแต่ละ Tool
- Retry ทุก Timeout โดยไม่รู้ว่าปลายทาง Commit ไปแล้วหรือยัง
อ่านต่อจากแหล่งต้นทาง
ที่มาของหลักคิดในบทนี้
- NIST SP 800-207 — Zero Trust Architecture ↗
- OWASP — LLM06:2025 Excessive Agency ↗
- OpenAI — A practical guide to building agents ↗
- Microsoft Learn — Least privilege for AI agents ↗
- ETDA/AIGC — แนวทางการประยุกต์ใช้ Generative AI อย่างมีธรรมาภิบาลสำหรับองค์กร ↗
ตรวจสอบแหล่งอ้างอิงล่าสุดเมื่อ 17 กันยายน 2569 · Architecture, เหตุการณ์ D-1048 ตัวเลข และแบบฝึกเป็นงานต้นฉบับของ ThinkToFinish และเป็นข้อมูลสมมติทั้งหมด