Từ trợ lý đồng hành đến đồng nghiệp: ý nghĩa khi AI vận hành tự chủ

Một góc nhìn dựa trên nghiên cứu về chuyển dịch từ công cụ gợi ý sang đồng đội tự chủ. Vì sao điều này diễn ra lúc này, những vấn đề phát sinh trong quá trình chuyển đổi, và cách triển khai mà không giao hết quyền kiểm soát.

Kỷ nguyên copilot đang chững lại

Ngày 15 tháng 4 năm 2026, Sam Altman đăng trên X rằng OpenAI sẽ phát hành "các cập nhật Codex tuần này tập trung vào nhóm và doanh nghiệp lớn."

Các phản hồi rất đáng chú ý. Mỗi lập trình viên hỏi về lộ trình lại có một người khác đặt câu hỏi khó hơn: tại sao Codex vẫn cần tôi giám sát? Sáu tháng trước, các nhà nghiên cứu BeyondTrust đã công bố một minh chứng cho thấy một tên nhánh Git được tạo đặc biệt có thể đánh lừa Codex tiết lộ token GitHub của người dùng. Một copilot có thể bị lừa tiết lộ token chỉ qua tên nhánh không phải là đồng nghiệp. Đó là một vũ khí đã lên nòng nhưng còn chốt an toàn.

Sự căng thẳng này tồn tại trong mọi cuộc thảo luận AI doanh nghiệp ở 2026. Copilot đã chạm trần, và các con số đã nói lên điều đó:

Sáng kiến NANDA của MIT báo cáo tại 2025 rằng 95% các dự án thử nghiệm AI sinh không mang lại giá trị kinh doanh đo lường được.
Một nghiên cứu của RAND được trích dẫn nhiều lần trên Reddit r/ArtificialIntelligence đầu 2026 phát hiện 80 đến 90% các dự án AI agent thất bại khi triển khai thực tế.
Tỷ lệ chấp nhận của lập trình viên với GitHub Copilot đã dừng lại ở mức 35 đến 40%, trong khi Cursor ở mức 42 đến 45% và Claude Code đạt 46% "được yêu thích nhất" trong khảo sát lập trình AI 2026. Một sự đảo ngược ngoạn mục cho một công cụ chỉ mới ra mắt tháng 2025.
Satya Nadella được cho là đã gọi việc triển khai Copilot nội bộ của Microsoft là "gần như không thể sử dụng" vào cuối 2025, và công ty đã công bố một "tái cấu trúc quan trọng" cho sản phẩm này.
Một nghiên cứu trên arXiv cuối 2025 phát hiện autocomplete kiểu Copilot thực tế tăng sự khó chịu ở các lập trình viên chuyên nghiệp, vì nó làm gián đoạn dòng suy nghĩ với các gợi ý hợp lý nhưng sai lệch tinh vi.

Sự chững lại này không phải do mô hình nền tảng thất bại. Đó là thất bại của mô hình tương tác. Copilot hoạt động ở cấp độ từng phím bấm hoặc câu hỏi. Đồng nghiệp vận hành ở cấp độ quy trình công việc. Bits&Chips đã diễn đạt rất hay trong bài luận tháng 2026 "Từ copilot đến đồng nghiệp": "Copilot hoạt động ở cấp độ tương tác cá nhân, còn agent vận hành ở cấp độ quy trình. Điều này quan trọng, vì trong hầu hết tổ chức, điểm nghẽn không nằm ở từng tác vụ riêng lẻ mà ở sự phối hợp giữa các tác vụ."

Đó là sự chuyển dịch mà các doanh nghiệp đang cố gắng thực hiện hiện nay. Không đồng đều, chưa hoàn hảo, nhưng ở quy mô đáng kể.

Phổ tự chủ

"Agent" đã trở thành một từ tiếp thị, nên hãy làm rõ. Có bốn cấp độ tự chủ AI khác nhau, và phần lớn sự thất vọng ở 2025 và 2026 xuất phát từ việc nhầm lẫn giữa các cấp độ này.

Cấp 1: copilot

Đề xuất. Xin phép. Luôn hiện trên màn hình. Autocomplete của GitHub Copilot là ví dụ điển hình. Giá trị đo bằng số phím bấm tiết kiệm được.

Cấp 2: trợ lý

Trả lời câu hỏi và soạn thảo tài liệu theo yêu cầu. ChatGPT, Claude trên trình duyệt, bảng chat của Microsoft 365 Copilot. Giá trị đo bằng chất lượng bản nháp và khả năng tổng hợp ngữ cảnh.

Cấp 3: agent

Nhận mục tiêu, lập kế hoạch các bước, thực thi qua nhiều công cụ, báo cáo lại. Claude Code quét repo và mở PR. Deep Research của ChatGPT chạy 20 phút tìm kiếm và trả về báo cáo có trích dẫn. Anthropic ghi nhận một phiên bản Claude hoàn thành nhiệm vụ kỹ thuật tự chủ kéo dài 7 giờ cho Rakuten. Giá trị đo bằng số quy trình hoàn thành trên mỗi giờ lao động của con người.

Cấp 4: đồng nghiệp

Một agent vận hành trong mô hình phân quyền hiện có, tham gia các kênh giao tiếp của nhóm, giữ ngữ cảnh qua nhiều ngày/tuần, và chịu trách nhiệm với nhật ký kiểm toán như nhân viên thật sự. Đây là ranh giới mới.

Cộng đồng r/ChatGPT trên Reddit đã đưa ra một bài kiểm tra thực tế để phân biệt các cấp độ này, tóm tắt: công cụ đó có chủ động không, hay chờ từng chỉ dẫn? Có xử lý tình huống bất ngờ không, hay bị lỗi và bắt bạn nhập lại? Có nhớ ngữ cảnh qua nhiều bước không, hay bạn phải lặp lại? Hầu hết sản phẩm quảng cáo là "AI agent" ở 2025 đều trượt hết các câu hỏi này. Những sản phẩm vượt qua mới thực sự là "đồng nghiệp" như mọi người đang nói đến.

Sử dụng máy tính vs kỹ năng: vì sao hạ tầng quan trọng

AI cấp đồng nghiệp cần hành động trong thế giới thực. Có hai hướng kiến trúc cho điều này, và mỗi hướng mang rủi ro rất khác nhau.

Sử dụng máy tính

AI điều khiển chuột và bàn phím mô phỏng. Nó thực sự nhìn thấy màn hình và nhấn nút. Anthropic ra mắt Computer Use cuối 2024, OpenAI's Operator theo sau. Điểm hấp dẫn là tính phổ quát: bất kỳ phần mềm nào có giao diện đồ họa đều có thể truy cập.

Cái giá phải trả là phạm vi ảnh hưởng. Agent sử dụng máy tính thừa hưởng mọi quyền của người dùng đăng nhập. Tháng 10 2025, nhóm bảo mật BeyondTrust chứng minh agent Codex của OpenAI có thể bị lừa, qua tên nhánh Git độc hại chứa lệnh shell, để đọc và gửi đi GITHUB_TOKEN của người dùng. Agent làm đúng như lập trình viên thật (checkout branch), nhưng không nhận ra tên nhánh là đầu vào nguy hiểm. Trong sự cố đó, mô hình phân quyền là tất cả hoặc không gì cả. Đó là kiểu thất bại mặc định của sử dụng máy tính.

Kỹ năng

AI gọi các kỹ năng rời rạc. Mỗi kỹ năng là một hàm rõ ràng, có kiểu và hợp đồng hẹp: "tìm tin nhắn Slack khớp q", "tạo issue Linear với title và body", "đọc file GitHub này." Khác với sử dụng máy tính, kỹ năng có hình dạng được phê duyệt trước. Agent chỉ có thể gọi với tham số đúng hợp đồng, và nền tảng có thể cho phép, từ chối hoặc hỏi lại trước khi rời sandbox.

Sự khác biệt về bảo mật nằm ở Nguyên tắc Đặc quyền Tối thiểu. Đây là nguyên lý nền tảng trong bảo mật thông tin: một tiến trình chỉ nên truy cập tài nguyên cần thiết để thực hiện chức năng, không hơn. Kỹ năng cho phép bạn áp dụng đặc quyền tối thiểu cho từng lần gọi. Sử dụng máy tính thì không.

Triển khai AI cấp đồng nghiệp dùng kỹ năng cho các hành động có cấu trúc (ghi vào CRM, mở ticket), và chỉ dùng sử dụng máy tính cho số ít ứng dụng không có API. Tỷ lệ này rất quan trọng. Nếu mọi hành động đều qua chuột mô phỏng, bạn chỉ có bản demo năng suất, không phải hệ thống thực tế.

Kiến trúc tin cậy doanh nghiệp thực sự cần

Chuyển từ copilot sang đồng nghiệp không phải nâng cấp mô hình. Đó là nâng cấp hạ tầng. Ba yếu tố tách biệt một đồng nghiệp có thể triển khai với một rủi ro tiềm tàng.

1. Cách ly quyền truy cập

Mỗi agent vận hành trong ranh giới quyền riêng, với thông tin xác thực mà agent không thể lấy ra khỏi sandbox. Thí nghiệm autoresearch nổi tiếng của Andrej Karpathy tháng 2026, nơi ông để agent chạy 700 thí nghiệm huấn luyện không giám sát suốt hai ngày, rất đáng chú ý ở chỗ không làm gì. Repo của Karpathy hướng dẫn người dùng "tắt mọi quyền" ở chế độ tự chủ. Điều này ổn với máy tính cá nhân nghiên cứu. Nhưng trong doanh nghiệp có kiểm soát, đó là lý do bị sa thải.

Ví dụ ngược lại là Moltbook, mạng xã hội chỉ dành cho AI từng gây sốt cuối tháng 1 2026 với 1.5 triệu agent tự chủ. Karpathy ca ngợi đây là "thứ gần nhất với viễn tưởng mà tôi từng thấy gần đây." Sau đó, các nhà nghiên cứu bảo mật tại Wiz phát hiện một API key database bị lộ ở frontend, cho phép truy cập đọc/ghi toàn bộ database sản xuất, bao gồm token xác thực của tất cả 1.5 triệu agent. Karpathy đổi ý trong vòng 24 giờ: "Thảm họa. Tôi hoàn toàn không khuyến nghị ai chạy thứ này trên máy tính của mình." Bài học không phải "agent nguy hiểm." Bài học là agent triển khai mà không cách ly quyền theo từng danh tính sẽ hợp nhất thành một vùng rủi ro chung.

2. Nhật ký kiểm toán

Mọi hành động đều được ghi lại, mọi quyết định đều truy vết được. Khung IMDA của Singapore, công bố tại Davos tháng 2026, quy định ma trận rủi ro hai trục: không gian hành động (đọc/ghi, có thể đảo ngược/không thể đảo ngược) và mức tự chủ (quyết định độc lập đến đâu). Trục nào càng cao, yêu cầu kiểm toán càng nhiều. Khung này đang được các nhà quản lý châu Âu và Mỹ nghiên cứu kỹ vì là một trong những công cụ đầu tiên chuyển quản trị từ nguyên tắc trừu tượng thành công cụ vận hành thực tế.

Simon Willison cũng đề xuất ghi log hợp nhất để agent tự giám sát hoạt động và phục hồi lỗi: "Agent có quyền truy cập hệ thống đầy đủ rất mạnh, nhưng cũng rất nguy hiểm." Ý thực tế: nếu triển khai agent mà không có log hợp nhất để cán bộ tuân thủ đọc theo thứ tự, bạn chỉ cách một sự cố là mất quyền triển khai.

3. Quyền truy cập kỹ năng có phạm vi

Không phải "truy cập email." Là truy cập search inbox where from:@customer.com AND within last 7 days. Các nền tảng agent hiện đại đang hướng tới phạm vi tham số hóa, nơi quyền gọi kỹ năng của agent bị giới hạn bởi các tham số quản trị viên phê duyệt trước, thay vì phạm vi OAuth rộng như người dùng thật.

Kết hợp ba yếu tố này sẽ trả lời câu hỏi mọi CISO đang đặt ra: agent này làm gì khi sai, và tôi biết bằng cách nào? Khảo sát State of AI của McKinsey 2026 cho thấy 72% doanh nghiệp lo ngại an ninh mạng với AI sinh, và bảo mật được nêu là rào cản số #1 để mở rộng quy trình agent, với khoảng hai phần ba số người trả lời. Cách ly quyền, nhật ký kiểm toán và quyền kỹ năng có phạm vi không phải là hình thức tuân thủ. Đó là hạ tầng bắt buộc.

Vì sao điều này quan trọng lúc này: ba lực đẩy hội tụ

Chuyển từ copilot sang đồng nghiệp ở 2026 không do một đột phá duy nhất. Đó là kết quả của ba đường cong giao nhau.

Lực đẩy 1: tích hợp không còn là đặt hàng riêng

Năm 2024, tích hợp agent vào hệ SaaS doanh nghiệp nghĩa là viết connector riêng cho từng công cụ. Đầu 2026, hợp đồng kỹ năng có kiểu và connector đóng gói sẵn đã rút ngắn công việc đó. Một agent từng cần sáu tuần tích hợp ở 2024 giờ chỉ cần một buổi chiều ở 2026. Bề mặt của một công ty tầm trung (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, lịch) nay đã được các thư viện connector mã nguồn mở trưởng thành bao phủ, với quyền truy cập có kiểu tích hợp sẵn.

Lực đẩy 2: đa agent trở thành thực tế

Gartner xếp Hệ thống Đa Agent là xu hướng công nghệ chiến lược hàng đầu năm 2026. Phó Chủ tịch Gene Alvarez đưa ra phép ẩn dụ nay xuất hiện trên mọi slide AI doanh nghiệp: "Hãy nghĩ đến đội kỹ thuật pitstop F1. Mỗi thành viên có vai trò chuyên biệt (thay lốp, tiếp nhiên liệu, nâng xe) nhưng phối hợp quanh một mục tiêu chung. Đó là hình mẫu triển khai agent doanh nghiệp ở 2026." Hệ thống đơn agent chạm trần lý luận ở các nhiệm vụ dài hạn. Đa agent, với vai trò chuyên biệt và bàn giao rõ ràng, là cách các nhóm vượt qua giới hạn đó hiện nay.

Lực đẩy 3: ngân sách doanh nghiệp được mở khóa

G2 báo cáo trong nghiên cứu State of Software 2026 rằng 57% công ty đã có AI agent vận hành thực tế (tăng từ khoảng 20% năm trước).
McKinsey phát hiện 23% doanh nghiệp đang mở rộng AI agent, với 62% đang thử nghiệm. Chỉ còn khoảng 15% tổ chức lớn đứng ngoài cuộc.
Khảo sát của Deloitte 2026 với 3,235 lãnh đạo doanh nghiệp xác định tài chính là ngành dẫn đầu, với nghiên cứu điển hình về agent AI ghi nhận và thực thi kết quả họp trong pipeline giao dịch từng cần ba nhà phân tích.
Sổ tay AI doanh nghiệp của Stanford, phát hành đầu 2026, thống kê 51 triển khai thực tế, với case fintech ETL migration trở thành mẫu tham chiếu cho nhóm ngành có kiểm soát.
Đầu tư hạ tầng AI doanh nghiệp báo cáo vượt $600 tỷ USD trong chu kỳ 2025.
Dario Amodei của Anthropic, phát biểu tại hội nghị Code with Claude, đưa ra xác suất 70 đến 80% cho công ty một người đầu tiên trị giá tỷ đô xuất hiện trong 2026, nhờ lực lượng agent.

Tiền đã sẵn, giao thức đã có, kiến trúc đã rõ. Điều đang được thương lượng ở mọi phòng họp là mức tự chủ, dưới kiểm soát nào, và cho quy trình nào.

Góc nhìn hoài nghi: Reddit, arXiv và các báo cáo sự cố nói gì

Một cái nhìn có trách nhiệm về chuyển dịch này phải đối thoại nghiêm túc với những người cho rằng tất cả đều bị thổi phồng.

Trên Reddit, đồng thuận ở r/LocalLLaMA, r/ClaudeCode, và r/ChatGPT là thực tế: agent lập trình đã xuất hiện và hữu ích. Hầu hết "agent" khác chỉ là workflow tự động khoác áo chatbot. Câu được trích dẫn hàng chục lần trên các chủ đề 2026, "Dùng Copilot khi cần gợi ý. Dùng Claude Code hoặc Cursor khi muốn nó thực sự làm việc," thể hiện rõ ranh giới thực dụng. Các cộng đồng này cũng rất khắt khe với benchmark. Ngay cả agent tốt nhất cũng chỉ đạt khoảng 60% trên Terminal-Bench và giảm còn 16% ở tác vụ khó. Claude Opus 4.5 dẫn đầu SWE-bench với 80.9%, nghĩa là vẫn có một trên năm tác vụ thất bại.

Hoài nghi học thuật khó lay chuyển hơn. Vishal Sikka (cựu CTO SAP, học trò John McCarthy) và cộng sự công bố Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, lập luận toán học rằng LLM transformer bị giới hạn cơ bản trong khả năng thực thi tác vụ tính toán và agent vượt quá một ngưỡng phức tạp nhất định. Kết luận của Sikka, "Không thể nào chúng đáng tin cậy" cho các hoạt động cực kỳ quan trọng, đang lan truyền trong mọi Slack của CISO. Bài báo không nói agent vô dụng. Nó khẳng định có loại vấn đề không thể loại bỏ con người khỏi vòng lặp, dù mô hình tốt đến đâu.

Sự cố thực tế củng cố sự hoài nghi. Một lãnh đạo CX bán lẻ được trích trong khảo sát Yellow.ai 2026: "Chúng tôi phải dừng AI hỗ trợ sau chỉ hai tuần, vì nó bắt đầu trích dẫn sai chính sách đổi trả và bịa ưu đãi giảm giá ở khoảng 1.35% số phiếu. Chi phí khắc phục còn lớn hơn khoản tiết kiệm kỳ vọng." Ở quy mô lớn, ngay cả tỷ lệ lỗi dưới 2% cũng nhanh chóng trở nên đắt đỏ.

Tóm lại: AI cấp đồng nghiệp là thực tế ở lập trình, nghiên cứu, vận hành có cấu trúc và quy trình hỗ trợ hẹp. Chưa thực tế ở các tương tác mở với khách hàng mà không có người kiểm duyệt. Doanh nghiệp có giá trị ở 2026 là những nơi trung thực về loại quy trình nào thuộc nhóm nào.

Ứng dụng thực tiễn: năm câu hỏi trước khi triển khai

Nếu nhóm bạn đang đánh giá một AI đồng nghiệp (tự xây hoặc bên thứ ba), đây là những câu hỏi phân biệt triển khai thực tế với suýt thành công.

Phạm vi ảnh hưởng lớn nhất của một hành động sai từ agent này là gì? Vẽ ra cụ thể. Nếu tệ nhất là "gửi email nháp cho nhầm người," yêu cầu quản trị thấp. Nếu là "sửa dữ liệu sản xuất" hoặc "gửi lệnh chuyển tiền," yêu cầu cao hơn nhiều lần. Xác định trước khi triển khai, không phải sau sự cố đầu tiên.
Agent lấy thông tin xác thực bằng cách nào, và có thể đọc token thô không? Có ba đáp án, chỉ một an toàn. Nếu agent có bản sao token OAuth của người dùng trong môi trường, bạn đã trao ví cho LLM. Nếu agent có danh tính riêng qua OAuth tài khoản dịch vụ, bạn phải theo dõi và thu hồi như một thực thể thật. Đáp án đúng: token không bao giờ đến agent. Nó nằm trên nền tảng, được mã hóa, chỉ được chèn ở lớp proxy mạng đúng lúc, chỉ cho các cuộc gọi qua kiểm tra chính sách, chỉ đến khi cuộc gọi trả về.
Mọi hành động có được ghi log ở nơi cán bộ tuân thủ đọc theo thứ tự không? Hợp nhất, truy vấn được, chống sửa đổi. Nếu trả lời "chúng tôi có log đâu đó trên CloudWatch," bạn chưa sẵn sàng.
Bạn có thể giới hạn quyền kỹ năng theo đúng tham số quy trình này cần không? Theo từng lần gọi, không phải từng tích hợp. Đọc/ghi. Theo ID tài nguyên. Theo khung thời gian. Quyền của agent nên là hình chữ nhật bao quanh công việc, không phải cả kho hàng.
Kịch bản khôi phục khi có sự cố là gì? Làm sao để đảo ngược hành động? Mất bao lâu? Ai được thông báo? Hành động không thể đảo ngược (chuyển tiền, email khách hàng, triển khai sản xuất) cần bước xác nhận hoặc cửa sổ trì hoãn. Hành động đảo ngược được có thể tự động.

Làm hết năm câu hỏi. Nếu trả lời được tất cả, bạn đã vượt qua kỷ nguyên copilot và bước vào giai đoạn thực sự thay đổi cách nhóm làm việc. Nếu mới trả lời được hai hoặc ba, đó là nơi cần tập trung tiếp, không phải lý do trì hoãn. AI đồng nghiệp mà lộ trình bạn hướng tới đã chạy thực tế ở đâu đó hôm nay. Khoảng cách giữa bạn và nó là khoảng cách hạ tầng, không phải AI tiên tiến. Và khoảng cách hạ tầng đóng lại rất nhanh.

Bạn không cần chờ bản phát hành mô hình tiếp theo. Hãy chọn nền tảng đã trả lời sẵn năm câu hỏi này cho bạn, và bắt đầu giao việc thực tế cho agent.

Câu hỏi thường gặp

Sự khác biệt thực sự giữa copilot và AI đồng nghiệp là gì?

Copilot đề xuất, xin phép, và sống trong một công cụ. Đồng nghiệp nhận mục tiêu, lập kế hoạch đa hệ thống, thực thi với quyền giới hạn, và chịu trách nhiệm với nhật ký kiểm toán như con người. Bits&Chips nói ngắn gọn: copilot vận hành ở cấp độ tương tác, đồng nghiệp ở cấp độ quy trình.

Agent nên xử lý thông tin xác thực người dùng thế nào?

Không phương án nào trong hai cách phổ biến là đúng. Sao chép token OAuth của người dùng vào môi trường agent đặt thông tin xác thực sống vào ngữ cảnh LLM. Tạo danh tính riêng cho mỗi agent biến mọi agent thành thực thể bạn phải theo dõi, thu hồi, kiểm toán như người thật. Mô hình hiệu quả là truy cập qua trung gian: token nằm trên nền tảng, được mã hóa; proxy mạng của sandbox gọi lại nền tảng khi có yêu cầu; nền tảng giải mã token và chỉ trả về header xác thực cho các cuộc gọi qua kiểm tra chính sách; agent không bao giờ đọc, ghi log, hoặc gợi ý về token thô.

Sử dụng máy tính hay kỹ năng, nên chọn gì?

Mặc định dùng kỹ năng cho mọi hệ thống có API. Chỉ dùng sử dụng máy tính khi hệ thống mục tiêu không có giao diện lập trình. Sự cố Codex của BeyondTrust là bài học cảnh báo: sử dụng máy tính thừa hưởng toàn bộ quyền người dùng, và đầu vào độc hại ở bất kỳ đâu trong tầm nhìn agent đều có thể thành lỗ hổng.

Nên cho agent tự chủ đến mức nào?

Áp dụng khung hai trục của IMDA Singapore: không gian hành động × tự chủ. Không gian hẹp (chỉ đọc, có thể đảo ngược) cho phép tự chủ cao. Không gian rộng (ghi, không thể đảo ngược, đối mặt khách hàng) cần xác nhận người thật, hoặc cửa sổ trì hoãn. Cấu hình tệ nhất là tự chủ cao trên hành động rủi ro mà không có nhật ký kiểm toán.

Đo lường ROI thế nào?

Đừng đo số phím bấm tiết kiệm. Hãy đo số quy trình hoàn thành trên mỗi giờ lao động, thời gian xử lý sự cố vận hành, và tỷ lệ chuyển giao (tác vụ agent trả lại cho người). Kết quả khảo sát của Deloitte 2026 cho thấy các đơn vị dẫn đầu theo dõi ba chỉ số: tỷ lệ hoàn thành quy trình, tỷ lệ lỗi, và tỷ lệ can thiệp của con người, tối ưu hóa tỷ lệ giữa chúng.

Làm gì với tỷ lệ thất bại thử nghiệm 95%?

Đọc kỹ phân tích của MIT NANDA. Các thử nghiệm thất bại chủ yếu dùng "Dumb RAG" (đổ hết vào ngữ cảnh), "Brittle Connectors" (tích hợp API lỗi), và không có kiến trúc sự kiện. Các thử nghiệm thành công có lớp vận hành quanh LLM: bộ nhớ, I/O, quyền truy cập. Lõi LLM không phải điểm nghẽn. Hạ tầng xung quanh mới là vấn đề.

Vị trí của VM0

Chúng tôi xây dựng Zero dựa trên một giả định kiến trúc: agent không bao giờ giữ thông tin xác thực. Không trong môi trường, không trong prompt, không trong bộ nhớ. Token luôn nằm trên nền tảng. Mọi cuộc gọi ra ngoài của agent đều qua proxy mạng quyết định, từng lần gọi, có chèn header xác thực hay chặn yêu cầu.

Đây là lựa chọn khác biệt. Các mô hình phổ biến ở 2026 là hoặc cấp cho agent danh tính OAuth riêng (bạn phải kiểm toán và thu hồi thêm một thực thể), hoặc đưa bản sao token người dùng vào biến môi trường (LLM có thể đọc ví của bạn). Chúng tôi không làm cả hai. Cách vận hành thực tế như sau.

Token không bao giờ đến agent. Khi bạn kết nối connector với Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot...), token OAuth được lưu mã hóa trên nền tảng. Token refresh nằm trong database và không bao giờ rời khỏi đó. Trong sandbox, không có biến môi trường GITHUB_TOKEN để đọc, không có file bí mật để mở, không có công cụ trả về token.

Proxy mạng trung gian mọi cuộc gọi. Mọi yêu cầu HTTP rời sandbox đều qua addon dựa trên mitmproxy. Proxy xác định connector từ hostname, tra cứu chính sách tường lửa cho agent, kiểm tra method và path có được phép không. Nếu được, proxy gọi lại webhook của nền tảng. Nền tảng giải mã token, làm mới nếu hết hạn, xử lý template header (${{ secrets.GITHUB_TOKEN }} thành giá trị thực), và chỉ trả về header xác thực cho proxy. Proxy chèn header vào yêu cầu gửi đi. Khi hoàn thành, header bị xóa khỏi bộ nhớ proxy. Agent không bao giờ thấy chúng.

Quyền theo agent, theo connector, và có kiểu ở cấp endpoint. Mỗi agent mang một đối tượng chính sách ánh xạ từng connector với nhóm quyền được đặt tên. github:repo-read không phải phạm vi mơ hồ. Đó là tập hợp quy tắc method-path cụ thể, ví dụ GET /repos/{owner}/{repo}/pulls. Cấp quyền GitHub không phải cấp toàn bộ GitHub. Chỉ cấp hình dạng ý định trong GitHub.

Ba trạng thái chính sách, không phải hai. Mọi quyền được phân giải thành allow, deny hoặc ask. Trạng thái cuối cùng sẽ hỏi người thật trước khi thực hiện. Mọi thứ tường lửa không khớp rõ ràng sẽ rơi vào unknownPolicy của từng connector, mặc định là deny. Đặc quyền tối thiểu là mặc định, không phải tùy chọn.

Một sandbox cho mỗi lần chạy. Mỗi lần thực thi agent chạy trong Firecracker microVM riêng với namespace mạng tách biệt. Khi kết thúc, namespace bị xóa. Hai lần chạy cùng agent là hai sandbox riêng với hai nhật ký kiểm toán riêng.

Nhật ký kiểm toán theo từng yêu cầu. Proxy quyết định cho phép/từ chối cũng ghi log JSONL theo từng lần chạy với metadata tường lửa cho mọi yêu cầu: connector, nhóm quyền khớp, quy tắc cụ thể khớp, quyết định, timestamp. Log này gửi về nền tảng. Nếu CISO cần biết agent làm gì ngày 14 từ 3-5 giờ chiều CST, chỉ cần một truy vấn.

CLI giải thích lý do bị chặn. Khi quyền chặn yêu cầu, agent (hoặc người dùng bên cạnh) có thể chạy zero doctor permission-deny <connector> --method <M> --path <P> để nhận lại nhóm quyền đã chặn, kèm link khắc phục. zero doctor permission-change cho phép admin bật/tắt quyền trực tiếp, hoặc thành viên gửi yêu cầu viết (giới hạn 500 ký tự, để lý do dễ đọc) chuyển tới admin. Quyền rủi ro cao như slack:chat:write hoặc gmail.send sẽ có cảnh báo bổ sung chỉ tới lựa chọn an toàn hơn, giới hạn cho bot.

Hai vai trò, một luồng phê duyệt. Chủ sở hữu và admin thay đổi quyền trực tiếp. Thành viên gửi yêu cầu kèm lý do, chuyển tới admin. Không có tầng "gần-admin" thứ ba. Luồng đủ nhỏ để mọi người thực sự sử dụng, đó là mục tiêu.

Chúng tôi chỉ dùng sử dụng máy tính cho số ít hệ thống cũ không có API. Mọi thứ khác qua kỹ năng. Mọi hành động đều kiểm tra chính sách. Mọi thông tin xác thực ở lại nền tảng. Mọi quyết định đều ghi log.

Nếu bạn đã vượt qua "autocomplete AI nữa" và muốn thử AI đồng nghiệp mà đội bảo mật sẽ phê duyệt, xem Zero xử lý quy trình định kỳ thế nào, phân loại sự cố sản xuất, hoặc chạy báo cáo sản phẩm buổi sáng.

Kỷ nguyên copilot chưa kết thúc. Nó đang được tích hợp vào thứ lớn hơn. Những đội sẽ chiến thắng chu kỳ tiếp theo là những người hiểu sự khác biệt này.