Middleware hay Sidecar: Cách nào tốt nhất để quản trị AI Agents?

Trong những năm gần đây, tôi đã dành thời gian xây dựng các lớp quản trị (governance layers) như schema registries cho Kafka, các chính sách cho Kong, hay xác thực hợp đồng cho các hệ thống hướng sự kiện. Nhiệm vụ luôn giống nhau: ngồi giữa các thành phần, thực thi các quy tắc và lưu lại vết dấu (trace).

Khi tôi bắt đầu chạy nhiều AI Agents khác nhau (Claude Code, Cursor, các bot LangChain tùy chỉnh), tôi nhận thấy một khoảng trống tương tự như trước đây. Mỗi agent đều có mô hình quyền hạn riêng. Không agent nào nói chuyện với agent nào. Không có chính sách chung. Không có truy vết thống nhất. Nghe có quen không? Nó giống hệt thời kỳ đầu của microservices vào năm 2018, trước khi service meshes trở nên phổ biến.

Vì vậy, tôi đã xây dựng agent-mesh để phục vụ nhu cầu của mình, một sidecar proxy cho các lệnh gọi công cụ (tool calls) của agent. Chính sách YAML, truy vết tập trung, danh tính cho từng agent. Một tệp nhị phân Go duy nhất, hoạt động với bất kỳ thứ gì sử dụng MCP hoặc HTTP.

Gần đây, Microsoft đã ra mắt Agent Governance Toolkit (AGT). Mã nguồn mở, giấy phép MIT. Giải quyết cùng một vấn đề nhưng với kiến trúc khác.

Đây là lúc đáng để so sánh hai cách tiếp cận một cách nghiêm túc, đặc biệt là khi OWASP vừa cung cấp cho chúng ta một từ vựng chung về những gì thực sự là "bảo mật agent".

Hai cách tiếp cận

Microsoft AGT là một middleware. Nó chạy bên trong tiến trình của agent với các callback Python cho LangChain, decorator cho CrewAI và plugin cho ADK. Kiểm tra chính sách mất dưới một mili-giây. Tích hợp sâu. Bạn chỉ cần thêm vài dòng code và agent của bạn được quản trị.

agent-mesh là một sidecar proxy. Nó chạy bên cạnh các agent của bạn. Nó đơn giản là chặn các lệnh gọi công cụ ở cấp độ MCP/HTTP. Không cần thay đổi code. Agent của bạn sẽ trỏ đến agent-mesh thay vì backend thực. agent-mesh kiểm tra chính sách, ghi log truy vết, chuyển tiếp hoặc từ chối.

# config.yaml — ví dụ về quản trị trong agent-mesh. Một file YAML nữa!
policies:
  - name: claude
    agent: "claude"
    rules:
      - tools: ["filesystem.read_*", "filesystem.list_*"]
        action: allow
      - tools: ["filesystem.write_file"]
        action: human_approval
      - tools: ["filesystem.move_file"]
        action: deny

  - name: default
    agent: "*"
    rules:
      - tools: ["*"]
        action: deny    # từ chối mặc định (fail closed)

# tích hợp vào Claude Code — một lệnh duy nhất, không thay đổi code
claude mcp add agent-mesh -- ./agent-mesh --mcp --config config.yaml

Nếu bạn đã từng làm việc với API gateways, bạn sẽ nhận ra mẫu này. Microsoft AGT giống như middleware của Express. agent-mesh tương tự như Envoy.

Cách tiếp cận nào tốt hơn?

Tất nhiên là không có cái nào tốt hơn tuyệt đối!

Middleware:

• Bạn sở hữu code của agent.
• Bạn "đặt hết trứng vào một giỏ" với một framework duy nhất (LangChain, CrewAI, Semantic Kernel).
• Bạn muốn độ trễ dưới một mili-giây.
• Agent của bạn viết bằng Python hoặc .NET.

Sidecar:

• Bạn chạy các agent hỗn hợp (công cụ CLI + framework + bot tùy chỉnh).
• Bạn không thể hoặc không muốn sửa đổi code của agent.
• Bạn muốn một chính sách YAML duy nhất cho mọi agent.
• Agent của bạn là Claude Code, Cursor, Gemini CLI, hoặc bất kỳ thứ gì gốc MCP.

Điểm cuối cùng rất quan trọng. Claude Code, Cursor, Gemini CLI, Cline, OpenCode — không cái nào trong số này cung cấp hook callback Python. Microsoft AGT không thể quản trị chúng. Một sidecar proxy thì có thể, vì nó hoạt động ở cấp độ giao thức.

Vậy còn Openclaw, LangChain và CrewAI thì sao?

OpenClaw hoạt động ở một lớp khác. Nó là một agent gateway tập trung vào việc cung cấp agent cho người dùng cuối thông qua các nền tảng nhắn tin (Telegram, Slack, Discord). Nó có chế độ cho phép/từ chối ở cấp công cụ và chế độ hỏi, nhưng không có chính sách ngữ nghĩa về các tham số hành động hay quản trị đa agent. Nó bổ trợ: OpenClaw định tuyến agent đến người dùng, agent-mesh quản trị những gì agent đó có thể làm.

LangChain có LangSmith Fleet: danh tính agent, quyền hạn, sandbox. Các tính năng thực sự. Nhưng chỉ giới hạn trong LangChain. Nếu bạn cũng chạy Claude Code và một agent HTTP tùy chỉnh, LangSmith sẽ không nhìn thấy chúng.

CrewAI có task guardrails (hàng rào nhiệm vụ), nghĩa là xác thực sau khi agent tạo ra kết quả. Đó là kiểm soát chất lượng, không phải quản trị. Bạn không thể chặn một hành động nguy hiểm trước khi nó xảy ra.

Cả hai đều không cung cấp chính sách dưới dạng mã (policy-as-code) đa agent.

Vậy còn Kong, Gravitee, Apigee thì sao?

Đây là các AI gateway và hoạt động ở một lớp khác. Chúng quản lý lưu lượng Bắc - Nam (north-south traffic) giữa ứng dụng của bạn và các LLM. Giới hạn tốc độ, ẩn dữ liệu PII, định tuyến ngữ nghĩa, trừu tượng hóa mô hình. Những thứ quan trọng, nhưng không phải là cùng một vấn đề.

Chúng không biết agent nào đã thực hiện lệnh gọi, không thực thi chính sách ở cấp độ hành động (cho phép create_issue, từ chối delete_repo), và không phân biệt quyền hạn theo danh tính agent.

Gateway và governance mesh bổ trợ cho nhau. Bạn có thể chạy Gravitee ở phía trước để định tuyến LLM và agent-mesh ở phía sau để quản trị các lệnh gọi công cụ. Các lớp khác nhau, công việc khác nhau.

Agent CLI / Framework
      │
  AI Gateway (Kong/Gravitee/Apigee) ← LLM routing, PII, giới hạn token
      │
  Governance Mesh (agent-mesh) ← chính sách ngữ nghĩa, danh tính agent, trace
      │
  Tools (GitHub, DB, APIs)

Ánh xạ theo OWASP Agentic Top 10

OWASP đã công bố Top 10 cho Ứng dụng Agentic, nỗ lực nghiêm túc đầu tiên để phân loại những gì có thể sai sót khi AI agents hoạt động trong thế giới thực. Nó được xem xét bởi hơn 100 nhà nghiên cứu bảo mật. Nếu bạn xây dựng hoặc vận hành agent, bạn nên đọc nó.

Dưới đây là cách bối cảnh hiện tại tương ứng với nó:

OWASP Risk	Ý nghĩa	Ai giải quyết
ASI01 — Goal Hijacking	Đầu đầu độc hại chuyển hướng mục tiêu agent	Phòng thủ ở cấp độ Prompt (không công cụ nào dưới đây giải quyết)
ASI02 — Tool Misuse	Agent sử dụng công cụ sai cách hoặc nguy hiểm	agent-mesh (chính sách ngữ nghĩa trên tham số), Microsoft AGT (chặn hành động)
ASI03 — Identity & Privilege Abuse	Agent lạm dụng token, vai trò, phiên làm việc	agent-mesh (danh tính từng agent, cấp phép tạm thời), Microsoft AGT (zero-trust Ed25519)
ASI04 — Delegated Trust	Sự tin tưởng mù quáng giữa các agent	agent-mesh (policy-as-code giữa các agent), Microsoft AGT (chấm điểm tin cậy)
ASI05 — Uncontrolled Autonomy	Các quyết định quan trọng không có xác thực của con người	agent-mesh (quy trình phê duyệt của con người), công cụ CLI (lời nhắc phê duyệt)
ASI06 — Memory Poisoning	Bộ nhớ persist bị đầu độc dữ liệu độc hại	Không được giải quyết trực tiếp bởi các lớp quản trị, cần sandbox runtime
ASI07 — Multi-Agent Comms	Truyền thông liên agent không được bảo mật	agent-mesh (xác thực JWT trên sidecar), Microsoft AGT (thành phần Agent Mesh)
ASI08 — Cascading Failures	Một agent thất bại kích hoạt phản ứng dây chuyền	agent-mesh (giới hạn tốc độ, phát hiện vòng lặp), gateway (circuit breaking)
ASI09 — Emergent Behavior	Agent phát triển hành vi không lường trước được	Khả năng quan sát + traces (LangSmith, agent-mesh traces, Microsoft AGT audit)
ASI10 — Rogue Agents	Agent bị xâm phạm lệch khỏi hành vi dự kiến	agent-mesh (thực thi chính sách, từ chối mặc định), Microsoft AGT (chấm điểm tin cậy)

Một vài điều nổi bật:

Không có công cụ nào bao phủ mọi thứ. ASI01 (goal hijacking) là vấn đề ở cấp độ prompt. Không proxy hay middleware nào có thể sửa chữa nó. ASI06 (memory poisoning) cần sự cô lập runtime, không phải chính sách.

Sự phân chia giữa middleware và sidecar thể hiện rõ ràng. Microsoft AGT và agent-mesh bao phủ khoảng cùng các rủi ro (ASI02-05, ASI07-08, ASI10), nhưng từ các vị trí khác nhau trong stack. Microsoft chặn bên trong tiến trình. agent-mesh chặn ở ranh giới giao thức. Phạm vi bao phủ giống nhau, nhưng phạm vi ảnh hưởng (blast radius) khác nhau nếu chính bản thân lớp quản trị bị xâm phạm.

Các Gateway (Kong, Gravitee, Apigee) hầu như không bao phủ điều này. Chúng không được thiết kế cho việc đó. Chúng quản lý lưu lượng LLM, không phải hành vi của agent. Điều đó ổn, đó là một lớp khác. Nhưng nếu ai đó nói với bạn rằng AI gateway của họ xử lý bảo mật agentic, hãy kiểm tra xem nó thực sự giải quyết những ASI nào.

Câu hỏi thực sự

Hệ sinh thái agentic đang chia tách thành hai mô hình quản trị:

Framework-level: Nhanh, tích hợp chặt chẽ, nhưng bạn bị khóa vào framework đó.

Protocol-level: Hoạt động với mọi thứ, không cần thay đổi code, nhưng thêm một bước nhảy mạng (network hop) phụ.

Tôi đặt cược rằng protocol-level sẽ thắng trong dài hạn. Cùng một cách mà Envoy đã thắng so với các circuit breaker đặc thù cho từng framework, vì trong thực tế, không ai chỉ chạy một framework duy nhất. Bạn sẽ có Claude Code để viết code, một pipeline LangChain cho dữ liệu, một agent tùy chỉnh cho vận hành. Bạn cần một lớp chính sách nhìn thấy tất cả chúng.

Nhưng có lẽ tôi có thiên kiến. Tôi đã xây dựng sidecar và làm việc trong môi trường đa framework.

Bài viết này được thực hiện với sự hỗ trợ của AI (Claude Opus 4.6) cho nghiên cứu và cấu trúc. Phân tích, so sánh kiến trúc và ý kiến dựa trên kinh nghiệm riêng của tôi khi xây dựng các lớp quản trị cho Kafka, Kong và agent-mesh.

agent-mesh là mã nguồn mở, viết bằng Go. Một tệp nhị phân, một cấu hình YAML. Hoạt động với bất kỳ agent nào nói chuyện MCP hoặc HTTP.