Xác thực là kiểm tra xem bạn là ai; ủy quyền là quyết định xem bạn được phép làm gì. Ngày càng có nhiều ứng dụng tích hợp AI chỉ xác minh danh tính người dùng một lần khi đăng nhập, sau đó cho phép tác nhân (agent) bên dưới thực hiện bất kỳ hành động nào trên mọi tài nguyên trong suốt phần còn lại của phiên làm việc, điều này thực chất là trao cho nó một "tấm séc để trống". Thiết kế đó mở cửa cho các vụ rò rỉ dữ liệu vô ý, gửi email không mong muốn, hoặc thậm chí là các cập nhật cơ sở dữ liệu mang tính hủy diệt, và rủi ro sẽ tăng lên mỗi khi một trợ lý AI có thể thực hiện hàng loạt lệnh gọi công cụ với độ trễ chỉ tính bằng mili giây.

Tại sao sai lầm này vẫn tiếp diễn

Hầu hết các nhà phát triển AI đều coi màn hình đăng nhập là cổng bảo mật duy nhất. Mã nguồn sẽ yêu cầu mật khẩu hoặc mã thông báo (token), đánh dấu phiên làm việc là "đã xác thực", và sau đó mặc định rằng mọi yêu cầu tiếp theo đều an toàn. Trong một ứng dụng web truyền thống, các cú nhấp chuột chậm rãi của người dùng đóng vai trò như một điểm kiểm soát tốc độ tự nhiên; con người sẽ dừng lại một chút trước khi nhấn "xóa". Tuy nhiên, một tác nhân AI có thể thực hiện hàng chục lệnh gọi công cụ chỉ trong vài giây. Nếu nền tảng chỉ hỏi "Người dùng đã đăng nhập chưa?", thì mỗi lệnh gọi đều sẽ thừa hưởng cùng một đặc quyền không giới hạn đó.

Nguyên nhân gốc rễ là sự tiện lợi. Các đội ngũ phát triển thường cấp một tài khoản dịch vụ (service account) duy nhất có thời hạn dài cho toàn bộ ứng dụng để mã nguồn không phải quản lý nhiều token hoặc phạm vi (scope) khác nhau. Tài khoản đó thường có quyền hạn rộng lớn—đọc, ghi, xóa—trên tất cả các dự án. Khi một trợ lý AI chạy trong phiên làm việc đó, nó sẽ tự động thừa hưởng các quyền này, bất kể nhiệm vụ hiện tại có thực sự cần đến chúng hay không.

Những rủi ro tiềm ẩn

  • Lộ dữ liệu – Một tác nhân có khả năng đọc bất kỳ tệp nào sau khi người dùng đăng nhập có thể vô tình đưa các tài liệu mật vào một phản hồi mà sau đó được chia sẻ ra bên ngoài tổ chức.
  • Các hành động ngoài ý muốn – Trợ lý AI của một kỹ sư hỗ trợ có thể thực thi một truy vấn SQL thô trực tiếp vào cơ sở dữ liệu production chỉ vì phiên làm việc của kỹ sư đó vẫn đang hoạt động, ngay cả khi truy vấn đó không liên quan đến yêu cầu (ticket) đang xử lý.
  • Tuân thủ quy định – Nhiều quy định về bảo vệ dữ liệu yêu cầu quyền truy cập phải được giới hạn ở mức tối thiểu cần thiết. Một mô hình cấp quyền tràn lan có thể vi phạm các nguyên tắc này và dẫn đến việc bị kiểm toán hoặc bị phạt.
  • Chi phí vận hành – Những sai lầm làm xóa hoặc sửa đổi các bản ghi sẽ buộc các đội ngũ phải khôi phục các thay đổi, điều tra nguyên nhân gốc rễ và xây dựng lại niềm tin với người dùng—tất cả đều gây lãng phí thời gian và tiền bạc.

Bước còn thiếu: ủy quyền theo từng hành động

Việc ủy quyền nên được đánh giá tại mọi "cánh cửa" bên trong hệ thống, chứ không chỉ ở lối vào chính. Câu hỏi cần thay đổi từ "Đây là ai?" thành "Hành động cụ thể này trên tài nguyên cụ thể này có được phép thực hiện ngay bây giờ hay không?". Việc triển khai bước kiểm tra này không đòi hỏi phải thiết kế lại toàn bộ hệ thống; nó chỉ cần chuyển đổi từ một cờ (flag) phiên duy nhất sang các token có phạm vi hẹp và thời hạn ngắn.

Cách thức hoạt động trong thực tế

  1. Yêu cầu một token với phạm vi (scope) được xác định – Khi tác nhân AI cần gọi một công cụ, trước tiên nó phải lấy một token liệt kê chính xác các quyền hạn cần thiết (ví dụ: read:ticket, execute:sql_query).
  2. Xác thực token cho mỗi lần gọi – Trước khi công cụ chạy, dịch vụ sẽ kiểm tra xem token có bao gồm phạm vi cần thiết và token đó đã hết hạn hay chưa.
  3. Đối chiếu tài nguyên với phạm vi – Nếu yêu cầu nhắm vào một dự án hoặc cơ sở dữ liệu cụ thể, token phải cấp quyền truy cập rõ ràng cho định danh đó.
  4. Từ chối hoặc cho phép – Nếu bất kỳ bước kiểm tra nào thất bại, lệnh gọi sẽ bị từ chối và tác nhân sẽ nhận được một lỗi để thông báo cho người dùng.

Sự khác biệt trong mã nguồn rất rõ ràng. Một cách tiếp cận "tồi" có thể trông như thế này:

if session.is_authenticated():
    tool.run(params)

Một cách tiếp cận "tốt" sẽ mở rộng việc kiểm tra:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

Mẫu thứ hai tuy thêm vào một vài dòng mã nhưng buộc hệ thống phải đặt đúng câu hỏi cho mọi thao tác.

Các tiêu chuẩn giúp mọi thứ dễ dàng hơn

Các phạm vi (scopes) của OAuth 2.0 đã cung cấp một phương thức được áp dụng rộng rãi để giới hạn những gì một token có thể làm. Bằng cách cấp các mã thông báo truy cập có thời hạn ngắn và mã hóa các phạm vi như project:1234:write hoặc email:send, các nhà phát triển có thể dựa vào các thư viện hiện có để thực hiện bước xác minh.

Tiêu chuẩn mới hơn là Rich Authorization Requests (RFC 9396) giúp mở rộng ý tưởng này, cho phép máy khách (client) yêu cầu các quyền hạn chi tiết tại thời điểm thực thi (runtime) thay vì định nghĩa trước một danh sách tĩnh. Sự linh hoạt đó rất hữu ích khi một quy trình làm việc của AI có thể cần thêm hoặc bớt các khả năng một cách tức thời dựa trên ý định của người dùng.

Đối lập lập luận: sự đơn giản so với tính bảo mật

Một số nhóm lập luận rằng việc kiểm tra theo từng hành động làm tăng độ trễ và độ phức tạp của mã nguồn, đặc biệt là khi trợ lý AI phải gọi nhiều công cụ liên tiếp một cách nhanh chóng. Họ chỉ ra rằng một mã thông báo phiên (session token) duy nhất sẽ tránh được chi phí vận hành của việc lấy và xác thực một mã thông báo mới cho mỗi lần gọi. Tuy nhiên, sự đánh đổi ở đây là nguy cơ bị lạm dụng cao hơn đáng kể. Các dịch vụ xác thực mã thông báo hiện đại được thiết kế để hoạt động trong micro giây, và các lượt truyền tải mạng (network round-trip) bổ sung có thể được gom nhóm hoặc lưu bộ nhớ đệm mà không làm mất đi nguyên tắc đặc quyền tối thiểu (principle of least privilege). Trong các môi trường mà tính toàn vẹn của dữ liệu và sự tuân thủ là yếu tố không thể thương lượng, chi phí hiệu suất khiêm tốn này sẽ được bù đắp bởi việc giảm thiểu rủi ro.

Những điều cần theo dõi tiếp theo

  • Việc áp dụng các mã thông báo có phạm vi (scoped tokens) trong các AI SDK – Hãy chú ý đến các bản cập nhật của các bộ công cụ nền tảng AI lớn; nhiều bộ công cụ đang bắt đầu cung cấp các hàm hỗ trợ cho các phạm vi dựa trên OAuth.
  • Các khung chính sách dưới dạng mã (Policy-as-code frameworks) – Các giải pháp mới nổi cho phép các nhóm khai báo các quy tắc ủy quyền trong một tệp khai báo, sau đó tự động thực thi chúng trong thời gian chạy (runtime).
  • Nhật ký kiểm tra (Audit logs) hiển thị các quyết định theo từng hành động – Khi có nhiều nền tảng ghi lại từng lần kiểm tra ủy quyền hơn, các tổ chức sẽ có được khả năng hiển thị về việc hành động AI nào đang được cho phép hoặc bị chặn, từ đó cung cấp thông tin cho các điều chỉnh chính sách trong tương lai.

Bài học rút ra

Coi một phiên đăng nhập là quyền được làm bất cứ điều gì là công thức dẫn đến những hậu quả không mong muốn. Bằng cách chuyển quyết định ủy quyền từ thời điểm đăng nhập sang mỗi lần gọi công cụ riêng lẻ — và bằng cách tận dụng các mã thông báo có phạm vi, thời hạn ngắn — các ứng dụng AI có thể duy trì sự tiện lợi của các tác nhân tự trị (autonomous agents) trong khi vẫn bảo vệ được dữ liệu, tuân thủ các quy định và tránh được những sai sót tốn kém. Những dòng mã bổ sung là một cái giá nhỏ cho một hệ thống luôn đặt ra câu hỏi đúng đắn mỗi khi một hành động được thực hiện.