Chuyển đến nội dung chính
Một key không có hạn chế nguồn là một bearer credential thuần túy: ai giữ chuỗi đó đều có thể trình nó từ bất cứ đâu. Trường allow_ips biến một key thành một api key có whitelist IP — nó chỉ hoạt động khi được trình từ một địa chỉ nguồn bạn đã liệt kê. Một key bị rò rỉ được phát lại từ máy của kẻ tấn công, một residential proxy, hoặc một CI runner bị xâm phạm sẽ bị từ chối trước khi nó chạm tới một mô hình. Đây là nửa ràng-buộc-nguồn của least agency: model_limits giới hạn những mô hình nào một key có thể vươn tới, và allow_ips giới hạn nơi mà key có thể được trình từ đó.

1. allow_ips làm gì

allow_ips chứa một danh sách các địa chỉ nguồn hoặc dải CIDR. Trên mỗi request, OrcaRouter so sánh IP nguồn của caller với danh sách đó:
  • Khớp → request tiến tới các kiểm tra giới hạn mô hình, quota, và chính sách.
  • Không khớp → request bị từ chối ở tầng auth với HTTP 403 (access_denied), trước bất kỳ cuộc gọi mô hình thượng nguồn nào.
  • Danh sách rỗng → không hạn chế; key được chấp nhận từ bất kỳ địa chỉ nào.
Việc kiểm tra là cổng đầu tiên mà một key đi qua, cùng với tính hợp lệ của key — nó chạy trước guardrails, trước firewall, trước đo lường. Một nguồn không được liệt kê không bao giờ chạm tới các chính sách hay số dư của bạn.
Một allow_ips rỗng nghĩa là mọi IP đều được phép, không phải không cái nào. Để trống là mặc định không hạn chế — hãy ghim key để trường này làm bất cứ điều gì.

2. Định dạng được chấp nhận

Mỗi mục là một IP đơn hoặc một dải CIDR. Trộn cả hai thoải mái; liệt kê một mục mỗi dòng.

Địa chỉ đơn

203.0.113.7 — chính xác một host. Tốt nhất cho một server IP cố định hoặc một NAT gateway với địa chỉ egress ổn định.

Dải CIDR

203.0.113.0/24 — cả một block. Tốt nhất cho một cloud subnet, một VPN pool, hoặc một autoscaling group đằng sau một egress CIDR.
Một IP trần khớp đúng một địa chỉ đó; một CIDR khớp mọi địa chỉ trong block. Cả IPv4 và IPv6 literal đều parse được.
Ghim vào dải hẹp nhất vẫn bao phủ mọi caller hợp lệ. Một host (/32) chặt hơn một /24; một /24 chặt hơn “bất cứ đâu”. Mỗi bit bạn bỏ đi nới rộng tập hợp các nơi mà một key bị rò rỉ vẫn hoạt động.

3. Đặt nó trong console

Đặt allow_ips trong trình chỉnh sửa key tại /console/token. Tạo hoặc chỉnh sửa một key yêu cầu vai trò Developer trở lên.
  1. Mở Console → API Keys và tạo hoặc chỉnh sửa một key.
  2. Trong trình chỉnh sửa key, nhập các địa chỉ đáng tin cậy của bạn vào trường IP allow-list — một IP hoặc CIDR mỗi dòng.
  3. Lưu. Hạn chế áp dụng ở request kế tiếp mà key đó thực hiện — không triển khai lại, không đổi code agent.
Xác minh địa chỉ nguồn thực mà gateway thấy trước khi bạn khóa một key. Nếu agent của bạn nằm sau một NAT, một load balancer, hoặc một egress proxy, địa chỉ mà OrcaRouter quan sát là hop egress đó — không phải IP riêng của agent. Allow-list địa chỉ egress, và test từ môi trường đã triển khai trước khi bạn ra mắt.

4. Một ví dụ cụ thể: một agent theo lịch

Một job theo lịch tóm tắt các ticket chỉ chạy từ một cloud subnet. Ghim key của nó vào subnet đó để credential vô dụng ở bất cứ nơi nào khác.
TrườngGiá trịHiệu ứng
allow_ips203.0.113.0/24chỉ block egress của scheduler có thể trình key này
model_limitsmột mô hình tóm tắtkhông thể leo lên một mô hình frontier
credit_limit_usdmột mức trần hằng tuầnmột vòng lặp mất kiểm soát không thể rút cạn số dư
Bản thân cuộc gọi relay không thay đổi — nó vẫn dùng key sk-orca-… như một bearer token:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Summarize this ticket..."}]
  }'
Được trình từ bên trong 203.0.113.0/24, cuộc gọi tiến tới. Phát lại đúng cùng request từ bất kỳ địa chỉ nào khác và gateway trả về:
{
  "error": {
    "message": "您的 IP 不在令牌允许访问的列表中 (request id: ...)",
    "type": "orcarouter_api_error",
    "code": "access_denied"
  }
}
Mô hình không bao giờ được gọi, không quota nào bị tiêu, và việc từ chối được ghi log.
allow_ips được cấu hình hoàn toàn qua trình chỉnh sửa key ở console — một hành động Developer-trở-lên trên session workspace của bạn. Không có self-service bằng relay-key cho nó: một key không thể nới rộng danh sách nguồn cho phép của chính nó.

5. Một danh sách IP cho phép chứa và không chứa gì

Một api key có whitelist IP ràng buộc nơi một key hoạt động — một lát của bán kính ảnh hưởng. Nó kết hợp với các trường phạm vi khác chứ không thay thế chúng.
Một credential bị tuồn ra từ log, một git commit, hoặc một laptop bị xâm phạm là gánh nặng chết trừ khi kẻ tấn công cũng có thể phát traffic từ dải allow-list của bạn. Đây là công việc cốt lõi của trường này — xem key bị rò rỉ để biết toàn bộ phản ứng sự cố.
Nếu vụ xâm phạm chính là một host được allow-list — một dependency bị đầu độc chạy trên server của chính bạn — kiểm tra IP nguồn đi qua. Ghép allow_ips với model_limits, một mức trần chi tiêu, và một chính sách firewall để một vụ xâm phạm từ nguồn-tin-cậy vẫn bị giới hạn.
Một IP pin không làm cho một key ngắn hạn. Kết hợp nó với một mốc hết hạn tuyệt đối và một lịch xoay vòng để một key vừa ngừng hoạt động từ những nơi mới vừa ngừng hoạt động cuối cùng.

6. Ghi chú vận hành

Nếu các caller của bạn không có địa chỉ nguồn ổn định (serverless với egress xoay vòng, client di động, mạng văn phòng rộng), một IP pin là điều khiển sai — bạn sẽ hoặc khóa traffic thật ra ngoài hoặc nới rộng dải cho đến khi nó vô nghĩa. Dựa vào model_limits, mức trần chi tiêu, hết hạn, và phần đính kèm chính sách thay thế.
Chỉnh sửa allow_ips có hiệu lực ở request kế tiếp — không có độ trễ lan truyền phải chờ. Khi bạn thêm một region hoặc di chuyển một subnet, cập nhật key trước, xác nhận dải mới hoạt động, rồi bỏ cái cũ.
allow_ips nằm trên từng key, nên mỗi agent có thể có ràng buộc nguồn riêng. Một key scheduler có thể ghim vào một batch subnet trong khi một key tương tác cho phép một dải văn phòng rộng hơn — cả hai trong cùng workspace.

7. Bước tiếp theo

Đối tượng token

Mọi trường trên một key, bao gồm allow_ips, trong một tham chiếu.

Giới hạn mô hình

Giới hạn những mô hình nào một key có thể vươn tới — nửa còn lại của ràng buộc nguồn + phạm vi.

Key bị rò rỉ

Phải làm gì ngay khi một key bị lộ.

Checklist least-agency

Cho mọi key đi qua cùng một lượt làm cứng.
Một danh sách IP cho phép là vết cắt bán-kính-ảnh-hưởng rẻ nhất bạn có thể làm: một trường, không đổi code, và một key bị rò rỉ ngừng hoạt động từ mọi nơi nó không định chạy. Ghép nó với phần còn lại của mô hình key có phạm vi để phòng thủ theo chiều sâu.