Cách ngăn chặn “bộ ba mối đe dọa chết người” của AI

• LLM có vấn đề mang tính cấu trúc là không thể tách biệt mã và dữ liệu, nên dễ bị tấn công prompt injection
• Đặc biệt, khi đồng thời được cấp quyền truy cập dữ liệu bên ngoài, quyền đọc bí mật nội bộ và quyền liên lạc với bên ngoài, cái gọi là bộ ba chết người (lethal trifecta) có thể xuất hiện và dẫn tới thiệt hại nghiêm trọng
• Các kỹ sư AI cần tư duy như kỹ sư cơ khí; thay vì cách tiếp cận mang tính quyết định luận, cần chấp nhận sự bất định của các hệ thống xác suất và chừa ra biên độ an toàn
• Cũng như các kỹ sư thời Victoria đã để dư địa bằng cách thiết kế dư thừa để đối phó với tính bất định của vật liệu, các hệ thống AI cũng cần đưa vào giới hạn an toàn, mức chấp nhận rủi ro và tỷ lệ lỗi
• Cũng như những cây cầu trong thế giới vật lý có giới hạn tải trọng, đã đến lúc các hệ thống AI cũng cần chuẩn mực đặt ra các giới hạn rõ ràng và biên độ an toàn

---

Vấn đề bảo mật mang tính bản chất của LLM

• Các mô hình ngôn ngữ lớn có một khiếm khuyết cấu trúc là không thể tách biệt mã và dữ liệu
• Vì vậy chúng dễ bị tấn công prompt injection
  • Kẻ tấn công lừa hệ thống làm theo những chỉ thị mà lẽ ra nó không được làm theo
  • Trong một số trường hợp, điều này chỉ tạo ra kết quả gây bối rối, chẳng hạn khiến tác nhân hỗ trợ khách hàng nói chuyện như cướp biển
  • Trong những trường hợp khác, nó có thể gây ra thiệt hại mang tính hủy hoại nghiêm trọng hơn nhiều

Bộ ba chết người (Lethal Trifecta)

• Tác động tồi tệ nhất xảy ra khi hình thành "bộ ba chết người"
• Ba thành phần gồm
  • Quyền truy cập vào dữ liệu không đáng tin cậy
  • Khả năng đọc thông tin mật quan trọng
  • Khả năng giao tiếp với thế giới bên ngoài
• Khi doanh nghiệp cố gắng cung cấp cho nhân viên các trợ lý AI mạnh mẽ và trao đồng thời cả ba quyền này, các vấn đề nghiêm trọng gần như là không thể tránh khỏi
• Không chỉ kỹ sư AI mà người dùng thông thường cũng cần học cách sử dụng AI an toàn
  • Việc cài đặt sai tổ hợp ứng dụng có thể vô tình tạo ra đủ ba yếu tố này

Cần thay đổi tư duy của kỹ sư AI

Tư duy như kỹ sư cơ khí

• Kỹ thuật AI tốt hơn là tuyến phòng thủ ưu tiên hàng đầu
• Các kỹ sư AI cần suy nghĩ như những kỹ sư xây dựng các công trình như cầu
  • Nhận thức rằng công việc cẩu thả có thể cướp đi sinh mạng con người

Bài học từ kỹ thuật thời Victoria

• Những công trình vĩ đại của nước Anh thời Victoria được xây bởi các kỹ sư không thể hoàn toàn chắc chắn về đặc tính vật liệu
  • Sắt thời đó thường có chất lượng thấp do năng lực yếu kém hoặc gian lận
  • Vì thế, các kỹ sư chọn sự thận trọng và tích hợp tính dư thừa thông qua thiết kế quá mức cần thiết
  • Kết quả là họ tạo nên những kiệt tác trường tồn hàng thế kỷ

Vấn đề của ngành bảo mật AI hiện nay

• Các nhà cung cấp bảo mật AI hiện nay không suy nghĩ theo cách đó
• Lập trình truyền thống là mang tính quyết định luận
  • Lỗ hổng bảo mật được xem là lỗi cần sửa
  • Sửa xong thì nó biến mất
• Các kỹ sư AI đã quen với lối tư duy này từ khi còn đi học
  • Vì vậy họ hành xử như thể chỉ cần thêm nhiều dữ liệu huấn luyện hơn và các system prompt thông minh hơn là có thể giải quyết vấn đề

Cách tiếp cận phù hợp với hệ thống xác suất

Giới hạn của dữ liệu huấn luyện và prompt

• Dữ liệu huấn luyện và các prompt thông minh hơn đúng là có thể giảm rủi ro
  • Các mô hình mới nhất và thông minh nhất giỏi hơn các mô hình đời cũ hoặc nhỏ hơn trong việc phát hiện và từ chối yêu cầu độc hại
• Nhưng chúng không thể loại bỏ hoàn toàn rủi ro
  • Không giống phần lớn phần mềm, LLM là hệ thống xác suất
  • Đầu ra được quyết định bởi việc lựa chọn ngẫu nhiên trong số các phản hồi khả dĩ
  • Vì vậy, cách tiếp cận an toàn mang tính quyết định luận là không phù hợp

Mô phỏng kỹ thuật của thế giới vật lý

• Cách tốt hơn là học theo các kỹ sư trong thế giới vật lý
• Học cách làm việc cùng những hệ thống không thể dự đoán
  • Thay vì chống lại những hệ thống thất thường mà không thể đảm bảo luôn vận hành đúng như ý định, hãy học cách làm việc cùng chúng
• Thoải mái hơn với tính không thể dự đoán bằng cách đưa vào biên độ an toàn, mức chấp nhận rủi ro và tỷ lệ lỗi

Chiến lược thiết kế dư thừa trong kỷ nguyên AI

• Dùng mô hình mạnh hơn mức cần thiết
  • Giảm nguy cơ bị lừa thực hiện hành vi không phù hợp
• Áp đặt giới hạn số lượng truy vấn mà LLM có thể nhận từ các nguồn bên ngoài
  • Điều chỉnh theo mức rủi ro thiệt hại từ các truy vấn độc hại
• Nhấn mạnh khả năng thất bại an toàn
  • Nếu hệ thống AI cần truy cập bí mật, hãy tránh trao cho nó toàn bộ chìa khóa của vương quốc

Sự cần thiết của việc đặt ra giới hạn an toàn

• Trong thế giới vật lý, cầu có giới hạn tải trọng
  • Dù không phải lúc nào cũng được hiển thị rõ ràng cho người lái xe, nó vẫn tồn tại
  • Điểm quan trọng là: các giới hạn này chừa ra một khoảng an toàn đáng kể trong phạm vi chịu đựng thực tế mà tính toán cho rằng cây cầu có thể chịu được
• Giờ đây, thế giới ảo của các hệ thống AI cũng đã đến lúc cần được trang bị tương tự
• Việc thiết kế các hệ thống có giới hạn an toàn rõ ràng và có dư địa là điều thiết yếu

[GN⁺]

Ý kiến trên Hacker News

• Liên kết bài viết lưu trữ
• Đây là bài thứ hai trên Economist trong tuần này nhắc đến lethal trifecta. Bài đầu tiên là Hệ thống AI sẽ không bao giờ hoàn toàn an toàn — “bộ ba chết người” cần phải đối phó, bài mà theo tôi đã giải thích rõ nhất trên truyền thông về prompt injection là gì và vì sao nó nguy hiểm. Có đoạn trích lời tôi nên có thể tôi hơi thiên vị, nhưng đây vẫn là bài tôi rất muốn khuyến nghị cho các lãnh đạo. Còn bài mới này thì tôi không thích lắm. Bài có nói rằng vì LLM mang tính phi định tính nên rất khó sửa các lỗ hổng bảo mật, rồi dùng phép so sánh rằng phải “over-engineering” như xây cầu và chuẩn bị cho sai số cho phép. Với cầu thì có thể đúng, nhưng với lỗ hổng bảo mật thì theo tôi đó không phải lời giải gốc rễ. Nếu hệ thống chỉ dính prompt injection 1 lần trong 100 lần thì kẻ tấn công vẫn sẽ tiếp tục thử các biến thể cho đến cùng. Chỉ cần chặn được một trong ba yếu tố của lethal trifecta (truy cập dữ liệu riêng tư, tiếp xúc với chỉ thị không đáng tin, đường thoát ra bên ngoài) thì cuộc tấn công sẽ không thành
  • Người xây cầu phần lớn không thiết kế để chống lại tấn công đối kháng. Dù có tính đến thì họ cũng thường tập trung vào việc dễ di chuyển và tái triển khai nhanh hơn là làm cho nó thật kiên cố. So với một cây cầu siêu chắc có thể sống sót sau ném bom, thường sẽ nhanh hơn và rẻ hơn nếu bắc thêm một cây cầu tạm. Xem ví dụ cụ thể
  • LLM cũng phi định tính như con người. Vì vậy có thể tiếp cận quản trị bảo mật giống như với con người. Chỉ cấp đặc quyền tối thiểu cần thiết bằng kiểm soát truy cập theo vai trò, và những tác vụ rủi ro hoặc tốn kém nên phải đi qua quy trình phê duyệt. Với các tổ chức trọng yếu như công nghệ, hạ tầng, quốc phòng, tài chính, việc xây dựng threat model trên giả định rằng trong đội có thể đã cài cắm điệp viên của các chính phủ nước ngoài như Nga, Trung Quốc, Israel, Triều Tiên... vốn là điều cơ bản
  • Thực ra hai bài đó là cùng một bài. Trên Economist, phần đầu mỗi số phát hành hằng tuần có loạt bài “Leaders”, nơi họ rút gọn và khái quát hóa các bài phân tích chuyên sâu trong cùng số. Tức là họ áp dụng cấu trúc kim tự tháp ngược cho cả tờ báo (giải thích về kim tự tháp ngược). Bài được liên kết lần này đóng vai trò như một bản tóm lược của toàn bộ bài phân tích gây tranh cãi đó
  • Tôi nghĩ về vấn đề bảo mật của LLM theo kiểu: “Nếu code của tôi có thể bị social engineering chọc thủng thì sao?” LLM giống con người ở chỗ, dù huấn luyện kỹ đến đâu thì vẫn có thể bị lừa. Nếu bạn cấp quyền root trên máy tính rồi cho phép bất kỳ ai trên thế giới trò chuyện với LLM, thì sớm muộn gì nó cũng sẽ lộ lỗ hổng. Cũng như ta không ủy quyền vô hạn cho con người, ta không nên cho LLM quyền truy cập dữ liệu không liên quan đến người yêu cầu, hay quyền sửa dữ liệu người dùng
  • Vấn đề là chỉ cần cắt một phía của lethal trifecta là được, nhưng trên thực tế ba yếu tố này đan xen vào nhau. Ví dụ, nội dung bên ngoài như email cũng có thể là dữ liệu cá nhân, và nếu gửi email thì nội dung trong inbox của tôi có thể rơi vào tay kẻ tấn công. Hơn nữa, các hệ thống như email hay GitHub hữu dụng nhất khi vừa nhận vừa gửi được, nhưng đặt server riêng cho từng chức năng thì lại kém hiệu quả
• Với nền tảng cơ khí, tôi thấy bài này chưa đủ. Người ta hay nói “cứ tăng độ bền lên là được”, nhưng thực tế phải hiểu rất chi tiết nhiều chế độ hỏng hóc khác nhau mới áp dụng được. lethal trifecta chỉ là một chế độ hỏng hóc, và người ta đang thêm “độ bền” để ngăn nó. Đúng ra không phải kiểu “cây cầu này rung quá, hãy nghĩ cách đi qua cây cầu rung cho an toàn”, mà phải sửa cây cầu để nó đừng rung quá mức ngay từ đầu
  • Tôi có cảm giác thế giới đang phát điên. Theo phép so sánh cây cầu kia thì giống như từ trước tới nay ta đã biết kỹ thuật xây cầu, nhưng thỉnh thoảng sàn cầu đột nhiên biến mất khiến người ta rơi xuống sông, vậy mà thay vì bàn cách khác thì lại nói “căng lưới bên dưới, ai rơi thì hứng”. Chúng ta đang đổ hàng tỷ đô lên một công nghệ vốn dĩ không thể dự đoán, rồi chỉ nghĩ đến chuyện lắp thêm lan can. Thật vô lý
  • Hễ bài báo có cụm “coders need to” là tôi mất hứng ngay. Cảm giác phép so sánh đã sai từ gốc, và ngay cả người có kinh nghiệm thực tế trong lĩnh vực đó nghe cũng thấy gượng. Điều kiện ví dụ mà nhà báo đưa ra kiểu “nếu trong công ty, LLM đồng thời có thể truy cập dữ liệu không đáng tin, thông tin quan trọng và giao tiếp với bên ngoài” mới chính là vấn đề. Nhiều công ty tự tạo ra rủi ro này vì ưu tiên tính năng hơn bảo mật. Lập luận rằng “LLM phi xác suất nên cách tiếp cận mang tính quyết định luận là không phù hợp” là một bước nhảy logic. Dù phi định tính thì logic sandbox vẫn còn nguyên giá trị; nói cách khác, kéo dài phép so sánh quá mức lại còn ít giúp ích cho chính lĩnh vực đó. Dùng thuật ngữ đúng và kiến thức miền sẽ tốt hơn, nhưng như vậy có lẽ bài báo sẽ bớt hấp dẫn
• Chẳng lẽ bài báo thực sự chỉ nói rằng giải pháp là giới hạn tốc độ và dùng model tốt hơn thôi sao? Kỹ sư phần mềm đã nghiên cứu những thứ này từ hàng chục năm trước. Ngành này biết câu trả lời về bảo mật, vấn đề là nó không hợp với thái độ hiện tại là vội vàng tung sản phẩm AI ra thị trường
  • AI giờ cũng là cùng một lĩnh vực IT, vậy kết luận rốt cuộc là “chúng ta chưa hề hiểu bảo mật”. Nói AI cẩu thả là không đúng với thực tế. Không có cách nào tách hoàn hảo dữ liệu và token chỉ thị là một giới hạn nền tảng, không phải do bất cẩn. Nói rằng “mọi thứ đã được giải quyết từ vài chục năm trước” là ngạo mạn
  • Kiểu phát biểu “chúng ta đã biết hết về bảo mật từ hàng chục năm trước” thường xuất hiện khi một ngành mới bận tái tạo những tiêu chuẩn tồi cũ kỹ để cho kịp tung ra “sản phẩm AI”. Chỉ cần nhìn các trường hợp như tiêu chuẩn MCP bị thủng ngay từ đầu thì những cách tiếp cận kiểu “viết prompt cho hay” đã thành lố bịch. Vấn đề lớn nhất là gần như mọi người trong ngành AI đều thiết kế chuyện MCP server truy cập trực tiếp vào DB mà không hề thấy đáng nghi. Đây là ví dụ cho thấy không phải cứ làm được là nên làm; vì bảo mật lỏng lẻo như vậy mà vô số sản phẩm AI đang thực sự bị xâm phạm
  • Khẳng định “chúng ta đã hiểu bảo mật rồi” thực ra không đúng. Càng chuyển sang bài toán con người thì càng như vậy, vì dù đổ hàng tỷ vào đào tạo lặp đi lặp lại thì hiệu quả vẫn giảm dần. Gần đây còn có trường hợp ngay cả chuyên gia bảo mật rất giỏi cũng bị một cú phishing đơn giản trên YouTube lừa
• Bài gốc của @simonw: The lethal trifecta for AI agents, cũng có thể xem thêm bài viết liên quan. Tôi cũng để lại liên kết thảo luận liên quan trên HN
• lethal trifecta là vấn đề xảy ra khi LLM đồng thời có thể truy cập dữ liệu không đáng tin, xem thông tin quan trọng và giao tiếp ra bên ngoài. Giải pháp là giảm rủi ro bằng quản lý ranh giới (quyền hạn), về cơ bản là bảo mật 101
  • Đúng, nhưng trên thực tế lại có căng thẳng rất lớn giữa bảo mật và tính năng. Muốn làm việc hữu ích với dữ liệu cá nhân thì sẽ mở ra lỗ hổng prompt injection. Thêm nữa, việc gom tối đa các ngữ cảnh liên quan như vậy rất hiệu quả cho agent, nhưng nếu tách biệt/cô lập hoàn toàn agent đọc đầu vào không đáng tin thì lại làm giảm tính hữu dụng. Xem bài blog liên quan
  • Nói chặt chẽ thì đây cũng chỉ là kiểm soát truy cập (Access Control) cơ bản. Ngay khi nối Internet, rủi ro tăng vọt. Nếu có một nhà nghiên cứu bảo mật cực giỏi thì chỉ với một prompt injection duy nhất cũng có thể chiếm được cả hệ thống, khiến ít nhất một trong các điều kiện lập tức được thỏa mãn
• LLM không phân biệt prompt và dữ liệu. Nó không có khái niệm như NX bit (bit cấm thực thi), và cũng chưa có ai hiện thực được thứ gì tương tự. Tất nhiên, cũng giống như việc NX bit được đưa vào nhưng vẫn không thể chặn hoàn toàn remote code execution, chỉ riêng nó cũng không phải đối sách hoàn hảo. Cách thực tế nhất hiện nay là quản lý tiến trình agent LLM bằng các cơ chế bảo mật sẵn có. Ví dụ chạy bằng tài khoản người dùng riêng để hạn chế truy cập file, đồng thời áp thêm giới hạn qua mạng, phần cứng, cgroups. Dù vậy, nếu lệnh bị trộn vào dữ liệu không đáng tin, rủi ro LLM làm lộ cả dữ liệu bí mật vẫn còn nguyên. Và nếu người dùng không nhận ra đầu ra của LLM rồi sao chép nó ra bên ngoài, đường thoát dữ liệu lại mở ra lần nữa
  • Về chuyện “chưa ai tạo ra thứ tương tự”, tôi tự hỏi có ai thật sự từng thử chưa, hoặc liệu có dữ liệu huấn luyện liên quan hay không. Động vật có tính xã hội tự nhiên biết compartmentalization (phân tách ngăn). Chó cũng biết nhìn sắc mặt người để giấu chuyện có thức ăn. Bản thân tôi khi nuôi con cũng luôn phân chia và quản lý thông tin theo đời sống xã hội, tri thức mật, dữ liệu cá nhân của con, những thông tin con còn khó tiếp nhận, tiếng nói nội tâm của tôi, hay nội dung học từ nguồn không đáng tin. Trí thông minh quan trọng, nhưng wisdom mới là thứ vẫn chưa hề được xem là ưu tiên cấp một trong thế giới LLM. Đến cả chó con và trẻ nhỏ còn đang vượt trội hơn ở năng lực phân tách ngăn này
• Tôi thấy một trích dẫn rất ấn tượng trong bài phân tích liên quan: hệ thống CaMeL do Google đề xuất dùng hai LLM để né một phần rủi ro của lethal trifecta. Một model chỉ truy cập dữ liệu không đáng tin, model còn lại xử lý mọi dữ liệu khác. Một model có độ tin cậy cao sẽ chuyển chỉ thị ngôn ngữ của người dùng thành đoạn code trong phạm vi bị giới hạn, còn model không đáng tin chỉ điền vào các chỗ trống của đoạn code đó. Cấu trúc này cho phép đảm bảo về bảo mật, nhưng đổi lại phạm vi công việc mà LLM có thể làm bị hạn chế đáng kể. Tôi mới nghe lần đầu nên tò mò không biết thực tế hiệu quả ra sao. Liệu nó có thật sự đảm bảo được mức bảo mật “tuyệt đối” hay không, sẽ phát sinh những ràng buộc nào, và có thể trở thành phương án thay thế thực tiễn hay không. Nguồn bài viết
  • Tôi đã suy nghĩ khá lâu về bài báo CaMeL. Đây là một hướng tiếp cận khá tốt, nhưng triển khai thực tế rất khó và hệ thống chỉ có thể làm những việc với chức năng khá hạn chế. Tôi đã viết trong bài phân tích của mình
• Có đoạn dùng phép so sánh rằng “các kỹ sư AI cũng phải suy nghĩ như kỹ sư thật trong những lĩnh vực có thể dẫn tới thiệt hại nhân mạng như xây cầu”. Theo kiểu “kỹ sư AI từ thời đi học đã bị đóng khung tư duy rằng chỉ cần thêm dữ liệu huấn luyện và prompt thông minh hơn là có thể giải quyết vấn đề”
  • Ở đây, ý “kỹ sư AI phải nghĩ như kỹ sư thật” nghĩa là không chỉ như software engineer, mà như kỹ sư đúng nghĩa; giờ phần mềm cũng nằm trong cầu và ô tô nên ít nhất cũng phải có tư duy của kỹ sư làm ra vật thể thật
  • Nó như đang ngầm gợi ý rằng nên có chứng chỉ hành nghề software engineering, thậm chí cả chứng nhận đạo đức. Nhưng vì phần mềm phi đạo đức nhưng hợp pháp vẫn tạo ra lợi nhuận cực cao, tôi thấy ý tưởng này khó mà áp dụng thực tế
  • Kết cục của suy nghĩ “chỉ cần dữ liệu huấn luyện tốt hơn là giải quyết được” là cuối cùng chính những thiệt hại bi thảm đó lại trở thành dữ liệu huấn luyện
  • Đừng quên vai trò của “architect” bên cạnh software “engineer”
• Tôi tự hỏi liệu có cơ hội kinh doanh nếu vận hành một sản phẩm phần mềm theo mô hình thuê bao nhỏ, chuyên tự động giám sát tài khoản LLM và lọc/xử lý pipeline đầu vào hay không