Vé đến vào thứ ba. Trợ lý AI được kết nối với Jira, Confluence và Slack — nhóm năng suất tiêu chuẩn của doanh nghiệp. Người quản lý sản phẩm đã yêu cầu nó cung cấp "lịch sử sự cố trên dịch vụ thanh toán". Mô hình trả về một bản tóm tắt kỹ lưỡng: dòng thời gian, nguyên nhân cốt lõi, các yếu tố góp phần và một phần được lấy từ báo cáo khám nghiệm tử thi do một đơn vị kinh doanh khác viết chưa bao giờ được chia sẻ với nhóm sản phẩm.
Mọi lệnh gọi API đều thành công. Mọi kiểm tra quyền đều được thông qua. Mô hình đã có quyền truy cập vào Confluence. Khám nghiệm tử thi ở Confluence. Người dùng đã có một phiên hợp lệ. Không ai đã định nghĩa được cái gì
Vé đến vào thứ ba. Trợ lý AI được kết nối với Jira, Confluence và Slack — nhóm năng suất tiêu chuẩn của doanh nghiệp. Người quản lý sản phẩm đã yêu cầu nó cung cấp "lịch sử sự cố trên dịch vụ thanh toán". Mô hình trả về một bản tóm tắt kỹ lưỡng: dòng thời gian, nguyên nhân cốt lõi, các yếu tố góp phần và một phần được lấy từ báo cáo khám nghiệm tử thi do một đơn vị kinh doanh khác viết chưa bao giờ được chia sẻ với nhóm sản phẩm.
Mọi lệnh gọi API đều thành công. Mọi kiểm tra quyền đều được thông qua. Mô hình đã có quyền truy cập vào Confluence. Khám nghiệm tử thi ở Confluence. Người dùng đã có một phiên hợp lệ. Không ai xác định được "lịch sử sự cố của người dùng này trong bối cảnh quy trình công việc này" thực sự có nghĩa là gì.
Không ai để ý cho đến khi bản tóm tắt được dán vào một slide điều hành và ai đó trong phòng nhận ra nội dung mà họ không có ý định chia sẻ.
Đây là vấn đề về ủy quyền llm — và nó không được giải quyết bằng cách thắt chặt quyền API.
Thất bại là hành vi đúng đắn
Mô hình không gặp trục trặc. Nó đã thực hiện chính xác những gì nó được thiết kế để làm: tổng hợp thông tin liên quan trên các hệ thống được kết nối và tổng hợp phản hồi hữu ích. Việc tích hợp Jira đã trả lại các vé có liên quan. Việc tích hợp Confluence trả về các tài liệu liên quan. Tích hợp Slack trả về bối cảnh luồng có liên quan. Người mẫu đã tập hợp chúng thành một câu trả lời mạch lạc.
Thất bại là không ai xác định ranh giới ủy quyền cho quy trình làm việc - chỉ dành cho các lệnh gọi API riêng lẻ trong đó.
Sự khác biệt này quan trọng về mặt kiến trúc. Trong các hệ thống doanh nghiệp truyền thống, khi người dùng yêu cầu dữ liệu, yêu cầu đó sẽ nằm trong phạm vi cấp API: người dùng này có thể đọc những bản ghi này, những tài liệu này, những thông báo này. Hệ thống thực thi phạm vi đó ở mọi cuộc gọi. Ranh giới phạm vi là rõ ràng, được thực thi và có thể kiểm tra được.
Trong quy trình làm việc AI được kết nối với nhiều hệ thống doanh nghiệp, câu hỏi về phạm vi sẽ thay đổi. Người dùng có quyền. Mô hình có kết nối. Nhưng mô hình không hỏi "người dùng này dự định lấy gì?" - nó hỏi "điều gì liên quan đến việc trả lời câu hỏi này?" Hai câu hỏi đó trả về các tập kết quả khác nhau và khoảng cách giữa chúng là nơi ranh giới ủy quyền sụp đổ.
API xác thực danh tính. Bối cảnh tổng hợp của LLM.
Ủy quyền doanh nghiệp truyền thống hoạt động theo mô hình ba lớp mà hầu hết các kiến trúc sư đều hiểu ngầm:
Xác thực - bạn là ai? Xác thực danh tính, xác nhận phiên, kiểm tra thông tin đăng nhập.
Ủy quyền - bạn được phép làm gì? RBAC, ACL, thực thi chính sách. Đây là nơi mà hầu hết các khoản đầu tư bảo mật doanh nghiệp đều tồn tại.
Ủy quyền theo ngữ cảnh - bạn dự định làm gì trong quy trình làm việc cụ thể này? Lớp này không tồn tại trong hầu hết các kiến trúc xác thực doanh nghiệp vì các hệ thống truyền thống không cần đến nó. Truy vấn cơ sở dữ liệu trả về chính xác những gì bạn yêu cầu. Điểm cuối REST trả về một tài nguyên đã xác định. Phạm vi của phản hồi được xác định bởi yêu cầu.
LLM phá vỡ lớp thứ ba. Một mô hình được kết nối với mười hệ thống doanh nghiệp không truy xuất một tài nguyên — nó tổng hợp ngữ cảnh trên tất cả các hệ thống mà nó có quyền truy cập, được xếp hạng theo mức độ liên quan đến lời nhắc. Mục đích của người dùng ("cho tôi biết về lịch sử sự cố") trở thành phạm vi truy xuất của mô hình và phạm vi đó chỉ bị giới hạn bởi những gì mô hình có thể truy cập chứ không phải bởi những gì người dùng phải xem.
Kết quả: quy trình làm việc AI có thể đáp ứng mọi hoạt động kiểm tra ủy quyền cá nhân ở lớp API trong khi trả về phản hồi vi phạm mục đích của tổ chức đằng sau các chính sách đó. Mọi cuộc gọi đều được ủy quyền. Sự tổng hợp là không.
Sự sụp đổ ranh giới ủy quyền
Mẫu lỗi này có tên: Phá vỡ ranh giới ủy quyền - thời điểm quy trình làm việc AI kế thừa phạm vi truy cập rộng hơn mục đích của người dùng mà nó đang hành động.
Nó khác với lỗi cấp phép. Các quyền đã chính xác. Ranh giới giữa "nội dung người dùng này được phép truy cập" và "nội dung người dùng này dự định truy cập trong ngữ cảnh này" đơn giản là chưa được xác định — bởi vì cơ sở hạ tầng xác thực doanh nghiệp được xây dựng cho các yêu cầu có chủ đích, có phạm vi, không phải dành cho các hệ thống AI tổng hợp theo chiều ngang trên mọi thứ họ có thể tiếp cận.
Sự sụp đổ ranh giới ủy quyền xuất hiện theo các mô hình có thể dự đoán được trong quá trình triển khai AI của doanh nghiệp:
Một phi công phụ của doanh nghiệp được kết nối với các hệ thống nhân sự, tài chính và kỹ thuật sẽ trả về thông tin tiền lương khi được hỏi về việc lập kế hoạch số lượng nhân sự — vì các kết nối của mô hình bao gồm hệ thống nhân sự và "lập kế hoạch số lượng nhân viên" về mặt ngữ nghĩa liền kề với dữ liệu lương thưởng.
AI hỗ trợ với Slack và quyền truy cập bán vé sẽ đưa ra cuộc thảo luận leo thang nội bộ khi tóm tắt vấn đề của khách hàng - vì luồng nội bộ về khách hàng đó nằm trong phạm vi tích hợp Slack của mô hình.
Trợ lý nhà phát triển có quyền truy cập vào kho lưu trữ và tài liệu sẽ trả về thông tin chi tiết về kiến trúc bảo mật khi được hỏi về cách xử lý lỗi của dịch vụ — vì tài liệu về mô hình mối đe dọa nằm trong cùng không gian Confluence với sổ tay kỹ thuật.
Không ai trong số này là lỗi. Không ai trong số họ có thể bị đánh giá truy cập. Mọi sự cho phép của cá nhân đều hợp lệ. Ủy quyền quy trình công việc chưa bao giờ được xác định.
Giả định ẩn trong Enterprise Auth
Kiến trúc giả định mọi yêu cầu đều có chủ ý. Giả định này được đưa vào cách xác thực doanh nghiệp được thiết kế và thực thi và nó được duy trì tốt trong nhiều thập kỷ vì các hệ thống truyền thống không tạo ra bối cảnh bên cạnh — chúng đáp ứng các yêu cầu rõ ràng.
Người dùng truy vấn cơ sở dữ liệu: truy vấn xác định phạm vi. Người dùng gọi API: điểm cuối xác định tài nguyên. Yêu cầu và phản hồi có mối quan hệ ràng buộc trực tiếp mà chính sách ủy quyền có thể chi phối.
Quá trình xử lý trợ lý AI "cung cấp cho tôi bối cảnh về vấn đề của khách hàng này" không có yêu cầu giới hạn. Nó có một mục tiêu ngữ nghĩa mà nó sẽ đáp ứng bằng cách duyệt qua mọi hệ thống được kết nối mà nó có quyền truy cập. Mô hình này không biết rằng việc tích hợp Slack không được cho là sẽ hiển thị luồng báo cáo nội bộ. Nó biết rằng chủ đề này có liên quan. Liên quan
Nguồn tin: Dev.to AI — Tác giả: NTCTech. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.