AI Agent ต้องมีบัตรผ่าน: ทำไม OAuth token อย่างเดียวไม่พอ

เวลาคุยเรื่อง AI agent ในองค์กร เรามักเริ่มจากคำถามที่ดูจับต้องได้:

• ใช้ model ไหน
• ต่อ tool อะไรได้บ้าง
• ทำงานแทนคนได้กี่ขั้น
• ลดเวลาทีมได้กี่เปอร์เซ็นต์

แต่เมื่อ agent เริ่มแตะระบบจริง คำถามที่สำคัญกว่าคือ:

ระบบรู้ไหมว่า agent ตัวไหนกำลังทำงานแทนใคร

นี่คือประเด็นจาก CrowdStrike วันที่ 24 มิถุนายน 2026 ที่ผมคิดว่าควรเอามาแปลเป็นภาษา operator ทันที เพราะมันไม่ใช่แค่ security deep tech แต่เป็นปัญหาหน้างานของทุกทีมที่เริ่มให้ AI agent เข้าไปทำงานกับระบบภายใน

ปัญหา: token บอกว่า “เข้าได้” แต่ไม่บอกว่า “เข้าแทนใคร”

CrowdStrike ชี้ว่า OAuth access token ที่ใช้อยู่ทั่วไปออกแบบมาสำหรับโลกที่ actor ค่อนข้างชัด เช่น user คนหนึ่ง หรือ application ตัวหนึ่ง

แต่ AI agent ไม่ได้เรียบง่ายแบบนั้น

agent อาจ:

• ทำงานแบบ interactive โดย user ยังอยู่หน้าเครื่อง
• ทำงาน offline หลัง user สั่งแล้วหายไป
• ทำงานอัตโนมัติจาก queue หรือ schedule
• เรียก agent ตัวอื่นต่อเป็น chain
• ทำงานแทนหลาย user ในช่วงเวลาเดียวกัน

ถ้า token บอกได้แค่ว่า client คือแอปอะไร หรือ subject คือ user คนไหน ระบบปลายทางยังไม่รู้ข้อมูลสำคัญสามอย่าง:

1. agent instance ไหน เป็นคนลงมือ
2. user คนไหน เป็นคนมอบหมายหรือเกี่ยวข้อง
3. ความสัมพันธ์ระหว่าง agent กับ user คืออะไร เช่น delegated task, automated case handling, หรือ transitive subtask

ช่องว่างนี้ทำให้ระบบทำ authorization หยาบเกินไป และ audit ย้อนหลังได้ยาก

ทำไมเรื่องนี้กระทบทีมไทยเร็วกว่าที่คิด

หลายทีมอาจรู้สึกว่านี่เป็นเรื่อง enterprise ใหญ่ ๆ แต่จริง ๆ SMB ก็เจอเร็วมาก โดยเฉพาะเมื่อใช้เครื่องมือแนวนี้:

• coding agent ที่เปิด PR หรือแก้ไฟล์ production
• internal chatbot ที่อ่าน CRM หรือ ticket
• automation agent ที่ยิง API ไปยัง accounting, ecommerce, LINE OA, spreadsheet
• MCP server ที่เชื่อมหลาย data source ให้ assistant เรียกใช้
• social หรือ customer-care agent ที่ตอบแทนทีมใน inbox

ยิ่ง agent ทำงานข้ามระบบมากขึ้น คำว่า “ใครเป็นคนทำ” จะไม่พอ ต้องถามเพิ่มว่า:

• ทำใน session ไหน
• ด้วย task id อะไร
• ได้สิทธิ์จากใคร
• สิทธิ์หมดอายุเมื่อไร
• มี human approval ตรงจุดไหน
• ถ้า agent เรียก tool ต่อ tool เราเก็บ chain ครบไหม

ถ้าไม่มีคำตอบ เวลามี incident ทีมจะเหลือแค่ log ที่บอกว่า token ถูกใช้สำเร็จ แต่ไม่รู้ context ของการตัดสินใจ

Google Cloud เสริมอีกด้าน: agent ต้องมี context ที่ตรวจได้

ในวันเดียวกัน Google Cloud เขียนว่า agent ที่ trustworthy ต้องไม่ได้มีแค่โมเดลเก่ง แต่ต้องมี trusted business context

ผมมองว่าสองบทความนี้ต่อกันพอดี:

• CrowdStrike พูดเรื่อง identity และ delegation
• Google Cloud พูดเรื่อง context, permission-aware retrieval และ governance

ถ้ารวมกัน ภาพที่ได้คือ agent production-ready ต้องตอบได้สองชุดคำถาม:

ชุดที่ 1: Who is acting?

• agent instance ไหน
• behalf of user คนไหน
• delegated scope คืออะไร
• downstream tool เห็น context นี้ไหม

ชุดที่ 2: What is it acting on?

• ดึงข้อมูลจาก source ไหน
• context ล่าสุดไหม
• permission ตามมาด้วยหรือเปล่า
• retrieval มีหลักฐานให้ตรวจไหม

agent ที่ตอบคำถามสองชุดนี้ไม่ได้ อาจทำงานได้เร็ว แต่ยังไม่ควรได้สิทธิ์แตะระบบสำคัญ

Operator Kit: Agent Passport ก่อนปล่อยเข้าระบบจริง

นี่คือ checklist ที่ทีมใช้ได้ทันที ก่อนให้ agent เข้า CRM, GitHub, database, support inbox หรือ MCP server

1. Agent Passport

ให้ agent ทุกตัวมีเอกสารสั้น ๆ หนึ่งหน้า ไม่ใช่แค่ prompt

ต้องระบุ:

• agent_name
• owner_team
• purpose
• allowed_tools
• allowed_data
• forbidden_actions
• max_runtime
• escalation_owner
• kill_switch

ตัวอย่าง:

agent_name: support_refund_triage_agent
owner_team: customer_ops
purpose: triage refund requests and prepare draft response
allowed_tools:
  - read_support_ticket
  - read_order_status
  - draft_reply
forbidden_actions:
  - issue_refund
  - change_customer_tier
  - export_customer_data
max_runtime: 30 minutes
escalation_owner: support_lead
kill_switch: disable_queue_worker

หลักคิดคือ ถ้า agent ไม่มี passport มันยังไม่ควรเข้าระบบ production

2. Delegation Receipt

ทุก task ที่ agent ทำแทนคนควรมี receipt

ต้องตอบได้ว่า:

• user หรือ workflow ไหนเริ่มงาน
• user อนุญาตให้ทำอะไร
• task scope คืออะไร
• สิทธิ์หมดอายุเมื่อไร
• ต้องขอ approval ก่อน action ไหน

รูปแบบ log ง่าย ๆ:

{
  "task_id": "refund-triage-20260625-001",
  "agent_instance_id": "agent-run-8f91",
  "initiated_by": "support_queue",
  "on_behalf_of": "support_team",
  "delegated_scope": ["read_ticket", "read_order", "draft_reply"],
  "expires_at": "2026-06-25T10:00:00+07:00",
  "approval_required_for": ["send_reply", "issue_refund"]
}

จุดสำคัญคืออย่าให้ token เป็นหลักฐานเดียว ต้องมี context ของการมอบหมายด้วย

3. Access Boundary

แยกสิทธิ์ตาม action ไม่ใช่ตามความสะดวกของ integration

อย่างน้อยควรแยก:

• read
• draft
• propose change
• execute change
• export
• delete
• financial action
• customer-impacting action

หลายระบบพลาดเพราะให้ API key เดียวที่ทำได้ทุกอย่าง แล้วหวังว่า prompt จะห้าม agent เอง

prompt ไม่ใช่ permission boundary

4. Transitive Call Log

ถ้า agent เรียก tool หรือ agent ตัวอื่นต่อ ต้องเก็บ chain

ตัวอย่าง log ที่ควรมี:

user_request -> planning_agent -> crm_lookup_tool -> policy_rag_tool -> reply_draft_agent

ในแต่ละ hop ควรเก็บ:

• caller
• callee
• purpose
• input classification
• output classification
• permission check result
• timestamp

เพราะ incident ส่วนใหญ่ไม่ได้เกิดจาก call แรกเสมอไป แต่อาจเกิดตอน agent ส่ง context ต่อให้ระบบถัดไป

5. Human Gate และ Kill Switch

ก่อนให้ agent ทำ action ที่มีผลจริง ควรกำหนด gate ให้ชัด

ต้องมี approval สำหรับ:

• ส่งข้อความหาลูกค้า
• refund หรือ charge เงิน
• เปลี่ยนข้อมูลลูกค้า
• merge code
• deploy
• export data
• ลบหรือ archive record

และต้องมี kill switch ที่คนจริงใช้ได้ทันที เช่น:

• disable agent config
• revoke tool token
• pause queue
• block MCP server route
• rotate credential

ถ้าปิด agent ไม่ได้ใน 1 นาที แปลว่ายังไม่พร้อม production

Decision tree: agent นี้ควรได้สิทธิ์แค่ไหน

ใช้คำถาม 6 ข้อนี้ก่อนเปิดสิทธิ์

1. action นี้อ่านอย่างเดียวหรือเปลี่ยน state
2. ถ้าเปลี่ยน state กระทบลูกค้า เงิน ข้อมูลส่วนตัว หรือ production ไหม
3. agent ทำงานแบบมี user อยู่หน้าเครื่อง หรือ offline
4. token แยกตาม agent instance ได้ไหม
5. downstream system เห็น delegation context ไหม
6. audit log ตอบได้ไหมว่าใครสั่ง ทำเมื่อไร ใช้ข้อมูลอะไร และหยุดตรงไหน

ถ้าตอบข้อ 4 ถึง 6 ไม่ได้ ให้เริ่มจาก read-only หรือ draft-only ก่อน

สิ่งที่ไม่ควรทำ

อย่าเริ่มด้วยการให้ agent ถือ credential เดียวกับคนในทีม

อย่าให้ service account กว้าง ๆ แล้วบอกว่า “เดี๋ยว prompt คุม”

อย่าให้ MCP server เปิด tool ทุกตัวโดยไม่มี allowlist

อย่าให้ agent ทำงานข้ามระบบโดยไม่มี correlation id

อย่าให้ agent ส่งผลลัพธ์ถึงลูกค้าโดยไม่มี review gate ในช่วงแรก

สรุปสำหรับ operator

บทเรียนของ CrowdStrike ไม่ใช่ว่า OAuth ใช้ไม่ได้ แต่คือ OAuth token อย่างเดียวไม่พอจะอธิบายโลกของ AI agent ที่มี instance, delegation และ transitive workflow

บทเรียนของ Google Cloud คือ agent ที่น่าเชื่อถือไม่ได้เกิดจากโมเดลอย่างเดียว แต่เกิดจาก context, permission และ retrieval ที่ตรวจสอบได้

ดังนั้นก่อนถามว่า agent ทำงานแทนคนได้แค่ไหน ให้ถามก่อนว่า:

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

ถ้ายังตอบไม่ได้ อย่าเพิ่งให้มันถือกุญแจ production

ให้มันเริ่มจากบัตรผ่านใบเล็ก ๆ ก่อน