AIエージェントのサプライチェーン攻撃とは、エージェントが実行時に取り込む MCP サーバー・Skill・プラグインなどの外部コンポーネント配信経路を侵害し、業務 AI 実行環境に任意コードや悪意ある指示を注入する攻撃である。

従来のサプライチェーン攻撃が「ライブラリ」「コンテナイメージ」を狙ったのに対し、AIエージェント時代の攻撃面は「実行時に動的にロードする MCP / Skill」へと広がった。Anthropic 自身が認める設計意図と、公開 MCP サーバーの大量露出という現実が、この問題を加速させている。

本ガイドは情シス・SRE・セキュリティ担当者を対象に、(1) 信頼ソースの allowlist 化、(2) 最小権限とサンドボックス、(3) 入出力ガードと監査ログの 3 層防御 を 3 ステップで設計する手順を解説する。読み終えたとき、自社のエージェント運用環境で「最初に何を絞り、何を監視するか」を即決できる状態を目指す。

การโจมตีห่วงโซ่อุปทาน (Supply Chain Attack) ของ AI Agent คือการโจมตีที่มุ่งเน้นไปที่การบุกรุกช่องทางการจัดส่งส่วนประกอบภายนอกที่ Agent ดึงมาใช้ในขณะรันไทม์ เช่น MCP Server, Skill และปลั๊กอิน เพื่อฉีดโค้ดอันตรายหรือคำสั่งที่ไม่พึงประสงค์เข้าไปในสภาพแวดล้อมการทำงานของ AI ในองค์กร

ในขณะที่การโจมตีห่วงโซ่อุปทานแบบเดิมมุ่งเป้าไปที่ "ไลบรารี" หรือ "คอนเทนเนอร์อิมเมจ" แต่ในยุคของ AI Agent พื้นที่การโจมตีได้ขยายวงกว้างไปยัง "MCP / Skill ที่ถูกโหลดแบบไดนามิกในขณะรันไทม์" ซึ่งเจตนาในการออกแบบที่ Anthropic ยอมรับเอง ประกอบกับความเป็นจริงที่มีการเปิดเผย MCP Server สู่สาธารณะเป็นจำนวนมาก กำลังเร่งให้ปัญหานี้ทวีความรุนแรงขึ้น

คู่มือฉบับนี้จัดทำขึ้นสำหรับเจ้าหน้าที่ฝ่ายไอที, SRE และผู้รับผิดชอบด้านความปลอดภัย โดยอธิบายขั้นตอนการออกแบบ การป้องกัน 3 ชั้น (3-Layer Defense) ใน 3 ขั้นตอน ได้แก่ (1) การทำ Allowlist สำหรับแหล่งที่มาที่เชื่อถือได้, (2) การใช้หลักสิทธิ์ขั้นต่ำ (Least Privilege) และ Sandbox, และ (3) การใช้ระบบคัดกรองอินพุต/เอาต์พุต (Input/Output Guard) และบันทึกการตรวจสอบ (Audit Log) เมื่ออ่านจบ คุณจะสามารถตัดสินใจได้ทันทีว่า "ควรจำกัดส่วนใดและควรเฝ้าระวังสิ่งใดเป็นอันดับแรก" ในสภาพแวดล้อมการใช้งาน Agent ขององค์กรคุณ

ในขณะที่การโจมตีห่วงโซ่อุปทาน (Supply Chain Attack) แบบดั้งเดิมมุ่งเป้าไปที่ "ไลบรารีและคอนเทนเนอร์" แต่ในยุคของ AI Agent พื้นที่การโจมตี (Attack Surface) ได้ขยายตัวไปยัง MCP Server, Skill และปลั๊กอินที่ถูกโหลดแบบไดนามิกในขณะรันไทม์ เนื่องจากองค์ประกอบเหล่านี้รับคำสั่งจากภายนอกเพื่อดำเนินการรันคำสั่ง, จัดการไฟล์ และเรียกใช้ API บนเครื่องคอมพิวเตอร์ที่ใช้ปฏิบัติงาน ความเสียหายจึงส่งผลกระทบต่อระบบธุรกิจขององค์กรในทันที

ในส่วนนี้จะสรุปเหตุผลเชิงโครงสร้างที่ทำให้พื้นที่การโจมตีขยายตัวขึ้น รวมถึงกรณีตัวอย่างที่เกิดขึ้นจริง

MCP（Model Context Protocol） は、エージェントが外部のツール・データソース・コードを呼び出すための共通プロトコルだ。基礎は AIエージェントプロトコル（MCP・A2A）入門 で扱った。Skill はこれを拡張し、再利用可能なワークフローを「スキル」として配布する仕組みとして登場している。

実行モデルは 3 つのレイヤで成り立つ。

特に下層の MCP サーバーは、設計上「クライアントから送られたリクエストに応じて OS コマンドを実行できる」性質を持つ。この実行能力こそが、サプライチェーン攻撃の入口となる。

มีการรายงานเหตุการณ์ที่เกี่ยวข้องกับห่วงโซ่อุปทาน (Supply Chain) ของ AI Agent จากแหล่งข้อมูลสาธารณะหลายแห่ง โดยขอยกตัวอย่างกรณีสำคัญ 3 ประการ ดังนี้:

• ช่องโหว่ RCE แบบ "by design" ใน Anthropic MCP: ในรายงานคำแนะนำที่เผยแพร่โดย OX Security เมื่อวันที่ 15 เมษายน 2026 ได้ชี้ให้เห็นว่าการใช้งาน Model Context Protocol (MCP) ในรูปแบบอ้างอิง (Reference Implementation) มีการออกแบบที่เอื้อให้เกิดการรันคำสั่งโดยไม่ได้รับอนุญาต (Arbitrary Command Execution) โดย Anthropic ได้แสดงจุดยืนว่าโมเดลการทำงานแบบ STDIO เป็น "ค่าเริ่มต้นที่ปลอดภัยตามการออกแบบ" และจะไม่ทำการเปลี่ยนแปลงครั้งใหญ่ โดยถือว่าการทำ Sanitization เป็นความรับผิดชอบของผู้ใช้งาน (ที่มา: OX Security / SecurityWeek) ซึ่งคาดว่ามีขอบเขตผลกระทบจากการดาวน์โหลดรวมกว่า 150 ล้านครั้ง
• การเปิดเผย MCP Server สู่สาธารณะเป็นจำนวนมาก: BlueRock Security ได้วิเคราะห์ MCP Server กว่า 7,000 แห่ง และประกาศว่าพบช่องโหว่ที่อาจเป็น SSRF (Server-Side Request Forgery) ประมาณ 36.7% นอกจากนี้ยังมีการรายงานว่ามี MCP Server จำนวนมากที่เปิดเผยอยู่บนเครือข่ายสาธารณะโดยไม่มีการตรวจสอบสิทธิ์ (Authentication)
• การเผยแพร่ทักษะอันตรายผ่าน Marketplace: นักวิจัยด้านความปลอดภัยหลายรายได้รายงานการตรวจพบการแจกจ่ายทักษะ (Skill) ที่เป็นอันตรายผ่านทาง "Skill Marketplace" ของ AI Agent

ในส่วนของความพร้อมด้านการป้องกัน รายงาน "State of AI Security 2026" ของ Cisco ระบุว่ามีองค์กรเพียง ประมาณ 29% เท่านั้นที่มีความพร้อมในการนำ AI แบบ Agent ไปใช้งานจริง ซึ่งแสดงให้เห็นว่าในขณะที่พื้นผิวการโจมตี (Attack Surface) กำลังขยายตัว แต่ความพร้อมของฝ่ายป้องกันยังคงตามไม่ทัน

แนวป้องกันด่านแรกคือการระบุว่า "สามารถรัน MCP Server หรือ Skill ใดได้บ้าง" ผ่านรายการอนุญาต (allowlist) การอนุญาตทั้งหมดโดยค่าเริ่มต้น (default allow-all) นั้นเปรียบเสมือนการไม่ป้องกันเลย และในเมื่อช่องโหว่ในการออกแบบได้ปรากฏชัดเจนแล้ว จุดเริ่มต้นเดียวที่มีคือการที่องค์กรต้องจำกัดความน่าเชื่อถือของเส้นทางเชื่อมต่อด้วยตนเอง

ช่องทางการส่งมอบที่ต้องตรวจสอบสามารถแบ่งออกได้เป็น 3 ประเภท ได้แก่ (1) MCP Server บนเครือข่ายสาธารณะ (2) Skill ที่แจกจ่ายผ่าน Marketplace และ (3) MCP / Skill ที่พัฒนาขึ้นภายในองค์กร ซึ่งแต่ละประเภทมีความเสี่ยงในลักษณะที่แตกต่างกัน

เมื่อใช้งาน MCP Server แบบสาธารณะ ให้ตรวจสอบสิ่งต่อไปนี้เป็นอย่างน้อย:

• มีการระบุวิธีการยืนยันตัวตน (OAuth, API Key, mTLS) ไว้ในเอกสารอย่างชัดเจน และไม่มี Endpoint ที่ไม่ต้องยืนยันตัวตน
• มีการระบุข้อมูลองค์กรของผู้ให้บริการ ข้อมูลติดต่อ และช่องทางการรายงานช่องโหว่ไว้อย่างชัดเจน
• การสื่อสารได้รับการเข้ารหัสด้วย TLS และมีการป้องกันเพิ่มเติม เช่น Certificate Pinning
• มีการเปิดเผย SBOM และประวัติการเปลี่ยนแปลงของผู้ให้บริการ เพื่อให้สามารถติดตามช่องโหว่ของไลบรารีที่ใช้งานอยู่ได้

MCP แบบสาธารณะที่ใครก็สามารถเข้าถึงได้โดยไม่ต้องยืนยันตัวตนนั้นไม่เหมาะสำหรับการใช้งานในองค์กร ในช่วงแรกควรจำกัดการใช้งานไว้เพียง "MCP Server ที่อยู่ภายในเครือข่ายของบริษัท" หรือ "MCP ที่เชื่อมต่อโดยตรงกับผู้ให้บริการที่มีการยืนยันตัวตน" เท่านั้น ส่วนการนำ MCP แบบสาธารณะภายนอกมาใช้งานควรใช้วิธีการประเมินและทยอยนำเข้ามาใช้ตามความเหมาะสมจะเป็นแนวทางที่ปฏิบัติได้จริงมากกว่า

ควรจัดการกับ Skill และแพ็กเกจ MCP โดยตั้งสมมติฐานว่า "สามารถถูกดัดแปลงแก้ไขได้เช่นเดียวกับคอนเทนเนอร์อิมเมจหรือแพ็กเกจ npm"

• การตรวจสอบลายเซ็น (Signature Verification): ตรวจสอบให้แน่ใจว่าสิ่งที่แจกจ่ายมานั้นมีลายเซ็นของผู้ให้บริการ (เช่น Sigstore / cosign) และนำเข้าเฉพาะสิ่งที่ผ่านการตรวจสอบแล้วเท่านั้น
• SBOM: ดึงรายการไลบรารีที่ต้องพึ่งพา (Dependency) ซึ่งใช้ภายใน Skill และนำไปตรวจสอบกับ CVE ที่ทราบข้อมูลแล้ว
• การล็อกค่าแฮช (Hash Pinning): บันทึกค่าแฮช ณ เวลาที่นำเข้า และคำนวณใหม่เป็นระยะเพื่อเปรียบเทียบว่ามีการดัดแปลงแก้ไขหรือไม่

แนวทางในอุดมคติคือการมี "Internal Mirror" ที่ไม่อนุญาตให้อัปเดตอัตโนมัติจาก Marketplace และแจกจ่ายเฉพาะเวอร์ชันที่ผ่านการตรวจสอบภายในบริษัทแล้วเท่านั้น แม้ว่าการทำ Internal Mirror อาจดูเป็นการลงทุนที่มากเกินไป แต่เมื่อพิจารณาจากข้อมูลที่มีการตรวจพบ Skill ที่มีเจตนาร้ายหมุนเวียนอยู่จริง การทำเช่นนี้ถือเป็นทางเลือกที่สมเหตุสมผลในฐานะต้นทุนเพื่อดึงขอบเขตของห่วงโซ่อุปทาน (Supply Chain) กลับมาอยู่ภายใต้การควบคุมขององค์กร

การจำกัดสิทธิ์ของคำสั่งหรือ API ที่ MCP / Skill เรียกใช้ และการทำ Sandbox การทำงานของ Agent ทั้งในระดับ OS และเครือข่าย จะช่วยจำกัดความเสียหายให้เกิดขึ้นเฉพาะจุดได้ แม้จะมีเครื่องมือที่เป็นอันตรายหลุดรอดเข้ามาก็ตาม บทบาทของ Step 2 คือการจำกัดขอบเขตความเสียหายทางกายภาพ โดยตั้งอยู่บนสมมติฐานที่ว่าช่องโหว่แบบ "by design" อาจทำให้เกิดพฤติกรรมที่ไม่พึงประสงค์ได้

การแยกสิทธิ์ (Privilege Separation) ต้องได้รับการออกแบบทั้งในระดับ OS และระดับการสื่อสาร (Communication Layer)

โดยพื้นฐานแล้ว ควรแยก Agent, MCP Client และ MCP Server ออกจากกันในบริบทการทำงาน (Execution Context) ที่แตกต่างกัน

สถานะที่ว่า "รันด้วย Docker ไปก่อน" ในความเป็นจริงมักเป็นกรณีที่มีการแยกส่วนไม่เพียงพอ การตั้งค่าที่รันด้วยสิทธิ์ root ภายในคอนเทนเนอร์, การ Mount Docker socket ของโฮสต์ หรือการแชร์ /var/run ไม่สามารถเรียกว่าเป็น Sandbox ได้ แนวทางที่ปลอดภัยคือการจำกัดชุดคำสั่งที่ Skill สามารถรันได้ให้เหลือเพียงไฟล์ที่อนุญาต (Allowlist) เท่านั้น และบล็อก System Call อื่นๆ ทั้งหมด

มีการชี้ให้เห็นว่า MCP Server เกือบ 40% อาจมีช่องโหว่ SSRF (จากการวิเคราะห์โดย BlueRock Security) ซึ่งเป็นปรากฏการณ์ที่ MCP / Skill สามารถ "ส่งคำขอ HTTP ไปยังเครือข่ายภายในหรือจุดเชื่อมต่อข้อมูลเมตา (Metadata Endpoint) ของระบบคลาวด์ได้โดยอิสระ"

การป้องกันหลักคือการทำ Allowlist สำหรับ egress (การสื่อสารขาออก) ดังนี้:

• บล็อกการสื่อสารทั้งหมด ไปยัง Metadata Endpoint 169.254.169.254 (แม้จะบังคับใช้ IMDSv2 แล้ว ก็ควรใช้เป็นเกราะป้องกันเพิ่มเติม)
• บล็อกการสื่อสารไปยังช่วง IP ส่วนตัว (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ฯลฯ) ยกเว้นปลายทางที่จำเป็นต่อการปฏิบัติงาน
• จำกัดการสื่อสารภายนอกด้วย HTTPS และใช้ Allowlist ของโดเมน
• พิจารณาการโจมตีแบบ DNS Rebinding โดยเพิ่มการตรวจสอบซ้ำหลังจากแก้ไข IP (IP resolution) แล้ว

สภาพแวดล้อมการทำงานของ MCP / Skill ที่ไม่มีการควบคุม egress มีความเสี่ยงที่จะถูกขโมย Temporary Credentials จาก IAM Role ของ AWS หากใช้งานบนระบบคลาวด์ ควรปฏิบัติต่อตัวกรอง egress ว่าไม่ใช่แค่ "มีไว้ก็ดี" แต่เป็น "ความเสี่ยงที่เกิดขึ้นจริงหากไม่มี"

การบันทึก Input Prompt และ Output Action ของ MCP / Skill รวมถึงการตรวจจับรูปแบบที่ผิดปกติ จะช่วยให้สามารถตรวจพบการโจมตีได้ตั้งแต่เนิ่นๆ และปฏิบัติตามข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ (Compliance) เช่น PDPA ได้ในเวลาเดียวกัน หาก Step 1 และ 2 คือการป้องกันเพื่อ "จำกัดการบุกรุก" Step 3 ก็คือเลเยอร์สำหรับ "ตรวจจับหลังจากถูกบุกรุกและแสดงความรับผิดชอบ (Accountability)"

การมองว่า Input/Output Guard เป็นส่วนขยายของรูปแบบที่ได้อภิปรายไว้ใน มาตรการรับมือ Prompt Injection และ การติดตั้ง AI Guardrails จะช่วยให้เข้าใจโครงสร้างได้ง่ายขึ้น

MCP / Skill の入力経路は 3 つある。(1) ユーザーからの直接プロンプト、(2) RAG・データベース・ファイルから取り込まれた文字列、(3) 別の MCP サーバーや別エージェントからの応答。

特に注意すべきは (2) と (3) で、ユーザーが意図せずデータ経由で攻撃指示を注入される「間接プロンプトインジェクション」だ。

「全部のリクエストを LLM で精査する」のは現実的でないことが多いため、書き込み・削除・外部通信を伴うツール呼び出しのみ重い検査を入れる方針が、コストとリスクのバランスとして取りやすい。

การเรียกใช้ MCP / Skill ควรบันทึกเป็น Structured Log โดยระบุว่า "เมื่อใด ใคร เอเจนต์ใด เครื่องมือใด อาร์กิวเมนต์ใด และผลลัพธ์คืออะไร" โดยมีรายการที่ควรมีในบันทึกขั้นต่ำดังนี้:

• Request ID (สามารถเชื่อมโยงกับ Agent Session ได้)
• Agent ID และ User ID ของผู้เรียกใช้ (กรณีเป็น HITL ให้ระบุผู้อนุมัติด้วย)
• ชื่อเครื่องมือและพารามิเตอร์ (ต้องทำ Masking ข้อมูล PII)
• ขนาดของค่าที่ส่งกลับและปลายทางของการสื่อสารภายนอก
• การเกิดข้อยกเว้น (Exception) หรือการหมดเวลา (Timeout)

สัญญาณสำหรับการตรวจจับความผิดปกติที่พบบ่อย ได้แก่ (a) การเรียกใช้เครื่องมือจำนวนมากในเวลาอันสั้น (b) การส่งข้อมูลออก (Egress) ไปยังโดเมนที่ไม่คุ้นเคย (c) การอ่านไฟล์จำนวนมาก และ (d) การส่งข้อมูลที่มีข้อมูลส่วนบุคคลออกไปยังภายนอก สิ่งเหล่านี้สามารถเริ่มต้นด้วยกฎง่ายๆ ที่รวมเข้ากับเครื่องมือ SIEM / SOC ที่มีอยู่ เพื่อให้สามารถมองเห็นภาพรวมได้โดยใช้เงินลงทุนเริ่มต้นต่ำ

Audit Log ไม่เพียงแต่ใช้สำหรับการตรวจจับการโจมตีเท่านั้น แต่ยังมีบทบาทสำคัญในการ รับประกันว่า "สามารถแสดงประวัติการเข้าถึงข้อมูลส่วนบุคคลได้" เพื่อรองรับ PDPA และการตรวจสอบ โดยควรนำไปใช้ร่วมกับการ เข้ารหัสข้อมูล เช่น AES-256 เพื่อให้เกิดทั้งความลับของข้อมูลในขณะจัดเก็บ (Data at Rest) และความสามารถในการตรวจสอบย้อนกลับ (Traceability) ไปพร้อมกัน

ความจริงก็คือ สมมติฐานที่ว่า "การตั้งค่าเริ่มต้นก็เพียงพอแล้ว" หรือ "เครือข่ายภายในองค์กรนั้นปลอดภัย" สำหรับ MCP / Skill นั้นได้พังทลายลงไปแล้ว ความล้มเหลวที่พบบ่อยที่สุดเกิดจากความมั่นใจในโครงสร้างที่มากเกินไป

ในที่นี้ เราจะหยิบยกตัวอย่างทั่วไป 2 ประการที่พบเห็นได้มานำเสนอ

誤解として最も多いのは「ローカルマシンで動かしているから外部には漏れない」という考え方だ。Anthropic の MCP リファレンス実装における脆弱性の核心は、ローカル実行であってもユーザーのマシン上で任意のコマンドを実行できてしまう点にあった。具体的に何が起きるのかを整理する。

• ブラウザに保存された Cookie、パスワード、SSH 鍵の窃取
• 開発者の PC から到達可能なクラウド管理コンソール（AWS / GCP）への横移動（ラテラルムーブメント）
• IDE 内に保存されている別案件のソースコードや顧客データの抜き出し

「ローカル」は「企業の境界の外側」ではなく、業務システムへ接続可能な高権限を持つ別のホストとして扱うのが正しい。社内ガイドラインにおいて、MCP / Skill を実行する PC が本番 DB へ直接アクセスできない構成にし、必要に応じて踏み台サーバーや短命クレデンシャルを経由する運用に切り替えることで、被害範囲を大幅に縮小できる。

อีกรูปแบบที่พบบ่อยคือ การตั้งค่าเพื่อความสะดวกในการพัฒนาหลุดเข้าไปในสภาพแวดล้อมจริง (Production)

• เซิร์ฟเวอร์ MCP ที่ไม่มีการตรวจสอบสิทธิ์ซึ่งใช้ในการพัฒนา ยังคงค้างอยู่ใน Docker image ที่นำไป Deploy จริง
• ตัวแปรสภาพแวดล้อม (Environment variable) MCP_ALLOW_ALL=true ถูกตั้งค่าไว้ในระบบจริงด้วย
• API ที่เปิด CORS ไว้ทั้งหมดเพื่อการดีบั๊กยังคงทำงานอยู่ในระบบจริง

สิ่งเหล่านี้เป็นความผิดพลาดในการกำหนดค่าแบบคลาสสิก แต่ในยุคของ AI Agent ผลกระทบจะขยายวงกว้างขึ้น วิธีที่มีประสิทธิภาพคือการแยกไฟล์กำหนดค่า MCP / Skill สำหรับการพัฒนา, การทดสอบ (Staging) และการใช้งานจริง (Production) ออกจากกัน และใช้กลไกใน CI/CD Pipeline เพื่อปฏิเสธ "รายการ MCP ที่ไม่อนุญาตให้ใช้ใน Production" ในระหว่างขั้นตอนการ Build นอกจากนี้ การจัดการโครงสร้างพื้นฐานด้วย Infrastructure as Code และรวมไว้ในขั้นตอนการทำ Code Review จะช่วยให้ตรวจพบข้อผิดพลาดเหล่านี้ได้ง่ายขึ้น

ลำดับความสำคัญในการป้องกัน MCP / Skill คือ "การสำรวจการใช้งานในปัจจุบัน → การทำ allowlist → การจำกัดสิทธิ์ให้น้อยที่สุด → การตรวจสอบ" หากพยายามดำเนินการทั้งหมดพร้อมกันมักจะล้มเหลว ในส่วนนี้จะตอบคำถาม 2 ข้อที่พบบ่อยที่สุดในการปฏิบัติงานจริง

Q. บริษัทที่ปฏิบัติตาม PDPA ของไทยอยู่แล้ว ควรดำเนินการอย่างไรเพิ่มเติมในการใช้งาน AI Agent?

ในบริบทของ PDPA เมื่อ AI Agent มีการเข้าถึงข้อมูลส่วนบุคคล จำเป็นต้องดำเนินการเพิ่มเติมใน 4 ประเด็น ได้แก่ (1) การระบุวัตถุประสงค์ในการประมวลผล (2) การบันทึกรายการเข้าถึงข้อมูล (3) การจำกัดการโอนข้อมูลข้ามพรมแดน และ (4) การตอบสนองต่อคำร้องขอจากเจ้าของข้อมูลส่วนบุคคล

ในทางปฏิบัติ ควรมีการเตรียมความพร้อมดังนี้:

• ติดแท็ก "ประเภทของข้อมูลส่วนบุคคลที่ประมวลผล" ไว้ในบันทึกการตรวจสอบ (Audit Log) ของ MCP / Skill
• แยก Skill ที่จัดการข้อมูลส่วนบุคคลไว้ในกลุ่มเฉพาะ และจำกัดสิทธิ์ในการเผยแพร่ให้เฉพาะบุคลากรที่ผ่านการอบรมด้าน PDPA เท่านั้น
• สำหรับ MCP ที่มีการส่งข้อมูลข้ามพรมแดน (เช่น การเรียกใช้ API ในต่างประเทศ) ให้ใช้ระบบ Egress Filter ร่วมกับกลไกการขอความยินยอมล่วงหน้า
• กำหนดระยะเวลาการเก็บรักษาบันทึกข้อมูล (Log Retention) ให้ยาวนานเพียงพอตามข้อกำหนดทางธุรกิจ เพื่อให้สามารถตอบสนองต่อคำร้องขอเปิดเผยประวัติการเข้าถึงข้อมูลจากเจ้าของข้อมูลได้

เมื่อนำไปใช้ร่วมกับรูปแบบการจัดการกุญแจเข้ารหัสที่กล่าวถึงใน การนำ AES-256 มาใช้เพื่อรองรับ PDPA ของไทย จะช่วยให้สามารถปฏิบัติตามข้อกำหนดด้านการตรวจสอบได้ง่ายขึ้น ทั้งในส่วนของการจัดเก็บข้อมูลและการสื่อสารข้อมูล

Q. หากมี SOC / SIEM อยู่แล้ว ควรบูรณาการการตรวจสอบ AI Agent อย่างไร?

แทนที่จะสร้างโครงสร้างพื้นฐานการตรวจสอบใหม่ การนำ "MCP / Skill calling" เข้าสู่ SIEM ที่มีอยู่เดิมในฐานะแหล่งข้อมูลใหม่ถือเป็นแนวทางที่สมเหตุสมผลที่สุด โดยขั้นตอนแรกที่แนะนำมี 4 ประการ ดังนี้:

1. กำหนดมาตรฐานบันทึก (Log) ของ MCP / Skill ให้อยู่ในรูปแบบ JSON Lines และส่งเข้าสู่ช่องทางการนำเข้าข้อมูลของ SIEM เดิม
2. นำกฎการตรวจจับการ Jailbreak และการรั่วไหลของข้อมูลที่มีอยู่เดิม มาประยุกต์ใช้กับเหตุการณ์ tool_call ด้วย
3. ลงทะเบียนเซสชันของ AI Agent ให้เป็นเอนทิตีที่เทียบเท่ากับ "User Session"
4. ยกระดับความสำคัญของการเรียกใช้เครื่องมือที่มีความเสี่ยงสูง (เช่น exec, http_post, การลบไฟล์ ฯลฯ) ให้เป็นคลาสการแจ้งเตือนแยกต่างหาก

หากมุ่งเป้าไปที่การทำให้ SOC เดิมสามารถจัดการ AI Agent ได้เสมือนเป็น Workload ใหม่หนึ่งรายการ โดยไม่จำเป็นต้องจัดตั้ง "ทีมตรวจสอบเฉพาะทางด้าน AI" ขึ้นมาใหม่ จะช่วยให้เกิดความยั่งยืนทั้งในด้านบุคลากรและการดำเนินงาน สำหรับการฝึกซ้อมในมุมมองของผู้โจมตี สามารถศึกษาได้จาก คู่มือการปฏิบัติ AI Red Teaming ซึ่งควรนำไปปรับใช้ควบคู่ไปกับการฝึกซ้อมด้านการป้องกัน

การโจมตีห่วงโซ่อุปทาน (Supply Chain Attack) ของ AI Agent ได้นำมาซึ่ง พื้นผิวการโจมตี (Attack Surface) ที่มาตรการรักษาความปลอดภัยแบบเดิมไม่ได้คาดคิดไว้ ให้กับองค์กร เนื่องจากการเกิดขึ้นของช่องทางการส่งมอบใหม่ที่เรียกว่า MCP และ Skill รวมถึงการเลือกใช้การออกแบบที่ Anthropic ยอมรับเองว่าเป็น "by design"

การป้องกันไม่ได้ขึ้นอยู่กับเครื่องมือเพียงอย่างเดียว แต่ต้องออกแบบเป็น 3 ชั้น ดังนี้:

• Step 1: จำกัด MCP / Skill ที่จะนำมาใช้ด้วย Allowlist และตรวจสอบช่องทางการส่งมอบด้วยลายเซ็นดิจิทัล (Signature) และ SBOM
• Step 2: ดำเนินการใน Sandbox ที่มีสิทธิ์จำกัด (Least Privilege) และตัดการเชื่อมต่อ SSRF / Egress ในระดับกายภาพ
• Step 3: บันทึกการเรียกใช้งานทั้งหมดลงใน Audit Log เพื่อใช้ในการตรวจจับความผิดปกติ และเชื่อมโยงกับข้อกำหนดด้าน PDPA / SOC

การเตรียมความพร้อมทั้งหมดในคราวเดียวนั้นไม่สมเหตุสมผล การเริ่มต้นจากการสำรวจการใช้งาน MCP / Skill ในปัจจุบัน และจำกัดการใช้ MCP สาธารณะก่อน ถือเป็นก้าวแรกที่คุ้มค่าที่สุด

สำหรับคู่มือที่เกี่ยวข้อง คุณสามารถอ่าน AI Agent Protocol (MCP・A2A) Introduction, AI Guardrails Implementation, AI Red Teaming และ Claude Mythos and Project Glasswing ควบคู่กันไป เพื่อสร้างแนวป้องกันการใช้งาน AI Agent ให้มีความครอบคลุมทั้งในมุมของการตรวจจับและการโจมตี