Blog, Insight Hub

Prompt Injection คืออะไร เมื่อคำสั่งที่ซ่อนอยู่หลอก AI ให้ทำสิ่งที่เราไม่ได้สั่ง

Prompt Injection คืออะไร? เมื่อคำสั่งที่ซ่อนอยู่หลอก AI ให้ทำสิ่งที่เราไม่ได้สั่ง

เราเริ่มคุ้นเคยกับการสั่ง AI ด้วย Prompt เช่น

“ช่วยสรุปเอกสารนี้ให้หน่อย”

“อ่านอีเมลทั้งหมดแล้วบอกว่ามีเรื่องไหนต้องรีบตอบ”

“ค้นข้อมูลจากเว็บไซต์เหล่านี้แล้วทำรายงานให้ฉัน”

หรือแม้แต่

“ตรวจเอกสารในระบบแล้วดำเนินการตามที่จำเป็น”

คำสั่งเหล่านี้ดูธรรมดา และเป็นสิ่งที่ AI Assistant หรือ AI Agent
รุ่นใหม่สามารถช่วยทำได้มากขึ้นเรื่อย ๆ

แต่ลองจินตนาการว่า เอกสาร เว็บไซต์ หรืออีเมลที่ AI กำลังอ่านอยู่นั้น มี
“คำสั่งอีกชุดหนึ่ง” ซ่อนอยู่

และ AI ไม่สามารถแยกได้อย่างสมบูรณ์ว่า

ข้อความไหนคือ “ข้อมูลที่ต้องอ่าน”

กับ

ข้อความไหนคือ “คำสั่งที่ควรทำตาม”

นี่คือจุดเริ่มต้นของความเสี่ยงที่เรียกว่า Prompt Injection

OWASP จัด Prompt Injection เป็น LLM01:2025 ใน OWASP Top 10 for LLM
Applications โดยอธิบายว่า Prompt Injection เกิดขึ้นเมื่อ Input
สามารถเปลี่ยนพฤติกรรมหรือ Output ของ Large Language Model ไปในทิศทางที่ไม่ได้ตั้งใจ
และผลกระทบอาจรวมถึงการเปิดเผยข้อมูล การเข้าถึง Function โดยไม่ได้รับอนุญาต
หรือแม้แต่การสั่งงานระบบที่เชื่อมต่อกับ LLM ได้

ประเด็นสำคัญจึงไม่ใช่เพียง

“AI จะตอบผิดหรือไม่?”

แต่กำลังกลายเป็น

“ถ้ามีใครสามารถหลอก AI ให้ทำตามคำสั่งของเขาแทนคำสั่งของเรา จะเกิดอะไรขึ้น?”

Prompt Injection คืออะไร?

Prompt Injection คือเทคนิคที่พยายามใช้ข้อความหรือ Content
เพื่อเปลี่ยนแปลงพฤติกรรมของ AI ให้ทำสิ่งที่ผู้พัฒนา ผู้ดูแลระบบ หรือผู้ใช้ไม่ได้ตั้งใจ

ถ้าเปรียบเทียบแบบง่าย ๆ

AI ได้รับคำสั่งว่า

“อ่านเอกสารนี้แล้วสรุปเนื้อหา”

ตามปกติ AI ควรมองเนื้อหาในเอกสารเป็น Data

แต่หากในเอกสารมีข้อความที่ถูกออกแบบมาเพื่อพยายามให้ AI เปลี่ยนคำสั่ง เช่น
ให้ละเลยงานเดิมและทำสิ่งอื่นแทน ปัญหาจะเกิดขึ้นหากระบบตีความข้อความดังกล่าวเป็น
Instruction แทนที่จะเป็นเพียง Content

OWASP ระบุว่า Prompt Injection
ไม่จำเป็นต้องเป็นข้อความที่มนุษย์มองเห็นหรืออ่านออกได้เสมอไป
ตราบใดที่เนื้อหานั้นถูกระบบนำไปประมวลผล และในระบบ Multi-modal
คำสั่งโจมตียังอาจมากับภาพหรือ Input ประเภทอื่นได้ด้วย

ดังนั้นในยุค Generative AI

Data อาจไม่ได้เป็นเพียง Data อีกต่อไป

เพราะ Data ที่ AI อ่านอาจมีข้อความที่พยายามทำหน้าที่เป็น Instruction อยู่ภายใน

Prompt Injection ต่างจาก Jailbreak อย่างไร?

สองคำนี้มักถูกใช้ปะปนกัน

แต่มีความแตกต่างที่ควรรู้

Prompt Injection เป็นแนวคิดกว้างกว่า หมายถึงการใช้ Input
เพื่อเปลี่ยนพฤติกรรมของ LLM ไปในทิศทางที่ไม่ได้ตั้งใจ

ส่วน Jailbreaking มักหมายถึงความพยายามทำให้โมเดลละเลยหรือหลีกเลี่ยงข้อจำกัดด้าน
Safety ที่ถูกกำหนดไว้

OWASP อธิบายว่า Jailbreaking สามารถถือเป็นรูปแบบหนึ่งของ Prompt Injection
ที่มุ่งทำให้โมเดลไม่ปฏิบัติตาม Safety Protocols ของตน

พูดง่าย ๆ คือ

Jailbreak → พยายามข้ามข้อจำกัดของโมเดล

ขณะที่

Prompt Injection → พยายามควบคุมหรือเปลี่ยนพฤติกรรมของระบบ AI

และเมื่อ AI เชื่อมต่อกับข้อมูลหรือ Tool ภายนอก ผลกระทบของ Prompt Injection
อาจขยายออกไปนอกตัว Chatbot

1. Direct Prompt Injection — โจมตีผ่าน Prompt โดยตรง

รูปแบบแรกคือ Direct Prompt Injection

เกิดเมื่อผู้ใช้ส่ง Input ที่พยายามเปลี่ยนพฤติกรรมของ AI โดยตรง

ตัวอย่างเชิงแนวคิด เช่น ระบบ Customer Service AI ถูกออกแบบมาให้ตอบเฉพาะข้อมูลสินค้า
แต่ผู้ใช้พยายามส่งข้อความที่ชักนำให้ระบบละเลยข้อจำกัดเดิมและเปิดเผยข้อมูลที่ไม่ควรเปิดเผย

Direct Prompt Injection Attack Flow

Attack Flow จะมีลักษณะประมาณนี้

Attacker → Malicious Prompt → LLM → Unintended Behavior

OWASP ระบุว่า Direct Prompt Injection สามารถเกิดขึ้นได้ทั้งจากความตั้งใจของผู้โจมตี
หรือแม้แต่ Input ที่ไม่ได้ตั้งใจแต่กระตุ้นพฤติกรรมที่ไม่คาดคิดของระบบ

สำหรับ Chatbot ทั่วไป ผลกระทบอาจจำกัดอยู่ที่ Output

แต่เมื่อ LLM สามารถเรียก Database, API หรือ Tool ได้ ผลกระทบอาจสูงขึ้นอย่างมาก

2. Indirect Prompt Injection — อันตรายอาจซ่อนอยู่ในสิ่งที่ AI อ่าน

รูปแบบที่น่าสนใจและสำคัญมากสำหรับองค์กรคือ Indirect Prompt Injection

เพราะผู้โจมตีไม่จำเป็นต้องพูดกับ AI โดยตรง

เขาเพียงสร้าง Content ที่รู้ว่า AI จะมาอ่าน

เช่น

Website Email PDF Word Document Cloud Document
Support Ticket Source Code Knowledge Base Search Result

แล้วฝังข้อความที่พยายามเปลี่ยนพฤติกรรมของ AI ไว้ภายใน

Microsoft อธิบายว่า Indirect Prompt Injection เกิดขึ้นเมื่อผู้โจมตีใส่คำสั่งลงใน
Third-party Content แล้ว AI เข้าใจข้อความนั้นผิดว่าเป็นคำสั่งที่ถูกต้อง ซึ่งอาจนำไปสู่
Unauthorized Actions, Data Breaches หรือการสูญเสีย System Integrity ได้

Indirect Prompt Injection Attack Flow

Attack Flow จึงเปลี่ยนเป็น

Attacker → External Content → AI Reads Content → Injection Interpreted
as Instruction → AI Behavior Changes

นี่คือเหตุผลว่าทำไม Prompt Injection จึงเริ่มมีลักษณะคล้าย Social Engineering
สำหรับ AI

OpenAI เองอธิบายว่า Prompt Injection ในระบบ Agent รุ่นใหม่มีความคล้าย Social
Engineering มากขึ้น เพราะผู้โจมตีไม่ได้พยายามหาเพียง “Magic String” แต่พยายามสร้าง
Content ที่หลอกโมเดลในบริบทที่มันกำลังทำงานอยู่

3. ลองนึกภาพ AI Agent อ่านอีเมลของเรา

สมมติองค์กรมี AI Agent เชื่อมต่อกับ Email

ผู้บริหารสั่งว่า

“อ่านอีเมลใหม่ทั้งหมด แล้วสรุปเรื่องสำคัญให้ฉัน”

Agent จึงเปิดอีเมลทีละฉบับ

ผู้โจมตีส่งอีเมลที่มีข้อความซึ่งถูกออกแบบให้พยายามชักนำ Agent ให้ทำงานอื่น

ถ้า Agent ถูกออกแบบไม่ดีพอ มันอาจตีความข้อความใน Email ซึ่งควรเป็น Untrusted
Data ว่าเป็น Trusted Instruction

ปัญหาจะร้ายแรงขึ้นหาก Agent มีสิทธิ์เข้าถึง

Email + Cloud Drive + CRM + Financial Documents

เพราะ Prompt Injection ไม่ได้พยายามเปลี่ยนเพียงคำตอบอีกต่อไป แต่อาจพยายามชักนำ
Agent ให้ค้นหาหรือส่งข้อมูลที่ผู้ใช้ไม่ได้ร้องขอ

OpenAI ยกตัวอย่างสถานการณ์ลักษณะนี้โดยตรงว่า Agent ที่ได้รับคำสั่งกว้าง ๆ ให้จัดการอีเมล
อาจถูกข้อความอันตรายในอีเมลพยายามชักนำให้ค้นหาและแบ่งปันข้อมูลที่ผู้ใช้ไม่ได้ตั้งใจให้ส่งออก

Agent Risk Equation

นี่ทำให้เกิดสมการความเสี่ยงใหม่

Prompt Injection + Sensitive Data Access + Tool Permission = Higher
Impact

4. Prompt Injection กับ RAG

องค์กรจำนวนมากกำลังสร้างระบบ Retrieval-Augmented Generation หรือ RAG

แนวคิดคือ

User Question → Retrieve Relevant Documents → Send Context to LLM →
Generate Answer

ข้อดีคือ AI สามารถตอบคำถามโดยใช้ Knowledge Base ขององค์กร

แต่คำถามด้าน Security คือ

“ถ้าเอกสารที่ RAG ดึงมา มี Prompt Injection อยู่ข้างในล่ะ?”

สมมติ Knowledge Base มีเอกสารหลายหมื่นไฟล์

หากเอกสารหนึ่งถูกแก้ไขหรือถูก Upload ด้วย Content ที่พยายามเปลี่ยนพฤติกรรมของ AI

Flow อาจกลายเป็น

Attacker → Poisoned Document → Vector Database → Retrieval → LLM
Context → Prompt Injection

OWASP ระบุชัดว่า RAG และ Fine-tuning ไม่สามารถกำจัด Prompt Injection
ได้ทั้งหมด และยกตัวอย่างการโจมตีที่ผู้โจมตีแก้ไขเอกสารใน Repository ที่ระบบ RAG
ใช้เป็นแหล่งข้อมูล

ดังนั้น

RAG ≠ Prompt Injection Protection

RAG ช่วยเรื่อง Grounding และ Knowledge Retrieval

แต่ไม่ได้ทำให้ Content ที่ Retrieve มา “น่าเชื่อถือ” โดยอัตโนมัติ

5. Prompt Injection ในภาพก็เกิดขึ้นได้

Generative AI รุ่นใหม่ไม่ได้อ่านเฉพาะ Text

ระบบสามารถรับ

Image Audio Video Document Screenshot

OWASP เตือนว่าระบบ Multi-modal เพิ่ม Attack Surface ใหม่
เพราะข้อความหรือคำสั่งอาจถูกซ่อนใน Input รูปแบบอื่น เช่น ภาพที่มาพร้อมกับข้อความปกติ

ลองนึกภาพ AI Agent ที่มี Vision

ผู้ใช้บอกว่า

“ดู Screenshot นี้แล้วช่วยสรุปให้หน่อย”

แต่ภายในภาพมีข้อความที่ถูกออกแบบเพื่อชักนำโมเดล

มนุษย์อาจไม่ได้สังเกตข้อความดังกล่าว

แต่ Vision Model อาจอ่านมันได้

นี่ทำให้แนวคิด Security แบบเดิมที่ตรวจเฉพาะ Text Input อาจไม่เพียงพอในยุค
Multimodal AI

6. Prompt Injection อันตรายขึ้นมากเมื่อ AI มี Tools

Chatbot รุ่นแรกทำงานประมาณ

Prompt → LLM → Response

หากถูก Prompt Injection ผลกระทบหลักอาจเป็น Output ที่ผิดหรือไม่เหมาะสม

แต่ AI Agent รุ่นใหม่ทำงานประมาณ

Prompt → LLM → Planning → Tool Selection → Tool Call → Action

Tool อาจเป็น

Search Web Read Email Send Email Read Files Write
Files Query Database Call API Update CRM Run Code

เมื่อถึงจุดนี้ Prompt Injection ไม่ใช่เพียง Content Security Problem

แต่สามารถกลายเป็น System Security Problem

Microsoft เปิดเผยงานวิจัยในเดือนพฤษภาคม 2026 เกี่ยวกับช่องโหว่ใน AI Agent
Framework ซึ่งเส้นทางการโจมตีสามารถทำให้ Prompt Injection นำไปสู่ Host-level
Remote Code Execution ได้ในบางเงื่อนไข โดยประเด็นสำคัญคือเมื่อโมเดลถูกเชื่อมเข้ากับ
Tool และสามารถส่ง Parameter ไปยัง Code ได้ ผลกระทบของ Prompt Injection
สามารถขยายจากการควบคุมข้อความไปสู่การ Execute Action บนระบบจริง

นี่คือเหตุผลว่าทำไม Security Architecture ของ AI Agent จึงสำคัญมากกว่าการเขียน
System Prompt ให้แข็งแรงเพียงอย่างเดียว

7. MCP ทำให้เรื่องนี้สำคัญขึ้นอีก

Model Context Protocol หรือ MCP ทำให้ AI สามารถเชื่อมต่อกับ Data Source
และ Tool ได้เป็นมาตรฐานมากขึ้น

สิ่งนี้สร้างโอกาสมหาศาลสำหรับ Enterprise AI

แต่ขณะเดียวกันก็เพิ่ม Trust Boundary ใหม่

MCP Architecture

ตัวอย่าง Architecture:

AI Agent → MCP Client → MCP Server → Enterprise Tool/Data

หาก MCP Server, Tool Description หรือ Content ที่ Tool
ส่งกลับมาถูกควบคุมหรือแก้ไขโดยผู้ไม่หวังดี อาจเกิดความเสี่ยงจาก Prompt Injection หรือ
Tool Poisoning

Microsoft ระบุว่าใน MCP Ecosystem มีความเสี่ยงจาก Indirect Prompt Injection
และ Tool Poisoning ซึ่งอาจทำให้ข้อมูลลูกค้าถูกเปิดเผยในลักษณะที่องค์กรไม่ได้คาดคิด

ดังนั้นก่อนองค์กรจะถามว่า

“เราจะเชื่อม MCP Server อะไรเพิ่มดี?”

ควรถามก่อนว่า

“เราเชื่อถือ MCP Server นี้ได้แค่ไหน และมันมีสิทธิ์ทำอะไร?”

8. Prompt Injection อาจนำไปสู่ Data Exfiltration

หนึ่งในผลกระทบที่น่ากังวลคือ Data Exfiltration

สมมติ Agent สามารถอ่าน

Private Documents

และสามารถเรียก

External URL หรือ Communication Tool

Prompt Injection อาจพยายามทำให้ Agent

ค้นข้อมูล → นำข้อมูลมาใช้ → ส่งข้อมูลออก

Microsoft ระบุ Data Exfiltration เป็นหนึ่งใน Security Impact สำคัญของ
Indirect Prompt Injection โดยการโจมตีอาจพยายามทำให้ LLM ค้นหาข้อมูลของผู้ใช้ก่อน
แล้วใช้ช่องทางบางอย่างส่งข้อมูลกลับไปยังผู้โจมตี

นี่แสดงให้เห็นว่า AI Security ต้องสนใจ Information Flow

ไม่ใช่เพียง Prompt Filtering

ต้องถามว่า

ข้อมูลสามารถไหลจาก Source ไหน → ผ่าน Model → ไป Destination ไหนได้บ้าง?

9. Prompt Injection ต่างจาก Hallucination อย่างไร?

สองเรื่องนี้ควรแยกออกจากกันอย่างชัดเจน

Hallucination

AI สร้างข้อมูลผิดหรือไม่มีหลักฐานรองรับ โดยไม่จำเป็นต้องมีผู้โจมตี

ส่วน

Prompt Injection

มี Input หรือ Content ที่พยายามทำให้ AI เปลี่ยนพฤติกรรมไปจากสิ่งที่ระบบตั้งใจ

จำง่าย ๆ ว่า

Hallucination = AI เข้าใจหรือสร้างข้อมูลผิด

Prompt Injection = AI ถูกชักนำให้ทำผิดจากเจตนาของผู้ใช้หรือระบบ

อย่างไรก็ตาม ทั้งสองความเสี่ยงสามารถเกิดพร้อมกันได้

10. System Prompt อย่างเดียวป้องกันไม่ได้

หลายองค์กรอาจคิดว่า

“เราเขียน System Prompt ว่าอย่าทำตามคำสั่งจากเอกสารก็พอแล้ว”

แต่ในระบบจริงไม่ควรพึ่ง System Prompt เพียงชั้นเดียว

OWASP ระบุว่า Prompt Injection เป็นความเสี่ยงจากธรรมชาติของการประมวลผล Prompt
และแม้จะใช้ RAG หรือ Fine-tuning ก็ไม่ได้แก้ปัญหาอย่างสมบูรณ์

Microsoft จึงแนะนำแนวคิด Defense in Depth ที่ประกอบด้วยหลายชั้น เช่น Content
Isolation, Detection, Behavioral Monitoring, Policy Enforcement และ
Runtime Controls

หลักคิดสำคัญคือ

อย่าออกแบบระบบโดยสมมติว่า Prompt Injection จะถูก Block ได้ 100%

ควรออกแบบว่า

“ถ้า Prompt Injection หลุดผ่านเข้ามาได้ เราจะจำกัดความเสียหายอย่างไร?”

11. Least Privilege สำคัญมากสำหรับ AI Agent

ถ้า AI Agent มีสิทธิ์

Read Email + Send Email + Read Drive + Delete Files + Access CRM + Run
Code

Prompt Injection เพียงครั้งเดียวอาจมี Impact สูงมาก

แต่ถ้า Agent มีสิทธิ์เฉพาะ

Read เอกสารที่กำหนด

ผลกระทบก็ถูกจำกัดลง

ดังนั้นหลัก Least Privilege ที่ใช้ใน Cybersecurity มานานจึงมีความสำคัญอย่างยิ่งใน
Agentic AI

Agent ควรได้รับ

Minimum Data Access

Minimum Data Access

Minimum Tool Access

Minimum Action Permission

Minimum Duration of Access

และควรแยก

Permission Separation

Read Permission

ออกจาก

Write / Execute / Delete Permission

อย่างชัดเจน

12. Human-in-the-Loop สำหรับ High-impact Action

Action ที่มีผลกระทบสูงไม่ควรถูก Execute โดย AI โดยไม่มีการตรวจสอบตามระดับความเสี่ยง

ตัวอย่างเช่น

ส่งอีเมลภายนอก

โอนเงิน

ลบข้อมูล

เปลี่ยน Permission

Deploy Code

แก้ไข Production System

ส่งข้อมูล Confidential ออกนอกองค์กร

ควรพิจารณาให้มี Human Approval

Flow อาจเป็น

AI proposes action → System shows action + destination + data → Human
verifies → Execute

OpenAI แนะนำให้ผู้ใช้ตรวจสอบรายละเอียดอย่างระมัดระวังก่อนยืนยัน Action ที่มีผลสำคัญ
และหลีกเลี่ยงการให้ Agent มีคำสั่งกว้างเกินความจำเป็น

13. Prompt Injection Detection ไม่ควรเป็น Control เดียว

องค์กรสามารถใช้ระบบตรวจจับ Pattern ที่น่าสงสัย หรือ Prompt Shield
เพื่อช่วยลดความเสี่ยง

แต่ Detection ไม่ควรเป็นกำแพงเพียงชั้นเดียว

เพราะ Attack สามารถเปลี่ยนรูปแบบได้ และบาง Injection อาจซ่อนอยู่ใน

Text HTML Document Code Image Encoded Content

Microsoft ระบุว่า Defense Stack ควรใช้หลายกลไกร่วมกัน เช่น Prompt
Sanitization, Content Isolation, Runtime Monitoring และ Policy-based
Controls

แนวคิดที่เหมาะสมจึงเป็น

Detect + Isolate + Restrict + Verify + Monitor

ไม่ใช่เพียง

Detect → Allow

14. Treat External Content as Untrusted

องค์กรควรสร้าง Trust Boundary ให้ชัดเจนว่า Content ที่มาจากภายนอกคือ Untrusted
Input

เช่น

Email from Internet Website Uploaded Document Third-party
API Search Result External Knowledge Base MCP Server
Response

แม้ Content จะถูกเขียนเป็นภาษาธรรมชาติและดูเหมือนคำสั่ง ก็ไม่ควรได้รับ Authority
เท่ากับ System Instruction หรือ User Intent

นี่เป็นหนึ่งในโจทย์พื้นฐานของ Secure Agent Architecture:

Instruction ≠ Data

และ

Data ≠ Authority

AI ต้องสามารถอ่านข้อมูลโดยไม่ทำให้ข้อมูลนั้นได้รับสิทธิ์ในการควบคุมระบบโดยอัตโนมัติ

15. AI Agent ต้องมี Audit Log

ระบบ AI สำหรับองค์กรควรสามารถตอบย้อนหลังได้ว่า

User สั่งอะไร?

AI อ่านข้อมูลจากไหน?

Retrieve เอกสารอะไร?

Model ตัดสินใจเรียก Tool ไหน?

ส่ง Parameter อะไร?

Tool ทำ Action อะไร?

ข้อมูลถูกส่งไป Destination ไหน?

ใครอนุมัติ?

หากไม่มีข้อมูลเหล่านี้ Incident Response จะยากมาก

เพราะ Security Team อาจรู้เพียงว่า

“AI ทำบางอย่างผิด”

แต่ไม่สามารถ reconstruct Attack Path ได้

16. Prompt Injection Incident Response

องค์กรที่เริ่ม Deploy AI Agent ควรเพิ่ม Prompt Injection เข้าไปใน Incident
Response Playbook

เมื่อสงสัยว่ามีเหตุการณ์ ควรสามารถ

Suspend Agent

Revoke Token

Disable Tool

Terminate Session

Block External Source

Preserve Logs

Identify Exposed Data

Review Actions

Rotate Credentials

Patch / Modify Architecture

และทำ Post-Incident Review

เช่นเดียวกับ Cyber Incident ประเภทอื่น

เป้าหมายไม่ใช่เพียงหยุด Agent

แต่ต้องตอบให้ได้ว่า

“Injection เข้ามาทางไหน และสามารถเดินทางไปถึง Action ได้อย่างไร?”

Prompt Injection Defense Architecture สำหรับองค์กร

Defense in Depth Architecture

องค์กรสามารถออกแบบ Defense in Depth ได้ประมาณนี้

Layer 1 — Identity & Authentication

ยืนยันตัวตน User, Agent, Application และ Tool

Layer 2 — Input Trust Classification

แยก Trusted Instruction ออกจาก Untrusted Content

Layer 3 — Prompt / Content Protection

ตรวจจับ Injection, Suspicious Content และ Malicious Pattern

Layer 4 — Retrieval Security

ควบคุม Knowledge Base, RAG Source และ Document Permission

Layer 5 — Model Guardrails

กำหนด Policy และ Behavioral Constraints

Layer 6 — Tool Authorization

ตรวจสอบสิทธิ์ทุก Tool Call

Layer 7 — Data Loss Prevention

ป้องกัน Sensitive Data ออกจาก Boundary ที่กำหนด

Layer 8 — Human Approval

ใช้กับ High-risk Actions

Layer 9 — Runtime Monitoring

ตรวจจับ Plan Drift, Anomalous Behavior และ Unexpected Tool Calls

Layer 10 — Audit & Incident Response

เก็บหลักฐานและสามารถหยุดระบบได้ทันที

Microsoft แนะนำแนวคิดในทิศทางเดียวกัน โดยเน้น Defense in Depth และ
Information-flow Control แทนการพึ่งกลไกป้องกันเพียงจุดเดียว

Checklist สำหรับ CIO / CISO / AI Governance

ก่อนเปิด AI Agent ใช้งานจริง ลองถาม 10 ข้อนี้

1. AI อ่านข้อมูลจาก Internet หรือ External Source หรือไม่?

2. ระบบแยก Trusted Instruction กับ Untrusted Content อย่างไร?

3. RAG Knowledge Base มีใครสามารถ Upload หรือแก้ไขเอกสารได้บ้าง?

4. Agent เชื่อมต่อ Tool อะไรบ้าง?

5. Tool แต่ละตัวมี Read / Write / Execute Permission ระดับใด?

6. Agent สามารถส่งข้อมูลออกนอกองค์กรได้หรือไม่?

7. High-impact Action ต้องมี Human Approval หรือไม่?

8. มี Prompt Injection Detection และ Runtime Monitoring หรือไม่?

9. สามารถ Audit Tool Call และ Data Flow ย้อนหลังได้หรือไม่?

10. ถ้า Agent ถูก Prompt Injection สามารถหยุด Agent และ Revoke Permission
ได้ทันทีหรือไม่?

ถ้าหลายข้อยังตอบไม่ได้ องค์กรอาจยังไม่พร้อมให้ Agent มี Autonomous Permission
ในระบบสำคัญ

Prompt Injection กับ Zero Trust

แนวคิดของ Zero Trust สามารถนำมาประยุกต์กับ AI ได้อย่างน่าสนใจ

Zero Trust บอกว่า

Never trust, always verify

สำหรับ AI Agent เราอาจขยายเป็น

Never trust content merely because the AI can read it.

Website ไม่ควรได้รับ Authority เพียงเพราะ Agent เปิดมัน

Email ไม่ควรกลายเป็นคำสั่งเพียงเพราะ Agent อ่านมัน

PDF ไม่ควรสามารถสั่ง Tool เพียงเพราะ RAG Retrieve มันขึ้นมา

MCP Server ไม่ควรได้รับสิทธิ์ทั้งหมดเพียงเพราะเชื่อมต่อสำเร็จ

นี่คือแนวคิด Zero Trust for Agentic AI

Prompt Injection เกี่ยวอะไรกับ Shadow AI?

Shadow AI กับ Prompt Injection เป็นความเสี่ยงที่สามารถเชื่อมต่อกันได้

ถ้าพนักงานนำ AI Agent ที่ไม่ได้รับอนุมัติมาเชื่อมกับ

Email + Drive + CRM

องค์กรอาจไม่รู้ว่า Agent มี Permission อะไร

และถ้า Agent นั้นไปอ่าน Content ที่มี Prompt Injection

Attack Path อาจกลายเป็น

Shadow AI → Excessive Permission → Untrusted Content → Prompt
Injection → Tool Abuse → Data Leakage

นี่คือเหตุผลที่ AI Governance ไม่ควรดูเพียงว่า

“อนุญาต AI ตัวไหน?”

แต่ต้องดูด้วยว่า

“AI ตัวนั้นอ่านอะไร เชื่อมอะไร และทำอะไรได้?”

จาก Prompt Injection สู่ AI Security Architecture

ในยุค Chatbot เราอาจคิดว่า Security ของ AI คือการป้องกันไม่ให้มันพูดสิ่งที่ไม่เหมาะสม

แต่ในยุค AI Agent Security Boundary กว้างขึ้นมาก

จาก

Prompt → Response

กลายเป็น

Identity → Prompt → Model → Memory → RAG → Tool → MCP → API → Data →
Action

ทุกจุดสามารถกลายเป็น Trust Boundary ได้

และทุก Connection สามารถเพิ่ม Attack Surface

Prompt Injection จึงไม่ใช่ปัญหาของ Prompt Engineer เพียงอย่างเดียว

แต่เป็นเรื่องของ

Cybersecurity Architecture

Identity Security

Application Security

Data Security

AI Governance

และ Incident Response

บทสรุป: ในยุค AI Agent สิ่งที่ AI อ่าน อาจพยายามกลายเป็นคำสั่ง

Prompt Injection ทำให้เราต้องเปลี่ยนวิธีคิดเกี่ยวกับ Input ของระบบ AI

ใน Software แบบเดิม เราพยายามแยก

Code ออกจาก Data

แต่ใน Generative AI ความท้าทายคือการแยก

Instruction ออกจาก Content

เพราะทั้งสองอย่างอาจถูกเขียนด้วยภาษาธรรมชาติเหมือนกัน

และเมื่อ AI สามารถเชื่อมต่อกับ Email, Cloud Drive, Database, API, MCP
และระบบธุรกิจต่าง ๆ ได้ ความผิดพลาดในการแยกสองสิ่งนี้อาจไม่ได้จบแค่คำตอบผิด

แต่อาจนำไปสู่ Data Exposure, Unauthorized Action หรือ System Compromise
ได้ ขึ้นอยู่กับ Architecture และ Permission ของระบบ

ดังนั้นคำถามสำคัญสำหรับองค์กรไม่ควรมีเพียง

“AI ของเราตรวจจับ Prompt Injection ได้หรือไม่?”

แต่ควรถามว่า

“ถ้า Prompt Injection หลุดผ่านเข้ามาได้ AI
ของเรามีอำนาจมากพอที่จะสร้างความเสียหายได้แค่ไหน?”

นี่คือเหตุผลที่ Secure AI ต้องสร้างจาก

Least Privilege + Trust Boundaries + Data Protection + Human
Approval + Monitoring + Auditability + Defense in Depth

เพราะในยุค Agentic AI

เราไม่ควรเชื่อทุกสิ่งที่ AI อ่าน และไม่ควรให้ AI ทำทุกสิ่งที่มันคิดว่าควรทำ

เกี่ยวกับผู้เขียน

อาจารย์ปรเมศร์ เพียรสกุล ผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยไซเบอร์ (Cybersecurity) ปัญญาประดิษฐ์ (Artificial Intelligence: AI) และการวิเคราะห์ข้อมูลเชิงกลยุทธ์ ปัจจุบันดำรงตำแหน่งประธานเจ้าหน้าที่บริหาร (Chief Executive Officer: CEO) และผู้ก่อตั้ง บริษัท อินเทลลิเจนท์ ดาต้า อนาไลติก จำกัด โดยมุ่งพัฒนาและประยุกต์ใช้เทคโนโลยี เพื่อเปลี่ยนข้อมูลให้เป็นข่าวกรองที่เชื่อถือได้สำหรับการตัดสินใจของผู้บริหารและองค์กรอย่างมีประสิทธิภาพและยั่งยืน