Khi một Agent biết quá nhiều quyền
Trong vài năm đầu của làn sóng AI Agent, kiến trúc phổ biến thường khá đơn giản:
1User
2 ↓
3LLM / Agent
4 ↓
5MCP / Tool Calling
6 ↓
7GitHub / Google Drive / Database / Slack / API...
Agent nhận yêu cầu, lựa chọn công cụ, gọi API và trả kết quả.
Cách tiếp cận này hoạt động tốt cho demo. Nhưng khi đưa vào một doanh nghiệp thực sự, một loạt câu hỏi khó bắt đầu xuất hiện:
- Agent được phép đọc repository nào?
- Nó có được gửi email không?
- Nếu được gửi, gửi cho ai?
- Agent tạo một ứng dụng mới thì ứng dụng đó được truy cập Internet đến đâu?
- Nếu code do AI sinh ra có lỗi thì sao?
- Làm thế nào để một nhân viên không chuyên kỹ thuật có thể dùng AI mà không vô tình cấp cho agent quá nhiều quyền?
- Khi agent muốn thực hiện 20 thao tác có side effect, con người có phải ngồi approve từng thao tác hay không?
Cloudflare đang thử trả lời những câu hỏi đó bằng một dự án khá tham vọng: Cloudflare OS.
Repository được Cloudflare mô tả là một “Agent workspace built on Cloudflare Workers for creating documents, building apps, and running agents with your company’s context and systems”. Dự án được phát hành mã nguồn mở theo Apache 2.0 và tính đến ngày 9/8/2026 đã thu hút gần 7 nghìn star trên GitHub. (Cloudflare OS README)
Nhưng điều thú vị nhất là: Cloudflare OS không thực sự là một hệ điều hành theo nghĩa Windows, Linux hay macOS.
Nó giống một hệ điều hành dành cho AI workload trong doanh nghiệp hơn.
Cloudflare OS thực chất là gì?
Cloudflare nói rằng hệ thống này ban đầu được phát triển để sử dụng nội bộ. Từ engineering, sales cho đến nhiều bộ phận khác trong Cloudflare đã sử dụng nó để hỗ trợ công việc hàng ngày. (Cloudflare OS README)
Cloudflare OS cung cấp ba thành phần chính:
- Một giao diện Agent Chat có thể được nạp kiến thức về cách công ty vận hành.
- Một môi trường sandbox cho phép AI tạo ứng dụng nhỏ.
- Một lớp bảo mật gọi là Gatekeeper để kiểm soát agent và các ứng dụng do AI tạo ra.
Cloudflare không muốn các công ty đơn giản cài một sản phẩm tên là Cloudflare OS.
Ý tưởng của họ là:
1Cloudflare OS
2 ↓
3customize
4 ↓
5Your Company OS
Ví dụ:
1MWG OS
2Grab OS
3Netflix OS
4Company X OS
Trong đó AI không chỉ chat với nhân viên mà còn có thể tạo phần mềm, truy cập tài nguyên nội bộ, cộng tác với người dùng và thực hiện công việc thay họ.
1. Gadget: AI không chỉ sử dụng phần mềm, AI tạo phần mềm cho từng người
Đây có lẽ là ý tưởng khác biệt nhất của Cloudflare OS.
Trong mô hình SaaS truyền thống:
1 ┌── User A
2 │
3Google Slides ─────┼── User B
4 │
5 └── User C
Mọi người sử dụng cùng một ứng dụng trung tâm.
Cloudflare OS đưa ra một mô hình khác.
Giả sử người dùng nói:
1Tạo cho tôi dashboard theo dõi issue của repository này.
AI có thể tạo hẳn một ứng dụng.
Cloudflare gọi ứng dụng này là:
Gadget
Nhưng điểm quan trọng là Gadget không nhất thiết là một dịch vụ SaaS dùng chung cho toàn công ty.
Mỗi người có thể có instance riêng:
1User A
2 ↓
3Issue Dashboard A
4 ↓
5sandbox riêng
6
7User B
8 ↓
9Issue Dashboard B
10 ↓
11sandbox riêng
Người A sau đó có thể nói:
1Thêm biểu đồ số issue theo team.
Agent sửa code.
Người B có thể yêu cầu:
1Bỏ biểu đồ đi.
2Thêm bảng SLA.
Agent sửa một phiên bản khác.
Cloudflare cho rằng AI làm thay đổi một giả định tồn tại suốt nhiều thập kỷ của SaaS:
Phần mềm phải được xây dựng tập trung bởi developer rồi mọi người dùng cùng một phiên bản.
Khi AI có khả năng sửa phần mềm với chi phí rất thấp, software có thể trở nên cá nhân hóa đến cấp từng người dùng.
2. Blueprint: template không còn chỉ là dữ liệu
Cloudflare OS còn có khái niệm:
1Blueprint
Có thể hiểu đơn giản:
1Gadget = một instance ứng dụng
2Blueprint = code/template để tạo Gadget
Ví dụ công ty có Blueprint:
1Sales Dashboard
Một nhân viên tạo:
1Sales Dashboard của tôi
Nhân viên khác tạo:
1Sales Dashboard khu vực miền Nam
Một người khác yêu cầu AI sửa thành:
1Sales Dashboard + Forecast
Điều này khác với template trong PowerPoint hoặc Google Docs.
Template truyền thống chủ yếu là:
1layout
2+
3content mẫu
Blueprint chứa:
1UI
2+
3logic
4+
5backend
6+
7API
8+
9state
Nói cách khác:
Blueprint là template của cả một ứng dụng.
Cloudflare xem đây là một sự dịch chuyển đáng kể khỏi kiến trúc cloud truyền thống: thay vì người tạo phần mềm phải vận hành một dịch vụ cho tất cả người dùng, mỗi người có thể chạy bản sao riêng rồi để AI tiếp tục sửa bản sao đó theo nhu cầu. (Cloudflare OS README)
3. Vấn đề lớn nhất của Agent không phải LLM, mà là quyền hạn
Một agent đủ thông minh nhưng được trao quyền sai có thể nguy hiểm hơn một agent kém thông minh.
Ví dụ chúng ta cấu hình:
1Agent
2 ├── Gmail MCP
3 ├── GitHub MCP
4 ├── Slack MCP
5 ├── Database MCP
6 └── Google Drive MCP
Agent có thể nhìn thấy hàng chục hoặc hàng trăm tools.
Nhưng câu hỏi thực sự là:
1Agent cần quyền gì
2cho nhiệm vụ hiện tại?
Ví dụ người dùng yêu cầu:
1Phân tích issue của repository abc.
Agent thực sự chỉ cần:
1GitHub
2└── repository abc
3 └── read issues
Không cần:
1GitHub toàn bộ organization
2Google Drive
3Slack
4Gmail
5Database
Cloudflare OS xây security model theo hướng capability-based access control.
Mặc định:
1Agent
2 access = NOTHING
3
4Gadget
5 access = NOTHING
Sau đó người dùng chủ động introduce resource cho agent.
Ví dụ:
1User
2 ↓
3Agent
4
5Introduce:
6github.com/company/product-a
7
8 ↓
9
10Agent
11 ↓
12Product-A repository
Thay vì:
1Agent
2 ↓
3GitHub MCP
4 ↓
5mọi repository user có quyền
Cloudflare nhấn mạnh rằng agent và Gadget không tự động thừa hưởng toàn bộ các external account mà hệ thống đã cấu hình. Quyền được giới hạn theo resource cụ thể mà người dùng giới thiệu vào nhiệm vụ. (Cloudflare OS README)
Đây là một khác biệt rất đáng chú ý so với cách triển khai MCP đơn giản hiện nay.
4. Gatekeeper: MCP Server nhưng có security policy đứng giữa
Cloudflare mô tả Gatekeeper khá thú vị:
“Gatekeepers are like supercharged MCP servers.” (Cloudflare OS README)
Có thể hình dung:
1Agent
2 ↓
3Gatekeeper
4 ↓
5GitHub
thay vì:
1Agent
2 ↓
3GitHub API
Gatekeeper chịu trách nhiệm:
1Authentication
2Authorization
3Resource Scope
4Audit Log
5Human Approval
6API abstraction
Ví dụ GitHub:
1Agent
2 ↓
3GitHub Gatekeeper
4 ↓
5GitHub OAuth
6 ↓
7Repository được user cho phép
Package gatekeeper-github trong repo cho thấy khá rõ ý tưởng này. Khi người dùng tạo connection, họ có thể chọn resource cụ thể như repository, issue hoặc pull request; Gadget sau đó chỉ được cấp quyền đối với resource đã chọn.
Đây chính là lớp thường còn thiếu trong kiến trúc:
1Agent + MCP
Một kiến trúc enterprise đầy đủ hơn có thể là:
1 ┌──────── Policy
2 │
3Agent ──→ Gatekeeper ──→ MCP/API
4 │
5 ├──────── Authentication
6 ├──────── Authorization
7 ├──────── Audit
8 ├──────── Scope
9 └──────── Approval
5. Ý tưởng rất hay: Agent không cần đứng chờ con người approve
Một trong những phần thú vị nhất của Gatekeeper nằm ở Human-in-the-loop.
Agent framework thông thường có thể hoạt động như sau:
1Agent:
2Tôi muốn tạo issue.
3
4SYSTEM:
5Approve?
6
7 ↓
8
9Agent đứng lại.
Người dùng đi họp 30 phút.
Quay lại thấy agent vẫn đang:
1Waiting for approval...
Kết quả là nhiều developer cuối cùng chọn:
1auto approve
hoặc những chế độ tương đương:
1--dangerously-skip-permissions
Agent chạy nhanh hơn.
Nhưng security gần như biến mất.
Cloudflare đưa ra cách giải quyết khác.
Khi agent muốn thực hiện một thao tác cần approval:
1Agent
2 ↓
3Gatekeeper
4 ↓
5simulate action
6 ↓
7trả simulated result
8 ↓
9Agent tiếp tục reasoning
Ví dụ:
11. Create issue A
22. Create issue B
33. Update issue C
44. Comment PR D
Agent có thể tiếp tục lập kế hoạch dựa trên kết quả mô phỏng.
Sau khi hoàn thành:
1Pending actions
2
3☑ Create issue A
4☑ Create issue B
5☑ Update issue C
6☑ Comment PR D
7
8[Approve all]
Người dùng duyệt một lần.
Theo README, Gatekeeper thậm chí có thể trả simulated result nếu agent đọc lại kết quả của một hành động chưa thực sự được commit. Sau khi agent hoàn thành, người dùng mới approve hoặc reject từng action hoặc cả batch. (Cloudflare OS README)
Nếu triển khai tốt, đây là một cơ chế rất đáng học hỏi khi xây agent cho doanh nghiệp.
6. Sandbox: code do AI viết không nên được tin tưởng mặc định
Cloudflare OS được thiết kế với giả định:
1AI-generated code
2=
3untrusted code
Đây là một giả định rất hợp lý.
Một agent coding có thể vô tình tạo:
1fetch("https://example.com", {
2 method: "POST",
3 body: confidentialData
4})
Cloudflare không cố dựa hoàn toàn vào prompt:
1"Please don't leak company data."
Họ khóa nó ở tầng runtime.
Server của Gadget chạy trong Dynamic Worker và bị hạn chế Internet mặc định. Nó chỉ có thể giao tiếp với các tài nguyên đã được cấp thông qua Workers Bindings/Gatekeepers. (Cloudflare OS README)
Client lại chạy trong sandboxed iframe, được hạn chế network bằng CSP và iframe sandbox.
Kiến trúc trở thành:
1 Internet
2 ↑
3 X
4 │
5┌─────────────────────┐
6│ Gadget Sandbox │
7│ │
8│ AI-generated code │
9│ │
10└─────────┬───────────┘
11 │
12 │ capability
13 ↓
14 Gatekeeper
15 ↓
16 Allowed API
Đây là triết lý bảo mật quan trọng:
Đừng cố làm cho AI không bao giờ viết code nguy hiểm. Hãy xây runtime để code nguy hiểm không có quyền làm điều nguy hiểm.
7. Tại sao lại gọi nó là “OS”?
Tên Cloudflare OS nghe có vẻ marketing, nhưng Cloudflare đưa ra một phép ánh xạ khá thú vị:
1Traditional OS Cloudflare OS
2------------------------------------------------
3Kernel workshop-backend
4
5Device Driver gatekeeper-*
6
7Shell workshop-frontend
8
9Process Gadget
10
11Executable Blueprint
12
13User User
14
15Permissions Shared permissions
16
17??? AI Agent
Theo cách nhìn này:
1Cloudflare OS kernel
quản lý:
1User
2Agent
3Gadget
4Resource
5Permission
6Sandbox
7External service
Một hệ điều hành truyền thống quản lý:
1Process
2Memory
3File
4Device
5User
6Permission
Còn Cloudflare OS quản lý AI workload.
Điểm Cloudflare muốn nhấn mạnh là AI Agent không hoàn toàn giống user.
Agent:
1có identity
2+
3có permission riêng
4+
5hành động thay user
6+
7tự sinh code
8+
9tự thực thi code
Do đó:
1Agent != User
Agent phải chịu trách nhiệm dưới một user nhưng đồng thời phải có permission nhỏ hơn user đó.
Đây chính là lý do capability security trở nên quan trọng.
8. Kiến trúc bên dưới: Workers + Durable Objects + Dynamic Workers + Facets
Cloudflare OS không chỉ là một frontend React gọi LLM API.
Họ xây khá sâu trên Workers Runtime.
Kiến trúc sử dụng mạnh:
1Cloudflare Workers
2Durable Objects
3Dynamic Workers
4Facets
5Cap'n Web RPC
Cloudflare mô tả:
11 Workspace
2 ↓
31 Durable Object
4
51 Gadget
6 ↓
7Dynamic Worker Facet
8
9Gatekeeper
10 ↓
11Facet gắn vào Workspace
Durable Objects đặc biệt phù hợp cho những Gadget cần state và realtime collaboration.
Ví dụ:
1User A ─┐
2 │
3 ├──→ Gadget Durable Object
4 │
5User B ─┘
Hai người có thể cùng tương tác với ứng dụng theo thời gian thực.
Cloudflare cũng cho biết một số tính năng của Workers Runtime như Dynamic Workers và Facets được phát triển trong quá trình xây Cloudflare OS. Kiến trúc tham chiếu của Cloudflare cũng dùng Workers, Durable Objects, Dynamic Workers và sandbox để tách state, code execution và quyền truy cập công cụ. (Cloudflare OS README, Cloudflare Reference Architecture)
9. Code Mode: Agent dùng code như một universal tool
Agent trong Cloudflare OS sử dụng một kiến trúc Cloudflare gọi là Code Mode. Trong mô hình này, LLM viết một chương trình nhỏ để phối hợp nhiều công cụ thay vì gọi từng tool tuần tự qua nhiều vòng model. (Cloudflare Code Mode)
Thay vì bắt LLM lựa chọn từ hàng trăm tool:
1tool_1()
2tool_2()
3tool_3()
4...
5tool_300()
Agent có thể viết code để phối hợp API.
Conceptually:
1Agent
2 ↓
3generate code
4 ↓
5execute code
6 ↓
7call capabilities
8 ↓
9process result
Điều này đặc biệt hợp với Gadget.
Cloudflare yêu cầu frontend và backend của Gadget giao tiếp thông qua Cap’n Web RPC.
Do đó khi Gadget có:
1getOrders()
2getRevenue()
3updateTask()
thì API đó đồng thời khá dễ để agent sử dụng.
Kết quả là:
ứng dụng được AI tạo ra gần như mặc nhiên có một API thân thiện với AI.
Người dùng có thể vừa thao tác GUI:
1click
2drag
3type
vừa nói với agent:
1Lấy toàn bộ task overdue và chia lại theo team.
mà developer không phải viết thêm một MCP server riêng cho từng Gadget.
10. Cloudflare OS không bắt buộc dùng model của Cloudflare
Một chi tiết quan trọng đối với doanh nghiệp là phần agent không bị gắn cứng vào một LLM duy nhất.
README cho biết Cloudflare OS hỗ trợ nhiều model provider và cả self-hosted model. (Cloudflare OS README)
Do đó về concept hoàn toàn có thể có:
1Cloudflare OS
2 ↓
3Internal LLM Gateway
4 ↓
5Qwen / DeepSeek / Llama / model nội bộ
Trong doanh nghiệp, đây là một hướng rất hấp dẫn vì có thể tách:
1AI Runtime
2≠
3LLM Provider
Model chỉ đảm nhiệm intelligence.
Còn:
1permission
2sandbox
3tools
4audit
5workflow
6resource
7identity
được quản lý bởi một lớp khác.
11. Đây có thể là hướng tiến hóa tiếp theo của MCP
MCP giải quyết một bài toán rất quan trọng:
1LLM
2↕
3Tool
Nhưng để vận hành agent trong production, còn hàng loạt bài toán khác:
1Identity
2Permission
3Isolation
4Audit
5Approval
6Lifecycle
7State
8Collaboration
9Application Runtime
Cloudflare OS có thể được nhìn như một tầng nằm phía trên MCP:
1 User
2 │
3 ↓
4 ┌───────────────┐
5 │ Agent Runtime │
6 │ │
7 │ Cloudflare OS │
8 └───────┬───────┘
9 │
10 Capabilities
11 │
12 ┌───────▼───────┐
13 │ Gatekeepers │
14 └───────┬───────┘
15 │
16 MCP / APIs
17 │
18 ┌──────────┼──────────┐
19 ↓ ↓ ↓
20 GitHub Google Internal
21 Systems
MCP vẫn rất hữu ích.
Nhưng MCP không nhất thiết phải là toàn bộ security architecture.
12. Bài học quan trọng cho doanh nghiệp xây AI Agent
Điểm đáng học từ Cloudflare OS không nhất thiết là phải clone repository rồi triển khai nguyên hệ thống.
Quan trọng hơn là kiến trúc của nó cho thấy một agent enterprise có thể cần ít nhất bốn lớp.
Lớp 1 — Intelligence
1LLM
2Planner
3Reasoning
4Code Mode
Lớp 2 — Agent Runtime
1Agent lifecycle
2Context
3Memory
4Execution
5Task state
Lớp 3 — Capability & Guardrail
1Gatekeeper
2Permission
3Human approval
4Audit
5Resource scope
Lớp 4 — Sandbox
1Network isolation
2Code execution isolation
3Filesystem isolation
4Resource limits
Và bên dưới mới là:
1MCP
2API
3Database
4GitHub
5Slack
6ERP
7CRM
8DWH
Kiến trúc tổng quát:
1 USER
2 │
3 ↓
4 ┌───────────┐
5 │ Agent │
6 └─────┬─────┘
7 │
8 ↓
9 ┌─────────────────┐
10 │ Agent Runtime │
11 └───────┬─────────┘
12 │
13 ↓
14 ┌─────────────────┐
15 │ Capability Layer│
16 │ + Guardrails │
17 └───────┬─────────┘
18 │
19 ┌───────┴────────┐
20 ↓ ↓
21 Sandbox Gatekeeper
22 │
23 ↓
24 MCP / API
25 │
26 ┌──────────┼──────────┐
27 ↓ ↓ ↓
28 DB GitHub ERP
Đây có lẽ là một kiến trúc thực tế hơn nhiều so với:
1LLM → MCP → Database
Cloudflare OS báo hiệu một thay đổi lớn hơn
Trong thời kỳ SaaS, con người phải học cách sử dụng phần mềm.
1Human
2 ↓
3learn software
4 ↓
5use features
AI đang đảo ngược mối quan hệ đó:
1Human
2 ↓
3describe need
4 ↓
5AI modifies software
6 ↓
7software adapts to human
Nếu xu hướng này tiếp tục, chúng ta có thể bước vào một giai đoạn mà công ty không còn chỉ sở hữu:
1ERP
2CRM
3Office Suite
4BI
5Internal Tools
mà sở hữu một AI Operating Environment nằm phía trên tất cả chúng:
1 Company AI OS
2 │
3 ┌────────────────┼────────────────┐
4 ↓ ↓ ↓
5 Agent Gadget Workflow
6 │ │ │
7 └────────────────┼────────────────┘
8 ↓
9 Gatekeepers
10 ↓
11 Company systems & data
Nhân viên không nhất thiết phải tìm đúng phần mềm để giải quyết một vấn đề.
Họ chỉ cần nói:
1Tôi cần một công cụ để làm việc này.
Agent có thể tạo công cụ đó.
Nhưng khi AI có khả năng tự tạo phần mềm, tự viết code và tự thao tác dữ liệu, security không thể chỉ dựa vào system prompt.
Chúng ta cần:
1sandbox
2+
3capability
4+
5identity
6+
7audit
8+
9human approval
ở tầng hạ tầng.
Và có lẽ đây mới là ý tưởng quan trọng nhất mà Cloudflare OS đang thử nghiệm.
Cloudflare OS hiện vẫn được chính dự án xem là early access; phiên bản phát hành tháng 8/2026 là v2, một bản viết lại lớn dựa trên kinh nghiệm từ phiên bản đầu tiên. Vì vậy đây chưa phải thứ nên mặc nhiên coi là một nền tảng enterprise hoàn thiện. (Cloudflare OS README)
Nhưng về mặt kiến trúc, nó cho thấy một hướng đi rất đáng chú ý:
Tương lai của AI Agent có thể không chỉ cần model tốt hơn hay nhiều MCP hơn. Nó có thể cần một “hệ điều hành” thực sự để quản lý agent, code, quyền hạn và tài nguyên giống như hệ điều hành ngày nay quản lý process, memory và device.
Bình luận