การสวมรอยตัวตนของเวิร์กโฟลว์: Noma Labs เปลี่ยนอีเมลฝ่ายสนับสนุนทั่วไปให้กลายเป็นการเข้าถึงข้อมูลที่มีสิทธิ์สูง

เมื่อวันที่ 9 กันยายน 2026 ทีมวิจัยของ Noma Security ซึ่งเขียนในนาม Noma Labs ได้เผยแพร่บทความเกี่ยวกับสิ่งที่ทีมเรียกว่าการสวมรอยตัวตนของเวิร์กโฟลว์ (workflow identity hijacking): เวิร์กโฟลว์ AI ระดับองค์กรอ่านข้อความธรรมดาที่มาถึงจุดเข้าแบบสาธารณะ — กล่องจดหมายฝ่ายสนับสนุน, issue บน GitHub, ฟอร์มเว็บ, เอกสารที่แชร์กัน — แล้วดำเนินงานตามที่ร้องขอโดยใช้บัญชีบริการที่มีสิทธิ์สูงของตนเองแทนสิทธิ์ของผู้ส่ง คำอธิบายทีละขั้นของ Noma แสดงให้เห็นคนนอกส่งอีเมลไปยังที่อยู่ฝ่ายสนับสนุนสาธารณะของบริษัท และขอสิ่งต่างๆ รวมถึงตัวเลขยอดขายรายไตรมาสจากอีเมลล่าสุดของผู้อำนวยการฝ่ายการเงิน ไม่กี่นาทีต่อมา เนื้อหาก็มาถึงกล่องจดหมายของผู้โจมตี ไม่มีโมเดลใดถูกหลอก และไม่มีบัญชีใดถูกเจาะ ซึ่งเป็นประเด็นของรายงาน: “ผู้โจมตีเพียงแค่ต้องขอ” คลังบันทึกไม่พบความเสียหายจริง — ไม่มีการระบุชื่อเหยื่อ และไม่มีระบบที่ใช้งานจริงถูกระบุว่าถูกบุกรุก — และจัดเกรดข้อค้นพบเป็นงานวิจัย ระดับความรุนแรงปานกลาง ความเชื่อมั่น A และสถานะถูกโต้แย้งเป็นเท็จ บทความนี้อ้างอิงจากรายงานของ Noma Labs จากบทความของ Dark Reading ที่เผยแพร่ในวันเดียวกัน และจากบทความติดตามของ CSO Online และคลังเหตุการณ์ AIเก็บรายการนี้ไว้เคียงข้างรายการข้างเคียง โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง และระดับความเชื่อมั่นของตนเอง

ฟิลด์ของบันทึกนั้นคุ้มค่าที่จะอ่านก่อนตัวเนื้อหา โดยมีแท็กเป็น INFRA และ EXFIL ครอบคลุมภูมิภาค GLOBAL มีวันที่ระบุ precise ถึงระดับวันเพียงวันเดียวคือ 9 กันยายน 2026 และไม่ได้ถูกทำเครื่องหมายว่าเป็นรายการสำคัญ วันที่ดังกล่าวเป็นวันที่เผยแพร่งานวิจัยเท่านั้น ไม่มีไทม์ไลน์เหตุการณ์แนบมาด้วย เพราะไม่มีเหตุการณ์ใดให้กำหนดเวลา นี่คือสิ่งแรกที่ต้องยึดไว้: สิ่งที่ Noma เผยแพร่คือกลไกและหมวดหมู่ ไม่ใช่รายงานการละเมิด

สิ่งที่ Noma แสดงให้เห็น และสิ่งที่มันไม่ได้แสดงให้เห็น

ลำดับเหตุการณ์ของกล่องข้อความฝ่ายสนับสนุนเป็นตัวอย่างที่สร้างขึ้น ไม่ใช่กรณีของลูกค้า รายงานของ Noma ไม่ได้ระบุชื่อองค์กร ไม่ได้ให้จำนวนการติดตั้งใช้งานที่ได้รับผลกระทบ ไม่ได้เผยแพร่ข้อมูลเทเลเมทรีจากไปป์ไลน์จริงใด ๆ และไม่ได้แนบลิงก์การรัน proof-of-concept สำหรับสถานการณ์นี้ ซึ่งต่างจากงานวิจัยเดือนกรกฎาคมของกลุ่มที่ชี้ไปยังการรัน GitHub Actions แบบสาธารณะ สิ่งที่รายงานเสนอแทนคือคำอธิบายกลไกที่ละเอียดเพียงพอจะตรวจสอบเทียบกับสถาปัตยกรรมได้ โดยมีอินพุตที่ไม่ผ่านการตรวจสอบสิทธิ์เข้ามา โมเดลตีความอินพุตนั้นได้อย่างถูกต้อง ไปป์ไลน์ดำเนินการเรียกปลายทาง และการเรียกนั้นกระทำด้วยสิทธิ์ของผู้สร้างเวิร์กโฟลว์

Sasi Levi หัวหน้าฝ่ายวิจัยความปลอดภัยของ Noma และผู้เขียนรายงาน สรุปสาเหตุรากในประโยคเดียวว่า “ตัวตนและสิทธิ์การอนุญาตของผู้ใช้ที่เรียกใช้งานเวิร์กโฟลว์ถูกแยกออกจากตัวตนและสิทธิ์การอนุญาตที่ใช้ในการดำเนินการเวิร์กโฟลว์นั้น” ในกรณีที่เงื่อนไขนี้เป็นจริง เวิร์กโฟลว์จะกลายเป็น—ตามถ้อยคำในรายงาน—“พร็อกซีที่ไม่มีการยืนยันตัวตนสำหรับการดำเนินการที่ได้รับสิทธิ์พิเศษและการลักลอบส่งข้อมูลออกอย่างเงียบ ๆ”

เนื่องจากการดำเนินการเหล่านี้ทำงานผ่านระบบอัตโนมัติที่เชื่อถือได้พร้อมข้อมูลรับรองที่ถูกต้อง Noma จึงโต้แย้งว่าแทบไม่มีอะไรให้การแจ้งเตือนแบบดั้งเดิมตรวจจับได้ คำขอเป็นเรื่องปกติ เอาต์พุตของโมเดลเป็นเอาต์พุตของโมเดลที่ถูกต้อง การเรียก API ได้รับการยืนยันตัวตนแล้ว และการตอบกลับก็คือการตอบกลับที่เวิร์กโฟลว์ถูกสร้างขึ้นมาเพื่อส่ง CSO Online อ้างคำพูดของ Vibhum Dubey นักทดสอบเจาะระบบที่ทำให้ปัญหาการตรวจจับเป็นรูปธรรมว่า "เหตุการณ์แต่ละเหตุการณ์อาจดูชอบธรรมโดยสมบูรณ์ สัญญาณที่มีประโยชน์จะมาจากการเชื่อมโยงผู้ร้องขอต้นทาง ตัวตนที่ใช้ในปลายทาง ทรัพยากรที่เข้าถึง พารามิเตอร์ที่ให้มา และการกระทำสุดท้าย"

การตรวจสอบที่ล้มเหลวคือการตรวจสอบสิทธิ์ ไม่ใช่ตัวกรองเนื้อหา

ภาพประกอบที่คมชัดที่สุดในรายงานคือคำขอที่เหมือนกันสองรายการ จากประธานเจ้าหน้าที่ฝ่ายการเงิน: "ตัวเลขยอดขายรายไตรมาสจากผู้อำนวยการฝ่ายการเงินในอีเมลล่าสุดของเขาคืออะไร?" จากผู้ส่งภายนอก: คำเดียวกันทุกคำ ประเด็นของ Noma คือพรอมป์ตและการดำเนินการที่ขอเหมือนกัน ขณะที่การตัดสินใจเรื่องการอนุญาตควรแตกต่างกันโดยสิ้นเชิง — "ประธานเจ้าหน้าที่ฝ่ายการเงิน (CFO) มีสิทธิได้รับข้อมูลนั้น ผู้ส่งภายนอกไม่มีสิทธิ"

รายงานโต้แย้งว่า ตัวตรวจจับการโจมตีแบบ prompt injection มาตรฐานและแนวป้องกันของเอเจนต์จัดประเภทอินพุตทั้งสองแบบว่าเหมือนกัน เพราะไม่มีสิ่งใดในอินพุตทั้งสองที่ถือเป็นอันตรายให้ตรวจจับได้ "ความเสี่ยงด้านความปลอดภัยไม่ได้อยู่ที่พรอมป์ต แต่อยู่ที่ขอบเขตการอนุญาต" ข้ออ้างเชิงโครงสร้างของ Noma สืบเนื่องมาจากแนวคิดนี้: แนวป้องกัน คำสั่งระบบ และตัวกรองอินพุต "ไม่ได้ถูกออกแบบมาให้ทำหน้าที่เป็นขอบเขตการอนุญาต" ดังนั้นไปป์ไลน์ที่พึ่งพาสิ่งเหล่านี้ในการตัดสินว่าผู้เรียกใช้สามารถดึงข้อมูลใดได้ จึงพึ่งพากลไกควบคุมที่ไม่เคยถูกกำหนดให้ทำงานนั้นตั้งแต่แรก

ความแตกต่างนี้สำคัญในทางปฏิบัติ การฉีดพรอมต์โดยตรงบิดเบือนวิธีที่โมเดลปฏิบัติตามคำสั่ง การฉีดพรอมต์โดยอ้อมซ่อนคำสั่งไว้ในเนื้อหาที่โมเดลจะอ่านในภายหลัง ส่วนการยึดตัวตนของเวิร์กโฟลว์ (workflow identity hijacking) ตามนิยามของ Noma ไม่จำเป็นต้องมีทั้งสองอย่าง เพราะคำขอนั้นเป็นคำขอที่โมเดลควรเข้าใจและไปป์ไลน์ควรดำเนินการ ผู้ป้องกันที่ใช้เวลาทั้งปีเสริมความแข็งแกร่งต่อการฉีดพรอมต์ได้ทำงานอยู่ในอีกเลเยอร์ที่แตกต่างออกไป

เวิร์กโฟลว์แบบสแตติกอยู่นอกเหนือความพยายามในการเสริมความแข็งแกร่งของเอเจนต์

Noma แยกสองสิ่งที่มักถูกใช้แทนกันเป็นประจำ เวิร์กโฟลว์ AI คือลำดับแบบคงที่ที่กำหนดไว้ล่วงหน้า ซึ่งโมเดลเป็นเพียงขั้นตอนการประมวลผลขั้นตอนเดียว — คำเรียกสั้น ๆ ในรายงานคือ ขั้นตอน A, โมเดล, ขั้นตอน B, ขั้นตอน C — และไปป์ไลน์แบบดีเทอร์มินิสติกที่ล้อมรอบโมเดลเป็นตัวควบคุมว่าเกิดอะไรขึ้น เวิร์กโฟลว์แบบ agentic เป็นแบบอัตโนมัติ: เอเจนต์ตัดสินใจว่าจะทำขั้นตอนใดและจะเรียกใช้เครื่องมือใด รายงานโต้แย้งว่าความพยายามด้านความปลอดภัยในปัจจุบันจำนวนมากไปอยู่ที่ประเภทที่สอง คือการจำกัดการเข้าถึงเครื่องมือและการกำหนดขอบเขตสิทธิ์สำหรับเอเจนต์ที่ตัดสินใจแบบไดนามิก และการควบคุมเหล่านั้นไปไม่ถึงประเภทแรก

รายงานยังปิดช่องหลบเลี่ยงที่ชัดเจนอีกด้วย การจำกัดว่าใครหรือสิ่งใดสามารถกระตุ้นเวิร์กโฟลว์ได้ไม่ได้แก้ปัญหา: หากระบบอัตโนมัติทำงานตามกำหนดเวลาเวลา 8:00 น. และดำเนินการกับกล่องจดหมายที่ใครก็เขียนถึงได้ การตรวจสอบว่า "ใครสามารถกระตุ้นเวิร์กโฟลว์นี้ได้" ก็ตอบคำถามผิดข้อ กฎของ Noma คือระบบอัตโนมัติทุกระบบต้องได้รับการประเมินโดย "ฝ่ายที่เชื่อถือได้น้อยที่สุดซึ่งสามารถมีอิทธิพลต่อสิ่งที่ระบบนั้นดำเนินการ" — รวมถึงอีเมล แบบฟอร์ม ตั๋ว ปัญหาใน GitHub เอกสารที่แชร์ และข้อความแชต

Noma กล่าวว่า Google แก้ไขกรณีของ Google Workflows แล้ว; Google ยังไม่ได้เผยแพร่สิ่งใดเลย

แพลตฟอร์มเดียวที่ถูกระบุชื่อในรายงานคือของ Google Noma ระบุว่าตนตรวจพบเวกเตอร์ความเสี่ยงเดียวกันภายใน Google Workflows ว่าตนได้รายงานอย่างมีความรับผิดชอบ และว่า Google ได้รับทราบรายงานและยืนยันการแก้ไข "โดยไม่เปิดเผยรายละเอียดการนำไปใช้งาน" ประโยคดังกล่าวคือเนื้อหาทั้งหมดของบันทึกสาธารณะ ไม่สามารถค้นหาคำแนะนำของ Google บันทึกการเผยแพร่ หรือ CVE ที่อธิบายเวกเตอร์นี้ได้ และรายงานทุติยภูมิทุกฉบับเกี่ยวกับการแก้ไข — รวมถึงฉบับที่เผยแพร่ในช่วงหลายวันหลังวันที่ 9 กันยายน — ล้วนระบุว่าเป็นผลงานของ Noma ไม่ใช่ของ Google

รายงานยังไม่สอดคล้องกันอย่างสมบูรณ์เกี่ยวกับผลิตภัณฑ์ Google ที่หมายถึง เนื้อความระบุชื่อ Google Workflows; หัวข้อส่วนหนึ่งในรายงานเดียวกันเขียนว่า "Google Workspace: AI Workflow Identity Hijacking." ทั้งสองเป็นผลิตภัณฑ์ของ Google ที่มีขอบเขตความไว้วางใจแตกต่างกัน และรายงานไม่ได้ทำให้ทั้งสองสอดคล้องกัน Noma ไม่ได้ระบุว่ากรณีที่รายงานนั้นถูกใช้ประโยชน์แล้วหรือไม่ มีลูกค้ากี่รายที่ได้รับผลกระทบ หรือการแก้ไขเปลี่ยนแปลงอะไรไป — และเนื่องจาก Google ไม่ได้กล่าวอะไร ช่องว่างเหล่านี้จึงไม่อาจถูกปิดจากฝั่งผู้ขายได้

GitLost คือเส้นแบ่งเดียวกันที่มองผ่านเลนส์ที่แคบลง

การเปิดเผยก่อนหน้านี้ของ Noma ทำให้หมวดหมู่นี้มีแบบอย่าง ในเดือนกรกฎาคม 2026 กลุ่มได้เผยแพร่งานวิจัยเกี่ยวกับ GitHub Agentic Workflows ซึ่งตั้งชื่อว่า GitLost: เวิร์กโฟลว์ที่ทริกเกอร์เมื่อมีการมอบหมาย issue จะอ่านชื่อและเนื้อหาของ issue แล้วตอบกลับด้วยความคิดเห็น และเนื่องจากเอเจนต์มีสิทธิ์อ่านทั่วทุกรีโพซิทอรีขององค์กร ผู้ใช้ภายนอกจึงใช้การมอบหมาย issue เพื่อเข้าถึงข้อมูลรีโพซิทอรีส่วนตัวได้ Dark Reading รายงานเรื่องนี้เมื่อวันที่ 7 กรกฎาคม 2026 และอธิบายถึงผู้โจมตีที่ซ่อนคำสั่งในภาษาอังกฤษธรรมดาไว้ในเนื้อหาของ issue ที่เปิดในรีโพซิทอรีสาธารณะ โดยไม่ต้องใช้ข้อมูลรับรองและไม่ต้องมีทักษะการเขียนโค้ด

การนำเสนอสองแบบไม่เหมือนกัน และความแตกต่างคือส่วนที่น่าสนใจ บทความของ Dark Reading ในเดือนกรกฎาคมเป็นเรื่องเกี่ยวกับการฉีดพรอมต์ (prompt-injection): ข้อความที่ผู้โจมตีควบคุมถูกอ่านเป็นคำสั่ง รายงานของ Noma ในเดือนกันยายนอธิบาย GitLost ในแง่ของทริกเกอร์และการเข้าถึงแบบอ่านทั่วทั้งรีโพซิทอรี และนำเสนอว่าเป็นขอบเขตการอนุญาตเดียวกันที่มองจากมุมหนึ่ง คำอธิบายทั้งสองแบบเข้ากับเวิร์กโฟลว์ที่เอเจนต์อ่านข้อความซึ่งคนนอกเป็นผู้เขียน แต่มีเพียงคำอธิบายแรกเท่านั้นที่ขึ้นอยู่กับการที่โมเดลถูกชี้นำ ตอนนี้ Noma กล่าวว่าได้รายงานเวกเตอร์ความเสี่ยงเดียวกันไปยัง Google แล้ว แต่ไม่ได้ระบุว่ากรณี GitLost เคยถูกใช้โจมตีเกินกว่าการสาธิตที่เผยแพร่หรือไม่

คำอธิบายของ Noma เองเกี่ยวกับการเข้าถึงคือ Hacker News, Dark Reading และสื่อต่างประเทศอีกกว่า 100 แห่งได้รายงานข่าวงานวิจัย GitLost ตัวเลขดังกล่าวเป็นข้อมูลของผู้ขาย และบทความนี้ไม่ได้นับจำนวนการรายงานข่าวนั้นอย่างเป็นอิสระ

ผู้ปฏิบัติเห็นพ้องกันว่ากลไกนี้มีมานานแล้ว ที่ถกเถียงกันคือชื่อ

การรายงานข่าวจากสำนักข่าวอิสระไม่ได้โต้แย้งข้อค้นพบนี้ และผู้ปฏิบัติงานจากภายนอกสองรายได้โต้แย้งในประเด็นความใหม่มากกว่าเนื้อหาสาระ Morey Haber หัวหน้าที่ปรึกษาด้านความปลอดภัยของ BeyondTrust กล่าวกับ Dark Reading ว่า "ไม่มีใครหลอกให้โมเดล AI ทำอะไรที่มันไม่ควรทำ โมเดลทำตามที่ถูกสั่งอย่างตรงไปตรงมา โดยคนแปลกหน้า (ที่ไม่น่าเชื่อถือ) และเวิร์กโฟลว์รอบ ๆ มันใช้ตัวตนของคนอื่นเพื่อทำให้สิ่งนั้นเกิดขึ้น เนื่องจากมันไม่ได้ถูกกำหนดขอบเขตและปฏิบัติตามหลักสิทธิ์น้อยที่สุด" CSO Online อ้างคำพูดของ Vibhum Dubey ซึ่งอธิบายรูปแบบนี้ว่าเป็น "ประเภทที่รู้จักกันดีของจุดอ่อนด้านการอนุญาต" และเสริมว่าในกรณีที่อินพุตที่ไม่ได้ผ่านการยืนยันตัวตนสามารถกระตุ้นเวิร์กโฟลว์ที่เชื่อถือได้ซึ่งดำเนินการด้วยสิทธิ์ของตัวเอง "เวิร์กโฟลว์นั้นสามารถทำหน้าที่เป็นตัวแทนที่สับสนได้อย่างมีประสิทธิผล"

Ram Varadarajan ประธานเจ้าหน้าที่บริหารของ Acalvio เสนอการควบคุมที่แตกต่างออกไปโดยสิ้นเชิงแก่ Dark Reading: แทนที่จะกรองมากขึ้น ให้หว่านสภาพแวดล้อมด้วยตัวล่อ — เธรดผู้บริหารปลอม บันทึกโทเค็นล่อ — ซึ่งไม่มีเหตุผลอันชอบธรรมใด ๆ ที่เวิร์กโฟลว์ที่ได้รับอนุญาตจะต้องแตะต้อง ดังนั้นคำขอที่ดูไม่เป็นอันตรายซึ่งเอื้อมไปหาสิ่งเหล่านี้จะไปชนขอบเขตที่มันไม่ควรข้ามเด็ดขาด ข้อโต้แย้งที่มีอยู่นั้นเกี่ยวกับว่าการมีส่วนร่วมที่มีประโยชน์คือชื่อใหม่สำหรับช่องโหว่การมอบอำนาจในยุคปี 1988 หรือคำอธิบายที่ใช้ได้จริงว่าช่องโหว่นั้นอยู่ที่ใดในปัจจุบัน จุดยืนของ Noma คืออย่างหลัง: รูปแบบนี้เป็นเชิงระบบทั่วทั้งไปป์ไลน์ AI ขององค์กร และกรอบความปลอดภัย AI ในปัจจุบันมองผิดพื้นผิว

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

การควบคุมที่ Noma แนะนำอยู่ในระดับแอปพลิเคชันมากกว่าระดับโมเดล การมอบหมายสิทธิ์ด้วยโทเค็นที่รับรู้ตัวตนหมายถึงการนำคีย์ API สำหรับผู้ดูแลแบบคงที่ออกจากเวิร์กโฟลว์ AI และดำเนินการกับข้อมูลโดยใช้โทเค็นการมอบหมายสิทธิ์ที่มีอายุสั้นและมีขอบเขตจำกัดซึ่งผูกกับผู้ร้องขอที่ผ่านการยืนยันตัวตน เพื่อให้บริบทของผู้ใช้ถูกส่งต่อไปยังการเรียกที่เข้าถึงข้อมูลจริง จุดตรวจสอบการอนุญาตตามบริบทหมายถึงการถือว่าผลลัพธ์ทุกอย่างของโมเดลเป็นอินพุตที่ไม่น่าเชื่อถือ และวางการประเมินการควบคุมการเข้าถึงและการป้องกันระหว่างรันไทม์อย่างชัดเจนไว้ระหว่างขั้นตอนการแปลงของโมเดลกับการเรียกฐานข้อมูลหรือเครื่องมือใด ๆ ที่ตามมา การแยกผลลัพธ์แบบอสมมาตรหมายถึงการแยกการดึงข้อมูลออกจากช่องทางการสื่อสารภายนอกในเชิงโครงสร้าง เพื่อให้เวิร์กโฟลว์ที่จัดการข้อมูลภายในที่ละเอียดอ่อนไม่ใช้เส้นทางการทำงานร่วมกับกลไกอัตโนมัติที่ตอบกลับบุคคลภายนอก

Dubey ให้การทดสอบที่ถูกกว่าทั้งสามวิธีแก่ CSO Online: เปรียบเทียบผลลัพธ์ในระดับสิทธิ์ต่างๆ “หากผู้ใช้ที่มีสิทธิ์ต่ำสามารถได้ผลลัพธ์เดียวกันกับผู้ดูแลระบบ เพราะระบบปลายทางมองเห็นเพียงตัวตนของเวิร์กโฟลว์ นั่นคือจุดที่ฉันจะมุ่งเน้นการตรวจสอบ”

สิ่งที่บันทึกยังเปิดไว้

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

• Google ผลิตภัณฑ์ใดที่ได้รับการแก้ไข และการแก้ไขคืออะไร ข้อความบรรยายของ Noma ระบุว่า Google Workflows ขณะที่หัวข้อในส่วนของบริษัทระบุว่า Google Workspace และ Google ยังไม่ได้เผยแพร่ข้อมูลใด ๆ องค์กรต่าง ๆ ยังไม่สามารถระบุได้จากแหล่งข้อมูลสาธารณะว่าไปป์ไลน์ที่ตนใช้งานอยู่ในขอบเขตหรือไม่

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

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

• ใครเป็นผู้ตั้งข้อโต้แย้งนี้ Noma Labs เป็นหน่วยงานวิจัยของ Noma Security ซึ่งจำหน่ายระบบควบคุมความปลอดภัยสำหรับเอเจนต์แบบเดียวกับที่รายงานของบริษัทแนะนำ นั่นไม่ได้ทำให้ข้อค้นพบนั้นผิด — ทั้ง Dark Reading และ CSO Online ต่างรายงานเรื่องนี้ และทั้งสองไม่พบข้อผิดพลาดทางข้อเท็จจริง — แต่มันเป็นบริบทที่ผู้อ่านควรคำนึงถึงไว้ขณะชั่งน้ำหนักว่าหมวดหมู่นี้ถูกกำหนดขอบเขตไว้กว้างเพียงใด

ระดับความรุนแรง medium และแฟล็กความเสียหายจริงที่เป็น false ของระเบียนนี้อธิบายหลักฐาน ไม่ใช่อธิบายกลไก สิ่งที่ Noma สร้างขึ้นมาจริงนั้นแคบและตรวจสอบได้ นั่นคือ ตัวตนของตัวกระตุ้นในเวิร์กโฟลว์กับตัวตนของการทำงานเป็นคนละสิ่ง ตัวหลังมักมีอำนาจมากกว่า และไปป์ไลน์ที่ไม่เคยเปรียบเทียบทั้งสองจะทำกับคนแปลกหน้าในแบบเดียวกับที่มันจะทำกับคนที่มันถูกสร้างมาเพื่อ การควบคุมที่ตามมาจึงไม่หรูหราในทำนองเดียวกัน — ให้ถามว่า สำหรับระบบอัตโนมัติแต่ละตัว ใครสามารถมีอิทธิพลต่อสิ่งที่มันกระทำได้ และมีสิ่งใดในลำดับถัดไปที่ตรวจสอบซ้ำหรือไม่ว่าผู้ที่ขอได้รับอนุญาตให้ขอ