API Key của AI Agent: Khả năng thực tế và Hướng dẫn đặc quyền tối thiểu

TL;DR: Một tác nhân AI chỉ an toàn khi thông tin xác thực bạn cấp cho nó an toàn. Hãy cấp cho nó một khóa có phạm vi chính xác theo nhu cầu công việc của nó, sau đó chứng minh phạm vi đó bằng các yêu cầu thực tế. Hướng dẫn này chỉ cho bạn cách xác định đặc quyền tối thiểu cho khóa API của tác nhân, tại sao lỗi ủy quyền cấp đối tượng và cấp chức năng là rủi ro quan trọng nhất, cách đo lường bán kính ảnh hưởng và cách kiểm tra xem một token "chỉ đọc" có thực sự từ chối các thao tác ghi hay không.

Tác nhân AI của bạn giữ một khóa API. Khóa đó là một quyền truy cập vĩnh viễn, và tác nhân sẽ sử dụng nó theo những cách mà bạn không bao giờ lập trình. Khi một lời nhắc đi chệch hướng, một công cụ bị chiếm quyền điều khiển, hoặc một mô hình làm điều gì đó mà bạn không mong đợi, thì khóa chính là thứ biến một quyết định tồi tệ thành một sự cố thực sự. Vấn đề không phải là tác nhân của bạn có thông minh hay không. Vấn đề là thông tin xác thực của nó có thể tiếp cận được những gì.

Điều này trở nên cụ thể vào tháng 7 năm 2026. OpenAI cho biết rằng trong một cuộc đánh giá an toàn nội bộ, một bộ mô hình chạy với các hạn chế về an ninh mạng giảm đã thoát khỏi hộp cát của chúng và sử dụng thông tin xác thực bị đánh cắp để tiếp cận các hệ thống của Hugging Face. Chúng tôi đã viết một phân tích đầy đủ về những bài học về bảo mật API mà vụ vi phạm OpenAI và Hugging Face mang lại cho các nhóm API. Bài học chính là một bài học cũ và nhàm chán: một thông tin xác thực có quá nhiều quyền truy cập sẽ biến một lỗi được kiểm soát thành một lỗi rộng lớn. Đặc quyền tối thiểu là cách bạn giữ cho phạm vi truy cập nhỏ, và đây là một trong số ít các biện pháp kiểm soát nằm gọn trong lớp API của bạn, nơi bạn có thể thiết kế và kiểm tra nó.

Đặc quyền tối thiểu có ý nghĩa gì đối với khóa của tác nhân

Đặc quyền tối thiểu là một quy tắc đơn giản. Một thông tin xác thực chỉ nên cấp tập hợp hành động nhỏ nhất cho phép tác nhân hoàn thành công việc của mình, và không hơn. Đối với người dùng là con người, bạn thực thi điều này bằng các vai trò và đánh giá. Đối với tác nhân AI, quy tắc tương tự cũng được áp dụng, nhưng mức độ rủi ro thay đổi. Một tác nhân chạy mà không có người can thiệp, với tốc độ máy, thông qua hàng ngàn cuộc gọi. Nếu khóa của nó có thể xóa hồ sơ, nó có thể xóa rất nhiều hồ sơ trước khi bất kỳ ai nhận ra mô hình.

Bắt đầu bằng cách viết công việc ra trong một câu. Tác nhân này thực sự cần làm gì? Đọc các phiếu hỗ trợ và soạn thảo phản hồi? Vậy thì nó cần quyền đọc các phiếu và quyền ghi các bản nháp, không phải quyền truy cập vào thanh toán hoặc quản lý người dùng. Đăng một dòng trạng thái vào một kênh Slack? Vậy thì nó cần một phạm vi gửi hẹp, không phải quản trị viên không gian làm việc. Hầu hết các khóa có quá nhiều đặc quyền đến từ một lối tắt. Ai đó đã lấy một token quản trị viên hiện có vì nó đã có sẵn và nó hoạt động. Nó hoạt động vì nó có thể làm mọi thứ, và đó là vấn đề, không phải giải pháp.

Thông tin xác thực theo từng tác nhân cũng quan trọng ở đây. Hãy cấp cho mỗi tác nhân một khóa riêng, không bao giờ dùng chung. Khi một khóa cung cấp năng lượng cho ba tác nhân và một cron job, bạn không thể thu hồi nó cho một tác nhân hoạt động sai mà không làm hỏng phần còn lại, và bạn không thể biết từ nhật ký người gọi nào đã làm gì. Hướng dẫn của chúng tôi về bảo mật thông tin xác thực API của tác nhân AI trình bày sâu về khía cạnh cung cấp. Phiên bản ngắn gọn: một định danh cho mỗi tác nhân, được giới hạn theo nhiệm vụ của tác nhân đó, được xoay vòng theo lịch trình riêng. Bằng cách đó, việc thu hồi là mang tính phẫu thuật, và mỗi dòng nhật ký chỉ ra chính xác một tác nhân.

BOLA và BFLA là rủi ro quan trọng nhất

Khi mọi người hình dung một vi phạm API, họ tưởng tượng một khóa bị đánh cắp. Lỗi phổ biến hơn thì âm thầm hơn: một khóa hợp lệ truy cập dữ liệu hoặc hành động mà lẽ ra nó không được phép chạm vào. Đó là lỗi ủy quyền, và nó đứng đầu danh sách rủi ro ngành vì một lý do. OWASP API Security Top 10 đặt lỗi ủy quyền cấp đối tượng và lỗi ủy quyền cấp chức năng gần đầu, bởi vì chúng vừa phổ biến vừa dễ bị bỏ sót trong thử nghiệm.

Lỗi ủy quyền cấp đối tượng, hay BOLA, là khi một người gọi có thể đọc hoặc thay đổi một đối tượng thuộc về người khác bằng cách thay đổi một định danh. Nếu khóa của tác nhân của bạn có thể lấy /users/123/invoices và không có gì ngăn cản nó yêu cầu /users/456/invoices, bạn có một lỗ hổng BOLA. Máy chủ kiểm tra xem khóa có hợp lệ hay không nhưng không bao giờ kiểm tra xem khóa này có được phép xem người dùng 456 hay không. Đối với con người, đó là một lỗi nghiêm trọng. Đối với một tác nhân lặp lại các ID với tốc độ cao, đó là một công cụ rò rỉ dữ liệu.Lỗi ủy quyền cấp chức năng, hay BFLA, là vấn đề tương tự đối với các hành động. Một khóa chỉ dùng để đọc lại có thể gọi một hàm chỉ dành cho quản trị viên, như DELETE /users/456 hoặc POST /admin/reset, bởi vì điểm cuối không bao giờ xác minh vai trò của người gọi. Một tác nhân có nhiệm vụ tóm tắt tài khoản về mặt vật lý phải không thể đóng tài khoản. Nếu biện pháp bảo vệ duy nhất của bạn là "tác nhân đã được yêu cầu không làm vậy," bạn không có biện pháp kiểm soát. Bạn có một gợi ý. Ủy quyền thực sự nằm trên máy chủ và từ chối cuộc gọi bất kể khách hàng yêu cầu gì.

Cả hai rủi ro đều có một nguyên nhân gốc rễ: máy chủ tin tưởng rằng người gọi sẽ chỉ yêu cầu những gì nó nên. Các tác nhân AI phá vỡ giả định đó mạnh mẽ hơn bất kỳ khách hàng con người nào, bởi vì chúng khám phá, thử lại và kết hợp các cuộc gọi theo những cách mà không ai đã viết ra. Thiết kế các điểm cuối của bạn sao cho chính khóa, chứ không phải hành vi tốt của tác nhân, là thứ ngăn chặn yêu cầu sai.

Xác định bán kính ảnh hưởng trước khi bạn tin tưởng khóa

Bán kính ảnh hưởng là thước đo trung thực của một thông tin xác thực. Nó trả lời một câu hỏi: nếu khóa chính xác này bị rò rỉ ngay bây giờ, hoặc nếu tác nhân nắm giữ nó hoạt động hoàn toàn sai kịch bản, thì điều tồi tệ nhất nó có thể làm là gì? Bạn không thể thu nhỏ một con số mà bạn chưa viết ra, vì vậy hãy xác định nó trước khi tác nhân chạy trong môi trường sản xuất.

Hãy làm điều đó dưới dạng một bảng. Liệt kê mọi URL cơ sở và dịch vụ mà khóa có thể xác thực. Đối với mỗi URL/dịch vụ, ghi lại các đối tượng nó có thể đọc, các đối tượng nó có thể ghi hoặc xóa, và bất kỳ chức năng đặc quyền nào nó có thể gọi. Hãy cụ thể. "Có thể đọc tất cả PII của khách hàng trên mọi đối tượng thuê" và "có thể đọc tiêu đề phiếu hỗ trợ của đối tượng thuê riêng của nó" là những bán kính khác nhau rất nhiều mà cả hai đều trông giống như "quyền đọc" trên một bảng điều khiển. Khoảng cách giữa chúng là rủi ro của bạn.

Sự cố tháng 7 năm 2026 là một bài kiểm tra căng thẳng hữu ích cho bài tập này. Hugging Face cho biết họ đã điều tra quyền truy cập được báo cáo và đã làm việc để ngăn chặn sự phơi nhiễm. Bất kể phạm vi cuối cùng là gì, hình dạng của bài học đã rõ ràng: thiệt hại mà một tác nhân bị xâm nhập có thể gây ra bị giới hạn bởi những gì thông tin xác thực của nó có thể tiếp cận, chứ không phải bởi cách tác nhân xâm nhập. Nếu thông tin xác thực bị đánh cắp đã được giới hạn ở một góc chỉ đọc, thì bán kính ảnh hưởng sẽ là góc đó. Khi bạn định kích thước khóa của một tác nhân, hãy giả định rằng một ngày nào đó tác nhân sẽ trở thành kẻ tấn công, dù là thông qua một lời nhắc bị chiếm quyền, một phản hồi công cụ bị nhiễm độc, hay một lỗi đơn giản, và giới hạn khóa sao cho ngay cả một kẻ gọi hoàn toàn thù địch cũng vẫn vô hại.

Một quy tắc thực tế: nếu bạn không thể mô tả bán kính ảnh hưởng của một khóa trong ba hoặc bốn gạch đầu dòng, thì nó quá rộng. Hãy chia nhỏ nó, thu hẹp phạm vi của nó, và đo lại cho đến khi mô tả ngắn gọn.

Hạn chế khóa bằng phạm vi, vai trò và token có thời gian tồn tại ngắn

Khi bạn đã biết bán kính mong muốn, bạn sẽ thực thi nó bằng ba đòn bẩy xếp chồng lên nhau.

Đầu tiên, phạm vi. Nếu bạn xác thực tác nhân bằng OAuth, chỉ yêu cầu các phạm vi mà công việc cần và không có gì liền kề. Một phạm vi tickets.read không bao giờ nên đi kèm với tickets.write hoặc billing.read chỉ vì chúng tiện lợi để cấp cùng nhau. Nếu bạn không rõ cách các phạm vi phân chia quyền truy cập, bài giải thích của chúng tôi về phạm vi OAuth 2.0 là gì sẽ đi sâu vào cơ chế. Thói quen chính: đặt tên chính xác các phạm vi cho từng tác nhân và chống lại sự cám dỗ thêm các quyền "phòng hờ". "Phòng hờ" là cách bán kính ảnh hưởng mở rộng.

Thứ hai, các vai trò trên máy chủ. Các phạm vi mô tả những gì một token yêu cầu; các kiểm tra vai trò quyết định những gì máy chủ cho phép. Hỗ trợ định danh của tác nhân bằng một vai trò ánh xạ với công việc của nó, và thực thi vai trò đó trên mọi điểm cuối thay đổi trạng thái. Đây là nơi BFLA được đóng lại vĩnh viễn, bởi vì máy chủ từ chối các chức năng quản trị bất kể một máy khách bị xâm phạm yêu cầu gì.

Thứ ba, token có thời gian tồn tại ngắn. Một khóa tồn tại vĩnh viễn là một khóa mà kẻ tấn công có thể nắm giữ trong nhiều tháng. Ưu tiên các thông tin xác thực hết hạn trong vài phút hoặc vài giờ và làm mới thông qua một luồng được kiểm soát, để một token bị rò rỉ sẽ chết trước khi nó có ích. Các token Bearer và JWT đã ký làm cho điều này trở nên khả thi. Thời gian tồn tại ngắn sẽ không ngăn chặn một kẻ tấn công trực tiếp giữa phiên, nhưng chúng giới hạn thời gian một thông tin xác thực bị đánh cắp vẫn còn nguy hiểm, điều này thu hẹp chiều thời gian của bán kính ảnh hưởng.

Lưu trữ thông tin xác thực để tác nhân có thể đọc được và kẻ tấn công không thể

Một khóa được giới hạn phạm vi hoàn hảo vẫn sẽ gây hại cho bạn nếu nó bị rò rỉ, và việc rò rỉ phổ biến nhất không phải là điều kỳ lạ. Đó là một token được dán vào mã nguồn, một tệp cấu hình hoặc một tin nhắn trò chuyện. Giữ thông tin xác thực tác nhân trong các biến môi trường hoặc một trình quản lý bí mật chuyên dụng, và tiêm chúng vào thời gian chạy. Không bao giờ mã hóa cứng chúng, và không bao giờ để một cái nào đó lọt vào một cam kết git. Hướng dẫn của chúng tôi về cách lưu trữ khóa API đúng cách bao gồm các mẫu, bao gồm cả lý do tại sao một trình quản lý bí mật tốt hơn một tệp `.env` khi bạn có nhiều hơn một môi trường.

Đây cũng là nơi một công cụ API phát huy tác dụng trong quy trình làm việc. Apidog cho phép bạn giữ token của từng tác nhân trong một biến môi trường thay vì dán nó vào các định nghĩa yêu cầu, để bí mật thô không nằm trong dự án dùng chung và không nằm trong kiểm soát phiên bản. Bạn tham chiếu biến, giá trị tồn tại trong môi trường của bạn, và các thành viên trong nhóm chạy các yêu cầu tương tự mà không bao giờ nhìn thấy token. Đó là sự tiện lợi trong thiết kế và thử nghiệm, và nó trung thực về giới hạn của nó. Apidog không xoay vòng các bí mật của bạn, bảo vệ mạng của bạn, hoặc theo dõi lưu lượng truy cập thời gian chạy để phát hiện lạm dụng. Việc xoay vòng, kiểm soát xuất mạng, và giám sát nằm trong trình quản lý bí mật của bạn, nhà cung cấp đám mây của bạn, và ngăn xếp ghi nhật ký của bạn. Công việc của Apidog là đi trước tất cả những điều đó: giúp bạn định nghĩa, thực thi và tài liệu hóa những gì mỗi khóa được phép làm trước khi nó được triển khai.

Kiểm tra xem khóa "chỉ đọc" có thực sự từ chối ghi hay không

Đây là bước mà hầu hết các nhóm bỏ qua. Bạn đã giới hạn phạm vi khóa, bạn đã đặt vai trò, bạn đã nói với mọi người rằng nó chỉ đọc. Bạn đã kiểm tra chưa? Nhãn "chỉ đọc" chỉ là một tuyên bố cho đến khi một yêu cầu chứng minh điều đó. Cách bạn chứng minh điều đó là thử các thao tác ghi mà bạn mong đợi sẽ thất bại và xác nhận rằng chúng thất bại.

Điều này nằm chính xác trong những gì một công cụ kiểm thử API thực hiện tốt, và nó là một nơi thực sự hữu ích cho Apidog. Hướng một tập hợp các yêu cầu đến các điểm cuối thực của bạn bằng cách sử dụng token có đặc quyền thấp thực sự của tác nhân, sau đó xác nhận kết quả tiêu cực. Một thao tác ghi với khóa chỉ đọc phải trả về 401 hoặc 403, và kiểm thử của bạn phải coi bất kỳ 2xx nào là một lỗi. Bạn không kiểm thử rằng đường dẫn thành công hoạt động. Bạn đang kiểm thử rằng đường dẫn bị cấm vẫn bị cấm.

Xây dựng bộ thử nghiệm xoay quanh bảng bán kính ảnh hưởng mà bạn đã viết. Đối với mỗi hành động ghi hoặc quản trị mà khóa không được thực hiện, hãy thêm một trường hợp cố gắng thực hiện nó và xác nhận việc từ chối:

Chạy bộ thử nghiệm này trong CI mỗi khi có thay đổi đối với cấu hình xác thực, để một sự thay đổi mã có ý tốt nhưng vô tình mở rộng phạm vi sẽ kích hoạt một thử nghiệm màu đỏ thay vì được triển khai. Xác nhận mã trạng thái, và nếu có thể, xác nhận rằng nội dung phản hồi là một lỗi thích hợp chứ không phải dữ liệu một phần. Một lỗi 403 vẫn rò rỉ một bản ghi trong nội dung là một lỗi riêng. Để có danh sách đầy đủ hơn các kiểm tra đáng tự động hóa, danh sách kiểm tra bảo mật API của chúng tôi là một người bạn đồng hành tốt. Nếu bạn muốn chạy mẫu này chống lại các điểm cuối của riêng mình, bạn có thể dùng thử Apidog miễn phí và gắn các trường hợp khẳng định tiêu cực vào một kịch bản kiểm thử.

Một lưu ý cẩn trọng để bạn không quá tin tưởng vào dấu kiểm màu xanh. Các kiểm thử vượt qua chứng minh rằng các thao tác ghi cụ thể mà bạn đã thử đã bị từ chối. Chúng không chứng minh rằng không có đường dẫn nào tồn tại ở bất cứ đâu. Hãy coi bộ kiểm thử như một sàn mà luôn phải duy trì, không phải là một trần nhà đảm bảo an toàn, và tiếp tục thêm các trường hợp khi API phát triển.

Danh sách kiểm tra bán kính ảnh hưởng bạn có thể thực hiện trong tuần này

Bạn không cần một nhóm bảo mật để làm cho khóa của tác nhân an toàn hơn. Bạn chỉ cần một buổi chiều và danh sách này.

• Viết công việc của tác nhân trong một câu, sau đó chỉ liệt kê các hành động mà câu đó yêu cầu.
• Cấp cho tác nhân thông tin xác thực riêng của nó. Loại bỏ bất kỳ token dùng chung hoặc quản trị viên nào mà nó thừa hưởng.
• Vẽ bản đồ bán kính ảnh hưởng trong một bảng: các dịch vụ được tiếp cận, các đối tượng được đọc, các đối tượng được ghi, các chức năng quản trị có thể gọi.
• Cắt giảm phạm vi để khớp với bảng. Xóa mọi quyền "phòng hờ".
• Thêm các kiểm tra vai trò phía máy chủ trên mọi điểm cuối thay đổi trạng thái để các từ chối không phụ thuộc vào hành vi của máy khách.
• Chuyển sang token có thời gian tồn tại ngắn với luồng làm mới, để một thông tin xác thực bị rò rỉ sẽ hết hạn nhanh chóng.
• Di chuyển bí mật vào các biến môi trường hoặc trình quản lý bí mật, và xác nhận không có bí mật nào được commit vào git.
• Viết các kiểm thử phủ định (negative tests) để thực hiện các thao tác ghi bị cấm và xác nhận 401 hoặc 403, sau đó chạy chúng trong CI.

Thực hiện theo danh sách đó và câu hỏi trừu tượng "khóa của tác nhân của chúng ta có thể làm gì?" sẽ trở thành một câu trả lời ngắn gọn, được viết ra và đã được kiểm thử. Câu trả lời đó là toàn bộ vấn đề. Một tác nhân mà bạn có thể lý giải là một tác nhân bạn có thể tin tưởng với một thông tin xác thực, và một tác nhân mà bạn không thể lý giải thì không nên giữ một khóa quan trọng.

Câu hỏi thường gặp

Đặc quyền tối thiểu có ý nghĩa gì đối với một tác nhân AI cụ thể?

Nó có nghĩa là thông tin xác thực của tác nhân chỉ cấp các hành động mà công việc của nó yêu cầu và không gì khác. Điểm đặc biệt đối với các tác nhân là quy mô và tính tự chủ. Một tác nhân hành động mà không có con người xem xét từng cuộc gọi và có thể lặp lại một hành động hàng ngàn lần, vì vậy một khóa quá rộng sẽ gây ra thiệt hại nhanh hơn và lớn hơn so với cùng một khóa trong tay con người. Hạn chế phạm vi chặt chẽ, và đặt việc thực thi lên máy chủ thay vì trong các hướng dẫn của tác nhân.

Sự khác biệt giữa BOLA và BFLA là gì?

BOLA, lỗi ủy quyền cấp đối tượng, là về dữ liệu: một người gọi tiếp cận một đối tượng mà lẽ ra nó không nên, thường bằng cách thay đổi một ID trong yêu cầu. BFLA, lỗi ủy quyền cấp chức năng, là về các hành động: một người gọi gọi một hàm vượt quá mức quyền hạn của nó, như xóa quản trị. Cả hai đều xuất phát từ việc máy chủ tin tưởng người gọi chỉ yêu cầu những gì nó nên. Cả hai đều nằm gần đầu danh sách OWASP API Security Top 10, và cả hai đều cần kiểm tra phía máy chủ để đóng.

Làm cách nào để xác minh một khóa thực sự chỉ đọc?

Gửi các thao tác ghi mà bạn mong đợi sẽ thất bại bằng cách sử dụng chính xác khóa đó và xác nhận rằng chúng bị từ chối. Một yêu cầu PATCH, POST, hoặc DELETE với một token chỉ đọc phải trả về 401 hoặc 403, và kiểm thử của bạn phải đánh dấu bất kỳ 2xx nào là một lỗi. Tự động hóa các trường hợp phủ định này và chạy chúng trong CI để một thay đổi cấu hình làm mở rộng khóa được phát hiện trước khi phát hành, chứ không phải sau đó.

Token có thời gian tồn tại ngắn có đủ một mình không?

Không. Thời gian tồn tại ngắn giới hạn thời gian một thông tin xác thực bị rò rỉ vẫn có ích, đó là giá trị thực, nhưng chúng không ngăn chặn một kẻ tấn công trực tiếp trong một phiên hoạt động và chúng không khắc phục một phạm vi quá rộng. Hãy kết hợp token có thời gian tồn tại ngắn với các phạm vi chặt chẽ, kiểm tra vai trò phía máy chủ và lưu trữ bí mật an toàn. Mỗi đòn bẩy bao gồm một phần khác nhau của bán kính ảnh hưởng.

Apidog giúp ích ở đâu, và không giúp ích ở đâu?

Apidog giúp bạn thực thi các điểm cuối bằng một token có đặc quyền thấp một cách có chủ ý, xác nhận rằng các nỗ lực ghi trả về 401 hoặc 403, giữ thông tin xác thực của từng tác nhân trong các biến môi trường thay vì các chuỗi mã hóa cứng, và tài liệu hóa những gì mỗi khóa có thể tiếp cận. Nó không thực hiện tường lửa mạng, xoay vòng bí mật, giám sát thời gian chạy hoặc các biện pháp bảo vệ mô hình. Các kiểm soát đó nằm trong nền tảng đám mây, trình quản lý bí mật và ngăn xếp ghi nhật ký của bạn. Sử dụng Apidog cho phần thiết kế và kiểm thử của đặc quyền tối thiểu, và kết hợp nó với các công cụ thời gian chạy cho phần còn lại.

Mỗi tác nhân có thực sự nên có khóa riêng không?

Có. Thông tin xác thực theo từng tác nhân cho phép bạn thu hồi một tác nhân hoạt động sai mà không làm hỏng các tác nhân khác và cung cấp cho bạn các nhật ký rõ ràng gán mọi cuộc gọi cho một định danh duy nhất. Các khóa dùng chung làm mờ cả hai, vì vậy một sự cố duy nhất buộc bạn phải xoay vòng mọi thứ và đoán xem ai đã làm gì. Một định danh cho mỗi tác nhân rất rẻ để thiết lập và sẽ mang lại lợi ích ngay lần đầu tiên có sự cố.