MCP server là gì và cách cho AI Agent dùng phần mềm nội bộ an toàn

Phòng kinh doanh muốn AI Agent tra khách trong CRM, phòng kế toán muốn nó đối chiếu hóa đơn, còn bộ phận IT thì chưa dám đưa khoá API toàn quyền cho một chương trình tự quyết định lệnh gọi tiếp theo. MCP server là gì? Đó là một lớp trung gian đặt trước phần mềm nội bộ, nói chuyện với AI Agent theo chuẩn Model Context Protocol, chỉ hiện ra một danh sách công cụ hẹp và mỗi lần gọi đều qua xác thực, kiểm quyền, kiểm đầu vào, giới hạn tần suất và ghi log. Bài này giải thích MCP hoạt động ra sao, rồi đi qua bốn lớp kiểm soát (xác thực, phân quyền theo scope, giới hạn thao tác, ghi log) theo đặc tả bản 2026-07-28 và hướng dẫn bảo mật của chính dự án MCP. Mọi nguồn tra ngày 05/10/2026.

MCP server nằm ở đâu giữa AI Agent và phần mềm nội bộ

Trang giới thiệu chính thức mô tả MCP là chuẩn mã nguồn mở để kết nối ứng dụng AI với hệ thống bên ngoài, gồm nguồn dữ liệu, công cụ và quy trình mẫu. Dự án dùng hình ảnh cổng USB-C: một chuẩn cắm chung thay cho từng sợi dây riêng. Claude, ChatGPT, Visual Studio Code và Cursor nằm trong danh sách ứng dụng đã hỗ trợ.

Có ba vai trò. Ứng dụng AI (host) chứa AI Agent. Máy khách MCP (client) nằm trong host và giữ kết nối tới từng server. MCP server là chương trình doanh nghiệp tự viết hoặc cài, đứng trước CRM, ERP, cơ sở dữ liệu hay API thanh toán. Agent không biết gì về cơ sở dữ liệu phía sau, nó chỉ thấy danh sách công cụ server công bố, mỗi công cụ có tên, mô tả và lược đồ tham số.

Giao thức dùng JSON-RPC. Client gọi tools/list để xem server có những công cụ nào, rồi gọi tools/call kèm tên công cụ và tham số để chạy. Với một CRM nội bộ, hai thông điệp đó trông như sau (ví dụ minh hoạ, tên công cụ do server tự đặt):

// tools/list: server công bố công cụ
{
  "name": "crm_tim_khach",
  "description": "Tìm khách hàng theo số điện thoại hoặc mã khách. Chỉ đọc.",
  "inputSchema": {
    "type": "object",
    "properties": { "so_dien_thoai": { "type": "string" } },
    "required": ["so_dien_thoai"],
    "additionalProperties": false
  }
}

// tools/call: agent gọi công cụ
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "crm_tim_khach",
              "arguments": { "so_dien_thoai": "0900000000" } } }

Danh sách này là hàng rào đầu tiên. Công cụ không có trong danh sách thì agent không gọi được, dù mô hình ngôn ngữ có bị lừa viết ra lệnh gì. Doanh nghiệp vì vậy kiểm soát được bề mặt tiếp xúc bằng cách sửa một danh sách, không phải rà lại từng prompt. Đặc tả cũng cho phép server trả danh sách khác nhau tuỳ quyền trình trên từng request, ví dụ chỉ hiện công cụ mà scope đã cấp cho phép dùng.

Vì sao không nên đưa khoá API toàn quyền cho agent

OWASP gọi lỗi này là Excessive Agency (mục LLM06:2025) và chia thành ba nguyên nhân: công cụ có quá nhiều chức năng, kết nối có quá nhiều quyền, và hành động nặng chạy không qua xác nhận. Ví dụ OWASP đưa ra rất đời thường: một công cụ đọc email nhưng kèm cả hàm gửi và xoá, hay kết nối cơ sở dữ liệu có quyền UPDATE và DELETE trong khi việc chỉ cần SELECT. MCP server là chỗ đặt các biện pháp giảm ba nguyên nhân đó vào một nơi duy nhất.

Xác thực: ai được nói chuyện với MCP server

Theo đặc tả ủy quyền của MCP bản 2026-07-28, phần xác thực là tuỳ chọn trong giao thức, nhưng với kết nối qua HTTP thì đặc tả khuyến nghị làm theo, còn kết nối stdio (chạy ngay trên máy) thì lấy thông tin xác thực từ biến môi trường. Server nội bộ truy cập qua mạng thì coi như bắt buộc, vì không có xác thực nghĩa là ai trong mạng cũng gọi được các công cụ đó.

Cơ chế dựa trên OAuth 2.1. MCP server đóng vai máy chủ tài nguyên: nhận yêu cầu, kiểm access token. Khi chưa có token, server trả HTTP 401 kèm header WWW-Authenticate chỉ cho client nơi lấy thông tin về máy chủ cấp quyền. Bốn yêu cầu đặc tả ghi rõ ở mức MUST đáng đưa vào hợp đồng với bên viết server:

1. Token phải được cấp riêng cho server này (kiểm audience theo RFC 8707). Client gửi tham số resource khi xin token, server từ chối token cấp cho dịch vụ khác.
2. Server không được nhận hay chuyển tiếp token nào khác. Nếu server gọi tiếp API phía sau thì dùng token riêng của nó, không đẩy nguyên token của client xuống.
3. Token nằm trong header Authorization: Bearer của mỗi request, không bao giờ nằm trong query string của URL.
4. Client dùng PKCE trong luồng cấp mã, còn máy chủ cấp quyền kiểm redirect URI khớp chính xác với giá trị client đã đăng ký.

Đặc tả còn khuyến nghị máy chủ cấp quyền phát token sống ngắn để giảm thiệt hại khi lộ. Về đăng ký client, bản 2026-07-28 đưa Client ID Metadata Documents lên làm cách ưu tiên, còn Dynamic Client Registration được đánh dấu là deprecated và giữ lại để tương thích ngược.

Phân quyền: cấp scope vừa đủ cho từng công cụ

Xác thực cho biết ai đang gọi, phân quyền quyết định người đó gọi được gì. Hướng dẫn Security Best Practices của MCP yêu cầu mô hình scope tối thiểu và tăng dần: bắt đầu với scope đọc rủi ro thấp, chỉ nâng khi agent thật sự thử một thao tác nhạy cảm. Khi token thiếu quyền, server trả HTTP 403 kèm lỗi insufficient_scope và nói rõ scope cần thiết, client xin lại token với scope mới (luồng step-up). Ví dụ lấy theo mẫu trong đặc tả:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                  scope="crm:notes:write",
                  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                  error_description="Cần quyền ghi chú để thực hiện thao tác này"

Bảng dưới là một cách chia scope cho MCP server của CRM, ví dụ minh hoạ để nhóm kỹ thuật đối chiếu với hệ thống của mình.

Hướng dẫn bảo mật cũng liệt kê những lỗi hay gặp khi thiết kế scope, và cả bốn lỗi đều xuất phát từ ý muốn đỡ phiền người dùng lúc cấp quyền: công bố toàn bộ scope trong scopes_supported, dùng scope ký tự đại diện như * hoặc all, gom quyền không liên quan vào một scope cho đỡ hỏi lại, và coi scope ghi trong token là đủ mà không kiểm quyền ở phía server. Mỗi lần nâng scope, server ghi log kèm mã tương quan để sau này dựng lại ai đã được cấp quyền gì. Việc này tốn rất ít công lúc viết, nhưng lúc điều tra sự cố nó là nguồn duy nhất cho biết một agent đã có quyền ghi từ khi nào.

Giới hạn thao tác: công cụ hẹp, đầu vào bị kiểm, tần suất bị chặn

Đặc tả của công cụ MCP ghi bốn việc server phải làm: kiểm mọi đầu vào của công cụ, có kiểm soát truy cập đúng nghĩa, giới hạn tần suất gọi và làm sạch đầu ra. Kèm theo là các khuyến nghị cho client: hỏi xác nhận với thao tác nhạy cảm, cho người dùng thấy tham số trước khi gửi, đặt timeout cho mỗi lệnh gọi. Đặc tả còn dặn client coi chú thích (annotations) của công cụ là không đáng tin, trừ khi chúng đến từ server đã được tin cậy.

Chuyển thành việc cụ thể cho nhóm viết server, có năm điều:

• Mỗi công cụ làm một việc. Hàm crm_them_ghi_chu chỉ thêm ghi chú, không có công cụ chạy SQL tự do hay lệnh shell, đúng với khuyến nghị của OWASP là thay công cụ mở bằng các hàm có mục đích rõ.
• Lược đồ đầu vào chặt, đặt additionalProperties: false để tham số lạ bị từ chối ngay.
• Kiểm quyền lại ở server cho từng bản ghi, không tin việc client đã kiểm. Ví dụ nhân viên chỉ xem khách thuộc chi nhánh mình.
• Giới hạn tần suất riêng cho công cụ xuất dữ liệu, thấp hơn nhiều so với công cụ tra cứu.
• Nội dung trả về được xem là dữ liệu, không phải chỉ dẫn. Ghi chú khách hàng chứa câu “bỏ qua mọi quy tắc trước” vẫn chỉ là chuỗi ký tự trong kết quả.

Một khung kiểm tối thiểu cho mỗi lệnh gọi, viết dưới dạng mã giả để nhóm kỹ thuật hình dung:

def goi_cong_cu(token, ten, tham_so):
    nguoi_dung = xac_thuc(token, audience="https://mcp.congty.vn")   # từ chối nếu sai audience
    cong_cu = DANH_SACH[ten]                                          # không có thì lỗi
    if cong_cu.scope not in nguoi_dung.scopes:
        return loi_403_insufficient_scope(cong_cu.scope)
    kiem_luoc_do(cong_cu.input_schema, tham_so)                       # additionalProperties=false
    chan_neu_vuot_gioi_han(nguoi_dung, ten)
    ket_qua = cong_cu.chay(tham_so, quyen_cua=nguoi_dung)             # quyền của người gọi, không phải tài khoản dịch vụ
    ghi_log(nguoi_dung, ten, tham_so, ket_qua)
    return lam_sach(ket_qua)

Ghi log để dựng lại ai đã làm gì

Đặc tả khuyến nghị phía client ghi log việc dùng công cụ để phục vụ kiểm toán, còn hướng dẫn bảo mật chỉ ra vì sao server cần log của riêng mình: khi server chuyển tiếp token của client xuống API phía sau, log của API đó chỉ thấy một danh tính khác, điều tra sự cố trở nên khó. Server tự ghi đủ năm nhóm thông tin sau.

Những kiểu tấn công vào MCP mà đặc tả đã nêu tên

Hướng dẫn bảo mật của dự án MCP mô tả nhiều kiểu tấn công, mỗi kiểu kèm cách chặn. Các kiểu liên quan nhất tới server nội bộ gồm: token passthrough (server nhận token sai audience rồi chuyển xuống), confused deputy (server làm proxy tới API bên thứ ba bằng một client ID tĩnh nên bị lợi dụng bỏ qua bước đồng ý của người dùng), SSRF (client bị dụ truy cập địa chỉ nội bộ như 169.254.169.254 để lấy khoá đám mây), chiếm tay cầm trạng thái (đoán mã giỏ hàng hay mã phiên làm việc của người khác) và máy chủ MCP chạy trên máy cá nhân mang mã độc.

Hướng dẫn nêu cách giảm tương ứng: chỉ nhận token cấp cho chính server, hỏi đồng ý riêng cho từng client, chặn dải IP nội bộ và đặt proxy chặn đầu ra, sinh mã bằng bộ sinh ngẫu nhiên an toàn và gắn mã với người dùng đã xác thực, chạy server cục bộ trong sandbox. Bản 2026-07-28 cũng nêu rằng MCP không còn phiên làm việc ở tầng giao thức, nên máy chủ cần tự kiểm quyền với mọi request và không coi việc cầm được một mã là bằng chứng danh tính.

Danh sách kiểm trước khi mở MCP server cho agent dùng

1. Kết nối qua HTTPS, có OAuth 2.1, token kiểm đúng audience.
2. Không nhận và không chuyển tiếp token của bên khác.
3. Mỗi công cụ có scope riêng, scope mặc định chỉ là quyền đọc.
4. Không có công cụ chạy SQL, shell hoặc truy cập tệp tuỳ ý.
5. Mọi tham số đi qua lược đồ chặt, ghi chú khách hàng và nội dung ngoài chỉ được xử lý như dữ liệu.
6. Giới hạn tần suất khác nhau cho công cụ đọc và công cụ xuất dữ liệu.
7. Thao tác ghi quan trọng có bước xác nhận do hệ thống bắt buộc.
8. Log đủ năm nhóm trường ở bảng trên, giữ theo chính sách lưu trữ của doanh nghiệp.
9. Có quy trình thu hồi scope hoặc gỡ công cụ trong vài phút khi phát hiện bất thường.
10. Đã qua kiểm tra bảo mật theo OWASP trước khi nghiệm thu, xem chín cửa kiểm tra bảo mật MONA tổng hợp.

MONA hỗ trợ viết và vận hành MCP server thế nào

MCP server là một phần mềm bình thường, cũng cần thiết kế, kiểm thử và vận hành như CRM hay ERP. MONA viết phần mềm theo yêu cầu, trong đó có lớp tích hợp để AI Agent dùng được CRM, hệ thống ERP và các phần mềm nội bộ khác của doanh nghiệp, xem thêm tại trang viết phần mềm cho doanh nghiệp. Với phần xác nhận thanh toán, bài API ngân hàng cho phần mềm bán hàng mô tả luồng nhận tiền tự động mà agent đối soát thường dựa vào, và MONA Pay là dịch vụ báo có chuyển khoản theo thời gian thực cho luồng đó. MONA Mail, API gửi email giao dịch, có sẵn MCP cho AI agent. MONA Cloud và MONA Base dùng chung MONA Pass và monacloud-mcp; MONA Cloud chạy ứng dụng, MONA Base cung cấp Postgres, Auth và Storage trên hạ tầng Việt Nam, đủ để đặt một MCP server cùng cơ sở dữ liệu của nó.

Doanh nghiệp đang có phần mềm nội bộ và muốn agent dùng được mà chưa muốn mở cổng API toàn quyền, gọi hotline 1900 636 648. MONA đọc hệ thống hiện có, đề xuất danh sách công cụ và scope theo đúng bảng ở trên, rồi báo giá phần viết MCP server.

Hỏi đáp

MCP khác API thông thường ở điểm nào?

API mô tả các endpoint cho lập trình viên đọc tài liệu rồi viết code gọi. MCP chuẩn hoá cách một ứng dụng AI tự khám phá công cụ qua tools/list và tự gọi qua tools/call, kèm lược đồ tham số để mô hình biết phải điền gì. Bên dưới, MCP server vẫn gọi các API thường để làm việc thật. Hai thứ nằm ở hai tầng khác nhau: API phục vụ lập trình viên viết code, MCP phục vụ ứng dụng AI tự tìm và dùng công cụ lúc chạy. Doanh nghiệp đã có API sẵn thì viết MCP server như một lớp mỏng bọc phía trước, không phải làm lại hệ thống.

Có bắt buộc dùng OAuth cho MCP server không?

Đặc tả ghi phần ủy quyền là tuỳ chọn, và kết nối stdio chạy cục bộ thì lấy thông tin xác thực từ môi trường. Với server truy cập qua HTTP từ nhiều máy, đặc tả khuyến nghị làm theo OAuth 2.1, còn dữ liệu doanh nghiệp thì không để ở trạng thái mở không xác thực. Ngay cả server chỉ chạy trong mạng nội bộ cũng cần xác thực, vì nhiều agent và nhiều người dùng cùng gọi vào một cổng.

Agent đọc nhầm một ghi chú độc hại trong CRM thì sao?

Nội dung ghi chú đi vào ngữ cảnh của mô hình và có thể chứa câu lệnh giả. Phần giữ an toàn nằm ở phía server: công cụ hẹp, scope tối thiểu, bước xác nhận cho thao tác ghi và xuất dữ liệu, giới hạn tần suất. Khi các lớp đó đủ, một câu lệnh giả cùng lắm cũng chỉ gọi được những công cụ mà người dùng đó đã được cấp. Thiệt hại tối đa vì thế bị chặn ở thiết kế, không phụ thuộc vào việc mô hình có nhận ra câu lệnh giả hay không. OWASP cũng đặt quyền tối thiểu và bước xác nhận cho hành động tác động cao ngay trong danh sách biện pháp của mục Excessive Agency.

MCP server nên chạy trên máy cá nhân hay trên máy chủ chung của doanh nghiệp?

Hướng dẫn bảo mật coi server chạy trên máy cá nhân là một nguồn rủi ro riêng, vì nó có cùng quyền với client và có thể bị cài mã độc qua lệnh khởi động. Dữ liệu doanh nghiệp đi qua server đặt trên hạ tầng do doanh nghiệp quản lý, có xác thực và log tập trung, là cách đỡ rủi ro hơn.

Bản đặc tả MCP đổi liên tục, viết xong có phải sửa lại không?

Đặc tả có đánh phiên bản theo ngày, và bản 2026-07-28 đã đổi một số điểm so với bản 2025-06-18, ví dụ việc đăng ký client. Các ý chính của bài này (tools/list, tools/call, kiểm audience, scope tối thiểu, ghi log) có mặt ở cả hai bản. Vì vậy phần thiết kế công cụ và phân quyền ở trên không phải làm lại, chỉ cập nhật lớp xác thực và định dạng thông điệp khi nâng phiên bản. Bản 2026-07-28 còn yêu cầu mỗi request mang thêm các trường _meta, nên thư viện MCP chính thức đã hỗ trợ phiên bản mới là điều cần kiểm tra trước khi nâng.

Đọc thêm

• AI Agent là gì và doanh nghiệp nên giao việc nào cho AI Agent
• Từ vibe coding lên hệ thống chạy thật: việc phải làm trước khi mở cho khách