เมื่อบริษัทความปลอดภัย RedAccess ค้นหาแอปที่สร้างด้วยเครื่องมือเขียนโค้ด AI และเผยแพร่บนโฮสติ้งของเครื่องมือเหล่านั้นเอง พบมากกว่า 5,000 แอปที่แทบไม่มีความปลอดภัยหรือการยืนยันตัวตน หน้าจอที่บริษัทแบ่งปันกับ Wired มี “บันทึกการขายและการเงินหลากหลายประเภทจากบริษัทอื่นหลายแห่ง” รวมอยู่ด้วย แอปที่สร้างด้วย AI สำหรับทีมการเงินอาจไปอยู่บนที่อยู่ที่เปิดให้เข้าถึงแบบเดียวกัน โดยมีบัญชีแยกประเภท เงินเดือน และผลประกอบการที่ยังไม่ประกาศอยู่เบื้องหลัง
Amjad Masad ซีอีโอของ Replit ตอบว่า “การที่แอปสาธารณะเข้าถึงได้บนอินเทอร์เน็ตเป็นพฤติกรรมที่คาดไว้” เขาพูดถูกในแง่กลไก ตามการตีความของผม การเปิดเผยเกิดจากการตั้งค่าการมองเห็นและการข้ามขั้นตอนตรวจสอบ ซึ่งทั้งสองเรื่องอยู่ในขอบเขตที่ผู้สร้างเครื่องมือจัดการได้
TL;DR (สรุปย่อ)
- เครื่องมือการเงินที่สร้างด้วย AI อาจทำข้อมูลรั่วไหลจากข้อผิดพลาดในการนำไปใช้งานหกแบบ ซึ่งผู้สร้างแก้ไขได้ ได้แก่ ลิงก์สาธารณะ รหัสผ่านและคีย์ที่ค้างในโค้ดหรือประวัติแชต สิทธิ์ฐานข้อมูลระดับผู้ดูแล การลงบัญชีโดยไม่มีผู้อนุมัติคนที่สอง การส่งข้อมูลให้บริการภายนอก และการเปลี่ยนการคำนวณโดยไม่มีใครบันทึกไว้
- แต่ละข้อผิดพลาดมีวิธีแก้ ส่วนใหญ่ใช้เครื่องมือ AI เดียวกับที่สร้างแอปดำเนินการได้ และมีการตรวจสอบง่าย ๆ ที่พิสูจน์ว่าการแก้ไขได้ผล เช่น ฐานข้อมูลปฏิเสธการเขียน หรือรหัสผ่านเก่าใช้ไม่ได้แล้ว
- กำหนดให้เครื่องมือการเงินอยู่บนเครือข่ายส่วนตัวเป็นค่าเริ่มต้น เพิ่มการลงชื่อเข้าใช้ของบริษัทเมื่อคนนอกทีมการเงินต้องใช้ และส่งมอบให้ IT เมื่อเครื่องมือลงบัญชีแยกประเภทโดยไม่มีผู้อนุมัติคนที่สอง แตะข้อมูลบัตร หรือส่งตัวเลขเข้าสู่งบการเงินที่อยู่ในขอบเขต SOX
- ภูมิภาคของเซิร์ฟเวอร์กำหนดตำแหน่งพื้นที่จัดเก็บ VPS หลักของแอป แต่ข้อมูลสำรอง ล็อก และบริการบุคคลที่สามอาจสร้างสำเนาที่อื่นได้ การที่ระบบทั้งหมดปฏิบัติตามข้อกำหนดหรือไม่เป็นอีกคำถามหนึ่ง นำกรอบข้อกำหนดของภูมิภาคไปปรึกษาทีมกำกับการปฏิบัติตามข้อกำหนด
ข้อผิดพลาดในการนำไปใช้งานที่ทำข้อมูลการเงินรั่วไหล
เครื่องมือการเงินที่สร้างด้วย AI อาจทำข้อมูลรั่วไหลจากข้อผิดพลาดหกแบบ ได้แก่ ทิ้งไว้บนลิงก์สาธารณะ เก็บข้อมูลรับรองในโค้ดหรือแชต เชื่อมต่อด้วยสิทธิ์ผู้ดูแลทั้งที่อ่านอย่างเดียวก็พอ ลงบัญชีโดยไม่มีผู้อนุมัติคนที่สอง ส่งข้อมูลการเงินให้บริการภายนอก และเปลี่ยนการคำนวณโดยไม่บันทึก แต่ละอย่างเป็นค่าเริ่มต้นที่ดูสะดวกในการสาธิต
วิธีแก้แต่ละข้อด้านล่างมีพรอมป์ต์สำหรับเครื่องมือ AI ที่สร้างแอป เปลี่ยนข้อความในวงเล็บเหลี่ยมก่อนวาง พรอมป์ต์เหล่านี้เป็นจุดเริ่มต้นที่ยังไม่ทดสอบและเขียนสำหรับบทความนี้ การที่ AI รายงานว่าแก้ไขแล้วไม่ได้พิสูจน์อะไร การตรวจสอบใต้พรอมป์ต์ต่างหากคือหลักฐาน ใช้พรอมป์ต์กับโค้ดและชุดข้อมูลตัวอย่างหรือข้อมูลสังเคราะห์ และอย่าวางบันทึกจริงหรือคีย์ที่ใช้งานจริงในแชต
ทิ้งเครื่องมือไว้บนลิงก์สาธารณะของผู้สร้างแอป AI
แดชบอร์ดคาดการณ์เงินสดที่เปิดเป็นสาธารณะบนโฮสติ้งของผู้สร้างแอป AI เปิดได้โดยทุกคนที่รู้ที่อยู่ รวมถึงทุกสิ่งที่แสดง เช่น อายุเจ้าหนี้การค้า งบประมาณเทียบผลจริง และผลประกอบการไตรมาสก่อนประกาศ รายงานของ Wired เกี่ยวกับผลการค้นพบของ RedAccess อธิบายว่านักวิจัยพบแอปเหล่านี้ด้วยการค้นหาโดเมนของผู้ให้บริการ AI แบบง่าย ๆ ผ่าน Google และ Bing
บางแอปเพียงขอให้ผู้เข้าชมลงชื่อเข้าใช้ด้วยอีเมลใดก็ได้ การเข้าสู่ระบบที่ยอมรับทุกอีเมลไม่ใช่การควบคุมการเข้าถึง
นำข้อมูลจริงออกจากโฮสติ้งของผู้ให้บริการ จนกว่าเครื่องมือจะทำงานบนเซิร์ฟเวอร์ที่คุณควบคุม ซึ่งส่วนถัดไปอธิบายตำแหน่งที่เหมาะสม ให้สร้างและสาธิตด้วยข้อมูลสังเคราะห์ หรือแซนด์บ็อกซ์หรือบริษัททดสอบของ ERP หากมี ห้ามใช้ข้อมูลส่งออกจริง หลังแก้ไขให้ปรับใช้ใหม่ เพราะที่อยู่ที่โฮสต์ให้บริการเวอร์ชันที่ปรับใช้ครั้งล่าสุด
สร้างชุดข้อมูลสังเคราะห์สำหรับแอปนี้ให้ตรงกับตารางและคอลัมน์ที่อ่าน: [ระบุตารางและคอลัมน์ เช่น vendors, invoices, journal_lines]
ใช้ชื่อผู้ขายและลูกค้าสมมติ เลขบัญชีธนาคารสมมติ และยอดใน [สกุลเงิน] ที่มีความสอดคล้องเหมือนบัญชีจริง: ทุกรายการสมุดรายวันต้องสมดุล และยอดรวมบัญชีแยกประเภทย่อยต้องตรงกับ [บัญชีคุมเจ้าหนี้ / ลูกหนี้การค้า]
ให้แอปใช้ชุดข้อมูลนี้แทนข้อมูลส่งออกจริง และระบุทุกไฟล์หรือการตั้งค่าที่เปลี่ยน
อย่าขอบันทึกจริงจากฉัน
ตรวจสอบว่าได้ผล: เปิดที่อยู่ที่ผู้ให้บริการโฮสต์จากเบราว์เซอร์ที่ออกจากระบบแล้ว หรือให้เพื่อนร่วมงานนอกทีมการเงินเปิด และยืนยันว่าเห็นเฉพาะข้อมูลสังเคราะห์ หน้าลงชื่อเข้าใช้ หรือไม่เห็นอะไรเลย จากนั้นค้นหาชื่อผู้ขายหรือลูกค้าสามชื่อจาก ERP จริงในไฟล์ข้อมูลและที่เก็บโค้ดของแอป โดยต้องไม่พบ สุดท้ายเรียกงบทดลองหรือหน้าสรุปของแอป และยืนยันว่าเดบิตรวมเท่ากับเครดิตรวม
ทิ้งข้อมูลรับรอง ERP ฟีดธนาคาร และฐานข้อมูลไว้ในโค้ดหรือแชต
หากเก็บข้อมูลรับรองที่ใช้งานจริงไว้ที่นั่น ผู้ที่อ่านประวัติแชต ที่เก็บโค้ด หรือไฟล์การตั้งค่า MCP ได้ อาจใช้มันเข้าถึง ERP ฐานข้อมูลการเงิน หรือการเชื่อมต่อฟีดธนาคารได้ด้วย MCP คือตัวเชื่อมที่ให้เครื่องมือ AI เช่น Claude สื่อสารโดยตรงกับ ERP หรือฐานข้อมูล และไฟล์ตั้งค่าของมันเป็นอีกที่ที่รหัสผ่านอาจค้างอยู่
State of Secrets Sprawl 2026 ของ GitGuardian พบข้อมูลลับไม่ซ้ำ 24,008 รายการที่เปิดเผยในไฟล์ตั้งค่า MCP โดย 14% เป็นสตริงเชื่อมต่อฐานข้อมูล PostgreSQL ในคอมมิต GitHub สาธารณะ รายงานเดียวกันพบว่าคอมมิตที่ Claude Code ร่วมเขียนมีอัตรารั่วไหลของข้อมูลลับประมาณสองเท่าของอัตราพื้นฐาน และระบุว่าปัจจัยมนุษย์ยังสำคัญเช่นกัน
การลบข้อความแชตไม่ย้อนคืนการเปิดเผย ผู้ที่มีสำเนาแชต ที่เก็บโค้ด หรือประวัติยังมีค่าเดิม สำหรับรหัสผ่าน คีย์ หรือโทเคนทุกตัวที่เคยอยู่ในที่เหล่านั้น ให้ออกใหม่ในคอนโซลผู้ดูแล ERP ฐานข้อมูล หรือฟีดธนาคาร แล้วปิดใช้งานตัวเก่า นี่คือการหมุนเวียนข้อมูลรับรอง
จากนั้นแอปอ่านข้อมูลรับรองเมื่อเริ่มทำงานจากตัวแปรสภาพแวดล้อม ซึ่งเป็นการตั้งค่ามีชื่อที่เก็บนอกโค้ด โดยชั้นปรับใช้เป็นผู้ส่งให้ ชั้นปรับใช้คือเครื่องมือที่สร้างและเรียกแอปบนเซิร์ฟเวอร์ของคุณ HashiCorp Vault เป็นขั้นถัดไปเมื่อหลายเครื่องมือแบ่งปันข้อมูลลับและต้องหมุนเวียนจากจุดเดียว
สำเนารหัสผ่านที่สมาชิกทีมใช้ควรอยู่ในตัวจัดการรหัสผ่านสำหรับคน เช่น Vaultwarden ส่วนแอปที่ทำงานอ่านค่าจากสภาพแวดล้อม เริ่มจากค้นหาข้อมูลลับที่ฝังตายตัวทั้งหมดในโค้ดที่ AI สร้าง
ตรวจสอบโครงการนี้เพื่อหาข้อมูลลับที่ฝังตายตัว ค้นหารหัสผ่าน คีย์ API โทเคนเข้าถึง และสตริงเชื่อมต่อทุกตัว รวมถึงในไฟล์ .env โน้ตบุ๊ก ไฟล์ตั้งค่า MCP และโค้ดที่เชื่อมกับ [ชื่อ ERP / ผู้ให้บริการฟีดธนาคาร / ฐานข้อมูลการเงิน]
แทนแต่ละค่าในโค้ดด้วยตัวแปรสภาพแวดล้อมที่มีชื่อ และให้รายการชื่อตัวแปรแก่ฉัน
ตรวจให้แน่ใจว่าไม่มีไฟล์ที่มีค่าจริงถูกคอมมิตเข้าที่เก็บโค้ด และระบุทุกคอมมิตในประวัติที่เก็บโค้ดที่มีค่าเหล่านี้ปรากฏ
แสดงเฉพาะตำแหน่ง อย่าพิมพ์ค่าข้อมูลลับใด ๆ
ตรวจสอบว่าได้ผล: ลองรหัสผ่านหรือโทเคนเก่าด้วยตนเอง หรือให้ IT ลอง และต้องถูกปฏิเสธ จากนั้นค้นหาค่าเก่าในไฟล์โครงการปัจจุบันโดยต้องไม่พบ ค่าที่ตรงกันซึ่งค้างในประวัติจะไม่ให้สิทธิ์เข้าถึงอีกต่อเมื่อคุณยืนยันว่าค่านั้นถูกเพิกถอนหรือหมดอายุแล้ว
เชื่อมต่อด้วยบัญชีผู้ดูแลของผู้สร้างทั้งที่เครื่องมือต้องอ่านอย่างเดียว
แดชบอร์ดที่แสดงอายุลูกหนี้การค้าต้องแก้ไขบัญชีแยกประเภททั่วไปไม่ได้ หากเชื่อมด้วยบัญชีผู้ดูแลของผู้สร้าง เครื่องมือจะได้รับสิทธิ์ของบัญชีนั้น คีย์ secret ของ Supabase หรือคีย์ service_role แบบเดิมให้สิทธิ์สูงในการเข้าถึงข้อมูลโครงการและข้าม Row Level Security จึงไม่ควรใช้สำหรับการอ่านอย่างเดียวตามปกติ รายงานที่สร้างสำหรับตารางอายุหนี้เพียงชุดเดียวจึงเปิดเผยบัญชีแยกประเภททั่วไปทั้งหมด รวมทั้งตารางเงินเดือน
ฝั่งการเขียนคือจุดที่สร้างความเสียหายราคาแพง การตรวจแอปที่สร้างด้วย AI จำนวน 1,072 แอปของ Symbiotic Security ซึ่งใช้ Supabase พบ 172 แอปที่ใครก็ลบบันทึกได้โดยไม่ยืนยันตัวตน 172 แอปที่ใครก็แก้บันทึกเดิมได้ และ 39 แอปที่ผู้ถือคีย์สาธารณะอ่านตารางได้ทั้งหมด
ให้ข้อมูลรับรองแบบอ่านอย่างเดียวที่จำกัดเฉพาะตารางที่เครื่องมืออ่าน ใน ERP หรือฐานข้อมูล หมายถึงผู้ใช้เชื่อมต่อเฉพาะ: บัญชีแยกที่สร้างสำหรับเครื่องมือ มีสิทธิ์อ่านวัตถุที่รายงานต้องใช้และไม่มีอย่างอื่น ใน Supabase เปิด Row Level Security ซึ่งเป็นกฎฐานข้อมูลกำหนดว่าแต่ละคำขอเห็นแถวใดได้ สำหรับทุกตารางที่เปิดให้เข้าถึงซึ่งเครื่องมือใช้ และตรวจสิทธิ์ตารางด้วย สิทธิ์กำหนดว่าบทบาททำ select, insert, update หรือ delete ได้หรือไม่ สำหรับแอปการเงินอ่านอย่างเดียว บทบาทที่ใช้ไม่ควรมีการเขียนที่ไม่จำเป็น คีย์ publishable อยู่ในโค้ดเบราว์เซอร์ได้เมื่อ RLS และสิทธิ์แบบน้อยที่สุดถูกต้อง คีย์ secret และ service_role แบบเดิมต้องอยู่ฝั่งเซิร์ฟเวอร์ และสงวนสำหรับงานแบ็กเอนด์ที่จำเป็นต้องมีสิทธิ์สูงจริงและบังคับตรวจสิทธิ์ของตนเอง
หมายเหตุ: การเห็นคีย์ publishable ของ Supabase หรือคีย์ anon แบบเดิมใน JavaScript ของหน้าเป็นเรื่องปกติ เอกสารคีย์ API ของ Supabase ระบุว่าเข้าถึงได้เฉพาะสิ่งที่ Row Level Security อนุญาต คีย์ secret ข้าม Row Level Security จึงห้ามปรากฏในสิ่งใดที่ส่งไปยังเบราว์เซอร์
ระบุการอ่านและการเขียนทุกครั้งที่แอปนี้ทำต่อ [ชื่อ ERP หรือฐานข้อมูล] โดยจัดตามตารางหรือวัตถุ
เปลี่ยนให้แอปอ่านเฉพาะ [ตารางที่ต้องใช้] และเชื่อมด้วยข้อมูลรับรองอ่านอย่างเดียวแยกต่างหากที่ส่งผ่านตัวแปรสภาพแวดล้อม ห้ามใช้บัญชีส่วนตัวของฉัน
หากแอปใช้ Supabase: เปิด Row Level Security สำหรับทุกตารางที่เปิดให้เข้าถึงซึ่งแอปแตะ ระบุสิทธิ์ select, insert, update และ delete ของ anon และ authenticated สำหรับแอปอ่านอย่างเดียวนี้ ลบสิทธิ์เขียนที่ไม่ต้องใช้ หากแอปใช้งานจริงอื่นพึ่งสิทธิ์นั้นให้แจ้งแทนการแก้ จากนั้นเขียนนโยบายให้ผู้ยังไม่เข้าสู่ระบบอ่านอะไรไม่ได้ และผู้เข้าสู่ระบบอ่านเฉพาะ [กฎ เช่น แถวของศูนย์ต้นทุนของตน] และยืนยันว่าไม่มีคีย์ secret หรือ service_role แบบเดิมในไฟล์ใดที่ส่งไปยังเบราว์เซอร์
ระบุนโยบายที่สร้าง
ตรวจสอบว่าได้ผล: ใช้ข้อมูลรับรองของเครื่องมือลองเขียนหนึ่งครั้ง เช่น แก้บันทึกทดสอบ และต้องถูกปฏิเสธ สำหรับ Supabase ขอแถวจากตารางการเงินขณะออกจากระบบ และต้องได้ผลลัพธ์ว่างหรือข้อผิดพลาด
ปล่อยให้เครื่องมือลงบัญชีแยกประเภทโดยไม่มีผู้อนุมัติคนที่สอง
เครื่องมือนำเข้ารายการสมุดรายวันที่ลงบัญชีตรง หรือเครื่องมือสร้างไฟล์ชำระเงินที่ส่งตรงไปธนาคาร ทำให้ผู้เรียกใช้งานเป็นทั้งผู้จัดทำและผู้อนุมัติ บั๊กเดียวทำให้รายการค้างจ่ายทั้งเดือนซ้ำ ฟิลด์ที่เปลี่ยนหนึ่งช่องส่งเงินผู้ขายไปผิดบัญชี นี่คือการละเมิดการแบ่งแยกหน้าที่ที่ฝ่ายการเงินไม่ยอมให้เกิดแม้ระหว่างคนสองคน และซอฟต์แวร์ที่สร้างด้วยผู้ช่วย AI ไม่ได้รับข้อยกเว้น
ความเสียหายไม่หยุดในแอป แบตช์ที่ผิดเข้าสู่บัญชี การย้อนคืนต้องมีรายการแก้ไขและคำอธิบายเมื่อปิดบัญชี และหากเครื่องมือลงบัญชีด้วยบัญชีส่วนตัวของผู้สร้าง รายการซ้ำทุกตัวก็มีชื่อผู้สร้างติดอยู่
เครื่องมือที่สร้างด้วย AI อ่านและเตรียมข้อมูล ส่วนการลงบัญชีและปล่อยชำระเงินทำในกระบวนการอนุมัติของ ERP เอง โดยผู้อนุมัติต้องไม่ใช่คนที่เรียกเครื่องมือ ระบบบัญชีทุกระบบที่ผมเคยทำงานด้วยถือว่ารายการและการอนุมัติเป็นสองเหตุการณ์ที่มีผู้รับผิดชอบสองคน และเครื่องมือที่สร้างด้วย AI ควรได้รับการปฏิบัติแบบเดียวกัน
ในทางปฏิบัติ เปลี่ยนการลงบัญชีตรงทุกจุดเป็นรายการร่างหรือการนำเข้าที่พักรออนุมัติภายใน ERP เครื่องมือยังทำส่วนที่น่าเบื่อ เช่น จับคู่ข้อมูล ตรวจสอบ และสร้างแบตช์ ส่วนการอนุมัติอยู่ใน ERP ร่วมกับการอนุมัติอื่นที่การปิดบัญชีพึ่งพา หาก ERP ไม่มีขั้นอนุมัติการนำเข้า ผลลัพธ์ของเครื่องมือต้องเป็นไฟล์ให้คนที่สองตรวจเทียบสรุปแบตช์และนำเข้าเอง
เครื่องมือที่ต้องลงบัญชีอัตโนมัติ สร้างไฟล์ชำระเงิน หรือเปลี่ยนข้อมูลธนาคารผู้ขายควรอยู่กับ IT ตามเงื่อนไขในส่วนถัดไป
ระบุทุกจุดที่แอปนี้สร้าง แก้ไข หรือลงบัญชี [รายการสมุดรายวัน / ใบเรียกเก็บ / การชำระเงิน] ใน [ชื่อ ERP]
เปลี่ยนแต่ละจุดให้แอปสร้างรายการร่างหรือการนำเข้าที่พักรอ ซึ่งต้องอนุมัติใน [ชื่อ ERP] ก่อนลงบัญชี หาก [ชื่อ ERP] ไม่มีขั้นอนุมัติการนำเข้า ให้สร้างไฟล์นำเข้าแทนและอย่าลงบัญชีอะไร
ลบเส้นทางโค้ดใด ๆ ที่ลงบัญชีหรือปล่อยชำระเงินโดยไม่มีการอนุมัตินั้น
สำหรับทุกแบตช์ สร้างสรุปจำนวนแถว เดบิตรวม และเครดิตรวม
ระบุทุกอย่างที่ยังลงบัญชีตรงเพื่อให้ฉันตรวจสอบ
ตรวจสอบว่าได้ผล: เรียกหนึ่งแบตช์จากข้อมูลตัวอย่าง ต้องไม่มีอะไรแสดงว่าลงบัญชีแล้วจนกว่าผู้ใช้คนที่สองจะอนุมัติใน ERP จากนั้นเทียบสรุปแบตช์กับข้อมูลแบตช์นั้นใน ERP: จำนวนแถว เดบิตรวม และเครดิตรวมต้องตรงกันทุกประการ ต่างหนึ่งแถวคือการกระทบยอดล้มเหลว ไม่ใช่ปัญหาการปัดเศษ
ส่งข้อมูลการเงินให้บริการนอกการควบคุม
ฟังก์ชันอธิบายผลต่างที่ส่งข้อมูลบัญชีแยกประเภททั่วไปทั้งหมดไป AI API ส่งทุกบรรทัดให้บุคคลที่สาม ยังมีอีกสองทางที่สังเกตยาก: สคริปต์วิเคราะห์บนหน้าที่รายงานทุกการเข้าชมให้ผู้ให้บริการ และเครื่องมือติดตามข้อผิดพลาดหรือล็อกที่เก็บเนื้อหาคำขอเต็ม ซึ่งอาจมีรายการเงินเดือน ข้อมูลธนาคารลูกค้า และตัวเลขก่อนประกาศ
สำหรับเครื่องมือภายในที่ฝ่ายการเงินสร้าง อย่าส่งผลประกอบการก่อนประกาศและเงินเดือนในการเรียกบริการบุคคลที่สาม เว้นแต่บริการและเส้นทางข้อมูลที่แน่นอนจะผ่านอนุมัติอย่างชัดเจนตามกระบวนการผู้ให้บริการ ความปลอดภัย และกำกับข้อกำหนดขององค์กร สำหรับข้อมูลอื่น ระบุทุกปลายทางและส่งเฉพาะฟิลด์ที่แต่ละคำขอต้องใช้ บริการภายนอกเก็บหรือใช้ข้อมูลที่รับเพื่อฝึกโมเดลหรือไม่เป็นเรื่องที่ผู้ลงนามสัญญาผู้ให้บริการต้องตรวจจากเงื่อนไขของผู้ให้บริการเอง หากทีมต้องการรู้ความถี่การใช้เครื่องมือ เครื่องมือวิเคราะห์แบบโฮสต์เอง เช่น Umami เก็บการดูหน้าเหล่านั้นไว้บนเซิร์ฟเวอร์ของคุณ
ระบุทุกจุดที่แอปนี้ส่งข้อมูลออกนอก [เซิร์ฟเวอร์ของเรา] รวมถึง AI API สคริปต์วิเคราะห์ การติดตามข้อผิดพลาด อีเมล เว็บฮุก และไฟล์ล็อก
สำหรับแต่ละปลายทาง ระบุให้ชัดว่ารับฟิลด์ใดบ้าง
แจ้งทุกสิ่งที่มี [ยอดเงินเดือน / เลขบัญชีธนาคาร / ผลประกอบการก่อนประกาศ / ชื่อลูกค้า]
สำหรับแต่ละรายการที่แจ้ง แสดงวิธีส่งฟิลด์น้อยลงหรือไม่ส่ง และแก้ไขหลังฉันยืนยันเท่านั้น
ตรวจสอบว่าได้ผล: เรียกแต่ละฟังก์ชันหนึ่งครั้งด้วยข้อมูลตัวอย่างที่มีเลขบัญชีปลอมและยอดเงินเดือนปลอมที่จำได้ง่าย ค้นหาทั้งสองค่าในเครื่องมือติดตามข้อผิดพลาดและล็อกโดยต้องไม่พบ สำหรับเส้นทาง AI API ให้แอปบันทึกเนื้อหาคำขอขาออกระหว่างการทดสอบนี้ ค้นหาสองค่าเดิมในล็อกโดยต้องไม่มี และมีเฉพาะฟิลด์ที่คุณอนุมัติ จากนั้นปิดการบันทึกนี้
เปลี่ยนการคำนวณโดยไม่มีบันทึกและไม่มีการกระทบยอด
ในเครื่องมือคำนวณรายการค้างรับค้างจ่ายหรือเครื่องมือตรวจสอบ revenue waterfall โค้ดคือมาตรการควบคุม เปลี่ยนสูตรเดียว ตัวเลขที่ใช้ปิดบัญชีก็เปลี่ยน และหากไม่มีการควบคุมเวอร์ชัน จะไม่มีใครบอกได้ว่าใครเปลี่ยนอะไรเมื่อไร
ใน กระทู้ r/ClaudeAI ของสำนักงาน CPA เกี่ยวกับเครื่องมือภายในที่สร้างด้วย Claude Code ผู้แสดงความคิดเห็นคนหนึ่งกล่าวถึงข้อจำกัดตรง ๆ ว่า “‘นักบัญชี + claude code’ ใช้ได้จนเจอข้อกำหนดหลักฐานการตรวจสอบ นั่นคือเพดานที่แท้จริง”
ตรึงพฤติกรรมปัจจุบันก่อนเปลี่ยนอะไร เมื่อผลลัพธ์ถูกตรึงแล้ว สามารถปรับปรุงตรรกะได้โดยยอดรวมไม่เปลี่ยนโดยไม่มีใครรู้ เก็บโค้ดในระบบควบคุมเวอร์ชันที่บันทึกทุกการเปลี่ยนพร้อมผู้เขียนและวันที่
เขียนการทดสอบที่เรียกเครื่องมือด้วยไฟล์ตัวอย่างคงที่และเทียบผลกับค่าฐานที่บันทึกไว้ เพื่อให้โค้ดต้องผ่านการกระทบยอดก่อนเผยแพร่การเปลี่ยนแปลง การทดสอบที่ตรึงไว้ปกป้องทุกสิ่งที่บันทึก รวมถึงข้อผิดพลาด ดังนั้นเทียบยอดรวมฐานกับยอด ERP ของงวดนั้นก่อนเชื่อถือ
กำหนดให้คนที่สองตรวจทุกการเปลี่ยนตรรกะการคำนวณ และกระทบยอดการทำงานจริงทุกครั้งกับยอดรวมของ ERP
นำโครงการนี้เข้าระบบควบคุมเวอร์ชันหากยังไม่ได้ทำ และระบุไฟล์ที่มีตรรกะการคำนวณ
เขียนการทดสอบที่เรียกแอปด้วย [ไฟล์ตัวอย่าง] และบันทึกผลลัพธ์วันนี้ ได้แก่ จำนวนแถวและยอดรวมตาม [บัญชี / นิติบุคคล / งวด]
ก่อนบันทึกผลลัพธ์ แสดงยอดรวมให้ฉันเทียบกับ [ชื่อ ERP] สำหรับ [งวด]
การเปลี่ยนใดที่ทำให้ยอดรวมเหล่านี้เปลี่ยนต้องทำให้การทดสอบล้มเหลว
อย่าเปลี่ยนตรรกะการคำนวณระหว่างเขียนการทดสอบ
ตรวจสอบว่าได้ผล: จงใจเปลี่ยนการคำนวณหนึ่งจุด เช่น กฎการปัดเศษ และยืนยันว่าการทดสอบล้มเหลว ย้อนการเปลี่ยนและยืนยันว่าทุกการทดสอบผ่านอีกครั้ง
ส่วนตัวเป็นค่าเริ่มต้น เพิ่มล็อกอินบริษัทเมื่อมีผู้ใช้มากขึ้น ให้ IT ดูแลบัญชีแยกประเภท
ห้ามทิ้งข้อมูลการเงินจริงบนโฮสติ้งของเครื่องมือ AI หากต้องการนำแอปการเงินที่สร้างด้วย AI มาใช้เฉพาะทีมการเงินอย่างปลอดภัย ให้วางบนเซิร์ฟเวอร์ที่คุณควบคุมและเข้าถึงผ่านเครือข่ายส่วนตัวเท่านั้น เพิ่มล็อกอินบริษัทเมื่อคนนอกทีมต้องใช้ และส่งให้ IT เมื่อเข้าข้อใดในรายการด้านล่าง
VPS คือเซิร์ฟเวอร์เสมือนเช่าที่คุณควบคุมระบบปฏิบัติการและชุดซอฟต์แวร์ เครือข่ายส่วนตัว หรือ tailnet ตามคำของ Tailscale เชื่อมอุปกรณ์ที่อนุมัติแล้วกับเซิร์ฟเวอร์นั้น เพื่อไม่ให้เครื่องมืออยู่บนอินเทอร์เน็ตเปิด คุณยังต้องปิดการเข้าถึงขาเข้าสาธารณะของแอป เช่น ด้วยไฟร์วอลล์เซิร์ฟเวอร์ และเปิดเฉพาะอินเทอร์เฟซ VPN หรือ tailnet ผู้ให้บริการตัวตนเก็บบัญชีผู้ใช้ของบริษัท และรีเวิร์สพร็อกซีเป็นผู้เฝ้าประตูหน้าแอปที่ส่งทุกคำขอผ่านการลงชื่อเข้าใช้ก่อน
| ระดับการนำไปใช้งาน | ใครเข้าถึงได้ | เหมาะกับ | ระบบที่ใช้ |
|---|---|---|---|
| เครือข่ายส่วนตัวเท่านั้น | ทีมการเงินบนอุปกรณ์ของตน | ตัวช่วยกระทบยอด การคาดการณ์เงินสด เช็กลิสต์ปิดบัญชี และทุกอย่างที่แสดงตัวเลขก่อนประกาศ | VPS ที่มีชั้นปรับใช้ เช่น Coolify หรือ Dokku เข้าถึงผ่าน Tailscale หรือ WireGuard เท่านั้น |
| ล็อกอินบริษัทอยู่ด้านหน้า | บุคคลที่ระบุทั่วบริษัท เช่น เจ้าของงบประมาณและหัวหน้าแผนก | หน้าดูงบประมาณเทียบผลจริง คำขอใช้จ่าย | ระดับ 1 พร้อมผู้ให้บริการตัวตน (Authentik หรือ Keycloak) หลังรีเวิร์สพร็อกซี (Caddy หรือ Nginx Proxy Manager) |
| IT หรือวิศวกรรมดูแล | ผู้ที่ IT กำหนด | เครื่องมือใดที่เข้าเงื่อนไขในรายการส่งมอบให้ IT | แพลตฟอร์มของ IT เอง |
โฮสติ้งของเครื่องมือ AI ไม่อยู่ในตารางด้วยเหตุผลในข้อผิดพลาดแรก แพลตฟอร์มปรับใช้ระดับองค์กร เช่น Northflank ก็ไม่อยู่เช่นกัน เพราะเหมาะกับองค์กรใหญ่ที่มีงบให้ผู้ให้บริการแพลตฟอร์มและการตรวจสอบที่จำเป็นอยู่แล้ว เป็นภาระสัญญามากกว่าที่เครื่องมือระดับแผนกสำหรับผู้ใช้ไม่กี่คนต้องการ
จากประสบการณ์ของผม Tailscale เป็นตัวเลือกเครือข่ายส่วนตัวที่เริ่มใช้ได้เร็วกว่าในสองตัวเลือก แต่ Tailscale โฮสต์บริการประสานงานเอง ส่วน WireGuard เป็นตัวเลือกที่โฮสต์เองได้ทั้งหมด
เหตุผลที่ผมให้เครือข่ายส่วนตัวเป็นค่าเริ่มต้น: เครื่องมือที่ไม่ตอบจากอินเทอร์เน็ตย่อมค้นหาไม่พบและโจมตีหน้าล็อกอินไม่ได้ ส่วนหน้าล็อกอินที่ AI เขียนดีได้เท่ากับโค้ด AI ที่อยู่เบื้องหลัง หากต้องเปิดแอปนอกเครือข่ายส่วนตัว ล็อกอินบริษัทเพิ่มชั้นยืนยันตัวตนที่มีการจัดการไว้ด้านหน้า จึงเป็นขั้นที่สอง
เมื่อเจ้าของงบประมาณต้องเข้าถึง เปลี่ยนล็อกอินของเครื่องมือเป็นล็อกอินบริษัท หรือ single sign-on (SSO) ผู้ใช้ใช้บัญชีบริษัทที่มีอยู่แล้ว ดังนั้นการปิดบัญชีนั้นปิดกั้นการเข้าสู่ระบบใหม่ ตั้งค่าการเพิกถอนเซสชัน การออกจากระบบแบบ back-channel หรืออายุเซสชันที่สั้นเหมาะสมเพื่อไม่ให้เซสชันเดิมค้าง พรอมป์ต์ใช้ OIDC ซึ่งเป็นโปรโตคอลล็อกอินมาตรฐานที่ Authentik และ Keycloak รองรับ
เปลี่ยนล็อกอินของแอปนี้เป็นล็อกอินบริษัทผ่าน [Authentik / Keycloak / ผู้ให้บริการตัวตนของเรา] โดยใช้ OIDC
อ่านกลุ่มของผู้ใช้แต่ละคนจากข้อมูลการเข้าสู่ระบบ
อนุญาต [หน้าเงินเดือน] เฉพาะสมาชิก [ชื่อกลุ่ม] และบังคับกฎนี้บนเซิร์ฟเวอร์สำหรับทุกหน้า ทุกการส่งออก และทุกปลายทาง API ไม่ใช่แค่ในเมนู
ปฏิเสธทุกคำขอที่ไม่มีข้อมูลเข้าสู่ระบบที่ถูกต้อง
ตรวจสอบว่าได้ผล: เข้าสู่ระบบด้วยบัญชีทดสอบที่ไม่อยู่ในกลุ่ม ขอหน้าและที่อยู่ส่งออกหรือ API ที่จำกัดโดยตรง และทั้งสองต้องถูกปฏิเสธ จากนั้นปิดบัญชีทดสอบในผู้ให้บริการตัวตน และยืนยันว่าเริ่มเซสชันใหม่ไม่ได้ ยืนยันด้วยว่าเซสชันเดิมถูกเพิกถอนหรือหมดอายุภายในเวลาที่กำหนด
บางเครื่องมือไม่ควรอยู่กับทีมเลย ส่งให้ IT หรือวิศวกรรมเมื่อข้อใดต่อไปนี้เป็นจริง:
- ลงบัญชีแยกประเภททั่วไปหรือระบบบันทึกหลักอื่นโดยไม่มีคนอนุมัติใน ERP
- สร้างไฟล์ชำระเงิน ปล่อยชำระเงิน หรือเปลี่ยนข้อมูลธนาคารผู้ขาย
- ผลลัพธ์ส่งเข้างบการเงินของบริษัทที่จดทะเบียนกับ SEC ซึ่งอาจทำให้เครื่องมืออยู่ในขอบเขตการควบคุมภายในด้านรายงานการเงิน (ICFR) ปรึกษาตรวจสอบภายในก่อนใช้ปิดบัญชี สำหรับผู้ออกหลักทรัพย์ที่อยู่ภายใต้ SOX มาตรา 404(b) ผู้สอบบัญชีภายนอกอาจทดสอบการควบคุมที่เกี่ยวข้องด้วย
- เก็บ ประมวลผล หรือส่งข้อมูลบัตรชำระเงิน
- ให้คะแนนความน่าเชื่อถือทางเครดิตของบุคคล
- ไม่มีใครในทีมรับผิดชอบติดตั้งแพตช์ ทบทวนสิทธิ์เข้าถึง และเลิกใช้งาน
เงื่อนไขที่หกมีน้ำหนักมากกว่าที่เห็น เมื่อโฮสต์เอง คุณ รับผิดชอบอัปเดต สำรองข้อมูล และเฝ้าระวัง เครื่องมือการเงินที่ไม่มีใครดูแลปลอดภัยกว่าเมื่ออยู่กับ IT ทีม IT อาจช้ากว่า แต่นั่นคือราคาของการกำกับดูแลที่เงื่อนไขเหล่านี้ต้องการ
ระดับ 1 และ 2 ต้องมีเซิร์ฟเวอร์ ชั้นปรับใช้ เครือข่ายส่วนตัว และสำหรับระดับ 2 ผู้ให้บริการตัวตน ก่อนใครเปิดเครื่องมือ ทีมการเงินที่ไม่มีวิศวกรต้องสร้างระบบนี้เอง Linux VPS ของเราให้สิทธิ์ root Coolify และ WireGuard ปรับใช้ได้ด้วยคลิกเดียว Tailscale ติดตั้งด้วยคำสั่งเดียวผ่านตัวติดตั้งทางการ ส่วน Authentik ทำงานจากชุด Docker Compose ทางการ ทีมจึงใช้เวลาแก้ปัญหาด้านบนแทนสร้างระบบปรับใช้จากศูนย์ ที่ตั้งของเรามีแฟรงก์เฟิร์ตและอัมสเตอร์ดัมใน EU ลอนดอนใน UK และหลายเมืองในสหรัฐฯ ให้คุณเลือกภูมิภาคของพื้นที่จัดเก็บ VPS หลักของแอปได้ การเลือกนั้นยอมรับได้หรือไม่ยังเป็นการตัดสินของฝ่ายกำกับข้อกำหนด
กฎที่ควรตรวจสอบกับทีมกำกับข้อกำหนดตามภูมิภาค
กรอบใดใช้บังคับขึ้นอยู่กับสิ่งที่เครื่องมือแตะ และตำแหน่งบริษัทกับบุคคลในข้อมูล ตารางเงินเดือนพนักงาน EU และตารางรายได้ที่ส่งเข้างบการเงินบริษัทจดทะเบียนในสหรัฐฯ อาจอยู่ภายใต้คนละกรอบ
ไม่มีเนื้อหาใดในบทความนี้เป็นคำแนะนำทางกฎหมาย ตารางด้านล่างระบุกรอบที่ควรปรึกษาทีมกำกับข้อกำหนด ไม่ได้ตัดสินว่ากรอบใดใช้กับคุณ
| ที่ไหน / เมื่อใด | กรอบการปฏิบัติตามข้อกำหนด | คำถามสำหรับฝ่ายกำกับข้อกำหนด | แหล่งอ่าน |
|---|---|---|---|
| สหรัฐฯ บริษัทที่รายงานต่อ SEC | Sarbanes-Oxley มาตรา 404 การควบคุมภายในด้านรายงานการเงิน (ICFR) | ผลลัพธ์เครื่องมือนี้ส่งเข้างบการเงินหรือไม่ และควรอยู่ในทะเบียนการควบคุมของเราหรือไม่? | AS 2201 ของ PCAOB |
| EU ข้อมูลส่วนบุคคล (เงินเดือน ค่าใช้จ่ายพนักงาน ข้อมูลธนาคารลูกค้า) | GDPR | ฐานทางกฎหมายของข้อมูลนี้ในเครื่องมือคืออะไร และมาตรการความปลอดภัยเป็นไปตามมาตรา 32 หรือไม่? | คู่มือ EDPB เพื่อรักษาความปลอดภัยข้อมูลส่วนบุคคล |
| UK ข้อมูลส่วนบุคคล | UK GDPR | ฐานทางกฎหมายของเราตาม UK GDPR คืออะไร และเครื่องมือเป็นไปตามหลักความปลอดภัยหรือไม่? | คู่มือ ICO ว่าด้วยหลักการคุ้มครองข้อมูล |
| ทุกที่ที่เกี่ยวข้องกับข้อมูลบัตร | PCI DSS (มาตรฐานอุตสาหกรรม ไม่ใช่กฎหมายในตัวเอง) | เครื่องมือนี้ทำให้ข้อมูลบัตรอยู่ในขอบเขตหรือไม่ และหลีกเลี่ยงการแตะข้อมูลบัตรทั้งหมดได้หรือไม่? | PCI Security Standards Council ว่าด้วย PCI DSS |
| EU หากเครื่องมือประเมินความน่าเชื่อถือทางเครดิตของบุคคล (กฎความเสี่ยงสูงของภาคผนวก III ปัจจุบันเริ่มใช้ตั้งแต่ 2 ธันวาคม 2027) | EU AI Act ประเภทความเสี่ยงสูง (ยกเว้น AI ที่ใช้ตรวจจับการฉ้อโกงทางการเงิน) | นี่เป็นระบบ AI ความเสี่ยงสูงตามภาคผนวก III หรือไม่? | หน้า AI Act ของคณะกรรมาธิการยุโรป; ภาคผนวก III ของ AI Act |
| ข้อมูลส่วนบุคคล EU หรือ UK ที่เปิดให้ผู้รับแยกต่างหากนอกเขตอำนาจที่เกี่ยวข้องเข้าถึง หรือสัญญาลูกค้าที่กำหนดที่เก็บบันทึก | GDPR บท V กฎ UK ว่าด้วยการโอนระหว่างประเทศ และสัญญาลูกค้า | ข้อมูลนี้อยู่บนเซิร์ฟเวอร์ใน [สถานที่] ได้หรือไม่ และมีสัญญาลูกค้าจำกัดหรือไม่? | คู่มือ EDPB ว่าด้วยการโอนข้อมูลระหว่างประเทศ; แนวทาง ICO ว่าด้วยการโอนระหว่างประเทศ |
สำหรับแถว SOX, AS 2201 คือมาตรฐาน PCAOB สำหรับการรับรองของผู้สอบบัญชีที่มาตรา 404(b) ของกฎหมาย Sarbanes-Oxley อ้างถึง โดยระบุการควบคุมรายการสมุดรายวันและรายการปรับปรุงในกระบวนการรายงานการเงินปลายงวดเป็นส่วนหนึ่งของการควบคุมที่ผู้สอบบัญชีประเมินเมื่อจัดการความเสี่ยงทุจริต นอกภูมิภาคเหล่านี้ เริ่มที่เว็บไซต์ของหน่วยงานกำกับข้อมูลส่วนบุคคลแห่งชาติ ที่ตั้งเซิร์ฟเวอร์กำหนดตำแหน่งพื้นที่จัดเก็บหลัก ไม่ได้บอกว่าข้อมูลสำรอง ล็อก หรือสำเนาของบุคคลที่สามทุกชุดอยู่ที่ไหน และเพียงอย่างเดียวไม่ทำให้เป็นไปตามกรอบด้านบน
คำถามที่พบบ่อย
Vibe Coding ปลอดภัยสำหรับเครื่องมือการเงินหรือไม่?
อาจปลอดภัยได้เมื่อปิดช่องว่างที่เดโมทิ้งไว้ ผมมองหลักฐานว่าเป็นปัญหาการนำไปใช้งานมากกว่าการเขียนโค้ด เครื่องมือการเงินเสี่ยงกว่าโครงการส่วนตัวเพราะอ่าน ERP และเขียนบัญชีได้ เมื่อมันลงบัญชีโดยไม่มีผู้อนุมัติคนที่สอง จัดการชำระเงิน หรือแตะข้อมูลบัตร ควรอยู่กับ IT
Shadow AI ในงานการเงินคืออะไร?
Shadow AI คือเครื่องมือ AI หรือแอปที่สร้างด้วย AI ซึ่งใช้กับข้อมูลบริษัทโดย IT ไม่รู้หรือไม่อนุมัติ เช่น แดชบอร์ดพยากรณ์ที่เชื่อม ERP ซึ่ง IT ไม่เคยเห็น รายงาน Cost of a Data Breach Report ปี 2025 ของ IBM พบว่าองค์กรที่มี Shadow AI ระดับสูงมีต้นทุนการละเมิดข้อมูลเฉลี่ยสูงกว่าองค์กรที่มีระดับต่ำหรือไม่มี $670,000 ตาม ประกาศของ IBM
ควรแสดงอะไรแก่ตรวจสอบภายในหรือผู้สอบบัญชีภายนอก?
เตรียมสี่เรื่องก่อนใช้เครื่องมือปิดบัญชี: ทำงานที่ไหนและใครเข้าถึงได้ ประวัติการเปลี่ยนพร้อมการทดสอบผลลัพธ์ที่ตรึงไว้ วิธีอนุมัติการลงบัญชีใน ERP และหลักฐานการกระทบยอดแต่ละแบตช์กับยอดรวม ERP ผู้สอบบัญชีเป็นผู้ตัดสินว่าต้องการอะไร สิ่งเหล่านี้ให้ข้อมูลรูปธรรมเพื่อประเมิน
ใครดูแลเครื่องมือการเงินที่สร้างด้วย AI หลังผู้สร้างย้ายงาน?
ระบุผู้รับผิดชอบในฝ่ายการเงินและผู้ติดต่อทางเทคนิคก่อนเปิดใช้ ให้เครื่องมือใช้ข้อมูลรับรองบริการแทนบัญชีส่วนตัวผู้สร้าง และเข้าถึงผ่านล็อกอินบริษัท เพื่อให้การปิดบัญชีบริษัทของผู้ลาออกปิดกั้นการเข้าสู่ระบบใหม่ โดยเพิกถอนเซสชันเดิมหรือให้หมดอายุตามนโยบายเซสชัน การเลิกใช้หมายถึงปิดข้อมูลรับรอง เก็บสิ่งที่นโยบายเก็บรักษากำหนด ลบส่วนที่เหลือ และปิดเครื่องมือ
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา