Bảo mật AI agent bắt đầu với một quy tắc: AI agent của bạn không bao giờ nên giữ thông tin đăng nhập của bạn. Đây là mô hình broker 38 năm tuổi thực thi điều đó.
AI agent là những phó thác bị nhầm lẫn. Đó là một mô hình bảo mật đã có từ 38 năm trước, và câu trả lời cũng lâu đời như vậy: đặt một broker — một lớp trung gian đáng tin cậy, có thể quan sát, xác định, kiểm toán, không thể giả mạo, phạm vi hẹp, điều khiển bởi chính sách, không phải AI — giữa agent và các API SaaS mà nó cần gọi, giữ thông tin đăng nhập mà agent của bạn không nên có.
Năm 1988, Norm Hardy đã xuất bản một bài báo ngắn mô tả một sự cố thực tế trong thời gian ông làm việc tại Tymshare. Một trình biên dịch Fortran tên là FORT nằm trong thư mục hệ thống tên SYSX. Để thu thập thống kê sử dụng, trình biên dịch cần ghi vào (SYSX)STAT, nên hệ điều hành đã cấp cho FORT một "giấy phép tệp nhà", cho phép nó ghi bất kỳ tệp nào trong SYSX. Tệp thanh toán của hệ thống, (SYSX)BILL, cũng nằm ở đó. Một người dùng khi gọi trình biên dịch có thể cung cấp tên tệp để nhận đầu ra gỡ lỗi tùy chọn. Một ngày nọ, một người dùng đã cung cấp (SYSX)BILL. Trình biên dịch yêu cầu hệ điều hành mở tệp đó để ghi; hệ điều hành, quan sát giấy phép tệp nhà, đã cho phép. Dữ liệu thanh toán bị ghi đè. Trình biên dịch đã làm đúng chức năng của nó. Lỗi nằm ở kiến trúc.
Hardy gọi đó là vấn đề phó thác bị nhầm lẫn: một chương trình có đặc quyền (phó thác) giữ quyền hạn riêng; một người gọi ít đặc quyền hơn yêu cầu nó làm gì đó; phó thác bị nhầm lẫn về quyền hạn mà nó đang sử dụng, và dùng quyền của chính nó. Cách khắc phục là lấy quyền đó khỏi phó thác hoàn toàn và đặt nó phía sau một lớp riêng biệt trung gian cuộc gọi khi cần. Lớp đó chính là broker.
Ba mươi tám năm sau, mọi AI agent mà công ty bạn vận hành đều là một phó thác bị nhầm lẫn. Và hầu hết chúng đều chạy mà không có broker.
Vì sao AI agent làm vấn đề bảo mật trở nên tồi tệ hơn
FORT của Hardy chỉ có một kênh đầu vào: dòng lệnh. Một AI agent hiện đại có hàng chục: nội dung email, trang web được truy xuất, PDF tải lên, đầu ra công cụ từ máy chủ MCP, tin nhắn từ các agent đồng nghiệp trong hệ thống đa agent. Bất cứ thứ gì xuất hiện trong cửa sổ ngữ cảnh đều có thể đưa ra chỉ dẫn, và theo thiết kế, agent coi tất cả đều hợp lệ.
Điều đó phá vỡ một giả định mà kiểm soát truy cập truyền thống dựa vào: người gọi kiểm soát đầu vào. Trong ứng dụng web, người gọi (phiên xác thực) và đầu vào (nội dung yêu cầu HTTP) đến từ cùng một nơi. Với agent, người gọi là bất kỳ ai định hình prompt, nghĩa là kẻ tấn công có thể viết email hoặc cài cắm kết quả tìm kiếm cũng là người gọi.
Vào tháng 11 năm 2025, các nhà nghiên cứu bảo mật tại PromptArmor đã trình diễn điều đó ngoài thực tế. Họ giấu chỉ dẫn độc hại trong font 1 pixel trên một hướng dẫn tích hợp. Khi một lập trình viên trỏ IDE Antigravity của Google vào đó, agent đã vượt qua bảo vệ tệp dựa trên .gitignore của chính nó bằng cách gọi shell tới cat. Sau đó, nó rò rỉ nội dung các tệp .env tới một URL webhook.site do kẻ tấn công kiểm soát thông qua subagent trình duyệt của Antigravity. Người dùng đã thiết lập đúng. Sandbox vẫn giữ vững. Agent đơn giản không thể phân biệt đâu là yêu cầu của người dùng và đâu là chỉ dẫn từ đầu vào.
Cùng một hình thái như FORT của Hardy, sau nhiều thập kỷ: quyền hạn rộng, đầu vào không tin cậy, không có cách nào tách biệt hai thứ đó.
Cộng đồng đã có câu trả lời. Chỉ là chúng bị phân tán.
Đây không phải là vấn đề mới. Cộng đồng bảo mật đã viết ra các giải pháp trong nhiều thập kỷ:
Bảo mật dựa trên năng lực (Dennis & Van Horn, 1966; sau này là ngôn ngữ E và dự án Caja của Mark Miller tại Google). Nguyên tắc: không cấp quyền chung dựa trên danh tính hoặc vị trí; hãy truyền các năng lực rõ ràng, không thể giả mạo cho từng tài nguyên mà chương trình được phép truy cập. Một năng lực gói cả bạn có thể làm gì với bạn có thể làm với cái gì, và không thể bị nhầm lẫn với thứ khác.
Thông tin đăng nhập qua broker (được chuẩn hóa bởi OWASP LLM Top 10). Không đặt token API vào ngữ cảnh của LLM. Một lớp trung gian đáng tin cậy thực hiện cuộc gọi thay mặt agent; mô hình quyết định làm gì, broker xử lý làm như thế nào. Prompt injection yêu cầu mô hình in thông tin đăng nhập sẽ không nhận được gì hữu ích. Thông tin đăng nhập không có ở đó.
Mô hình Phantom Token (Curity, ban đầu cho OAuth trong microservices). Agent giữ một handle phiên opaque, không phải bearer token thật. Một proxy xác thực handle, thay thế bằng thông tin đăng nhập thật ở biên mạng, rồi chuyển tiếp lên trên. Nếu agent rò rỉ môi trường, kẻ tấn công chỉ nhận được một chuỗi hết hạn khi phiên kết thúc.
Tiêm thông tin đăng nhập đúng lúc (hệ thống nhận diện workload như Aembit). Tạo thông tin đăng nhập ngắn hạn, phạm vi hẹp cho mỗi lần gọi thay vì cấp token dài hạn.
Tất cả những điều này không thiếu trong tài liệu. Nó chỉ thiếu trong mặc định. Hầu hết nền tảng agent vẫn đưa mô hình một token OAuth, không có broker ở giữa, và hy vọng mọi thứ sẽ ổn.
Broker của Zero hoạt động như thế nào
Chúng tôi không phát minh ra bất kỳ mô hình nào ở trên. Chúng tôi tích hợp chúng vào một broker duy nhất chạy mặc định cho mọi agent trên Zero. Đó là lớp trung gian đáng tin cậy mà các mô hình trên mô tả, được xây dựng cho nền tảng AI agent. Mọi cuộc gọi agent thực hiện tới một connector đều đi qua nó. Mỗi connector là một SaaS bên ngoài (Slack, GitHub, Notion, v.v.).
Broker nằm giữa mọi agent và mọi connector. Thông tin đăng nhập thật chỉ tồn tại ở phía broker của đường đứt nét.
Hãy hình dung nó gồm ba lớp.
1. Cách ly thông tin đăng nhập
Sandbox của agent không bao giờ giữ thông tin đăng nhập connector thật. Khi bạn kết nối một SaaS với Zero, token OAuth hoặc API key nằm ở phía broker. Sandbox nhận được một chuỗi placeholder trông giống như một biến môi trường bí mật để các công cụ hiện tại vẫn hoạt động, nhưng không SaaS nào chấp nhận nó.
Khi agent gửi yêu cầu tới một host connector đã đăng ký, broker sẽ khớp yêu cầu, giải quyết mẫu xác thực của connector, và tiêm thông tin đăng nhập thật ở biên mạng. Yêu cầu đi lên với xác thực hợp lệ; agent không bao giờ giữ thứ gì hữu ích. Một agent bị prompt injection mà xuất biến môi trường sẽ chỉ đưa cho kẻ tấn công một placeholder, không phải token SaaS.
Đây là mô hình phantom token, áp dụng cho AI agent.
2. Cổng chính sách connector
Một connector trong Zero nên hơn cả một công tắc bật/tắt. Mỗi connector mô tả các API base mà nó bao phủ và cách xác thực nên được tiêm vào. Khi dịch vụ upstream công bố ánh xạ phạm vi-đến-endpoint ổn định, nó cũng có thể mô tả quyền nào bao phủ từng phương thức và đường dẫn. slack-api-ref của Slack là một ví dụ điển hình.
Vì vậy, khi một agent kết nối với Slack gọi chat.postMessage, broker có thể ánh xạ yêu cầu đó tới chat:write. Khi nó đọc log kiểm toán, đó là admin.analytics:read. Với mỗi agent, permission_policies xác định cách các quyền được đặt tên đó hoạt động: cho phép, từ chối, hoặc hỏi. Chính sách được thực thi tại broker trước khi tiêm xác thực, không phải là gợi ý cho mô hình. Nếu agent cố thực hiện cuộc gọi bị phủ bởi quyền bị từ chối, có thể do bị prompt injection, cuộc gọi sẽ không bao giờ tới mạng upstream.
Không phải mọi connector đều có thể ánh xạ chi tiết như vậy hiện nay. Một số API upstream không công bố ánh xạ phạm vi-đến-endpoint ổn định. Bề mặt GraphQL của GitHub là trường hợp điển hình: REST có thể ánh xạ, nhưng GraphQL thì chưa. Với các connector đó, broker vẫn kiểm soát việc tiêm thông tin đăng nhập và đường đi mạng, trong khi cổng quyền rơi về chính sách connector hoặc host ở mức thô mà nền tảng có thể thực thi. Chúng tôi sẽ bổ sung khi có dữ liệu upstream. Chúng tôi không tuyên bố bao phủ những gì chưa xây dựng.
Token không mang quyền chung. Quyền được broker hóa theo từng agent, ở mức chi tiết mà upstream hỗ trợ. Đó là nửa câu trả lời dựa trên năng lực.
3. Vòng lặp vận hành và kiểm toán
Nguyên tắc đặc quyền tối thiểu chỉ hiệu quả nếu chế độ lỗi vẫn sử dụng được. Agent sẽ phát triển. Sáu tuần sau, một agent nghiên cứu ban đầu chỉ đọc từ Notion có thể cần ghi tóm tắt trở lại. Các chế độ lỗi phổ biến ở nơi khác: agent âm thầm chạy mà không có quyền mới và bị lỗi, hoặc người vận hành cấp quyền quá mức trong hoảng loạn và không bao giờ thu hồi lại.
Một yêu cầu connector bị từ chối trả về một 403 có cấu trúc: connector, phương thức, đường dẫn, base URL, và tên quyền khớp khi broker xác định được. Prompt hệ thống của agent hướng dẫn cách chẩn đoán từ chối và cách yêu cầu đúng quyền vừa bị chặn, tạo ra một URL cấp quyền một lần nhấp cho người dùng hoặc admin. Điều đó giữ đường nâng quyền gắn với đúng quyền đang được yêu cầu thay vì biến thành "cấp hết mọi thứ".
Yêu cầu thay đổi quyền nằm trong hàng đợi. Chủ sở hữu và admin có thể duyệt hoặc từ chối từ dashboard; yêu cầu được duyệt sẽ cập nhật chính sách agent, và lần thử lại tiếp theo sẽ thành công. Hầu hết nền tảng bỏ qua vòng lặp này. Nếu không có nó, "đặc quyền tối thiểu" chỉ nằm trên slide thay vì chạy thực tế.
Cùng đường broker đó phục vụ kiểm toán. Log mạng theo từng lần chạy ghi lại hoạt động mạng của sandbox trên HTTP, TCP, DNS, và quan sát gói ở tầng thấp hơn cho lưu lượng không phải TCP. Yêu cầu khớp connector bao gồm metadata broker có cấu trúc: connector, quyền khớp nếu có, kết quả cho phép/từ chối, metadata xác thực, và cờ tính phí. Nếu ai đó hỏi "agent này đã làm gì vào thứ Ba lúc 3 giờ chiều?", bạn có thể dựng lại câu trả lời từ các bản ghi đó. Phòng ngừa có thể bỏ sót. Dấu vết kiểm toán là cách bạn phát hiện ra.
Những gì chúng tôi chưa giải quyết
Ngay cả với tất cả những điều trên, một agent có quyền hợp lệ chat:write vẫn có thể bị thuyết phục đăng một tin nhắn xấu hổ lên kênh mà nó đã có quyền truy cập. Broker thu hẹp phạm vi thiệt hại; nó không loại bỏ hoàn toàn.
Nửa còn lại của câu trả lời là phê duyệt hành động rủi ro cao, xác thực đầu ra, và coi kết quả công cụ là không tin cậy theo mặc định. Công việc đó đang nằm trên lộ trình, chưa có trong sản phẩm. Bất kỳ ai tuyên bố đã giải quyết triệt để vấn đề phó thác bị nhầm lẫn đều đang bán hàng cho bạn.
Điều này nên là tiêu chuẩn tối thiểu, không phải tính năng
Bảo mật dựa trên năng lực đã có từ những năm 1970. Thông tin đăng nhập qua broker nằm trong OWASP LLM Top 10. Phantom token có trước thời đại LLM. Không phải vì không ai biết câu trả lời mà nó bị thiếu. Nó bị thiếu vì các nền tảng agent đầu tiên tối ưu cho "chạy được demo" và đẩy bảo mật sang bản phát hành sau, mà thường không bao giờ đến.
Thế hệ nền tảng tiếp theo nên đặt mục tiêu cao hơn. Token không nên vào ngữ cảnh mô hình. Quyền hạn nên được liệt kê theo từng agent. Việc nâng quyền nên qua con người. Mọi hành động nên kiểm toán được đầu cuối. Không điều nào mới. Tất cả nên là tiêu chuẩn cơ bản.
Khi bạn chọn nền tảng agent, hỏi "nó có an toàn không?" sẽ không giúp gì. Nhà cung cấp nào cũng nói có. Một câu hỏi tốt hơn: hãy cho tôi xem broker của bạn, và giải thích điều gì xảy ra khi một agent yêu cầu phạm vi mà nó chưa có.
Broker mặc định đứng trước mọi agent trên Zero. Danh mục connector, ánh xạ phạm vi, chính sách quyền, và logic broker đều nằm trong kho mã nguồn của Zero. Phát hiện connector nào chưa có? Hãy tạo issue.
Tài liệu tham khảo
Nền tảng
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (bài báo nền tảng về hệ thống năng lực)
- Mark Miller et al., Caja: bảo mật dựa trên năng lực cho web, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Sự cố thực tế được trích dẫn
- PromptArmor, Google Antigravity Exfiltrates Data, tháng 11 năm 2025
- Simon Willison, phân tích và tổng hợp, ngày 25 tháng 11 năm 2025
