API Keys

​

Quyền hạn

Không thể gán cho key. Hai quyền hợp lệ chỉ dành cho con người/dashboard và không thể cấp cho API key: orgs:admin (quản trị phiên bản, chỉ dành cho nhà điều hành) và keys:update. Yêu cầu POST /keys hoặc PATCH /keys/:id cố gắng cấp một trong hai quyền sẽ bị từ chối với HTTP 422. Xem hàng keys:update bên dưới để biết tại sao một bearer key có thể tạo key nhưng không bao giờ chỉnh sửa chúng.

​

Nhập và truy vấn sự kiện

​

Phiên & đánh giá

​

Bảng điều khiển

​

Truy vấn đã lưu (SQL composer)

​

Trợ lý AI

​

API keys

​

Người dùng bảng điều khiển

​

Cài đặt hoạt động

​

Cảnh báo & sự cố

​

Kiểm toán

Khi Audits được phát hành, những người được cấp quyền hiện có đã được mở rộng theo cùng hình dạng vai trò với cảnh báo: mọi người dùng và bộ quyền giữ alerts:read đã có audits:read, và mỗi người giữ alerts:write đã có audits:write. Các API key hiện có không được mở rộng — cấp audits:* cho một key một cách rõ ràng nếu nó cần bề mặt kiểm toán.

Các cấp quyền được lưu trữ của token alerts:ack kế thừa được phân tích cú pháp như incidents:ack nên những người trực sàn giữ quyền truy cập mà không cần khóa lại. Token không thể gán từ trình chỉnh sửa người dùng của bảng điều khiển; ma trận cung cấp incidents:ack thay thế.

Điểm cuối bộ chọn người nhận GET /alerts/recipients (liệt kê các email thành viên mà trình chỉnh sửa cảnh báo có thể thông báo) có thể truy cập được bởi người giữ hoặc alerts:read hoặc alerts:write, vì vậy trình chỉnh sửa cảnh báo có thể điền bộ chọn mà không được cấp users:read.

Người xem bảng điều khiển cần cả hai dashboards:read (để tải các chế độ xem đã lưu) và evaluations:read (các chỉ số health được tính toán từ dữ liệu đánh giá). Cấp dashboards:write để cho phép người dùng tạo hoặc chỉnh sửa bảng điều khiển, và dashboards:delete để loại bỏ chúng.

/health và /auth/* (yêu cầu OTP, xác minh OTP, kiểm tra phiên, đăng xuất) không xác thực theo thiết kế; chúng là luồng đăng nhập và điểm kiểm tra tính khả dụng. GET /access-granters yêu cầu một key hợp lệ nhưng không có quyền cụ thể, do đó bất kỳ người dùng đã đăng nhập nào cũng có thể thấy những quản trị viên nào liên hệ để yêu cầu thay đổi quyền truy cập.

​

Bộ quyền

• DEFAULT_USER_PERMISSIONS (cấp quyền được chọn trước khi quản trị viên mở + người dùng mới) mặc định là bộ standard. Xem Deployment.
• Cờ --set trên agenteye-orgctl (quản lý thành viên nhà điều hành) bắt đầu một thành viên từ một bộ được đặt tên, mà sau đó bạn tinh chỉnh bằng --add / --remove. Xem Tenant Management.

Khi một bộ bao gồm một quyền không thể gán được cho key (ví dụ, một bộ tùy chỉnh mang keys:update), hạt giống của một key từ bộ đó sẽ bỏ các token không thể gán được; máy chủ sẽ từ chối key nếu không với HTTP 422. Người dùng bảng điều khiển không phải chịu hạn chế đó.

​

Key Admin Bootstrap

​

Phạm vi tổ chức

​

Tạo Key

​

Key bộ thu thập (chỉ nhập)

curl -s -X POST http://your-server:8080/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "prod-collector",
    "key": "your-collector-secret",
    "permissions": ["events:add"]
  }'

​

Key bảng điều khiển (chỉ đọc)

curl -s -X POST http://your-server:8080/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dashboard",
    "key": "your-dashboard-secret",
    "permissions": ["events:read", "keys:read"]
  }'

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "prod-collector",
  "permissions": ["events:add"],
  "created_at": "2026-04-01T12:00:00Z"
}

​

Liệt kê Key

curl -s http://your-server:8080/keys \
  -H "Authorization: Bearer $ADMIN_KEY"

​

Vô hiệu hóa Key

curl -s -X POST http://your-server:8080/keys/<id>/disable \
  -H "Authorization: Bearer $ADMIN_KEY"

​

Tạo lại Key

curl -s -X POST http://your-server:8080/keys/<id>/regenerate \
  -H "Authorization: Bearer $ADMIN_KEY"

​

Quản lý Key trong Bảng điều khiển

​

Bố cục Key được Khuyến nghị

Key trợ lý. Key của trợ lý được hạt giống tự động bởi máy chủ từ biến env AGENT_API_KEY (bí mật tương tự mà agent trình bày như AGENTEYE_API_KEY); không có bước tạo key thủ công và không liên quan đến admin key. Quyền của nó được cố định trong mã nguồn nên phạm vi không thể được mở rộng bằng cấu hình sai: đọc trên các sự kiện / đánh giá / bảng điều khiển, cộng với dashboards-write và queries-read / write / run cho luồng tác giả “Ask AI to write a query”. Tất cả SQL vẫn đi qua cùng vai trò chỉ đọc và kiểm tra sql_guard như một truy vấn được viết bởi người dùng, vì vậy điều này mở rộng bề mặt tác giả, không phải bề mặt dữ liệu; các hoạt động tá hại (queries:delete, dashboards:delete) cố ý ở ngoài key trợ lý. Giống như key admin, nó được bảo vệ: nó không thể bị vô hiệu hóa hoặc tạo lại thông qua API key, chỉ xoay bằng cách thay đổi AGENT_API_KEY và khởi động lại. Người dùng bảng điều khiển ngoài ra cần quyền agent:use để xem và sử dụng trợ lý. Nếu bạn bật tự lợi sử dụng, cấp cho trợ lý một key events:add riêng biệt.