Reconix LogoReconix

การประเมินความปลอดภัย AI และ LLM

AI/LLM Application Penetration Testing

Chatbot, RAG Pipeline และ AI Agent คือช่องทางโจมตีใหม่ที่หลายองค์กรมองข้าม เราเข้าโจมตีด้วยมุมมองเดียวกับผู้ไม่หวังดี ทั้ง Prompt Injection, Jailbreak, การลักลอบดึงข้อมูล และการหลอกให้ Agent ใช้ Tool ในทางที่เป็นอันตราย แล้วส่งมอบแนวทางปิดช่องโหว่ให้คุณ

ในวงการ AI เรียกบริการนี้ว่า AI Red Teaming ด้วย ส่วน Reconix ใช้คำว่า Red Team กับการทดสอบแบบมุ่งเป้าหมาย (Objective-led) เท่านั้น

นัดหมายขอคำปรึกษา

AI/LLM Application Penetration Testing คืออะไร?

AI/LLM Application Penetration Testing คือการทดสอบเชิงรุกกับ LLM Application และ AI Agent ที่ต่อยอดจากโมเดล เราโจมตีฟีเจอร์ AI ของคุณในมุมที่ผู้ใช้และแหล่งข้อมูลเข้าถึงได้ ผ่าน System Prompt ข้อมูลที่ระบบดึงมาใช้ และ Tool ทุกตัวที่ระบบเรียกได้ แล้วหาวิธีทำให้ระบบทำในสิ่งที่ควรปฏิเสธ ไม่ว่าจะเป็นการเปิดเผยข้อมูลของผู้ใช้รายอื่น การรันคำสั่งที่ไม่ได้รับอนุญาต หรือการทำตามคำสั่งที่แอบซ่อนมาในเอกสาร

การทดสอบเจาะระบบแบบเดิมจะตรวจเฉพาะแอปที่หุ้มโมเดลอยู่ แต่แทบไม่แตะจุดอ่อนของตัวโมเดลเอง Prompt Injection ไม่ขึ้นในผลสแกน SAST และ Jailbreak ที่เปลี่ยน Support Bot ให้กลายเป็นช่องทางปล่อยข้อมูลก็ไม่ถูกบันทึกเป็น CVE ช่องโหว่กลุ่มนี้เป็นปัญหาเชิงพฤติกรรม ทางเดียวที่จะเจอคือลงมือโจมตีพฤติกรรมนั้นโดยตรง

เราทดสอบตาม OWASP Top 10 for LLM Applications 2025, OWASP AI Testing Guide v1 และ MITRE ATLAS รายงานที่คุณได้รับจะระบุทุกการโจมตีที่สำเร็จ พร้อม Prompt ที่ใช้ ข้อมูลหรือการกระทำที่หลุดออกไป และมาตรการที่ใช้ปิดช่องโหว่นั้น

สิ่งที่การทดสอบนี้หาเจอ

  • Prompt Injection ทั้งทางตรงและทางอ้อม รวมถึง Payload ที่แฝงอยู่ในเอกสารที่โมเดลดึงมาอ่าน
  • Jailbreak ที่หลบเลี่ยงคำสั่งด้านความปลอดภัยและนโยบายการกรองเนื้อหา
  • การรั่วไหลของ System Prompt และ Context ผ่านหน้าแชท
  • ข้อมูลรั่วข้ามผู้ใช้ในระบบ RAG Pipeline แบบ Multi-tenant
  • การใช้ Tool และ Function Call ในทางมิชอบ จนนำไปสู่การกระทำที่ Agent ไม่ควรทำ
  • Insecure Output Handling ที่ทำให้ข้อความจากโมเดลกลายเป็นช่องโหว่ XSS หรือ SQL Injection

AI/LLM Application Pentest vs. Penetration Testing ทั่วไป

จำเป็นทั้งคู่ แต่ค้นเจอช่องโหว่คนละกลุ่ม และไม่มีอย่างไหนแทนกันได้

AI/LLM Application Pentest

  • มุ่งโจมตีพฤติกรรมของโมเดล ทั้ง Injection, Jailbreak และการรั่วไหลของข้อมูล
  • ทดสอบ System Prompt, ข้อมูล RAG และการเรียกใช้ Tool
  • จับการรั่วข้อมูลข้ามผู้ใช้ในระบบ Multi-tenant
  • ทดสอบขอบเขตการตัดสินใจของ Agent และปัญหา Excessive Agency
  • อ้างอิง OWASP Top 10 for LLM Applications
  • ผลลัพธ์อิงพฤติกรรมจริง ทั้ง Prompt ที่ใช้ คำตอบ และวิธีแก้

Penetration Testing ทั่วไป

  • มุ่งโจมตีแอปและโครงสร้างพื้นฐานที่อยู่รอบโมเดล
  • ทดสอบ Auth, Access Control, Network และ Config
  • ค้นเจอช่องโหว่รูปแบบที่รู้จักและ CVE
  • ขอบเขตอยู่ที่โค้ดและ Stack ไม่ใช่ตัวโมเดล
  • อ้างอิง OWASP Top 10 สำหรับ Web หรือ Mobile
  • ผลลัพธ์เชิงเทคนิค ทั้ง Endpoint, Exploit และแนวทาง Patch

เมื่อไรที่คุณต้องการ AI/LLM Pentest

ถ้าคุณเปิดใช้งานหรือกำลังจะเปิดฟีเจอร์ LLM ที่แตะข้อมูลลูกค้า ลงมือทำ Action หรือสื่อสารในนามแบรนด์ของคุณ นั่นแปลว่าโมเดลขึ้น Production แล้ว และช่องทางโจมตีของมันก็ขึ้นตามไปด้วย การ Pentest เฉพาะแอปที่อยู่รอบๆ ไม่ได้บอกคุณว่าแค่ Support Ticket ใบเดียวจะยึด Agent ของคุณได้หรือไม่

ควรทำ AI/LLM Pentest ก่อนเปิดใช้งานทุกระบบที่ผู้ใช้ภายนอกเข้าถึงได้ ผลการทดสอบใช้ได้กับ Build ที่เราทดสอบ โดย System Prompt เวอร์ชันโมเดล และชุด Tool จะคงที่ตลอดช่วงทดสอบ

สิ่งที่เราทดสอบ

เรากำหนดขอบเขตแยกตาม AI แต่ละระบบ ตามสิ่งที่ระบบนั้นเข้าถึงได้ และแต่ละ Tier ครอบคลุมทุกการทดสอบของ Tier ที่อยู่ต่ำกว่า

Tier 1: Chat

สนทนาได้อย่างเดียว ไม่มีข้อมูลหรือ Tool นอกเหนือจาก Prompt เราทดสอบ Jailbreak และการหลบเลี่ยงนโยบาย การรั่วของ System Prompt การจัดการ Output ข้อมูลเท็จ และการใช้งานเกิน Rate Limit จนต้นทุนบานปลาย อ้างอิง OWASP LLM01, 05, 07, 09, 10

Tier 2: Read only

อ่านข้อมูลที่แอปใส่ไว้ใน Context เช่น ข้อมูลของผู้ใช้ที่เข้าสู่ระบบอยู่ เพิ่มการทดสอบการเปิดเผยข้อมูลสำคัญ และข้อมูลรั่วข้ามผู้ใช้หรือข้าม Tenant อ้างอิงเพิ่ม OWASP LLM02

Tier 3: Reads via tools/RAG

ดึงข้อมูลจากฐานความรู้ เอกสาร หรือ API ได้เอง เพิ่มการทดสอบ Indirect Injection ผ่านเนื้อหาที่ดึงมา การปนเปื้อนฐานความรู้ และจุดอ่อนของ Vector Store อ้างอิงเพิ่ม OWASP LLM01, 04, 08

Tier 4: Acts via tools

เขียน ส่ง หรือแก้ไขข้อมูลผ่าน Tool Call เพิ่มการทดสอบ Excessive Agency, Tool Call ที่ไม่ได้รับอนุญาต และการเชื่อม Action หลายขั้นจนเกิดผลกระทบจริง อ้างอิงเพิ่ม OWASP LLM06

ขั้นตอนการทำงาน

การโจมตีอย่างเป็นระบบ วางแผนเป็นขั้นตอนตั้งแต่กำหนดขอบเขตจนถึงทดสอบซ้ำ

01

Scope & Threat Model

เราไล่ดูว่า AI อ่านอะไรได้ พูดอะไรได้ และทำอะไรได้บ้าง ทั้งแหล่งข้อมูล Tool ผู้ใช้ และผลลัพธ์ที่ร้ายแรงที่สุดของแต่ละจุด เพื่อกำหนดเป้าหมายที่จะโจมตี

02

Recon & Behavior Mapping

ศึกษาว่าโมเดลตอบสนองอย่างไร Guardrail วางไว้ตรงไหน และ System Prompt น่าจะมีอะไรบ้าง ก่อนลงมือโจมตีจริง

03

Direct Prompt Attacks

Jailbreak การสวมบทบาท เทคนิค Encoding และการ Override คำสั่ง พุ่งเป้าตรงไปที่หน้าแชทเพื่อเอาชนะชั้นความปลอดภัย

04

Indirect Injection

แฝง Payload ไว้ในจุดที่โมเดลอ่านข้อมูล ทั้งเอกสาร หน้าเว็บ แหล่ง RAG และ Field ที่ผู้ใช้กรอก แล้วดูว่าโมเดลทำตามหรือไม่

05

Tool & Agency Abuse

สำหรับระบบ Agent เราพยายามสั่งให้เกิด Tool Call ที่ไม่ได้รับอนุญาต การใช้สิทธิ์เกินขอบเขต และการเชื่อม Action หลายขั้นที่เปลี่ยนคำขอธรรมดาให้กลายเป็นผลกระทบจริง

06

Data Exfiltration

ทดสอบว่าโมเดลปล่อย System Prompt ข้อมูลของผู้ใช้รายอื่น หรือ Context ที่ไม่ควรเปิดเผยออกมาหรือไม่ และข้อมูลนั้นรั่วไปได้ไกลแค่ไหน

07

Impact Analysis & Reporting

เราบันทึกทุกการโจมตีที่สำเร็จ พร้อม Prompt ที่ใช้ คำตอบที่ได้ ข้อมูลหรือ Action ที่หลุด และระดับความรุนแรงที่นำไปแก้ไขได้ทันที

08

Remediation & Retest

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

สิ่งที่คุณได้รับ

เมื่อปิดงาน คุณได้รับเอกสารส่งมอบ 5 รายการ

  • รายงานทางเทคนิค (Technical report)

    ทุกช่องโหว่ระบุ OWASP LLM ID ระดับความรุนแรงตาม OWASP Risk Rating Prompt หรือ Payload ที่ใช้จริง transcript ฉบับเต็ม ข้อมูลหรือการกระทำที่หลุดออกไป อัตราความสำเร็จ และมาตรการควบคุมที่ใช้แก้ไข

  • บทสรุปสำหรับผู้บริหาร (Executive summary)

    รายการเป้าหมายพร้อม Tier ที่ทดสอบ ผลกระทบร้ายแรงที่สุดที่พิสูจน์ได้ของแต่ละเป้าหมาย และส่วนที่ยังทดสอบไม่ครอบคลุม

  • รายงานความครอบคลุม (Coverage statement)

    ทุกหัวข้อการทดสอบมีสถานะกำกับว่าทดสอบแล้ว ไม่เกี่ยวข้อง หรือติดขัดจนทดสอบไม่ได้ พร้อมเหตุผล

  • การทดสอบซ้ำ (Retest)

    ทดสอบซ้ำทุกช่องโหว่หนึ่งรอบ โดยใช้ชุดการโจมตีเดิมและจำนวนครั้งที่พยายามเท่าเดิม

  • บันทึกปิดงาน (Close-out record)

    รายการ Payload ที่ฝังไว้และบัญชีทดสอบทั้งหมด พร้อมการยืนยันว่าลบออกแล้ว

อ้างอิง OWASP Top 10 for LLM Applications

ทุกช่องโหว่ที่พบจะอ้างอิงกับ OWASP Top 10 for LLM Applications ที่ดูแลโดย OWASP GenAI Security Project ทำให้ทีมของคุณมีภาษากลางในการสื่อสารว่าอะไรพลาด และพลาดเพราะอะไร

รายงานจะจับคู่ทุกการโจมตีที่สำเร็จเข้ากับ OWASP LLM ID เพื่อให้นักพัฒนาและผู้ตรวจสอบเห็นทั้งระดับความเสี่ยง หลักฐาน และวิธีแก้ไขได้ในที่เดียว

LLM01

Prompt Injection

อินพุตที่ออกแบบมาเพื่อลบล้างคำสั่งของโมเดล

LLM02

Sensitive Information Disclosure

โมเดลเผยข้อมูลที่ควรปกปิด

LLM03

Supply Chain

โมเดล ชุดข้อมูล หรือ Plugin ที่ถูกแทรกแซง

LLM04

Data & Model Poisoning

ข้อมูล Train หรือ Retrieval ที่ปนเปื้อนจนผลลัพธ์เพี้ยน

LLM05

Improper Output Handling

ระบบเชื่อข้อความจากโมเดลจนเกิด XSS หรือ SQLi

LLM06

Excessive Agency

Agent มีสิทธิ์มากเกินความจำเป็น

LLM07

System Prompt Leakage

ผู้ใช้ดึงคำสั่งที่ซ่อนไว้ออกมาได้

LLM08

Vector & Embedding Weaknesses

ช่องโหว่ในชั้น Retrieval และ Embedding ของ RAG

LLM09

Misinformation

คำตอบที่ผิดแต่ดูน่าเชื่อจนผู้ใช้ทำตาม

LLM10

Unbounded Consumption

การใช้ทรัพยากรเกินขีดจนเกิด DoS หรือค่าใช้จ่ายบานปลาย

รายงานของเราตอบข้อกำหนดแต่ละข้ออย่างไร

รายงานเป็นหลักฐานที่องค์กรของคุณใช้ยื่นประกอบข้อกำหนดเหล่านี้ และไม่ได้รับรองว่าองค์กรปฏิบัติตามข้อกำหนดแล้ว

  • แนวนโยบาย ธปท. เรื่อง การบริหารจัดการความเสี่ยงของการใช้งานระบบปัญญาประดิษฐ์ (12 ก.ย. 2568) ข้อ 4.4 ส่วนที่ 2 (3.2)

    ใช้กับสถาบันการเงิน สถาบันการเงินเฉพาะกิจ และผู้ประกอบธุรกิจระบบและบริการการชำระเงินภายใต้การกำกับ

    สิ่งที่ข้อนี้คาดหวัง
    ควรทดสอบรูปแบบการโจมตีต่าง ๆ อย่างต่อเนื่อง เพื่อให้มั่นใจว่าระบบ AI ไม่มีช่องโหว่ที่กระทบต่อความปลอดภัยของโมเดลและระบบ IT
    สิ่งที่รายงานของเราให้
    การทดสอบการโจมตีหนึ่งรอบ พร้อมหลักฐานพิสูจน์ทุกช่องโหว่ และการทดสอบซ้ำหนึ่งรอบ
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    ส่วนที่เป็น "อย่างต่อเนื่อง" องค์กรของคุณดำเนินการเอง งานหนึ่งครอบคลุม Build ที่ทดสอบหนึ่งชุด ส่วน data poisoning และ adversarial attack ต่อโมเดลต้องใช้โมดูลด้านโมเดลหรือข้อมูล

  • แนวนโยบาย ธปท. ข้อ 4.4 ส่วนที่ 2 (3.1)

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

  • แนวนโยบาย ธปท. ข้อ 4.4 ส่วนที่ 2 (3.3)

    สิ่งที่ข้อนี้คาดหวัง
    ควรติดตามภัยคุกคามโดยอ้างอิง OWASP ML Security Top 10, OWASP LLM Top 10 และ MITRE ATLAS
    สิ่งที่รายงานของเราให้
    ทุกช่องโหว่จับคู่กับรหัส OWASP LLM และ ATLAS
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    การเฝ้าติดตามภัยคุกคามอย่างต่อเนื่อง

  • NIST AI 600-1 (GenAI Profile), MS-2.7-007

    สิ่งที่ข้อนี้คาดหวัง
    AI red-teaming ต่อการโจมตี GAI เช่น Prompt Injection และการโจมตี ML เช่น data poisoning, membership inference และ model extraction
    สิ่งที่รายงานของเราให้
    ขอบเขตหลักครอบคลุม Prompt Injection และการใช้ Agent ในทางที่ผิด
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    การโจมตี ML ต้องใช้โมดูลด้านโมเดล

  • ISO/IEC 42001:2023, AI system verification and validation

    สิ่งที่ข้อนี้คาดหวัง
    บันทึกการทวนสอบและการตรวจสอบความถูกต้องของระบบ AI
    สิ่งที่รายงานของเราให้
    บันทึกการทดสอบความมั่นคงปลอดภัยที่ระบุวันที่ พร้อมผลการทดสอบและผลการทดสอบซ้ำ
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    ระบบบริหารจัดการ AI ขององค์กร

  • ISO/IEC 27001:2022, A.8.29 และ A.8.8

    สิ่งที่ข้อนี้คาดหวัง
    การทดสอบความมั่นคงปลอดภัยระหว่างพัฒนาและก่อนรับมอบระบบ รวมถึงการบริหารจัดการช่องโหว่ทางเทคนิค
    สิ่งที่รายงานของเราให้
    หลักฐานการทดสอบก่อนขึ้นระบบจริง และรายการแก้ไขพร้อมสถานะการทดสอบซ้ำ
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    การติดตามการแก้ไขและการลงนามรับมอบ

  • EU AI Act, Art. 15(5)

    เฉพาะระบบความเสี่ยงสูงที่ให้บริการในตลาด EU

    สิ่งที่ข้อนี้คาดหวัง
    ความทนทานต่อ data poisoning, model poisoning, adversarial examples และการโจมตีด้านการรักษาความลับ
    สิ่งที่รายงานของเราให้
    การโจมตีด้านการรักษาความลับและการบิดเบือนการทำงานที่ระดับ application
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    Poisoning ต้องใช้โมดูลด้านข้อมูล ส่วน conformity assessment อยู่นอกขอบเขต

  • PDPA มาตรา 37(1)

    สิ่งที่ข้อนี้คาดหวัง
    มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมสำหรับข้อมูลส่วนบุคคล
    สิ่งที่รายงานของเราให้
    หลักฐานว่าระบบ AI เปิดเผยข้อมูลส่วนบุคคลของผู้ใช้รายหนึ่งให้อีกรายเห็นได้หรือไม่
    ส่วนที่องค์กรของคุณยังต้องดำเนินการเอง
    PDPA ไม่ได้บังคับให้ทดสอบลักษณะนี้ มาตรการรักษาความมั่นคงปลอดภัยเป็นความรับผิดชอบขององค์กร

บริษัทหลักทรัพย์และธุรกิจสินทรัพย์ดิจิทัล

แนวนโยบาย ธปท. ฉบับนี้ไม่ได้ใช้กับบริษัทหลักทรัพย์และผู้ประกอบธุรกิจสินทรัพย์ดิจิทัล สำหรับองค์กรกลุ่มนี้ รายงานช่วยเสริมหลักฐานด้านความมั่นคงปลอดภัย IT ที่เก็บไว้สำหรับ ก.ล.ต. อยู่แล้ว

สิ่งที่เราไม่ทดสอบและไม่รับรอง

รายการเหล่านี้อยู่นอกขอบเขตงาน แต่ละรายการระบุเหตุผลและบริการที่รองรับงานส่วนนั้น

  • แพลตฟอร์ม บัญชี หรือโครงสร้างพื้นฐานของผู้ให้บริการ foundation model

    เหตุผล
    ไม่ใช่ทรัพย์สินขององค์กรคุณ องค์กรคุณจึงอนุญาตให้ทดสอบไม่ได้
    งานส่วนนี้ไปที่ใด
    ไม่มีให้บริการ

  • Model weights, การ training, fine-tuning และ serving stack

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

  • การทดสอบ load, stress หรือ denial-of-service ต่อระบบ AI หรือ backend

    เหตุผล
    เราตรวจ LLM10 ด้วยการทดสอบขีดจำกัดในปริมาณต่ำ โดยไม่ใช้ทรัพยากรของระบบจนหมด
    งานส่วนนี้ไปที่ใด
    DDoS Testing

  • การวัดอคติ ความเป็นธรรม toxicity หรือความถูกต้องของคำตอบ

    เหตุผล
    เป็นการประเมินคุณภาพ ซึ่งอยู่นอกการทดสอบความมั่นคงปลอดภัยเชิงโจมตี เรารายงาน misinformation เฉพาะกรณีที่ผู้โจมตีชักนำให้เกิดได้
    งานส่วนนี้ไปที่ใด
    ไม่มีให้บริการ

  • การสร้างเนื้อหาต้องห้ามจริง เช่น ข้อมูลที่ช่วยเพิ่มขีดความสามารถในการสร้างอาวุธ หรือ malware ที่ใช้งานได้จริง

    เหตุผล
    เราไม่สร้างเนื้อหาเหล่านี้ในทุกกรณี และพิสูจน์การข้ามการป้องกันด้วย proof marker ที่ไม่เป็นอันตราย
    งานส่วนนี้ไปที่ใด
    ไม่มีให้บริการ

  • การรับรองหรือยืนยันความสอดคล้อง (ISO/IEC 42001, EU AI Act, แนวนโยบาย AI สำหรับธนาคาร)

    เหตุผล
    รายงานเป็นหลักฐานด้านความมั่นคงปลอดภัย และไม่นับเป็น conformity assessment

  • เป้าหมาย บทบาทผู้ใช้ Tool หรือแหล่งข้อมูลที่ไม่อยู่ในรายการ

    เหตุผล
    ขอบเขตยึดตาม scope sheet ที่ลงนามแล้ว รายการใหม่ต้องยื่น change request
    งานส่วนนี้ไปที่ใด
    Change request

  • Social engineering ต่อพนักงานที่ดูแลระบบ AI

    เหตุผล
    เป็นบริการคนละสายงาน
    งานส่วนนี้ไปที่ใด
    การจำลอง Phishing, Red Teaming

  • การรับประกันว่าเป้าหมายปลอดภัย

    เหตุผล
    ผลลัพธ์ของ LLM ไม่คงที่ การทดสอบพิสูจน์ได้ว่าส่วนใดถูกเจาะ แต่พิสูจน์ไม่ได้ว่าส่วนอื่นจะไม่ถูกเจาะ
    งานส่วนนี้ไปที่ใด
    ระบุไว้ในรายงานทุกฉบับ
OWASP
Top 10 for LLM Applications
RAG
ทดสอบ Pipeline และ Agent
PoC
Prompt และคำตอบที่ทำซ้ำได้
0
รายงานที่ไม่ได้พิสูจน์

ทำไมต้องเลือก Reconix สำหรับ AI/LLM Application Penetration Testing?

  • พื้นฐานสาย Offensive ปรับใช้กับ AI

    เราเป็นนักทดสอบเจาะระบบมาก่อน จึงโจมตีระบบ LLM ด้วยสัญชาตญาณของผู้โจมตีจริง แทนการไล่รัน Prompt สำเร็จรูปตาม Checklist

  • เริ่มที่ชั้น Application ชั้นอื่นแยกตามคำขอ

    งานหลักโจมตีชั้น Application คือฟีเจอร์ AI ในมุมที่ผู้ใช้และแหล่งข้อมูลของคุณเข้าถึงได้ ส่วนชั้น Model, Data และ Infrastructure รวมถึงการ Pentest แอปที่หุ้ม AI และ Secure Code Review เป็นงานเสริมที่กำหนดขอบเขตและเสนอราคาแยกตามคำขอ เราตามการโจมตีเข้าไปในแอปรอบข้างเท่าที่เส้นทางของโมเดลพาไปถึง XSS ที่เกิดจาก Output ของโมเดลจึงอยู่ในขอบเขต

  • อ้างอิง OWASP LLM

    ผลการทดสอบจับคู่กับ OWASP Top 10 for LLM Applications รายงานจึงตรวจสอบย้อนได้ และทีมของคุณรู้ทันทีว่าแต่ละปัญหาอยู่ในความเสี่ยงกลุ่มไหน

  • หลักฐานที่ทำซ้ำได้

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

  • อัตราความสำเร็จที่ Retest เทียบได้

    คำตอบของ LLM ไม่เหมือนเดิมทุกครั้ง เราจึงบันทึกจำนวนครั้งที่ลองและจำนวนครั้งที่สำเร็จของทุกช่องโหว่ เช่น 6 จาก 20 ครั้ง และ Retest ทุกช่องโหว่หนึ่งรอบ โดยรันชุดการโจมตีเดิมด้วยจำนวนครั้งเท่าเดิม

สอดคล้องกับกฎระเบียบ

ข้อกำหนดด้านการปฏิบัติตามกฎหมายที่บริการนี้รองรับ

วิธีการทดสอบของเราออกแบบมาเพื่อตอบสนองข้อกำหนดของกฎระเบียบด้านความปลอดภัยไซเบอร์ที่สำคัญของไทย

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล

มาตรา 37 กำหนดให้ต้องมีมาตรการรักษาความปลอดภัยที่เหมาะสมในการประมวลผลข้อมูลส่วนบุคคล

ดูเพิ่มเติม
ธปท. iPentest

การทดสอบเจาะระบบเชิงข่าวกรอง ธปท.

การทดสอบ iPentest ประจำปีสำหรับสถาบันการเงินภายใต้เกณฑ์ IT Examination

ดูเพิ่มเติม
ดูข้อกำหนดทั้งหมด

คำถามที่พบบ่อย

รวมคำถามยอดนิยมเกี่ยวกับการทดสอบเจาะระบบ LLM Application และ AI Agent

เปิดตัว AI อย่างมั่นใจ เพราะผ่านการโจมตีทดสอบมาแล้ว

ก่อนที่ Chatbot หรือ Agent ของคุณจะถึงมือลูกค้า ให้ Reconix เข้าโจมตีด้วยมุมมองเดียวกับผู้ไม่หวังดี คุณจะได้ทั้ง Exploit ที่ใช้ได้จริง และมาตรการที่ใช้หยุดมัน

Reconix คือผู้เชี่ยวชาญการทดสอบเจาะระบบเชิงรุกที่เน้นการพิสูจน์ในประเทศไทย ให้บริการธุรกิจดิจิทัลภายใต้การกำกับดูแลทุกขนาด

บริการที่เกี่ยวข้อง

Web Application Penetration Testing

ทดสอบแอปที่ห่อหุ้ม AI ของคุณ ทั้ง Auth, Access Control และชั้น API

ดูรายละเอียด

Red Teaming & Adversary Simulation

จำลองผู้โจมตีจริงแบบ Goal-based ครอบคลุมทั้งคน กระบวนการ และเทคโนโลยี

ดูรายละเอียด

Secure Code Review

วิเคราะห์ระดับ Source Code ของโค้ดที่สร้าง Prompt เรียกโมเดล และจัดการ Output

ดูรายละเอียด