Chuyển đến nội dung chính
Khi một agent bị chiếm quyền — prompt injection, một kết quả tool bị đầu độc, một vòng lặp mất kiểm soát — những gì nó thực sự có thể làm bị giới hạn bởi đúng một thứ: API key của nó được phép làm gì. Một key không có giới hạn và không có chính sách biến một agent bị xâm phạm thành một sự cố trên toàn workspace. Trang này là lượt làm cứng bạn chạy đối với mọi key trước khi nó ra mắt, và lặp lại theo một nhịp sau đó. Nó cố tình ngắn: một checklist, một ví dụ chi tiết, rồi liên kết tới phần chuyên sâu cho mỗi trường. Để biết mô hình tư duy đằng sau nó, hãy bắt đầu với Phạm vi & key; để biết tham chiếu từng trường, xem tổng quan key.

​
1. Checklist least agency

Cho mọi key — mới hay hiện có — đi qua sáu cổng này trong trình chỉnh sửa key (/console/token). Đặt bất kỳ cái nào trong số chúng yêu cầu vai trò Developer trở lên; hai mặt phẳng chính sách (§5–6) được soạn riêng và gắn ở đây.
Đặt model_limits thành đúng danh sách agent này cần (và bật model_limits_enabled). Một cuộc gọi tới bất kỳ mô hình nào ngoài danh sách bị từ chối trước khi nó rời gateway, nên một agent bị chiếm quyền không thể leo lên một mô hình đắt hơn hoặc mạnh hơn. Kiểm tra: danh sách có ngắn như công việc cho phép — lý tưởng là một mô hình? Chuyên sâu: Giới hạn mô hình.
Đặt allow_ips thành các địa chỉ nguồn hoặc CIDR mà agent thực sự gọi từ đó. Một key bị rò rỉ được trình từ bất cứ nơi nào khác bị từ chối ở tầng auth. Rỗng nghĩa là mọi IP được phép. Kiểm tra: với một agent host-cố-định hoặc theo lịch, danh sách có không-rỗng và được định phạm vi tới egress đó không? Chuyên sâu: Danh sách IP cho phép.
Đặt credit_limit_usd thành một mức trần mà agent không bao giờ nên vượt trong cả đời nó. Gateway thực thi nó đối với chi tiêu của key. 0 nghĩa là không giới hạn — một vòng lặp mất kiểm soát có thể rút cạn toàn bộ số dư của bạn. Kiểm tra: mức trần có phải là một ngân sách thực, không phải 0? Chuyên sâu: Quota, mức trần & hết hạn.
Đặt expired_time thành một mốc hết hạn tuyệt đối — kết thúc của sprint, của lần triển khai, hoặc của lần chạy CI. -1 nghĩa là không bao giờ hết hạn. Một key ngắn hạn không thể tồn dư như bề mặt tấn công bị quên. Kiểm tra: một key tạm thời hoặc nhà thầu có một mốc hết hạn thực, không phải -1? Chuyên sâu: Key hết hạn.
Gắn một guardrail qua guardrail_id để văn bản request (và, ở nơi được hỗ trợ, response) được sàng lọc cho PII, secrets, và ý định injection trước khi nó đến mô hình. Kiểm tra: một key xử lý prompt nhạy cảm có một guardrail được gắn, hoặc kế thừa một mặc định workspace? Xem §5.
Gắn một chính sách firewall qua firewall_policy_id để mọi cuộc gọi tool, dispatch MCP, và egress mà key này phát ra được đánh giá đối với một danh sách cho phép những gì agent thực sự cần. Kiểm tra: một agent gọi tool có một chính sách firewall được gắn, hoặc kế thừa mặc định workspace? Xem §6.
Các trường ở trên là những đòn bẩy khách-hàng-cấu-hình-được duy nhất trên một key — đặt tất cả chúng trong console; không gì ở đây yêu cầu một thay đổi code agent. Đọc lại một key cho thấy nó đã che; plaintext hiển thị một lần lúc tạo. Xem Che key.

​
2. Cái gì / bao lâu một lần / ở đâu

Ba câu hỏi biến checklist từ một việc vặt một lần thành một tư thế.

Cái gì

Sáu cổng ở trên, theo thứ tự: model_limits → allow_ips → credit_limit_usd → expired_time → guardrail_id → firewall_policy_id.

Bao lâu một lần

Trên mọi key lúc tạo, và trong một lần xem xét định kỳ — khi phạm vi của một agent thay đổi, khi bạn xoay vòng một key, và theo một nhịp cố định cho các key dài hạn.

Ở đâu

Trong trình chỉnh sửa key của console (/console/token), với tư cách Developer+. Hai chính sách được soạn trong các console riêng của chúng, rồi gắn trên key.

​
3. Một key least-agency cụ thể

Một agent theo lịch tóm tắt các ticket hỗ trợ bằng một mô hình rẻ, từ một host, gần như không cần agency nào. Một key được làm cứng hoàn toàn:
TrườngGiá trịTại sao
model_limitsmột mô hình tóm tắtkhông thể leo lên một mô hình frontier
allow_ipsCIDR egress của schedulermột key bị rò rỉ vô dụng ở nơi khác
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ư
expired_timekết thúc của lần triển khaitự hết hạn, không thể tồn dư
guardrail_idmột guardrail che PIIvăn bản request được sàng lọc
firewall_policy_idchỉ allow-list các tool của nókhông có cuộc gọi tool bất ngờ
Nếu agent này bị chiếm quyền, nó vẫn chỉ có thể gọi một mô hình, chỉ từ một dải IP, chỉ tới mức trần của nó, và chỉ các tool mà chính sách firewall của nó cho phép. Phần còn lại của workspace không bị động chạm — và firewall audit trail cho thấy chính xác nó được phép làm gì.
Một key không có model_limits, không có allow_ips, credit_limit_usd: 0, expired_time: -1, và không gắn chính sách có agency tối đa. Nếu nó rò rỉ, người giữ nó có được toàn bộ workspace của bạn. Coi sự kết hợp đó là một phát hiện, không phải một mặc định — xem không giới hạn vs bị giới hạn.

​
4. Cuộc gọi relay /v1 vs console

Checklist được cấu hình trong console với session của bạn (một người dùng Developer+). Agent của bạn không bao giờ động vào các config route đó — nó trình relay key có phạm vi của nó (sk-orca-…) trên các cuộc gọi inference /v1/*, và các giới hạn cùng chính sách đã gắn ở trên được thực thi trên mỗi cái. 
# The agent's runtime call — the relay key, scoped by the checklist above.
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..."}]
  }'
Nếu model_limits của key không bao gồm openai/gpt-4o-mini, cuộc gọi này bị từ chối trước khi nó rời gateway. Nếu IP của caller không nằm trong allow_ips, nó bị từ chối ở tầng auth. Code agent ở nguyên; key quyết định bán kính ảnh hưởng.

​
5. Cổng 5 — guardrail đã gắn

guardrail_id gắn một chính sách nội dung có thứ tự, theo phạm vi workspace vào key. Phân giải là guardrail tường minh của key (nếu nó tồn tại và được bật), ngược lại mặc định workspace, ngược lại không có.
Guardrails là một công tắc tắt nghiêm ngặt khi bị tắt: một guardrail_id bị tắt hoặc đã xóa nghĩa là key không nhận được guardrail — nó không fallback về mặc định của workspace. Đây là điều ngược lại với mặt phẳng firewall (§6), nên hãy xác minh guardrail đã gắn được bật, không chỉ đính kèm.
Các quy tắc của một guardrail chạy trước mô hình (giai đoạn input) và, ở nơi được hỗ trợ, trên response (giai đoạn output), với các hành động block, mask, hoặc flag. Preset PII Shield, chẳng hạn, che PII trong request trước khi nó từng đến mô hình. Soạn và gắn guardrail với tư cách Developer+ — xem Guardrails và Gắn chính sách.

​
6. Cổng 6 — chính sách firewall đã gắn + phạm vi gateway

firewall_policy_id gắn một chính sách cuộc gọi tool theo phạm vi workspace. Nó chi phối các hành động một agent thực hiện — các tool được quảng bá, tool_calls do mô hình phát ra, dispatch MCP, và egress đi ra ngoài — đối với một danh sách quy tắc có thứ tự mà các verdict của nó là allow, audit, deny, sanitize, pending_approval, hoặc cap_cost.
Mặt phẳng firewall phân giải khác với guardrails: một chính sách firewall đã gắn bị tắt fallback về mặc định của workspace, nó không tắt việc thực thi. Vậy nên gắn một chính sách và vô hiệu hóa nó đưa key trở về mặc định của workspace — nó không bao giờ âm thầm không được bảo vệ.
Cách nhanh nhất để đặt cả hai mặt phẳng cùng lúc là một cấp độ tự chủ — một công tắc duy nhất cấu hình một cách nguyên tử tư thế firewall và guardrail của workspace bạn (tight / balanced / permissive), với hoàn tác một cú nhấp. Xem Firewall §8.
is_firewall_gateway là một loại key riêng — chỉ được đúc cho các route Firewall MCP và evaluate-hook (/api/v1/firewall/*), không bao giờ cho inference. Một key thông thường nhận 403 trên các route đó, và một gateway key trên đường inference là quá-phạm-vi. Bật cờ, và đọc plaintext của một gateway key, yêu cầu Admin+. Một key, một mục đích.

​
7. Sau checklist

Baseline secure-agents

Tư thế khởi đầu được khuyến nghị — một công tắc tự chủ, rồi tinh chỉnh từ traffic thực.

Gắn chính sách

Cách guardrail_id và firewall_policy_id đính kèm và phân giải.

Quyền quá mức

Mối đe dọa mà checklist này được xây dựng để kiềm chế.

Key bị rò rỉ

Phải làm gì ngay khi một key có phạm vi bị lộ.
Mỗi key càng hẹp, bán kính ảnh hưởng càng nhỏ nếu bất kỳ agent nào bị xâm phạm — và càng rõ ràng bản ghi về những gì mỗi agent được phép làm. Chạy checklist least agency trên mọi key, và cứ chạy nó tiếp.