Micha Rave, CEO และผู้ร่วมก่อตั้ง Hush Security – ซีรีส์สัมภาษณ์

Micha Rave, CEO และผู้ร่วมก่อตั้ง Hush Security, เป็นผู้บริหารด้านความปลอดภัยไซเบอร์และเทคโนโลยีที่มีประสบการณ์ซึ่งอาชีพของเขาครอบคลุมการพัฒนาซอฟต์แวร์, การจัดการผลิตภัณฑ์, เครือข่ายระดับองค์กร, ความปลอดภัยคลาวด์, และอัตลักษณ์. ก่อนร่วมก่อตั้ง Hush Security ในปี 2024, เขาใช้เวลามากกว่าห้าปีที่ Proofpoint ในตำแหน่ง Senior Director of Product Management for Cloud Security, ซึ่งรับผิดชอบผลิตภัณฑ์ Zero Trust Network Access (ZTNA) และ Secure Web Gateway (SWG). ก่อนหน้านั้นเขาเคยดำรงตำแหน่ง VP of Product Management ที่ Meta Networks, มุ่งเน้นที่เครือข่ายระดับองค์กรและความปลอดภัย, และเคยมีบทบาทผู้นำด้านผลิตภัณฑ์และวิศวกรรมที่ HARMAN International, Redbend, SanDisk, Hola, Jungo, และ Elbit Systems. พื้นฐานของเขาผสมผสานการพัฒนาซอฟต์แวร์เชิงปฏิบัติกับประสบการณ์กว่าสองทศวรรษในการสร้างและทำการตลาดผลิตภัณฑ์ด้านความปลอดภัย, เครือข่าย, การเสมือน, และเทคโนโลยีฝังตัว.

Hush Security เป็นบริษัทด้านความปลอดภัยไซเบอร์ที่มุ่งเน้นการปกป้องเอเจนต์ AI และอัตลักษณ์ที่ไม่ใช่มนุษย์อื่น ๆ โดยการแทนที่ข้อมูลประจำตัวที่อายุยาวและความลับคงที่ด้วยการเข้าถึงที่อิงอัตลักษณ์และควบคุมด้วยนโยบาย. แพลตฟอร์มของบริษัทค้นพบเอเจนต์ AI รวมถึงเอเจนต์เงาและเอเจนต์ที่พัฒนาภายใน, มอบอัตลักษณ์ที่ตรวจสอบได้ให้กับพวกเขา, และควบคุมการโต้ตอบกับระบบระดับองค์กรโดยใช้สิทธิ์ที่กำหนดขอบเขตและให้ทันที (just‑in‑time), นโยบายศูนย์กลาง, และบันทึกกิจกรรมที่ตรวจสอบได้. บริษัทก่อตั้งโดยผู้เชี่ยวชาญด้านความปลอดภัยจากทีมที่อยู่เบื้องหลัง Meta Networks, ซึ่งถูก Proofpoint เข้าซื้อในปี 2019. ในเดือนกรกฎาคม 2026, Hush ระดมทุน Series A จำนวน 30 ล้านดอลลาร์สหรัฐพร้อม Akamai Technologies เข้าร่วมเป็นนักลงทุนเชิงกลยุทธ์ร่วมกับ Battery Ventures และ YL Ventures, ทำให้เงินทุนรวมเป็น 41 ล้านดอลลาร์สหรัฐขณะที่บริษัทขยายเทคโนโลยีเพื่อการกำกับดูแลเอเจนต์ AI ระดับองค์กรและโครงสร้างพื้นฐานที่ไม่ใช่มนุษย์.

ก่อนก่อตั้ง Hush Security, คุณใช้หลายปีในการสร้างและนำผลิตภัณฑ์ด้านความปลอดภัย รวมถึงความปลอดภัยคลาวด์ที่ Proofpoint. สิ่งใดที่คุณเห็นในตลาดที่ทำให้คุณเชื่อว่าต้องมีความจำเป็นในการเริ่ม Hush, และแนวคิดเดิมนั้นได้พัฒนาอย่างไรกับการเติบโตอย่างรวดเร็วของ AI ที่เป็นเอเจนต์?

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

แนวคิดพื้นฐานของการก่อตั้งคือการย้ายการเข้าถึงของสิ่งที่ไม่ใช่มนุษย์จากความลับไปสู่การใช้ตัวตน. ตัวตนของงานที่ตรวจสอบได้, ใบรับรองอายุสั้นที่ออกให้ทันที, นโยบายที่บังคับใช้ในสายงาน. ไม่ต้องเขียนโค้ดใหม่.

AI ที่เป็นเอเจนต์ทำให้เรื่องนี้เร่งด่วน. เอเจนต์คือ NHI ที่ทำการให้เหตุผลและตัดสินใจในเวลารันว่าเครื่องมือใดจะเรียกใช้. หากมอบคีย์คงที่ให้กับมัน คุณจะให้ซอฟต์แวร์อิสระเข้าถึงระบบการผลิตอย่างถาวร, และเอเจนต์จะถูกปล่อยออกนอกกระบวนการเปลี่ยนแปลงใด ๆ, นักพัฒนาติดตั้งเซิร์ฟเวอร์ MCP ในวันอังคารและมันก็เริ่มเข้าถึงข้อมูลลูกค้าในวันศุกร์.

แนวคิดไม่ได้เปลี่ยนแปลง. แต่ขอบเขตเปลี่ยน. การเข้าถึงที่อิงอัตลักษณ์เป็นคำตอบที่ถูกต้องสำหรับงานประมวลผล. สำหรับเอเจนต์แล้วเป็นวิธีเดียวที่ทำงานได้: รู้จักทุกเอเจนต์ที่มี, ให้แต่ละเอเจนต์มีสิทธิ์การทำงานขั้นต่ำโดยค่าเริ่มต้น, และตรวจสอบทุกการกระทำ. มนุษย์มี IdP. เอเจนต์ก็ต้องการ IdP เช่นกันและนั่นคือ Hush.

Hush อ้างว่ามีความเห็นว่าเอเจนต์ AI ระดับองค์กรควรมีอัตลักษณ์ของตนเองและสิทธิ์ที่มอบหมายแทนที่จะสืบทอดสิทธิ์การเข้าถึงจากมนุษย์ที่ใช้พวกมัน. ทำไมระบบจัดการอัตลักษณ์และการเข้าถึง (IAM) แบบดั้งเดิมจึงประสบปัญหาในการจัดการกับเอเจนต์อิสระ, และสิ่งใดที่ต้องเปลี่ยนแปลง?

กรณีที่ชัดเจนคือเอเจนต์ทำหน้าที่แทนผู้ใช้. กรณีที่ซับซ้อนคือเอเจนต์ที่ไม่มีผู้ใช้เลย: งานที่กำหนดเวลา, ตัวตอบสนอง SOC อิสระ, พายไลน์ที่ให้เหตุผลและดำเนินการด้วยตนเอง. ไม่มีใครให้สิทธิ์มอบหมาย, ดังนั้นทีมจึงใช้เครื่องมือเดียวที่มีคือบัญชีบริการคงที่ที่มีสิทธิ์กว้างและคีย์ที่ไม่มีวันหมดอายุ. นั่นคือโมเดล shared‑secret เดิมที่ล้มเหลวมานานกว่าทศวรรษ, ตอนนี้ถูกผูกกับซอฟต์แวร์ที่ทำการประดิษฐ์เอง.

ระบบที่อยู่ฝั่งตรงข้ามทำให้สถานการณ์แย่ลง. API ภายในส่วนใหญ่, ฐานข้อมูล, และเซิร์ฟเวอร์ MCP ไม่ได้ทำการอนุญาตจริง. พวกมันตรวจสอบว่าคุณถือโทเคนที่ถูกต้องหรือไม่, ไม่ได้ตรวจสอบว่าคุณได้รับอนุญาตให้ทำอะไรกับโทเคนนั้น. การครอบครองเท่ากับการได้รับสิทธิ์.

สิ่งที่ต้องเปลี่ยนแปลง: ทุกเอเจนต์ต้องได้รับอัตลักษณ์ของตนเอง, ออกโดยใช้การเข้ารหัส, ไม่ว่าจะมีมนุษย์อยู่เบื้องหลังหรือไม่. การเข้าถึงจะให้ตามการกระทำ, มีอายุสั้นและกำหนดขอบเขต, พร้อมนโยบายที่บังคับใช้ในสายงานแทนการไว้ใจระบบเป้าหมาย. เมื่อมีผู้ใช้, สิทธิ์ของเอเจนต์จะเป็นส่วนตัดของสิ่งที่ผู้ใช้ทำได้และสิ่งที่เอเจนต์นั้นได้รับอนุญาตให้ทำสำหรับงานนั้น. เมื่อไม่มีผู้ใช้, อัตลักษณ์และนโยบายของเอเจนต์เองจะเป็นทั้งหมด. มนุษย์ได้รับหลักการ least privilege. เอเจนต์ต้องการหลักการ least agency.

คุณใช้แนวคิด “least agency” เมื่อพูดถึงความปลอดภัยของ AI. least agency แตกต่างอย่างไรจากหลักการความปลอดภัยไซเบอร์แบบดั้งเดิมที่เรียกว่า least privilege, และองค์กรจะกำหนดได้อย่างแม่นยำว่าเอเจนต์ AI ควรได้รับอนุญาตให้ทำอะไรสำหรับงานเฉพาะได้อย่างไร?

เอเจนต์ไม่มีพฤติกรรมที่คงที่. หากให้หนึ่งเอเจนต์เข้าถึงแบบอ่านใน CRM และเขียนในอีเมล, คุณไม่ได้ให้สองสิทธิ์แยกกัน, แต่คุณได้มอบทุกเส้นทางระหว่างสองระบบนั้น. least privilege จำกัดสิ่งที่เอเจนต์สามารถสัมผัสได้. มันไม่ได้บอกว่าเอเจนต์ควรทำอะไรกับสิ่งนั้น.

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

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

Least privilege ตัดสินว่าใครได้กุญแจ Least agency ตัดสินว่าพวกเขาสามารถทำอะไรได้เมื่อเข้าสู่ระบบ

เรามัก “ให้ยืม” ตัวตนของเราให้กับตัวแทนของเรา แต่เราไม่ต้องการให้ตัวแทนมีระดับสิทธิ์เท่ากับที่เรามี – นี่คือคำนิยามของ least agency

Hush เพิ่งระดมทุน การระดมทุนซีรีส์ A มูลค่า 30 ล้านดอลลาร์ ทำให้เงินทุนรวมเป็น $41 ล้าน โดยมี Akamai เข้าร่วมเป็นนักลงทุนเชิงกลยุทธ์พร้อมกับ Battery Ventures และ YL Ventures สิ่งที่การมีส่วนร่วมของ Akamai นำมานอกเหนือจากเงินทุนคืออะไร และคุณคาดหวังว่าความร่วมมือจะส่งผลต่อการขยายตัวของ Hush ไปสู่ความปลอดภัยของ AI‑agent ระดับองค์กรอย่างไร

Akamai อยู่ในเส้นทางการจราจรขององค์กรส่วนใหญ่ทั่วโลก และนั่นคือที่ที่ความปลอดภัยของตัวแทนต้องดำรงอยู่ คุณไม่สามารถควบคุมตัวแทนจากแดชบอร์ดหลังเหตุการณ์ได้ คุณต้องควบคุมมันแบบ inline ณ ขณะที่มันเรียกเครื่องมือหรือ API Akamai สร้างธุรกิจบนโมเดลนั้น

นอกจากเงินทุนแล้ว พวกเขานำมาสามสิ่ง: การกระจายสู่ CISO ที่กำลังถามวิธีควบคุมตัวแทนและการจราจร MCP; การยืนยันว่าตัวตนของตัวแทนเป็นหมวดหมู่จริง ไม่ใช่แค่ฟีเจอร์; และประสบการณ์หลายทศวรรษในการรักษาความปลอดภัยการจราจรเครื่อง‑ต่อ‑เครื่องในระดับโลก ซึ่งเป็นสิ่งที่การจราจรตัวแทน‑ต่อ‑เครื่องมือกำลังจะเป็น

Model Context Protocol (MCP) กำลังกลายเป็นชั้นสำคัญสำหรับการเชื่อมต่อ AI agents กับเครื่องมือและข้อมูลระดับองค์กร จากมุมมองด้านความปลอดภัย ความเสี่ยงใหม่ที่ MCP นำเข้ามาคืออะไร และองค์กรควรพิจารณาเรื่องตัวตนและการอนุญาตระหว่างตัวแทน, เซิร์ฟเวอร์ MCP, และทรัพยากรพื้นฐานอย่างไร

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

ตอนนี้มีปัญหาใหม่สามประการ:

1. Shadow MCP – ไม่มีใครรู้ว่ามีเซิร์ฟเวอร์กี่เครื่องหรือพวกมันทำอะไรบ้าง
2. Credential sprawl – เซิร์ฟเวอร์ส่วนใหญ่ยืนยันตัวตนด้วยโทเค็นคงที่ที่ให้สิทธิ์ทั้งหมดบนพื้นผิว ดังนั้นเอเจนต์จึงได้รับทุกอย่างที่โทเค็นทำได้
3. The collapsed chain – ทรัพยากรเห็นเพียงข้อมูลประจำตัวของเซิร์ฟเวอร์ MCP เท่านั้น จึงไม่สามารถบอกได้ว่าเอเจนต์คนใด, ทำงานให้ผู้ใช้คนใด, เป็นผู้เรียกใช้ การระบุตัวตนต้องอยู่ที่ฐานของทุกการโต้ตอบ การเข้าถึงควรเป็นแบบชั่วคราว, มีขอบเขตและอิงตามสิทธิ์ของเอเจนต์และผู้ใช้

Hush ก่อตั้งขึ้นโดยอิงแนวคิดว่าความลับคงที่และข้อมูลประจำตัวที่อายุยาวเป็นพื้นฐานที่เสียหายสำหรับการเข้าถึงเครื่องจักร เนื่องจากโครงสร้างพื้นฐานระดับองค์กรส่วนใหญ่ยังพึ่งพา API keys, token, และความลับอื่น ๆ อย่างหนัก บริษัทจะย้ายไปสู่การเข้าถึงแบบอิงตัวตนและอายุสั้นได้อย่างเป็นจริงโดยไม่ต้องสร้างสแตกเทคโนโลยีใหม่ทั้งหมดอย่างไร

คุณไม่ต้องสร้างใหม่ ใครบอกอย่างอื่นก็ยังไม่เคยเจอองค์กรระดับใหญ่ สิ่งที่เราปกป้องส่วนใหญ่เกิดขึ้นก่อนคำว่า non‑human identity ปรากฏและยังไม่ได้รับการเขียนใหม่

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

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

โมเดลเดียวกันใช้ได้กับบริการ Java อายุ 15 ปีและเซิร์ฟเวอร์ MCP ที่เพิ่งตั้งขึ้นเมื่อสัปดาห์ที่ผ่านมา เริ่มจากจุดที่มีความเสี่ยง, พิสูจน์ผล, แล้วดำเนินต่อ

AI agents จะทำงานแทนมนุษย์มากขึ้นและในหลายกรณีมอบหมายงานให้กับเอเจนต์อื่น ๆ เมื่อเวิร์กโฟลว์หลายเอเจนต์ซับซ้อนขึ้น คุณจะรักษาโซ่ของตัวตน, การอนุญาต, ความเป็นเจ้าของ, และความรับผิดชอบสำหรับทุกการกระทำอย่างไร

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

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

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

ระบบหลายเอเจนต์จะยากต่อการทำความเข้าใจมากขึ้น. ห่วงโซ่การดูแลสำหรับแต่ละการกระทำไม่จำเป็นต้องเป็นเช่นนั้น.

การฉีดคำสั่งและการโจมตีอื่น ๆ อาจทำให้เอเจนต์ AI ที่โดยปกติเป็นธรรมชาติถูกบังคับให้ทำการกระทำที่ผู้ดำเนินการไม่เคยตั้งใจไว้ได้. การควบคุมการเข้าถึงบนพื้นฐานของอัตลักษณ์สามารถจำกัดความเสียหายจากเอเจนต์ที่ถูกทำลายหรือถูกบิดเบือนได้ระดับใด, แม้ว่าโมเดล AI พื้นฐานจะทำงานผิดพลาด?

คุณจะไม่สามารถหยุดการฉีดคำสั่งที่ระดับโมเดลได้. โมเดลถูกออกแบบให้อ่านเนื้อหาที่ไม่เชื่อถือได้. สมมติว่าเอเจนต์ในที่สุดจะถูกชักชวนให้ทำสิ่งผิด. คำถามคือมันทำอะไรได้บ้างเมื่อเกิดเหตุการณ์นั้น.

การควบคุมการเข้าถึงบนพื้นฐานของอัตลักษณ์จำกัดขอบเขตการทำลาย. เอเจนต์ที่ถูกบิดเบือนโดยมีอำนาจจำกัดสามารถใช้การกระทำที่ได้รับมอบหมายให้ทำเท่านั้น. หากมันสามารถอ่านตั๋วและโพสต์ความคิดเห็น, การฉีดคำสั่งใด ๆ ก็ไม่ทำให้มันดึงข้อมูลฐานข้อมูลลูกค้าออกได้. โทเค็นไม่มีขอบเขตที่กว้างขวาง.

การระบุตัวผู้ใช้ทำให้ห่วงโซ่คงอยู่ครบถ้วน: ผู้ใช้คนไหน, เอเจนต์คนไหน, งานอะไร, ในทุกการเรียก. เอเจนต์จะไม่เกินขอบเขตที่ผู้ใช้ทำได้, และทุกการกระทำจะสามารถสืบค้นย้อนกลับได้.

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

โมเดลจะทำผิดพลาดบ้าง. อัตลักษณ์ที่จำกัด, การระบุตัว, และฐานพฤติกรรมทำให้ความผิดพลาดยังคงอยู่ได้.

Hush มุ่งเน้นการรักษาความปลอดภัยของ AI เป็นหลัก, แต่คุณใช้ AI ภายใน Hush อย่างไร? มีส่วนใดบ้าง เช่น การค้นหาอัตลักษณ์ที่ไม่ใช่มนุษย์, การวิเคราะห์รูปแบบการเข้าถึง, การจัดลำดับความเสี่ยง, หรือการบังคับใช้นโยบาย ที่ AI สามารถปรับปรุงแพลตฟอร์มความปลอดภัยได้อย่างมีนัยสำคัญ?

เราใช้ AI ทุกที่ที่มันคุ้มค่า.

ในผลิตภัณฑ์, ส่วนที่ยากไม่ใช่การค้นหาความลับ, แต่คือการทำความเข้าใจมัน. กุญแจปรากฏในทราฟฟิก. อัตลักษณ์ของงาน, การรวมผู้ขาย, โทเค็นการทดสอบสำหรับนักพัฒนา, หรือข้อมูลรับรองที่เสียหาย? LLM จะอ่านบริบทการทำงานและสัญญาณของเจ้าของแล้วเสนอคำตอบพร้อมคะแนนความมั่นใจ. มันสรุปว่าตัวอัตลักษณ์ทำอะไรในภาษามนุษย์ธรรมดา, ทำให้นโยบายเป็นสิ่งที่มนุษย์ยอมรับได้. มันจัดอันดับความเสี่ยงตามการเข้าถึงจริงและรัศมีการทำลาย, ไม่ใช่ความรุนแรงแบบคงที่. การบังคับใช้ยังคงเป็นเชิงกำหนด. AI ช่วยเขียนนโยบาย – แต่ไม่ได้มีสิทธิ์โหวตในเวลารัน.

ภายใน Hush, การเขียนโปรแกรมแบบเอเจนต์ได้เปลี่ยนแปลงเวลาในการทำงานของเรา. ฟีเจอร์ที่เคยใช้สปรินต์หนึ่งต้องใช้หลายวัน, และเราส่งมอบการรวมระบบด้วยความเร็วที่ทีม Series A ไม่อาจทำได้. LLM ทำการคัดกรองตั๋วสนับสนุน, จัดกลุ่มสาเหตุราก, และนำเสนอคำขอลูกค้าเพื่อการสนทนาระบบแผนงาน. เกตเวย์ MCP ของเราเองอยู่หน้าทุกอย่าง, ช่วยลูกค้าของเราวิเคราะห์และใช้ NHI และความเสี่ยงแบบเอเจนต์.

Hush กล่าวว่า บริษัท Fortune 500 หลายแห่งกำลังใช้เทคโนโลยีของตน, ในขณะที่ Kyndryl ได้ติดตั้ง Hush ภายในองค์กรและเริ่มจำหน่ายต่อให้กับลูกค้าองค์กร. คุณได้เรียนรู้อะไรจากการใช้งานในระดับใหญ่เหล่านี้เกี่ยวกับปัญหาการกำกับดูแลในโลกจริงที่บริษัทเผชิญเมื่อเอเจนต์ AI ย้ายจากการทดลองสู่การผลิต?

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

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

การเป็นเจ้าของหายไป. ถาถามว่าใครรับผิดชอบต่อเอเจนต์หรือ NHI จะได้ชื่อทีมเป็นคำตอบสูงสุด, หรือผู้รับเหมาที่ลาออก, หรือไม่มีคำตอบเลย.

และผู้ซื้อก็เปลี่ยนไป. นี่เป็นปัญหาของทีมแพลตฟอร์ม. ตอนนี้ CISO เป็นผู้เป็นเจ้าของเนื่องจากคณะกรรมการต้องการ. สิ่งนั้นทำให้เราย้ายจากการทดลองสู่การเปิดตัวระดับองค์กร, และเป็นเหตุผลที่ Kyndryl ติดตั้งภายในก่อนจะจำหน่ายต่อ.

เอเจนต์ไม่ได้สร้างปัญหาการกำกับดูแลใหม่. พวกมันทำให้ปัญหาที่องค์กรละเลยมานานทศวรรษด้วยบัญชีบริการแย่ลงอย่างมาก.

ขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม, ผู้อ่านที่ต้องการเรียนรู้เพิ่มเติมควรเยี่ยมชม Hush Security.