Tessl: Kỹ năng của AI Agent cần được quản lý như các thành phần trong chuỗi cung ứng phần mềm

Tại AI Native DevCon London, tôi bắt đầu với một câu hỏi đơn giản: ai đã thêm kỹ năng (skill) cho một tác nhân (agent) trong vài tháng qua? Nhiều cánh tay đã giơ lên. Sau đó, tôi yêu cầu mọi người chỉ giữ tay nếu họ thực sự đã xem xét kỹ năng đó và đọc tệp markdown.

Câu hỏi thứ hai đó chính là nơi bài nói chuyện thực sự bắt đầu.

Bài nói chuyện của tôi, "Tác nhân AI của bạn đã cài đặt phần mềm độc hại vì một tệp SKILL.md yêu cầu như vậy", nói về mô hình bảo mật mà chúng ta đang âm thầm xây dựng xung quanh các kỹ năng của tác nhân. Một kỹ năng có thể trông giống như tài liệu hướng dẫn. Nó có thể là một tệp markdown chứa các chỉ dẫn và siêu dữ liệu. Nhưng một khi tác nhân tin tưởng nó, kỹ năng đó có thể ảnh hưởng đến những gì tác nhân đọc, những gì nó thay đổi, những công cụ nào nó gọi và những phần nào trong không gian làm việc mà nó coi là ngữ cảnh đáng tin cậy.

Điều đó khiến các kỹ năng trở thành các thành phần trong chuỗi cung ứng. Chúng xứng đáng nhận được sự nghi ngờ, xem xét, kiểm chứng nguồn gốc, quét và kỷ luật cập nhật tương tự như những gì chúng ta đã học cách áp dụng cho các hệ sinh thái gói phần mềm.

Tôi tiếp cận vấn đề này từ công việc bảo mật dành cho nhà phát triển. Tôi đã dành nhiều thời gian cho việc lập trình an toàn, bảo mật JavaScript, các vấn đề hệ sinh thái kiểu npm, PyPI và gần đây hơn là nghiên cứu bảo mật AI xung quanh các kỹ năng, MCP và các tác nhân lập trình. Các mô hình này rất quen thuộc: các thành phần có thể tái sử dụng lan truyền nhanh chóng, thói quen xem xét không theo kịp tốc độ áp dụng và những kẻ tấn công nhận ra những nơi mà sự tin tưởng dễ bị lợi dụng nhất.

Sử dụng bài nói chuyện này làm ngữ cảnh cho tác nhân

Tessl đã biến bài nói chuyện tại AI Native DevCon của tôi thành một kỹ năng mà tác nhân của bạn có thể sử dụng làm ngữ cảnh. Bạn cũng có thể xem toàn bộ bản ghi.

Tại sao kỹ năng lại là một vấn đề chuỗi cung ứng?

Hầu hết mọi người nghĩ về một kỹ năng như là SKILL.md. Đó chỉ là một phần của đối tượng.

Một kỹ năng thường có phần frontmatter, nội dung chính, hướng dẫn cho tác nhân và đôi khi là các tài liệu hỗ trợ. Nó có thể bao gồm các tham chiếu, tài nguyên, gói, tệp cố định (fixtures), tệp hỗ trợ, tập lệnh cài đặt và các nội dung khác mà người đánh giá có thể không bao giờ đọc kỹ. Trong bài nói chuyện, tôi đã cố tình sử dụng lăng kính hệ sinh thái gói phần mềm, vì các nhà phát triển đã biết câu chuyện này từ npm và các kho lưu trữ khác.

Khi một gói được cài đặt, cuối cùng chúng ta đã học cách đặt câu hỏi về người duy trì, phiên bản, tệp khóa (lock files), tính toàn vẹn, chữ ký, các phụ thuộc bắc cầu, hành vi sau khi cài đặt và nguồn gốc. Các kỹ năng vẫn đang ở giai đoạn đầu của hành trình đó. Chúng là các thành phần AI có thể tái sử dụng, nhưng các biện pháp kiểm soát bảo mật của chúng vẫn đang đuổi theo đường cong áp dụng.

Trong nghiên cứu mà tôi đã thảo luận trong bài nói chuyện, chúng tôi đã quét khoảng 4.000 kỹ năng từ một hệ sinh thái kỹ năng công khai và tìm thấy một số lượng đáng kể các vấn đề: tải xuống đáng ngờ, rủi ro liên quan đến thông tin xác thực, hành vi giống phần mềm độc hại, lạm dụng và các lỗ hổng bảo mật. Tỷ lệ phần trăm chính xác không quan trọng bằng hướng đi. Các kỹ năng đã đủ nhiều, đủ hữu ích và đủ dễ để xuất bản đến mức tư duy chuỗi cung ứng phải được áp dụng ngay bây giờ.

Sai lầm sẽ là nói rằng, "Nó chỉ là markdown thôi mà". Trong quy trình làm việc của tác nhân, markdown có thể là hành vi.

Đọc kỹ năng một lần không phải là một mô hình bảo mật

Hướng dẫn bảo mật xung quanh các kỹ năng thường bắt đầu bằng điều gì đó như: hãy đọc kỹ năng trước khi kích hoạt nó và đừng tin tưởng mù quáng vào nội dung của bên thứ ba. Đó là lời khuyên hợp lý, nhưng chưa đủ.

Vấn đề đầu tiên là chiều sâu. Bạn chỉ đọc SKILL.md hay bạn đọc cả các tệp hỗ trợ? Bạn có kiểm tra các tài nguyên được tham chiếu không? Bạn có tìm kiếm các tập lệnh, tệp cố định hoặc gói mà kỹ năng có thể yêu cầu tác nhân sử dụng không? Bạn có hiểu tác nhân sẽ có quyền gì khi kỹ năng chạy không?

Vấn đề thứ hai là thời gian. Ngay cả khi bạn đã xem xét kỹ năng khi cài đặt, bạn có xem xét mọi bản cập nhật không? Bạn có xem xét mọi thay đổi mà nhóm của bạn chia sẻ nội bộ không? Bạn có xem xét mọi phiên bản được tải về trước khi một tác nhân tự hành sử dụng nó lần nữa không?

Vấn đề thứ ba là cách cấp quyền tin tưởng. Nhiều tác nhân lập trình hỏi liệu bạn có tin tưởng một thư mục không gian làm việc hay không. Một khi bạn nói có, thư mục đó có thể trở thành ranh giới. Tác nhân có thể coi các tệp bên trong nó là hướng dẫn, ngữ cảnh hoặc chính sách. Nếu một kỹ năng không an toàn nằm ở đó, tác nhân có thể kế thừa sự tin tưởng của bạn vào thư mục đó và áp dụng sự tin tưởng đó cho kỹ năng.

Đó là lý do tại sao tôi không nghĩ "đọc trước" là một mô hình hoàn chỉnh. Nó phụ thuộc vào sự chú ý hoàn hảo của con người trong một quy trình làm việc đang cố tình tự động hóa nhiều công việc hơn. Nó cũng giả định rằng nội dung rủi ro là hiển nhiên đối với người đánh giá. Trên thực tế, hành vi không an toàn có thể nằm trong các hướng dẫn bằng ngôn ngữ tự nhiên, các tham chiếu đi kèm hoặc các đường dẫn cập nhật mà mọi người không kiểm tra mỗi lần.

Rủi ro nằm ở bộ ba yếu tố

Mô hình rủi ro cốt lõi trong bài nói chuyện là sự kết hợp giữa ngữ cảnh riêng tư, nội dung không đáng tin cậy và giao tiếp bên ngoài.

Ngữ cảnh riêng tư là dữ liệu mà tác nhân có thể truy cập: thông tin xác thực, khóa API, tệp cấu hình, bí mật kho lưu trữ, dữ liệu khách hàng, tài liệu nội bộ, hộp thư đến, phiên trình duyệt hoặc bất kỳ thứ gì khác không bao giờ được phép rời khỏi ranh giới tác vụ cục bộ.

Nội dung không đáng tin cậy là tài liệu mà tác nhân đọc nhưng nhóm không tạo ra hoặc xác minh: một vấn đề (issue) do một người đóng góp không xác định mở, một email, một trang web, một bình luận trong pull request, một câu lệnh (prompt) được sao chép, một kỹ năng của bên thứ ba hoặc một kho lưu trữ được lấy từ nơi khác.

Giao tiếp bên ngoài là khả năng của tác nhân trong việc gửi thông tin ra ngoài ranh giới: mở kết nối mạng, đăng bình luận, tạo vấn đề, đẩy nhánh (push branches), gửi email, gọi API, tải tệp lên hoặc ghi vào các dịch vụ công cộng.

Bất kỳ hai trong số đó đều có thể gây rủi ro. Cả ba yếu tố cùng lúc mới là nơi chế độ lỗi trở nên nghiêm trọng. Một tác nhân có thể đọc ngữ cảnh riêng tư, tiêu thụ các hướng dẫn không đáng tin cậy và giao tiếp bên ngoài có hình thái của một vụ rò rỉ dữ liệu đang chờ kích hoạt.

Đây không chỉ là về một sản phẩm tác nhân hay một quy trình làm việc. Tôi đã sử dụng các ví dụ từ trợ lý cá nhân và tác nhân lập trình vì cùng một mô hình xuất hiện trên khắp không gian này. Tác nhân càng trở nên hữu ích, chúng càng thường xuyên chạm vào shell, trình duyệt, email, kho lưu trữ, API, bộ nhớ, plugin và dịch vụ của bên thứ ba. Đó là các tính năng từ góc độ người dùng. Từ góc độ kẻ tấn công, đó cũng là những nơi để gây ảnh hưởng đến hành vi.

Sự mệt mỏi khi phê duyệt làm cho ranh giới yếu đi

Sự phê duyệt của con người thường được coi là ranh giới an toàn. Đôi khi đúng là như vậy. Nhưng đó là một ranh giới mong manh khi quy trình làm việc huấn luyện mọi người phê duyệt lặp đi lặp lại.

Nếu một tác nhân yêu cầu quyền một lần, nhà phát triển có thể đọc kỹ. Nếu nó hỏi mười lần trong một tác vụ thông thường, nhà phát triển có thể bắt đầu nhấp qua mà không cần suy nghĩ. Nếu tác nhân chạy ở chế độ chấp nhận rộng rãi, ranh giới có thể biến mất hoàn toàn. Trong bài nói chuyện, tôi mô tả đây là sự chuyển dịch từ sự mệt mỏi vì lỗ hổng sang sự mệt mỏi vì chấp nhận: biện pháp kiểm soát bảo mật vẫn hiện diện trong giao diện, nhưng nó đã ngừng mang ý nghĩa trong quy trình làm việc thực tế.

Ngoài ra còn có vấn đề "phó tướng bị nhầm lẫn" (confused-deputy problem). Tác nhân có thể yêu cầu con người phê duyệt một thứ gì đó nghe có vẻ hợp pháp vì chính tác nhân đã bị ảnh hưởng bởi một kỹ năng, một email hoặc một nội dung không đáng tin cậy khác. Con người nhìn thấy một yêu cầu từ công cụ họ đang sử dụng, chứ không nhất thiết là hướng dẫn độc hại đã gây ra nó.

Đó là lý do tại sao câu hỏi không đơn thuần là "có sự tham gia của con người trong quy trình hay không?". Câu hỏi đúng đắn hơn là liệu con người đó có đủ ngữ cảnh, đủ thời gian và một yêu cầu cấp quyền đủ hẹp để đưa ra quyết định bảo mật thực sự hay không.

Ngôn ngữ tự nhiên có thể chứa đựng hành vi không an toàn

Bảo mật chuỗi cung ứng truyền thống thường bắt đầu bằng việc quét mã. Điều đó vẫn hữu ích, nhưng các skill (kỹ năng) bổ sung thêm một lớp bảo mật khác vì phần nguy hiểm có thể nằm ở ngôn ngữ tự nhiên.

Một skill có thể yêu cầu thực hiện hành vi bằng tiếng Anh thông thường. Một tệp tham chiếu có thể mã hóa các hướng dẫn chỉ có tác dụng khi tác nhân (agent) đọc chúng. Nội dung có thể được viết để trông có vẻ vô hại với con người trong khi vẫn được mô hình xử lý. Ngay cả văn bản trợ giúp trông có vẻ bình thường cũng có thể điều hướng tác nhân thực hiện các hành động không an toàn nếu tác nhân đó có quyền truy cập công cụ rộng rãi.

Bài thuyết trình gốc bao gồm các minh họa về hành vi skill không an toàn. Tôi sẽ không tái hiện lại cơ chế ở đây và bản ghi công khai đã được biên tập có chủ đích để phục vụ mục đích phòng thủ. Bài học không phụ thuộc vào các chi tiết vận hành: nếu một skill có thể gây ảnh hưởng đến tác nhân, thì việc chỉ xem xét nó dưới dạng văn bản markdown là chưa đủ.

Một danh mục ví dụ là đầu vào bị nhiễm độc (poisoned input): tác nhân đọc một email, vấn đề hoặc trang web chứa các hướng dẫn nhắm vào tác nhân thay vì con người. Một ví dụ khác là một skill có vẻ hữu ích nhưng lại yêu cầu tác nhân tìm nạp hoặc chạy một thứ gì đó không an toàn. Một ví dụ khác nữa là nội dung ẩn hoặc không rõ ràng mà con người có thể bỏ lỡ trong quá trình đánh giá nhưng mô hình vẫn xử lý.

Những ví dụ đó chỉ ra cùng một vấn đề cốt lõi. Các skill không chỉ là hướng dẫn dành cho con người. Chúng là hướng dẫn dành cho các hệ thống có thể có công cụ, ngữ cảnh, bộ nhớ và quyền hạn để hành động.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗