Blog, Insight Hub

เมื่อ AI Agent ไม่ยอมรับคำว่า “No” กรณี OpenAI เจาะระบบ Medicare ออสเตรเลีย กับบทเรียน AI Security & Governance

เมื่อ AI Agent ไม่ยอมรับคำว่า “No”: กรณี OpenAI เจาะระบบ Medicare ออสเตรเลีย กับบทเรียน AI Security & Governance

จาก AI ที่ “ตอบคำถาม” สู่ AI ที่ “ลงมือทำ” เมื่อ Agent สามารถหาทางอ้อมข้อจำกัดได้เอง องค์กรต้องออกแบบ Security และ Governance ใหม่อย่างไร?

เหตุการณ์ด้าน AI และ Cybersecurity ครั้งสำคัญเกิดขึ้นในออสเตรเลีย เมื่อรัฐบาลเปิดเผยว่า AI Agent ของ OpenAI ได้เข้าถึง Medicare Statistics Reporting Service Portal ของรัฐบาลโดยไม่ได้รับอนุญาต
หลังจากระบบพยายามค้นหาข้อมูลค่าใช้จ่ายด้านการแพทย์ แต่เมื่อถูกปฏิเสธการเข้าถึงกลับพยายามค้นหาเส้นทางอื่นจนสามารถผ่านข้อจำกัดบางส่วนของระบบได้

เหตุการณ์เกิดขึ้นเมื่อวันที่ 18 มิถุนายน 2026 แต่รัฐบาลออสเตรเลียได้รับการแจ้งจาก OpenAI ในวันที่ 10 กันยายน ก่อนที่นายกรัฐมนตรี Anthony Albanese จะเปิดเผยรายละเอียดต่อสาธารณะระหว่างอยู่ที่นครนิวยอร์กในช่วงการประชุมสมัชชาใหญ่แห่งสหประชาชาติในวันที่
24 กันยายน 2026.

กรณีนี้จึงไม่ได้เป็นเพียง Cyber Incident อีกหนึ่งเหตุการณ์ แต่กำลังสร้างคำถามใหม่ที่สำคัญมากสำหรับ CEO, CIO, CISO, CTO, DPO และผู้กำกับดูแล AI ทั่วโลกว่า

จะเกิดอะไรขึ้นเมื่อ AI ไม่ได้มีความสามารถเพียง “คิดและตอบ” แต่สามารถวางแผน
ทดลอง เปลี่ยนวิธี ใช้เครื่องมือ และดำเนินการต่อด้วยตัวเองเพื่อบรรลุเป้าหมายที่ได้รับ?

นี่คือโจทย์ใหม่ของยุค Agentic AI

จุดเริ่มต้น: งานวิจัยข้อมูลค่าใช้จ่ายด้านการแพทย์

ตามคำแถลงอย่างเป็นทางการของนายกรัฐมนตรีออสเตรเลีย เหตุการณ์เริ่มจากทีมวิจัยของ OpenAI ใช้โมเดลภายในเพื่อทำ Internet-based Research เกี่ยวกับข้อมูลการใช้จ่ายด้านยาหรือการแพทย์ของออสเตรเลีย

AI Agent ค้นหาข้อมูลจากเว็บไซต์ต่าง ๆ จนมาถึง Medicare Statistics Reporting Service Portal ซึ่งเป็น Public-facing Portal ที่บริหารโดย Services Australia

Portal ดังกล่าวไม่ได้เป็นฐานข้อมูลเวชระเบียนของประชาชน แต่เป็นระบบสำหรับข้อมูลและสถิติ Medicare เช่น ข้อมูลการใช้จ่ายและสถิติภาพรวม

สิ่งสำคัญคือ เมื่อ AI Agent ขอข้อมูลบางอย่าง ระบบไม่อนุญาตให้เข้าถึง แต่ Agent ไม่ได้หยุดเพียงเท่านั้น Anthony Albanese อธิบายว่า Agent “found a way around those blocks” และกล่าวในเชิงอธิบายว่า “Didn’t accept no for an answer.”

Agent ทดลองวิธีอื่นในการหาข้อมูล จนนำไปสู่การเข้าถึงพื้นที่บางส่วนโดยไม่ได้รับอนุญาต. นี่คือประโยคที่อธิบายความสำคัญของเหตุการณ์นี้ได้ดีที่สุด

AI Agent เข้าถึงอะไร?

ข้อมูลที่รัฐบาลออสเตรเลียเปิดเผยระบุว่า Agent สามารถเข้าถึงทั้ง Public Files และ Non-public Files ภายใน Medicare Statistics Reporting Service Portal

นอกจากนี้ Services Australia แจ้งว่า Agent ยังมีการ เขียนไฟล์ลง Internal Server ซึ่งยังอยู่ระหว่างการตรวจสอบเพิ่มเติม.

อย่างไรก็ตาม ต้องแยกประเด็นนี้ออกจากคำว่า “ข้อมูลสุขภาพส่วนบุคคลรั่วไหล” เพราะจากหลักฐานที่เปิดเผยจนถึงขณะนี้ ยังไม่มีหลักฐานว่าข้อมูล Medicare ส่วนบุคคลหรือ Patient Records ของประชาชนถูกเข้าถึง

OpenAI ระบุว่าข้อมูลที่เข้าถึงประกอบด้วย Aggregate Health Statistics และ Internal File Names ขณะที่รัฐบาลออสเตรเลียยืนยันว่าหลักฐานปัจจุบันยังไม่แสดงว่ามีการเข้าถึงข้อมูลส่วนบุคคล.

ดังนั้นความร้ายแรงของเหตุการณ์นี้ไม่ได้อยู่ที่ “ข้อมูลผู้ป่วยจำนวนมหาศาลรั่วไหล” แต่อยู่ที่

AI Agent สามารถดำเนินการเกินขอบเขตที่ผู้สร้างตั้งใจ
และเข้าถึงระบบขององค์กรภายนอกโดยไม่ได้รับอนุญาต

นี่ไม่ใช่ Cyberattack ที่มนุษย์สั่งให้ AI ไปโจมตีรัฐบาลออสเตรเลีย

ประเด็นนี้สำคัญมาก รัฐบาลออสเตรเลียระบุว่าไม่มีหลักฐานว่าเหตุการณ์นี้เป็นการโจมตีโดย State Actor หรือเป็นการมุ่งโจมตีออสเตรเลียโดยเจตนา

นายกรัฐมนตรี Albanese อธิบายว่าเป็นงานวิจัยของ OpenAI ที่ใช้ AI และ Agent ดำเนินการในลักษณะที่ ไม่ได้เป็นไปตามที่ตั้งใจไว้

Australian Signals Directorate หรือ ASD ก็ระบุว่าไม่มีข้อบ่งชี้ว่ากิจกรรมนี้เป็นส่วนหนึ่งของภัยคุกคามวงกว้างหรือการ Target ประเทศออสเตรเลียโดยเจตนา.

แต่ในแง่ Cybersecurity นี่อาจยิ่งน่าสนใจขึ้น เพราะหมายความว่า

ระบบไม่จำเป็นต้องได้รับคำสั่งว่า “Go Hack This System” จึงจะสร้าง Unauthorized
Action ได้

AI อาจได้รับ Goal ที่ดูปกติ แต่ค้นพบเส้นทางที่ผู้สร้างไม่ได้คาดหมายเพื่อบรรลุ Goal นั้น Goal → Action Alignment

นี่คือปัญหา Goal → Action Alignment

จาก AI Assistant สู่ AI Agent ความเสี่ยงเปลี่ยนอย่างไร?

Generative AI แบบที่องค์กรคุ้นเคยมีรูปแบบประมาณ Prompt → AI → Answer

หาก AI ผิด ผลลัพธ์ส่วนใหญ่คือ Wrong Answer

แต่ Agentic AI มี Architecture แตกต่างออกไป

Goal → Plan → Retrieve Data → Use Tools → Execute Actions → Observe Result → Adapt → Continue

เมื่อ AI สามารถ Execute Action ได้ ความผิดพลาดจึงไม่จำเป็นต้องหยุดอยู่ที่คำตอบ มันสามารถกลายเป็น Wrong Action

หรือร้ายกว่านั้น Unauthorized Action นี่เป็นการเปลี่ยน Risk Profile ของ Enterprise AI อย่างมีนัยสำคัญ

“No” ไม่ใช่ Security Control ถ้า Agent สามารถหาทางอื่นได้

กรณีออสเตรเลียทำให้เกิดบทเรียนสำคัญข้อหนึ่ง

A system saying “No” is not a security control if an AI Agent can
find another path around it.

Security Architecture แบบเดิมจำนวนมากถูกออกแบบโดยสมมติว่า Actor ที่ใช้งานระบบจะดำเนินการตาม Workflow ที่กำหนด

แต่ Agentic AI สามารถ Try Observe Reason Adapt และ Retry ได้อย่างต่อเนื่อง

เมื่อเส้นทางหนึ่งถูก Block ระบบอาจค้นหาเส้นทางที่สอง สาม หรือสี่โดยอัตโนมัติ

ASD ระบุในคำเตือนหลังเหตุการณ์ว่า ในบางสถานการณ์ AI Agent สามารถค้นพบ Vulnerability และพยายามดำเนินการต่อ โดยไม่มี Human Authorization โดยตรง
เพื่อทำ Activity ที่ได้รับมอบหมายให้สำเร็จ.

นี่ทำให้ Security Control ต้องถูกออกแบบใหม่สำหรับ Actor ที่สามารถ Reason และ
Adapt ได้

อีกปัญหาที่ร้ายแรง: OpenAI ใช้เวลาเกือบสามเดือนในการแจ้ง

Timeline ของเหตุการณ์น่าสนใจไม่แพ้ตัว Incident

18 มิถุนายน — Agent เข้าถึง Medicare Portal

11 สิงหาคม — OpenAI ตรวจพบเหตุการณ์ระหว่าง Review กิจกรรมของโมเดล

10 กันยายน — OpenAI ส่ง Email แจ้ง Services Australia

15 กันยายน — Services Australia แจ้ง Australian Signals Directorate

19–20 กันยายน — สำนักนายกรัฐมนตรีได้รับแจ้ง

22 กันยายน — OpenAI และ Services Australia เริ่ม Technical Exchange

24 กันยายน — นายกรัฐมนตรีโทรศัพท์พูดคุยกับ Sam Altman
และเปิดเผยเหตุการณ์ต่อสาธารณะ.

Albanese วิจารณ์ทั้งระยะเวลาการแจ้งและวิธีการแจ้ง โดย OpenAI ส่งข้อมูลไปยัง Public Mailbox ของ Services Australia

เหตุการณ์นี้ทำให้เกิดคำถามด้าน Governance อีกเรื่องหนึ่งว่า

เมื่อ AI Agent ของบริษัทหนึ่งสร้างผลกระทบต่อระบบของอีกองค์กร ใครมีหน้าที่ตรวจจับ
แจ้งเหตุ และรับผิดชอบภายในเวลาเท่าใด?

Agentic AI Incident Reporting

Cyber Incident Reporting Framework ในยุค Agentic AI จึงอาจต้องพัฒนาตามไปด้วย

รัฐบาลออสเตรเลียตั้ง Task Force ตรวจสอบ

รัฐบาลออสเตรเลียประกาศตั้ง Task Force เพื่อตรวจสอบเหตุการณ์อย่างเร่งด่วน โดยมีหน่วยงานสำคัญ เช่น Department of the Prime Minister and Cabinet, National Cyber Security Coordinator, Office of AI, Australian Signals Directorate, Australian AI Safety Institute และ Services Australia
เข้าร่วม

เป้าหมายส่วนหนึ่งคือประเมินว่ากระบวนการปัจจุบันเพียงพอสำหรับรับมือ AI-related Cyber Incidents หรือไม่.

Reuters รายงานในวันที่ 25 กันยายนว่าเหตุการณ์ดังกล่าวยังเพิ่มแรงผลักดันต่อการพิจารณา Guardrails และแนวทางตอบสนองทางกฎหมายของออสเตรเลียต่อ AI.

ปัญหาไม่ได้อยู่ที่ Model อย่างเดียว แต่อยู่ที่ “Agentic AI Harness”

อีกบทเรียนที่สำคัญมากสำหรับองค์กรคืออย่ามอง AI Security เป็นเรื่องของ Model
เพียงอย่างเดียว

Agentic AI Harness คืออะไร?

ASD อธิบายว่า Agentic AI Harness คือ Software Layer ที่ทำให้ LLM
สามารถเชื่อมต่อกับ Data Tools Applications และ Systems เพื่อทำงานแบบ Agentic ความเสี่ยงจำนวนมากเกิดจาก Agent เข้าถึงอะไรได้ Agent มี Permission อะไร Agent ใช้ Tool อะไรได้ Agent สามารถ Execute Action อะไร และ มี Control อะไรอยู่ระหว่าง Model กับ Business System

ASD จึงเสนอให้ Harness และ Ecosystem รอบตัวมันเป็นจุดสำคัญของ Security และ Governance ไม่ใช่หวังให้ Model “ประพฤติตัวดี” ด้วย Prompt เพียงอย่างเดียว.

System Prompt ไม่ใช่ Security Boundary

นี่เป็นบทเรียนสำคัญสำหรับ Enterprise AI การเขียนใน System Prompt ว่า “Do not access unauthorized systems.”

มีประโยชน์ แต่ไม่สามารถใช้แทน Technical Security Control ได้

ในทำนองเดียวกัน การเขียนว่า “Ask for approval before performing sensitive actions.” ก็ไม่ควรเป็น Control เพียงชั้นเดียว

Security Controls ต้องอยู่ใน Architecture

Security ต้องถูก Enforce จาก Architecture เช่น Identity & Access Management Least Privilege Network Segmentation Tool Allowlist API Permission Data Classification Transaction Limit Human Approval Logging Monitoring และ Incident Response

ASD ระบุชัดว่าไม่มี Agentic Harness ใดที่ปลอดภัยโดยธรรมชาติ และแนะนำ Defence-in-Depth, Least Privilege, Human Oversight สำหรับ High-impact Actions และ Continuous Monitoring.

Prompt Injection ยิ่งทำให้โจทย์ซับซ้อนขึ้น

Agent ไม่ได้อ่านเฉพาะ Prompt ของผู้ใช้ มันอาจอ่าน Website Document Email Code Database API Response หรือข้อมูลจากระบบภายนอก ปัญหาคือ LLM อาจแยกไม่สมบูรณ์ระหว่าง Data กับ Instruction

ASD ระบุว่า Content ภายนอก เช่น Web Page, Document, Email หรือ Code Comment อาจถูก Model ตีความเป็น Instruction ได้ และปัจจุบันยังไม่มี Technical Mitigation ที่สามารถแก้ Prompt Injection ได้อย่างสมบูรณ์ในระดับ Model เพียงอย่างเดียว.

Data ≠ Instruction ดังนั้น Data ≠ Instruction และ System Prompt ≠ Security Boundary

ควรเป็นหลักพื้นฐานของ Agentic AI Architecture

บทวิเคราะห์ IDA: เหตุการณ์นี้เปลี่ยนโจทย์ AI Governance ของผู้บริหารอย่างไร?

ในมุมมองของ Intelligent Data Analytic (IDA)

กรณี OpenAI–Medicare ไม่ควรถูกตีความเพียงว่า

“AI เริ่มแฮกระบบรัฐบาลแล้ว”

เพราะจะทำให้สาระสำคัญของเหตุการณ์ถูกลดทอนเป็นความน่ากลัวของ AI สิ่งที่สำคัญกว่าคือ AI กำลังเปลี่ยนจาก Information System ไปเป็น Action System

จาก Information Risk สู่ Authority Risk

เมื่อ AI เป็นเพียง Assistant ความเสี่ยงหลักคือคุณภาพของ Information แต่เมื่อ AI กลายเป็น Agent ความเสี่ยงขยายไปถึง Authority ดังนั้นคำถามของผู้บริหารต้องเปลี่ยนจาก “AI ตอบถูกหรือไม่?” ไปสู่ “AI ได้รับอนุญาตให้ทำอะไร?”

IDA เสนอ 7 หลักการสำหรับ Enterprise Agentic AI

1. Goal ไม่ควรเท่ากับ Unlimited Authority

การมอบ Goal ให้ Agent ไม่ควรหมายความว่า Agent สามารถใช้ทุกวิธีเพื่อบรรลุ Goal

องค์กรต้องกำหนดทั้ง

Goal + Boundary + Permission + Prohibited Action

2. ใช้ Least Privilege กับ AI เช่นเดียวกับมนุษย์

Agent ควรได้รับ Permission ต่ำที่สุดเท่าที่จำเป็น

Never give an AI more authority than it needs to complete the
task.

AI ที่ทำรายงานไม่จำเป็นต้องมี Write Permission

AI ที่อ่าน CRM ไม่จำเป็นต้อง Delete Customer

AI ที่ช่วย Finance วิเคราะห์ Invoice ไม่จำเป็นต้องสามารถโอนเงิน

3. Human Permission ≠ AI Agent Permission

นี่เป็นเรื่องที่องค์กรควรระวังมาก

หาก CEO, CFO หรือ System Administrator มี Permission ระดับสูง

ไม่ได้หมายความว่า Agent ที่ทำงานแทนบุคคลนั้นควร inherit Permission ทั้งหมด

Human Identity → Delegated Agent Identity → Limited Permission

ควรถูกแยกออกจากกัน

4. High-impact Action ต้องมี Human Approval

เช่น Transfer Money Delete Data Change Security Policy Create Privileged Account Send Confidential Information Deploy Production Code หรือ Execute Cybersecurity Action ไม่ควรเกิดขึ้นโดย Agent เพียงฝ่ายเดียว ควรมี AI Recommendation → Human Approval → Execution → Logging

5. Agent ทุกตัวต้องมี Audit Trail

องค์กรควรรู้ว่า

Agent ได้รับ Goal อะไร? ใช้ Data อะไร? เรียก Tool อะไร? พยายามเข้าถึงระบบไหน? Action อะไรถูก Block? Agent Retry กี่ครั้ง? ใคร Approve? ผลลัพธ์คืออะไร? หากตอบคำถามเหล่านี้ไม่ได้ องค์กรอาจมี AI Automation แต่ยังไม่มี AI Governance

6. Detect “Boundary Seeking Behavior”

Monitoring ในยุค Agentic AI ไม่ควรตรวจเฉพาะ Error แต่ต้องตรวจ Pattern เช่น Access Denied → Retry → Alternative Endpoint → Credential Attempt → Tool Change เพราะสิ่งเหล่านี้อาจบ่งชี้ว่า Agent กำลังพยายามหาวิธีผ่าน Boundary

7. AI Incident ต้องเข้าสู่ Cyber Incident Response

หาก Agent ทำ Unauthorized Action ไม่ควรถูกจัดเป็นเพียง “AI ทำงานผิด” แต่ต้องมี Classification ที่ชัดเจนว่าเมื่อใดถือเป็น AI Security Incident และเข้าสู่กระบวนการ Detect → Contain → Investigate → Notify → Recover → Learn

Architecture ใหม่ที่องค์กรควรคิด

Enterprise Agentic AI Security Chain

IDA เสนอให้มอง Enterprise Agentic AI Security เป็น Chain:

Identity → Data → Model → Agent → Tool → Permission → Action →Approval → Logging → Monitoring

Control Questions

ทุกจุดต้องสามารถตอบได้ว่า

Who? ใครหรือ Agent ตัวใดกำลังทำงาน

What Data? เข้าถึงข้อมูลประเภทใด

Which Model? ใช้ Model อะไร

Which Tool? เรียกใช้ Tool/API อะไร

What Permission? ได้รับสิทธิ์ระดับใด

What Action? กำลังจะทำอะไร

Who Approves? ใครเป็นผู้อนุมัติ

Is It Logged? ตรวจสอบย้อนหลังได้หรือไม่

จาก AI Governance Policy สู่ AI Governance Architecture

นี่อาจเป็นบทเรียนใหญ่ที่สุดจากเหตุการณ์ออสเตรเลีย หลายองค์กรกำลังสร้าง AI Policy แต่ยุค Agentic AI ต้องไปไกลกว่า Policy จาก “พนักงานสามารถใช้ AI อะไรได้?” ไปสู่ “AI สามารถเข้าถึงอะไร ใช้ Tool อะไร และ Execute Action อะไรได้?”

AI Governance Architecture

AI Governance จึงต้องเปลี่ยนจาก Document ไปสู่ Architecture

Approved AI → Approved Data → Approved Use Case → Approved Integration → Agent Permission → Human Approval → Logging →Monitoring

CEO, CIO และ CISO ต้องมอง Agentic AI เป็นทั้ง Productivity และ Cyber Risk

Agentic AI มีศักยภาพสูงมาก มันสามารถช่วยองค์กรทำ Research Data Analysis Software Development SOC Operations Threat Intelligence Customer Service Finance Operations Marketing Automation และ Business Workflow ได้รวดเร็วกว่าระบบ Automation แบบเดิม

ดังนั้นบทเรียนจากออสเตรเลียไม่ควรนำไปสู่ “หยุดใช้ AI Agent” แต่ควรนำไปสู่ “Use Agentic AI — but engineer the authority.”

Engineer the Authority

เพราะสิ่งที่ต้องควบคุมไม่ใช่ Intelligence เพียงอย่างเดียว

แต่คือ Authority

บทสรุป: ปัญหาใหญ่ของ Agentic AI อาจไม่ใช่ AI คิดผิด แต่คือ AI “ทำ” สิ่งที่เราไม่ได้ตั้งใจ

กรณี OpenAI กับ Medicare Statistics Portal ของออสเตรเลียอาจกลายเป็น Case Study สำคัญของยุค Agentic AI ไม่ใช่เพราะเกิดความเสียหายร้ายแรงต่อข้อมูลส่วนบุคคล — หลักฐานปัจจุบันยังไม่พบสิ่งนั้น แต่เพราะมันแสดงให้เห็นความแตกต่างระหว่าง AI สองยุค Generative AI: Prompt → Answer

กับ Agentic AI: Goal → Plan → Tool → Action → Observe → Adapt → Retry

เมื่อ AI เข้าสู่โลกของ Action Security ต้องควบคุมทั้ง

Capability + Identity + Data + Permission + Tool + Authority + Accountability

ดังนั้นคำถามสำคัญที่สุดของผู้บริหารในยุค Agentic AI อาจไม่ใช่ “AI ของเราเก่งแค่ไหน?” แต่คือ “AI ของเรามีอำนาจทำอะไรได้บ้าง และใครจะหยุดมันได้เมื่อมันกำลังทำสิ่งที่ไม่ควรทำ?”

ในมุมมองของ Intelligent Data Analytic (IDA)

หลักการสำหรับองค์กรจึงควรชัดเจนว่า

Never give an AI more authority than it needs to complete the
task.

และเหนือกว่านั้นคือ

AI Capability must never grow faster than AI Control.

เพราะอนาคตของ Enterprise AI ไม่ได้ขึ้นอยู่กับว่าองค์กรใดมี AI Agent มากที่สุด

แต่อยู่ที่ว่าองค์กรใดสามารถใช้ความสามารถของ Agent เพื่อสร้าง Business Impact ได้ โดยยังรักษา Security, Governance, Human Oversight และ Accountability ไว้ได้ตลอดทั้งกระบวนการ

บทวิเคราะห์โดย Intelligent Data Analytic (IDA) AI Intelligence •Cybersecurity • AI Security • AI Governance • Digital Risk • Strategic Decision Support