Chuyển đến nội dung chính
Bạn đang xây dựng một SaaS nơi nhiều customer-tenant chia sẻ một codebase và một workspace OrcaRouter. Mỗi tenant gửi prompt và chạy agent qua gateway của bạn, và vấn đề khó là bán kính sát thương: một tenant key bị rò rỉ, một agent tenant mất kiểm soát, hoặc PII của một tenant rơi vào log của một tenant khác không thể được phép tràn qua ranh giới. Công thức này kết nối ba kiểm soát khiến một gateway chung an toàn cho đa-tenant — một key có phạm vi giới hạn theo từng tenant, chính sách ở cấp workspace mà mọi tenant kế thừa, và các ghi đè theo từng tenant nơi một tenant cần nhiều hơn — tất cả từ console, với zero thay đổi đối với code ứng dụng của bạn.
Mọi thứ ở đây liên kết với workspace của bạn và được cấu hình từ console. Ứng dụng của bạn vẫn gọi https://api.orcarouter.ai/v1/chat/completions với key sk-orca-... của mỗi tenant — chỉ có chính sách trong gateway thay đổi. Các hành động cấu hình cần các vai trò được nêu theo từng bước; chỉ các cuộc gọi relay /v1/* dùng một tenant key.

​
1. Mô hình multi-tenant ai security

Một gateway đa-tenant có hình dạng đe dọa khác với một ứng dụng đơn lẻ. Các rủi ro quan trọng tỷ lệ với số lượng tenant:

Rò rỉ key = bán kính sát thương của một tenant

Một tenant key bị rò rỉ không nên có thể rút cạn tài khoản của bạn, gọi các mô hình bạn không bao giờ phơi bày, hoặc vươn vượt ngân sách của tenant đó.

Rò rỉ dữ liệu xuyên tenant

PII của một tenant rơi vào log chung, hoặc vào một response được định tuyến tới một tenant khác, phá vỡ lời hứa cô lập dữ liệu của bạn.

Một agent tenant ồn ào

Agent của một tenant lặp trên một tool hoặc fetch các host tùy ý không nên làm suy giảm gateway cho mọi người khác.

Compliance theo từng tenant

Một tenant được quản lý có thể cần masking PII và nơi-cư-trú-dữ-liệu mà phần còn lại của tenant không cần.
Mô hình bên dưới là hai lớp: một baseline workspace mà mọi tenant key kế thừa, cộng với phạm vi và ghi đè theo từng key siết một tenant mà không chạm các tenant khác. Xem phạm vi key, chính sách, workspace cho các quy tắc phân giải đầy đủ.

​
2. Baseline: một chính sách workspace mà mọi tenant kế thừa

Soạn tư thế bảo mật của bạn một lần ở cấp workspace để mọi tenant key kế thừa nó theo mặc định — không nhân bản theo từng tenant.
1

Một guardrail mặc định

Trong Guardrails → New guardrail, soạn một chính sách có tên (vd: tenant-baseline) và đánh dấu nó là mặc định workspace (is_default). Thêm một quy tắc PII, stage input, hành động mask, để không request của tenant nào mang PII thô lên thượng nguồn:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Bất kỳ tenant key nào không có liên kết guardrail tường minh đều fallback về mặc định này. Soạn một guardrail cần vai trò Developer.
2

Một chính sách firewall mặc định

Nếu các tenant của bạn chạy agent, làm điều tương tự trên mặt phẳng hành động: trong Firewall → Policies, soạn một chính sách mặc định hoặc — nhanh hơn — mở Firewall → Posture và áp dụng cấp độ tự chủ balanced autonomy level. Cái đó audit mọi cuộc gọi tool của tenant và gắn cờ PII toàn workspace trong khi deny các hành động phá hủy nhất, nên bạn quan sát hành vi tenant thực trước khi thực thi rộng rãi. Vai trò Developer.
Triển khai baseline theo thứ tự observe → shadow → enforce để một quy tắc mới không thể làm hỏng một tenant giữa chừng. Một chính sách firewall hỗ trợ một cờ shadow_mode theo từng chính sách (các verdict thực thi ghi log như [shadow] would …); bắt đầu các quy tắc guardrail ở hành động flag. Xem chế độ thực thi.

​
3. Một key có phạm vi giới hạn theo từng tenant

Đây là cốt lõi của cô lập tenant: không bao giờ chia sẻ một key giữa các tenant, và không bao giờ trao cho một tenant key toàn tài khoản của bạn. Phát hành một key cho mỗi tenant, có phạm vi chính xác những gì tenant đó được phép làm. Trong API Keys → New key, đặt:
Đặt credit_limit_usd thành mức trần của tenant đó (0 = không giới hạn). Đây là kiểm soát đa-tenant quan trọng nhất duy nhất: một tenant key bị rò rỉ hoặc lạm dụng chỉ có thể đốt ngân sách của tenant đó, không bao giờ là tài khoản của bạn. Xem denial-of-wallet.
Bật model_limits (model_limits_enabled) và chỉ liệt kê (các) mô hình mà gói của tenant đó bao gồm — để một key bị rò rỉ không thể chạy một mô hình đắt đỏ mà tenant không bao giờ trả tiền.
Đặt environment (một nhãn triển khai dạng tự do, vd: prod / staging) để traffic của một tenant có thể quy gán trong log của bạn và bạn có thể phân biệt key production với key test trong nháy mắt.
Đặt allow_ips thành các IP egress của backend tenant đó nếu nó gọi từ một server cố định, và expired_time cho các tenant dùng thử hoặc giới hạn thời gian (-1 = không bao giờ hết hạn).
Mọi tenant key tự động kế thừa guardrail tenant-baseline của workspace và chính sách firewall mặc định — bạn đã phát hành một key có phạm vi giới hạn, và nó đã được quản lý. Key bị che khi hiển thị sau khi tạo, nên sao chép nó một lần khi bạn cấp phát tenant.

​
4. Ghi đè theo từng tenant — siết một cái mà không chạm phần còn lại

Hầu hết các tenant cưỡi trên baseline. Khi một cái cần nhiều hơn — một tenant được quản lý, một tier doanh nghiệp, một tenant trong danh sách thử thách — gắn một chính sách có tên chặt hơn vào chỉ key đó:
Đặt trên keyHiệu lực cho một tenant đó
guardrail_idHoán đổi vào một guardrail có tên chặt hơn (vd: block-trên-PII).
firewall_policy_idHoán đổi vào một chính sách firewall chặt hơn (vd: default-deny tools).
Phân giải khác nhau giữa hai mặt phẳng — biết sự khác biệt:
Một guardrail_id tường minh (khi nó tồn tại và được bật) luôn áp dụng và không bao giờ âm thầm fallback. Nếu guardrail được gắn đó bị vô hiệu hóa, key nhận không có guardrail — nó không rớt xuống mặc định workspace. Để guardrail_id không đặt (0/null) để kế thừa mặc định tenant-baseline.
Một firewall_policy_id được gắn áp dụng khi nó tồn tại và được bật; nếu chính sách đó bị vô hiệu hóa, key fallback về chính sách firewall mặc định của workspace. (Đây là đối lập của hành vi công tắc tắt guardrail — theo chủ đích.)
Chỉnh một chính sách có tên dịch chuyển mọi key được gắn vào nó ở lần gọi kế tiếp. Nếu nhiều tenant chia sẻ một chính sách chặt hơn, một lần chỉnh chạm tất cả cùng lúc. Dùng một chính sách có tên riêng biệt theo từng lớp cô lập, không phải một chính sách chung khổng lồ, khi các tenant cần các quy tắc thực sự khác nhau.

​
5. Một ví dụ hai-tier cụ thể

Giả sử bạn vận hành một tier miễn phí và một tier doanh nghiệp được quản lý trên một workspace:
  1. Baseline workspace — guardrail tenant-baseline (PII mask trên input, block trên thẻ/SSN) làm is_default, cộng với cấp độ tự chủ firewall balanced. Mọi tenant kế thừa cái này.
  2. Key tenant tier miễn phí — không có guardrail_id (kế thừa baseline), model_limits ghim vào openai/gpt-4o-mini, một credit_limit_usd thấp.
  3. Key tenant doanh nghiệp — guardrail_id đặt thành một guardrail enterprise-pii chặt hơn (PII block, không phải mask, trên input; block secrets stage output), một firewall_policy_id với một tool allow-list chặt hơn, một mức trần tín dụng cao hơn, và allow_ips ghim vào backend của họ.
Cả hai tier gọi cùng endpoint /v1/chat/completions với key riêng của chúng. Gateway phân giải đúng chính sách theo từng key — code ứng dụng của bạn giống hệt nhau cho mọi tenant.

​
6. Compliance & nơi cư trú theo từng tenant

Một tenant được quản lý thường cần một chứng thực mà phần còn lại không cần. Compliance chạy như một đồng cấp workspace của guardrail và firewall:
  • Duyệt catalog framework và mức sẵn sàng mở cho mọi Member và miễn phí — xác nhận độ phủ cho framework mà một tenant hỏi về (soc2, hipaa, gdpr, iso_27001, pci_dss, và hơn nữa).
  • Cài đặt một pack (POST /api/compliance/packs/:key/install) cụ thể hóa các guardrail và chính sách firewall khớp vào workspace của bạn; nó yêu cầu workspace Admin và một gói trả phí.
  • Nơi cư trú dữ liệu ghim vùng của artifact báo cáo compliance của bạn (us / eu / uk / ap / cn / global) qua PUT /api/compliance/residency (Admin). Các lượt đọc xuyên vùng bị giữ lại.
Nơi cư trú ở đây quản lý artifact báo cáo compliance, không phải ghim-địa-lý dữ liệu suy luận. Cho câu chuyện request-log: log lưu giữ trong một mặc định 30 ngày (giới hạn cứng ở 180), và một lần tự-xóa của người dùng chạy một ân hạn 30 ngày rồi một lần chà sạch PII theo tầng tới các guardrail match và request log của người dùng đó.
Cho một lần chạy bằng chứng được audit đầy đủ, xem tạo bằng chứng SOC 2 và triển khai cho HIPAA.

​
7. Theo dõi mọi tenant từ một workspace

Mọi khả năng quan sát đều theo phạm vi workspace, nên một tập feed bao phủ mọi tenant của bạn — có thể lọc xuống một cái duy nhất:
  • Guardrails → Matches (mọi Member) — mọi quy tắc đã kích hoạt trên tất cả tenant: type, hành động, stage, chi tiết. Chuỗi con đã khớp được ghi lại chỉ khi Log raw content được bật cho guardrail đó (tắt theo mặc định — tư thế bảo thủ về quyền riêng tư, vốn quan trọng nhất trong đa-tenant). Đánh dấu một false positive để tinh chỉnh (Admin).
  • Firewall → Events / Runs (Developer+) — mọi cuộc gọi tool, gộp theo mỗi lần chạy agent, để vòng lặp của một tenant ồn ào hoặc một egress mới nổi bật.
  • Feed bất thường (Member) — các spike tốc độ/chi phí được chấm điểm đối với một baseline giờ-trong-tuần đã học bắt một tenant đốt ngoài pattern ngay cả khi mỗi cuộc gọi đều được cho phép riêng lẻ.
Một request bị block trả về HTTP 400 (guardrail_blocked / firewall_blocked), tốn tenant đó no quota, và được đánh dấu skip-retry — ranh giới được giữ mà không tính phí tenant cho việc từ chối.

​
8. Đi sâu hơn ở đâu

Phạm vi key, chính sách, workspace

Thứ tự phân giải đầy đủ cho liên kết key và mặc định workspace.

Tham chiếu Guardrails

Mọi loại quy tắc, thực thể PII, và ghi đè theo từng thực thể đầy đủ.

Tham chiếu Firewall

Verdict, bề mặt, cấp độ tự chủ, và mặt phẳng chính sách.

Dừng exfiltration dữ liệu

Khóa chặt egress đi ra ngoài của một tenant agent.