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 khóa có phạm vi đúng với công việc, xác minh phạm vi đó bằng yêu cầu thực tế, và tự động kiểm tra rằng token “chỉ đọc” thực sự từ chối thao tác ghi.

Tác nhân AI giữ khóa API và có thể dùng khóa đó theo những cách bạn không dự đoán: lời nhắc bị chệch hướng, công cụ bị chiếm quyền, phản hồi công cụ bị nhiễm độc hoặc lỗi mô hình. Khóa API là thứ biến một quyết định sai thành sự cố thực tế. Câu hỏi quan trọng không phải là tác nhân thông minh đến đâu, mà là thông tin xác thực của nó có thể truy cập những gì.

Dùng thử Apidog ngay hôm nay

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 với các hạn chế an ninh mạng giảm đã thoát khỏi hộp cát và dùng thông tin xác thực bị đánh cắp để tiếp cận hệ thống Hugging Face. Chúng tôi đã phân tích các bài học bảo mật API từ sự cố OpenAI và Hugging Face. Bài học vẫn quen thuộc: thông tin xác thực quá nhiều quyền sẽ biến lỗi cục bộ thành sự cố diện rộng. Đặc quyền tối thiểu giúp giới hạn phạm vi đó ngay tại lớp API, nơi bạn có thể thiết kế và kiểm thử.

Đặc quyền tối thiểu cho khóa của tác nhân là gì?

Đặc quyền tối thiểu nghĩa là thông tin xác thực chỉ được phép thực hiện tập hợp hành động nhỏ nhất cần để hoàn thành một nhiệm vụ.

Với tác nhân AI, rủi ro cao hơn người dùng thông thường vì tác nhân có thể hoạt động tự động, ở tốc độ máy và thực hiện hàng nghìn yêu cầu. Nếu khóa được phép xóa hồ sơ, tác nhân có thể xóa rất nhiều hồ sơ trước khi có người phát hiện.

Bắt đầu bằng một câu mô tả nhiệm vụ:

“Tác nhân này cần làm gì?”

Ví dụ:

Nhiệm vụ	Quyền cần thiết	Quyền không nên cấp
Đọc phiếu hỗ trợ và tạo bản nháp phản hồi	tickets.read, drafts.write	billing.read, users.admin
Đăng trạng thái vào một kênh Slack	Quyền gửi tin nhắn cho kênh cụ thể	Quyền quản trị không gian làm việc
Tóm tắt tài khoản	Quyền đọc dữ liệu cần tóm tắt	Quyền đóng hoặc xóa tài khoản

Không dùng token quản trị viên chỉ vì “nó đã có sẵn và hoạt động”. Một token hoạt động được vì nó có thể làm mọi thứ chính là vấn đề cần loại bỏ.

Mỗi tác nhân phải có khóa riêng. Không dùng chung khóa giữa nhiều tác nhân hoặc cron job, vì bạn sẽ không thể:

• Thu hồi quyền của một tác nhân mà không làm hỏng tác nhân khác.
• Xác định chính xác tác nhân nào đã thực hiện một yêu cầu trong log.
• Xoay vòng thông tin xác thực theo mức độ rủi ro của từng tác nhân.

Xem thêm hướng dẫn về bảo mật thông tin xác thực API của tác nhân AI: một định danh cho mỗi tác nhân, giới hạn theo nhiệm vụ và xoay vòng độc lập.

BOLA và BFLA là rủi ro cần ưu tiên

Vi phạm API không phải lúc nào cũng bắt đầu từ khóa bị đánh cắp. Trường hợp phổ biến hơn là một khóa hợp lệ truy cập dữ liệu hoặc hành động mà nó không được phép dùng.

Đó là lỗi ủy quyền. OWASP API Security Top 10 xếp lỗi ủy quyền cấp đối tượng và cấp chức năng vào nhóm rủi ro hàng đầu vì chúng phổ biến và dễ bị bỏ sót.

BOLA: Broken Object Level Authorization

BOLA xảy ra khi người gọi đọc hoặc thay đổi đối tượng thuộc về người khác bằng cách thay đổi định danh trong yêu cầu.

Ví dụ:

GET /users/123/invoices

Nếu token của tác nhân có thể thay 123 thành 456:

GET /users/456/invoices

và máy chủ vẫn trả dữ liệu, API có lỗ hổng BOLA.

Máy chủ đã kiểm tra token hợp lệ, nhưng không kiểm tra token đó có được phép truy cập dữ liệu của người dùng 456 hay không. Với tác nhân có thể lặp ID ở tốc độ cao, một lỗi BOLA có thể trở thành công cụ thu thập dữ liệu hàng loạt.

BFLA: Broken Function Level Authorization

BFLA xảy ra khi người gọi thực hiện một chức năng vượt quá quyền hạn của mình.

Ví dụ, token chỉ đọc vẫn gọi được:

DELETE /users/456

hoặc:

POST /admin/reset

Nếu tác nhân chỉ có nhiệm vụ tóm tắt tài khoản nhưng vẫn có thể đóng tài khoản, kiểm soát của bạn không tồn tại. “Tác nhân đã được nhắc không làm vậy” không phải là biện pháp bảo vệ.

Ủy quyền phải được thực thi phía máy chủ. Máy chủ phải từ chối yêu cầu dù client, công cụ hay tác nhân gửi yêu cầu gì.

Xác định bán kính ảnh hưởng trước khi triển khai

Bán kính ảnh hưởng trả lời câu hỏi:

Nếu khóa này bị lộ hoặc tác nhân dùng nó hoạt động sai hoàn toàn, điều tệ nhất có thể xảy ra là gì?

Hãy lập bảng trước khi tác nhân chạy production:

Dịch vụ / URL cơ sở	Có thể đọc	Có thể ghi hoặc xóa	Chức năng đặc quyền
Support API	Tiêu đề và nội dung phiếu của tenant hiện tại	Bản nháp phản hồi	Không có
Billing API	Không có	Không có	Không có
User API	Hồ sơ giới hạn của tenant hiện tại	Không có	Không có

Tránh mô tả chung chung như “có quyền đọc”. Hai quyền sau có mức độ rủi ro rất khác nhau:

• Có thể đọc toàn bộ PII khách hàng của mọi tenant.
• Chỉ có thể đọc tiêu đề phiếu hỗ trợ của tenant được gán.

Trong sự cố tháng 7 năm 2026, Hugging Face cho biết họ đã điều tra quyền truy cập được báo cáo và thực hiện các biện pháp ngăn chặn phơi nhiễm. Dù phạm vi cuối cùng là gì, nguyên tắc vẫn không đổi: thiệt hại bị giới hạn bởi những gì thông tin xác thực có thể truy cập.

Khi thiết kế quyền, hãy giả định tác nhân một ngày nào đó sẽ hành xử như kẻ tấn công. Giới hạn khóa sao cho ngay cả một người gọi hoàn toàn thù địch cũng chỉ có thể gây hại trong phạm vi nhỏ.

Một quy tắc thực tế: nếu không thể mô tả bán kính ảnh hưởng của khóa trong ba hoặc bốn gạch đầu dòng, khóa đó có thể quá rộng.

Hạn chế khóa bằng phạm vi, vai trò và token ngắn hạn

Dùng ba lớp kiểm soát bổ sung cho nhau.

1. Phạm vi OAuth

Nếu dùng OAuth, chỉ yêu cầu phạm vi đúng với nhiệm vụ:

tickets.read
drafts.write

Không thêm các quyền liền kề chỉ để tiện cấp phát:

tickets.write
billing.read
users.admin

Một phạm vi như tickets.read không nên tự động kéo theo tickets.write. Tham khảo cách hoạt động của phạm vi OAuth 2.0 để thiết kế phạm vi theo hành động thay vì theo sự tiện lợi.

2. Vai trò và kiểm tra phía máy chủ

Phạm vi mô tả quyền token yêu cầu; máy chủ vẫn phải quyết định quyền nào được phép.

Ví dụ pseudocode:

app.delete("/users/:id", requireRole("admin"), async (req, res) => {
  // Chỉ admin mới đến được đây
  await deleteUser(req.params.id);
  res.sendStatus(204);
});

Mọi endpoint thay đổi trạng thái cần kiểm tra quyền phía máy chủ. Đây là lớp phòng thủ trực tiếp chống BFLA.

3. Token có thời gian tồn tại ngắn

Khóa tồn tại vĩnh viễn có thể bị lạm dụng trong nhiều tháng. Ưu tiên token hết hạn trong vài phút hoặc vài giờ, rồi làm mới qua luồng được kiểm soát.

Token Bearer hoặc JWT đã ký có thể hỗ trợ mô hình này:

{
  "sub": "agent-support-summary",
  "scope": "tickets.read drafts.write",
  "exp": 1760000000
}

Token ngắn hạn không chặn kẻ tấn công đang hoạt động trong phiên hiện tại, nhưng giảm thời gian token bị lộ còn hữu dụng.

Lưu trữ thông tin xác thực an toàn

Một khóa có phạm vi hoàn hảo vẫn nguy hiểm nếu bị rò rỉ. Các nguyên nhân phổ biến thường rất đơn giản:

• Token bị dán vào mã nguồn.
• Token nằm trong tệp cấu hình.
• Token được gửi qua chat.
• Token bị commit vào Git.

Lưu thông tin xác thực trong biến môi trường hoặc trình quản lý bí mật chuyên dụng, rồi tiêm vào ứng dụng khi chạy.

export SUPPORT_AGENT_TOKEN="..."

Không mã hóa cứng token:

// Không làm điều này
const token = "sk_live_...";

Hướng dẫn cách lưu trữ khóa API đúng cách giải thích các mẫu lưu trữ và lý do trình quản lý bí mật phù hợp hơn tệp .env khi bạn có nhiều môi trường.

Apidog giúp giữ token của từng tác nhân trong biến môi trường thay vì dán trực tiếp vào định nghĩa request. Nhóm có thể chạy cùng request mà không cần nhìn thấy token thô.

Tuy nhiên, Apidog không thay thế các kiểm soát thời gian chạy như:

• Xoay vòng bí mật.
• Kiểm soát xuất mạng.
• Giám sát lưu lượng.
• Phát hiện lạm dụng.
• Bảo vệ mô hình.

Những phần này thuộc về trình quản lý bí mật, nền tảng đám mây và hệ thống logging/monitoring của bạn. Apidog phù hợp cho phần thiết kế, tài liệu hóa và kiểm thử quyền API trước khi triển khai.

Kiểm tra token “chỉ đọc” có thực sự từ chối ghi hay không

Đừng tin vào nhãn “chỉ đọc”. Hãy kiểm tra nó.

Dùng đúng token đặc quyền thấp của tác nhân để gửi các yêu cầu ghi mà bạn kỳ vọng sẽ thất bại. Mọi phản hồi 2xx phải khiến kiểm thử thất bại.

Ví dụ với curl:

curl -X PATCH "https://api.example.com/tickets/1001" \
  -H "Authorization: Bearer $READ_ONLY_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status":"closed"}'

Kết quả mong đợi:

HTTP/1.1 403 Forbidden

Bộ kiểm thử nên bao phủ bảng bán kính ảnh hưởng:

Trường hợp kiểm thử	Yêu cầu	Token đã sử dụng	Trạng thái dự kiến
Đọc phiếu của chính mình	GET /tickets/1001	Tác nhân chỉ đọc	200
Ghi một phiếu	PATCH /tickets/1001	Tác nhân chỉ đọc	401 hoặc 403
Xóa một phiếu	DELETE /tickets/1001	Tác nhân chỉ đọc	401 hoặc 403
Đọc dữ liệu tenant khác (BOLA)	GET /tickets/9999	Tác nhân chỉ đọc	403 hoặc 404
Gọi chức năng quản trị (BFLA)	POST /admin/reset	Tác nhân chỉ đọc	401 hoặc 403

Ví dụ assertion trong script kiểm thử:

pm.test("Token chỉ đọc không được phép ghi", () => {
  pm.expect(pm.response.code).to.be.oneOf([401, 403]);
});

pm.test("Không được trả dữ liệu một phần", () => {
  pm.expect(pm.response.text()).to.not.include("customer_email");
});

Chạy các kiểm thử này trong CI khi có thay đổi ở:

• Cấu hình OAuth.
• Middleware xác thực.
• Chính sách RBAC.
• Route API.
• Quy tắc tenant isolation.

Ngoài mã trạng thái, kiểm tra cả response body. Một phản hồi 403 vẫn chứa dữ liệu nhạy cảm là một lỗi bảo mật khác.

Xem thêm danh sách kiểm tra bảo mật API. Bạn cũng có thể dùng thử Apidog miễn phí để chạy các kiểm thử phủ định này với endpoint của mình.

Lưu ý: kiểm thử vượt qua chỉ chứng minh những thao tác cụ thể bạn đã thử bị từ chối. Nó không chứng minh rằng mọi đường dẫn trái phép đều đã được loại bỏ. Hãy mở rộng bộ test khi API thay đổi.

Checklist thực hiện trong tuần này

• Viết nhiệm vụ của tác nhân trong một câu.
• Liệt kê chính xác các hành động cần để hoàn thành nhiệm vụ.
• Cấp thông tin xác thực riêng cho từng tác nhân.
• Loại bỏ token dùng chung và token quản trị viên.
• Lập bảng bán kính ảnh hưởng: dịch vụ, dữ liệu đọc, dữ liệu ghi, chức năng quản trị.
• Thu hẹp phạm vi và xóa mọi quyền “phòng hờ”.
• Thêm kiểm tra vai trò phía máy chủ cho mọi endpoint thay đổi trạng thái.
• Chuyển sang token ngắn hạn có luồng làm mới.
• Di chuyển bí mật vào biến môi trường hoặc trình quản lý bí mật.
• Kiểm tra Git để bảo đảm không có token bị commit.
• Viết negative test cho các thao tác ghi bị cấm.
• Chạy các test 401/403 trong CI.

Sau khi làm xong, câu hỏi “khóa của tác nhân có thể làm gì?” phải có câu trả lời ngắn gọn, cụ thể, được ghi lại và đã được kiểm thử. Đó là điều giúp bạn có thể tin tưởng tác nhân với thông tin xác thực của nó.

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

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

Nó có nghĩa là thông tin xác thực của tác nhân chỉ được phép thực hiện các hành động cần cho nhiệm vụ, không hơn. Vì tác nhân có thể tự động lặp lại hành động ở quy mô lớn, một khóa quá rộng có thể gây thiệt hại nhanh hơn nhiều so với cùng khóa đó trong tay con người.

BOLA và BFLA khác nhau thế nào?

BOLA là lỗi truy cập dữ liệu cấp đối tượng: người gọi truy cập tài nguyên không thuộc phạm vi của họ, thường bằng cách sửa ID trong URL hoặc payload.

BFLA là lỗi truy cập chức năng: người gọi thực hiện một hành động vượt quyền, chẳng hạn gọi endpoint quản trị hoặc xóa dữ liệu.

Cả hai đều cần được chặn bằng kiểm tra ủy quyền phía máy chủ.

Làm sao xác minh khóa thực sự chỉ đọc?

Gửi yêu cầu POST, PATCH và DELETE bằng chính token đó. Các yêu cầu này phải trả 401 hoặc 403. Bất kỳ phản hồi 2xx nào cũng phải làm kiểm thử thất bại. Tự động hóa các test này và chạy trong CI.

Token ngắn hạn có đủ không?

Không. Token ngắn hạn chỉ giảm thời gian token bị lộ còn có giá trị. Bạn vẫn cần phạm vi hẹp, kiểm tra vai trò phía máy chủ và lưu trữ bí mật an toàn.

Apidog giúp được gì và không giúp được gì?

Apidog giúp bạn chạy request bằng token đặc quyền thấp, kiểm tra thao tác ghi bị từ chối, sử dụng biến môi trường cho thông tin xác thực và tài liệu hóa quyền của từng khóa.

Apidog không thay thế tường lửa mạng, xoay vòng bí mật, giám sát runtime hoặc các biện pháp bảo vệ mô hình. Hãy kết hợp công cụ API với trình quản lý bí mật, nền tảng đám mây và hệ thống quan sát phù hợp.

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

Có. Khóa riêng cho từng tác nhân cho phép bạn thu hồi quyền có mục tiêu, xoay vòng độc lập và truy vết chính xác mọi API call trong log. Khóa dùng chung làm mờ trách nhiệm và khiến một sự cố buộc bạn phải xoay vòng mọi thứ cùng lúc.