MCP giúp tác tử AI tìm và gọi công cụ kết nối với API. Tuy nhiên, MCP không tự quyết định tác tử được xem dữ liệu nào hoặc thực hiện hành động nào. Doanh nghiệp vẫn cần một lớp kiểm soát riêng, chẳng hạn hợp đồng cấp trường bằng GraphQL. Lớp này giới hạn dữ liệu trả về và chỉ cho phép những thao tác nghiệp vụ đã được phê duyệt.
Hãy hình dung một nhân viên vận hành hỏi trợ lý AI: “Đơn hàng nào sẽ lỡ giờ chốt giao hôm nay? Hãy kiểm tra tồn kho tại các kho khác. Sau đó, hãy tạo yêu cầu điều chuyển ở những nơi có thể bù phần thiếu hụt.” Theo The New Stack, quy trình này đòi hỏi tác tử gọi API để đọc đơn hàng và lượng hàng hiện có. Tác tử sau đó ghi yêu cầu điều chuyển trở lại hệ thống hoàn tất đơn.
Báo cáo của ngày hôm qua không cho biết kho còn bao nhiêu hàng vào chiều nay. Tác tử cần dữ liệu hiện thời và quyền thực hiện một hành động cụ thể. Máy chủ MCP có thể đưa API quản lý đơn hàng nội bộ đến gần tác tử hơn, nhưng kết nối chỉ là bước đầu. Doanh nghiệp còn phải xác định tác tử được phép nhìn thấy và làm gì sau khi kết nối.
MCP mở đường vào hệ thống, không giới hạn nội dung dữ liệu
MCP chuẩn hóa cách tác tử tìm và gọi công cụ, nhưng không thay thế chính sách kiểm soát dữ liệu của doanh nghiệp. Nếu công cụ MCP chuyển nguyên phản hồi từ API nguồn cho tác tử, phản hồi đó có thể chứa nhiều trường nhạy cảm nằm ngoài phạm vi cần thiết cho nhiệm vụ.
API quản lý đơn hàng có thể trả về dữ liệu nhận dạng cá nhân, thông tin tài chính, dấu hiệu gian lận và dữ liệu vận hành vốn chỉ dành cho mạng nội bộ đáng tin cậy. Một tác tử kiểm tra thời hạn giao hàng không nhất thiết cần truy cập tất cả những trường này.
Ứng dụng truyền thống thường xử lý vấn đề ở phần phụ trợ. Hệ thống kiểm tra quyền của người dùng, gọi API nguồn rồi chỉ trả lại phần dữ liệu phù hợp. Với tác tử linh hoạt, nhóm kỹ thuật vẫn cần nguyên tắc đó, nhất là khi doanh nghiệp phải quyết định cách AI được phân quyền đối với dữ liệu và mô hình.
Lọc phản hồi trong từng công cụ MCP có vẻ trực tiếp, nhưng làm tăng gánh nặng bảo trì. Bộ phận tài chính cần một cách nhìn đơn hàng. Nhóm hỗ trợ cần một phần ghi chú nội bộ, còn nhóm khác có thể cần kết nối hệ thống tồn kho. Doanh nghiệp sẽ phải duy trì nhiều công cụ tương tự. Mỗi công cụ cũng phải loại bỏ đúng các trường nhạy cảm.
Hợp đồng cấp trường tách quyền truy cập khỏi công cụ
Hợp đồng cấp trường xác định từng tác tử được xem trường dữ liệu nào và được gọi thao tác nào. Lớp này hoạt động độc lập với API nguồn và tác tử. Nhờ đó, doanh nghiệp có thể áp dụng cùng một ranh giới quyền truy cập cho nhiều công cụ. Họ không phải lặp lại logic lọc dữ liệu trong từng công cụ MCP.
MCP và hợp đồng cấp trường giải quyết hai vấn đề khác nhau. MCP tạo kết nối và mô tả cách gọi công cụ. Lớp quyền cấp trường đặt ranh giới có thể kiểm tra nhất quán, thay vì trông chờ từng người viết công cụ nhớ xóa cùng một thuộc tính khỏi mọi phản hồi.
Ranh giới này liên quan trực tiếp đến câu hỏi AI nên được trao bao nhiêu quyền. Một tác tử chỉ đọc không thể hoàn thành yêu cầu điều chuyển tồn kho. Ngược lại, quyền ghi quá rộng có thể cho phép tác tử sửa số lượng hàng, hủy đơn hoặc hoàn tiền.
GraphQL cung cấp hợp đồng cấp trường
GraphQL cho phép mỗi lệnh gọi API nêu chính xác các trường cần lấy, đồng thời cung cấp một điểm thực thi chính sách cho từng trường. Tác tử có thể nhận trạng thái và thời hạn giao của một đơn hàng mà không nhận thêm dữ liệu nhận dạng, tài chính hoặc chống gian lận được lưu trong cùng hệ thống.
Với yêu cầu kiểm tra đơn hàng có mã order-1842, tác tử có thể chỉ yêu cầu trạng thái và thời hạn giao:
query {
order(id: "order-1842") {
status
shipBy
}
}Phản hồi khi đó chỉ chứa hai trường tương ứng, bất kể hệ thống nguồn còn lưu những dữ liệu nào khác. Ban đầu, cách tiếp cận này giúp thu gọn phản hồi API lớn trên mạng di động. Nó cũng giảm nhu cầu viết riêng một lớp phụ trợ cho từng giao diện. Khi bên gọi là tác tử, cùng cơ chế trở thành nơi thực thi quyền truy cập chi tiết.
Nếu tác tử yêu cầu một trường như internalFraudScore hoặc customerSSN, máy chủ GraphQL có thể chặn yêu cầu hoặc không cho phép truy cập trường đó. Quy tắc được gắn với trường dữ liệu và áp dụng cho mọi thao tác yêu cầu trường ấy. Người viết công cụ không phải tự loại bỏ cùng một thuộc tính ở nhiều nơi.
Quyền ghi cần gắn với hành động nghiệp vụ cụ thể
Quyền ghi của tác tử nên gắn với một hành động nghiệp vụ cụ thể, không phải quyền sửa rộng trên hệ thống. Trong quy trình xử lý đơn hàng, thao tác requestInventoryTransfer có thể cho phép tác tử gửi yêu cầu điều chuyển mà không cấp quyền trực tiếp sửa tồn kho, hủy đơn hoặc hoàn tiền.
Môi trường thực thi xác thực quyền gọi thao tác. Dịch vụ bên dưới tiếp tục kiểm tra lượng hàng hiện có và các bước phê duyệt bắt buộc trước khi chấp nhận yêu cầu. Cấu trúc này cho tác tử đủ quyền để hoàn thành công việc mà không mở quyền truy cập ngoài nhiệm vụ.
Cách giới hạn hành động đặc biệt quan trọng khi tác tử AI trở thành một lớp mới trong hạ tầng. Khả năng tự kết hợp nhiều thao tác trong lúc chạy có thể tăng hiệu quả, nhưng cũng làm cho quyền quá rộng trở nên nguy hiểm hơn.
Không cần thay thế các API đang vận hành
Doanh nghiệp có thể đặt một lớp GraphQL trước các dịch vụ hiện dùng REST, gRPC, SOAP hoặc giao thức khác. Cách này không đòi hỏi doanh nghiệp viết lại toàn bộ API. API quản lý đơn hàng vẫn trả bản ghi rộng cho lớp tích hợp. Tác tử chỉ nhận các trường và thao tác được hợp đồng cho phép.
Theo The New Stack, GraphQL đã cung cấp mô hình hợp đồng cấp trường cho ứng dụng trong hơn một thập kỷ. Công nghệ này hỗ trợ hàng tỷ giao dịch mỗi ngày tại Shopify, Netflix, Airbnb, Expedia Group và Walmart. Nguồn này cho rằng kinh nghiệm vận hành quanh GraphQL có thể được áp dụng để kiểm soát quyền truy cập của tác tử AI.
MCP giúp tác tử tiếp cận hệ thống doanh nghiệp. Hợp đồng cấp trường bằng GraphQL xác định dữ liệu nào được trả về và hành động nào được phép thực hiện. Khi đưa MCP vào hệ thống nội bộ, doanh nghiệp nên xác định các ranh giới đó trước khi mở thêm công cụ cho tác tử.
