Authorization trong các ứng dụng LLM

• Mô hình ngôn ngữ lớn (LLM) là các hệ thống khó dự đoán xử lý đầu vào không chắc chắn từ người dùng, vì vậy việc áp dụng nguyên tắc đặc quyền tối thiểu (least privilege) là bắt buộc
• Khi LLM trên thực tế được dùng cho nhiều tác vụ như tìm kiếm nội bộ và tự động hóa, cần bảo đảm chúng chỉ hoạt động trong "quyền hiệu lực (effective permissions)" được cấp ở mức tối thiểu cần thiết để ngăn sự cố bảo mật và việc lạm dụng
• Trong kiến trúc RAG (retrieval-augmented generation), cần tách phần embedding dữ liệu và kiểm tra quyền khỏi nguồn dữ liệu, đồng thời cần kiểm soát quyền chi tiết ở cấp tài nguyên
• Càng gia tăng các cách sử dụng phức tạp như dữ liệu/RAG bên thứ ba, Agent, MCP..., thì vị trí và cách áp dụng quyền trên thực tế càng trở thành vấn đề cốt lõi của bảo mật
• Xác thực dựa trên token như OAuth có giới hạn trong việc kiểm soát quyền chi tiết theo đơn vị tài nguyên, vì vậy logic phân quyền thực tế phải được triển khai trực tiếp ở tầng ứng dụng

---

Thuật ngữ và khái niệm cơ bản

• Prompt: yêu cầu của người dùng gửi tới LLM (mệnh lệnh, câu hỏi, v.v.)
• RAG (Retrieval-Augmented Generation): workflow gắn thêm dữ liệu vào prompt để tăng độ chính xác của phản hồi từ LLM (ví dụ: tự động đính kèm danh sách ngày nghỉ của công ty)
• Context: dữ liệu bổ trợ được đính kèm vào prompt (như tài liệu liên quan được truy xuất)
• Embedding: biểu diễn vector số hóa của văn bản, được dùng cho tìm kiếm/đối sánh dữ liệu
• Agent: engine thực thi dựa trên LLM thực hiện hành động theo prompt (như tự động gọi công cụ)
• Tool: chức năng bên ngoài như API/ứng dụng mà LLM có thể gọi trực tiếp
• Model Context Protocol (MCP): giao thức chuẩn do Anthropic đề xuất cho việc truy cập tool của LLM

Nguyên tắc cốt lõi của mô hình phân quyền cho LLM

• Golden Rule:
  > LLM chỉ được phép hoạt động với mức quyền tối thiểu thật sự cần thiết để xử lý yêu cầu của người dùng
• Với người dùng thật, việc "thừa quyền theo thói quen" đôi phần còn có thể chấp nhận, nhưng LLM thì khó dự đoán, nhanh và khi sai sót có thể gây thiệt hại trên diện rộng.
  → "Quyền hiệu lực (effective permissions)" của LLM phải bị giới hạn trong giao của quyền người dùng, quyền LLM và quyền của tác vụ

Cách tính quyền hiệu lực (effective permissions)

• Quyền hiệu lực của ứng dụng LLM =
  1. quyền mà LLM có
  2. quyền mà người dùng có
  3. quyền cần thiết cho tác vụ được yêu cầu
     Giao của cả ba yếu tố này
• Người dùng "ủy quyền thay mặt (impersonation)" vai trò của mình cho LLM (như chatbot),
  nhưng không được vượt quá phạm vi quyền mà cả LLM và người dùng đang có
• Giải thích trực quan bằng sơ đồ Venn về quyền
  • Chỉ cho phép thực thi khi quyền của tác vụ được bao trọn trong phần giao

RAG (retrieval-augmented generation) và xử lý quyền

1. RAG dữ liệu 1st Party (nội bộ)

• Ví dụ: chatbot nội bộ tìm trong mã nguồn công ty các “tệp có chứa khóa bí mật”
• Embedding: chuyển mọi tệp thành vector và lưu vào DB, prompt cũng được chuyển thành vector để đối sánh theo độ tương đồng
• Vị trí áp dụng quyền:
  • Kiểm tra ngay tổ chức sở hữu thực tế, loại, repository và quyền của người dùng đối với “tệp” được trả về từ kết quả tìm kiếm
  • Xác minh người dùng có thể truy cập tệp đó hay không (quyền ở cấp tài nguyên)
  • Trong quá trình nối embedding với dữ liệu nguồn, kiểm tra quyền ở tầng ứng dụng
• Đưa logic quyền vào chính LLM là không ổn định (do đặc tính xác suất nên không thể bảo đảm)
• Tóm lại:
  • Trọng tâm của RAG là sau khi nối embedding với dữ liệu gốc phải áp dụng chặt chẽ quyền theo từng người dùng/từng tài nguyên

2. RAG dữ liệu 3rd Party (bên ngoài)

• Dùng embedding của dữ liệu từ API/hệ thống bên ngoài (ví dụ: wiki, hệ thống ticket, v.v.)
• Vấn đề: embedding và dữ liệu gốc nằm ở các hệ thống khác nhau → vị trí áp dụng quyền trở nên mơ hồ
• Ba cách xử lý quyền
  1. Ủy thác quyền cho hệ thống bên ngoài (xác minh quyền thật ở từng request API đơn lẻ, nhưng có vấn đề phản hồi chậm và rate limit)
  2. Đồng bộ ACL (danh sách kiểm soát truy cập) vào ứng dụng (độ chính xác/độ tin cậy cao nhưng tăng chi phí quản lý/đồng bộ ACL)
  3. Tự tái hiện logic phân quyền của hệ thống bên ngoài ở nội bộ (tăng gánh nặng quản lý/đồng bộ và độ phức tạp của logic)
• Kết luận: tùy tình huống thực tế, trade-off về “vị trí áp dụng quyền” và cách làm là rất quan trọng
  (cần lựa chọn giữa hiệu năng-độ đơn giản, chi phí quản lý-độ chính xác, v.v.)

LLM dựa trên agent (AI Agent) và quyền

• Ví dụ: chatbot tự động thực hiện các tác vụ bảo trì như xóa branch của repository hoặc đóng issue
• Với MCP (Model Context Protocol), có thể phơi bày tool (hàm/API) cho LLM theo cách chuẩn hóa
• Với mỗi request MCP, cần áp dụng mô hình quyền hiệu lực
  (giao của quyền người dùng/agent/tác vụ)
• Giới hạn của xác thực dựa trên token như OAuth
  • Dù thông tin quyền có trong token, nó không bao phủ được quyền thời gian thực ở cấp tài nguyên/tài nguyên cụ thể
  • Trên thực tế, chỉ một phần thông tin được đưa vào token, phần còn lại vẫn cần triển khai logic phân quyền riêng ở tầng ứng dụng

Kết luận và tóm tắt thực tiễn

• Trong môi trường LLM/RAG/Agent, trọng tâm của quản lý quyền là chọn “vị trí và cách áp dụng quyền”

• Thông qua mô hình quyền hiệu lực, cần giới hạn để LLM chỉ hoạt động trong phần giao của “người dùng + LLM + tác vụ”

• Token xác thực như OAuth chỉ nên dùng để nhận diện “ai là người gửi yêu cầu”,
  còn việc xác minh quyền thực tế theo từng tài nguyên bắt buộc phải được thực hiện trong ứng dụng

• Khi tích hợp với hệ thống bên ngoài,
  1) ủy thác quyền (giảm hiệu năng), 2) đồng bộ ACL (phức tạp vận hành), 3) tái hiện logic phân quyền (bảo trì cao)
  cần được thiết kế sau khi cân nhắc nhiều trade-off khác nhau

• Tóm tắt cuối cùng:
  > LLM chỉ nên hoạt động trong phạm vi quyền tối thiểu thật sự cần thiết để xử lý yêu cầu của người dùng,
  > và quyền hiệu lực (effective permissions) được định nghĩa là giao của quyền LLM, quyền người dùng và quyền tác vụ
  > Việc xác minh quyền thực tế phải luôn được thực hiện theo từng tài nguyên, ở tầng ứng dụng