메인 콘텐츠로 건너뛰기
여러분은 많은 고객-테넌트가 하나의 코드베이스와 하나의 OrcaRouter 워크스페이스를 공유하는 SaaS를 구축하고 있습니다. 각 테넌트는 여러분의 게이트웨이를 통해 프롬프트를 보내고 에이전트를 실행하며, 어려운 문제는 폭발 반경입니다: 유출된 테넌트 키, 폭주하는 테넌트 에이전트, 또는 한 테넌트의 PII가 다른 테넌트의 로그에 도착하는 것이 경계를 넘어 흘러넘치도록 허용되어서는 안 됩니다. 이 레시피는 공유 게이트웨이를 테넌트 안전하게 만드는 세 가지 컨트롤을 연결합니다 — 테넌트별 범위 지정 키, 모든 테넌트가 상속하는 워크스페이스 수준 정책, 그리고 한 테넌트가 더 필요로 할 때의 테넌트별 오버라이드 — 모두 콘솔에서, 애플리케이션 코드 변경 없이.
여기 있는 모든 것은 여러분의 워크스페이스에 바인딩되며 콘솔에서 구성됩니다. 여러분의 앱은 각 테넌트의 sk-orca-... 키로 https://api.orcarouter.ai/v1/chat/completions를 계속 호출합니다 — 게이트웨이의 정책만 바뀝니다. 구성 작업은 각 단계에서 명시한 역할을 요구합니다; /v1/* 릴레이 호출만 테넌트 키를 사용합니다.

​
1. 멀티 테넌트 AI 보안 모델

멀티 테넌트 게이트웨이는 단일 앱과 다른 위협 형태를 가집니다. 중요한 위험은 테넌트 수에 따라 규모가 커집니다:

키 유출 = 한 테넌트의 폭발 반경

유출된 테넌트 키는 여러분의 계정을 고갈시키거나, 노출하지 않은 모델을 호출하거나, 그 테넌트의 예산을 넘어 도달할 수 없어야 합니다.

테넌트 간 데이터 누출

한 테넌트의 PII가 공유 로그에, 또는 다른 테넌트로 라우팅된 응답에 도착하는 것은 여러분의 데이터 격리 약속을 깨뜨립니다.

시끄러운 테넌트 에이전트

한 테넌트의 에이전트가 툴에서 루프하거나 임의의 호스트를 가져오는 것이 다른 모든 사람을 위한 게이트웨이를 저하시켜서는 안 됩니다.

테넌트별 컴플라이언스

규제받는 테넌트는 나머지 테넌트가 필요로 하지 않는 PII 마스킹과 데이터 거주지가 필요할 수 있습니다.
아래 모델은 두 레이어입니다: 모든 테넌트 키가 상속하는 워크스페이스 기준선, 그리고 다른 테넌트를 건드리지 않고 한 테넌트를 강화하는 키별 범위와 오버라이드. 전체 해석 규칙은 범위 키, 정책, 워크스페이스를 참조하세요.

​
2. 기준선: 모든 테넌트가 상속하는 하나의 워크스페이스 정책

모든 테넌트 키가 기본적으로 상속하도록 보안 자세를 워크스페이스 수준에서 한 번 작성하세요 — 테넌트별 중복 없이.
1

기본 guardrail

Guardrails → New guardrail에서, 이름이 지정된 하나의 정책을 작성하고(예: tenant-baseline) 그것을 워크스페이스 기본값 (is_default)으로 표시하세요. stage input, action mask의 PII 규칙을 추가하여, 어떤 테넌트의 요청도 원시 PII를 업스트림으로 운반하지 않게 하세요:
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
명시적 guardrail 연결이 없는 모든 테넌트 키는 이 기본값으로 폴백합니다. guardrail 작성은 Developer 역할이 필요합니다.
2

기본 firewall 정책

테넌트가 에이전트를 실행하면, 액션 평면에서 동일하게 하세요: Firewall → Policies에서 기본 정책을 작성하거나 — 더 빠르게 — Firewall → Posture를 열고 balanced 자율성 수준을 적용하세요. 그것은 가장 파괴적인 액션을 거부하면서 모든 테넌트의 툴 호출을 감사하고 PII를 워크스페이스 전역으로 플래그하므로, 광범위하게 강제하기 전에 실제 테넌트 동작을 관찰합니다. Developer 역할.
새 규칙이 테넌트를 중간에 망가뜨릴 수 없도록 기준선을 observe → shadow → enforce 순서로 롤아웃하세요. firewall 정책은 정책별 shadow_mode 플래그를 지원합니다(강제 판정이 [shadow] would …로 로깅됨); guardrail 규칙은 flag 액션으로 시작하세요. 강제 모드를 참조하세요.

​
3. 테넌트별 범위 지정 키 하나

이것이 테넌트 격리의 핵심입니다: 테넌트 간에 키를 절대 공유하지 말고, 테넌트에게 여러분의 계정 전체 키를 절대 건네지 마세요. 테넌트당 하나의 키를, 그 테넌트가 할 수 있는 것에 정확히 범위 지정하여 발급하세요. API Keys → New key에서 다음을 설정하세요:
credit_limit_usd를 그 테넌트의 상한으로 설정하세요(0 = 무제한). 이는 단 하나의 가장 중요한 멀티 테넌트 컨트롤입니다: 유출되거나 남용된 테넌트 키는 결코 그 테넌트의 예산만 태울 수 있을 뿐, 여러분의 계정은 결코 아닙니다. denial-of-wallet를 참조하세요.
model_limits(model_limits_enabled)를 켜고 그 테넌트의 플랜이 포함하는 모델만 나열하세요 — 그래서 유출된 키가 테넌트가 결제하지 않은 비싼 모델을 실행할 수 없습니다.
environment(자유 형식 배포 레이블, 예: prod / staging)를 설정하여 테넌트의 트래픽이 여러분의 로그에서 귀속 가능하게 하고 프로덕션 키를 한눈에 테스트 키와 구별할 수 있게 하세요.
테넌트가 고정된 서버에서 호출하면 allow_ips를 그 테넌트의 백엔드 egress IP로 설정하고, 트라이얼이나 시간 제한 테넌트에는 expired_time을 설정하세요(-1 = 만료 안 됨).
모든 테넌트 키는 워크스페이스 tenant-baseline guardrail과 기본 firewall 정책을 자동으로 상속합니다 — 여러분은 범위 지정 키를 발급했고, 그것은 이미 통제됩니다. 키는 생성 후 표시 시 마스킹되므로, 테넌트를 프로비저닝할 때 한 번 복사하세요.

​
4. 테넌트별 오버라이드 — 나머지를 건드리지 않고 하나를 강화하기

대부분의 테넌트는 기준선을 탑니다. 하나가 더 필요할 때 — 규제받는 테넌트, 엔터프라이즈 티어, 보호관찰 목록의 테넌트 — 더 엄격한 이름이 지정된 정책을 그 키에만 연결하세요:
키에 설정그 한 테넌트에 대한 효과
guardrail_id더 엄격한 이름이 지정된 guardrail로 교체(예: PII 차단).
firewall_policy_id더 단단한 firewall 정책으로 교체(예: 기본 거부 툴).
해석은 두 평면 간에 다릅니다 — 차이를 아세요:
명시적 guardrail_id(존재하고 활성화되어 있을 때)는 항상 적용되며 결코 조용히 폴백하지 않습니다. 그 연결된 guardrail이 비활성화되면, 키는 어떤 guardrail도 받지 못합니다 — 워크스페이스 기본값으로 떨어지지 않습니다. tenant-baseline 기본값을 상속하려면 guardrail_id를 설정하지 않은 채로(0/null) 두세요.
연결된 firewall_policy_id는 존재하고 활성화되어 있을 때 적용됩니다; 그 정책이 비활성화되면, 키는 워크스페이스 기본 firewall 정책으로 폴백합니다. (이는 guardrail off 스위치 동작의 반대입니다 — 의도적으로.)
이름이 지정된 정책을 편집하면 그것에 연결된 모든 키가 다음 호출에서 이동합니다. 여러 테넌트가 하나의 더 엄격한 정책을 공유하면, 편집이 그 모두에 한 번에 적중합니다. 테넌트가 진짜로 다른 규칙을 필요로 할 때는 하나의 거대한 공유 정책이 아니라 격리 클래스별로 별개의 이름이 지정된 정책을 사용하세요.

​
5. 구체적인 2티어 예제

하나의 워크스페이스에서 무료 티어와 규제받는 엔터프라이즈 티어를 운영한다고 해봅시다:
  1. 워크스페이스 기준선 — is_default로서 tenant-baseline guardrail(입력에서 PII 마스크, 카드/SSN에서 차단), 그리고 balanced firewall 자율성 수준. 모든 테넌트가 이것을 상속합니다.
  2. 무료 티어 테넌트 키 — guardrail_id 없음(기준선 상속), openai/gpt-4o-mini로 고정된 model_limits, 낮은 credit_limit_usd.
  3. 엔터프라이즈 테넌트 키 — 더 엄격한 enterprise-pii guardrail로 설정된 guardrail_id(입력에서 PII block, 마스크 아님; output 단계 secrets 차단), 더 단단한 툴 허용 목록을 가진 firewall_policy_id, 더 높은 크레딧 상한, 그리고 그들의 백엔드로 고정된 allow_ips.
두 티어 모두 자신의 키로 동일한 /v1/chat/completions 엔드포인트를 호출합니다. 게이트웨이는 키별로 올바른 정책을 해석합니다 — 여러분의 애플리케이션 코드는 모든 테넌트에 대해 동일합니다.

​
6. 테넌트별 컴플라이언스 & 거주지

규제받는 테넌트는 종종 나머지가 필요로 하지 않는 증명이 필요합니다. 컴플라이언스는 guardrail과 firewall의 워크스페이스 동료로 실행됩니다:
  • 프레임워크 카탈로그와 준비도 탐색은 모든 Member에게 개방되고 무료 입니다 — 테넌트가 묻는 프레임워크(soc2, hipaa, gdpr, iso_27001, pci_dss, 그 외)의 커버리지를 확인하세요.
  • 팩 설치(POST /api/compliance/packs/:key/install)는 매칭되는 guardrail과 firewall 정책을 여러분의 워크스페이스로 구체화합니다; 워크스페이스 Admin과 유료 플랜을 요구합니다.
  • 데이터 거주지는 컴플라이언스 리포트 아티팩트의 지역(us / eu / uk / ap / cn / global)을 PUT /api/compliance/residency(Admin)를 통해 고정합니다. 교차 지역 읽기는 보류됩니다.
여기서 거주지는 추론 데이터 지리 고정이 아니라 컴플라이언스 리포트 아티팩트를 통제합니다. 요청 로그 이야기는: 로그는 기본 30일 보존되고(180일로 하드 상한), 사용자 자기 삭제는 30일 유예를 실행한 다음 그 사용자의 guardrail matches와 요청 로그로 캐스케이드하는 PII 정리를 실행합니다.
전체 감사된 증거 실행은 SOC 2 증거 생성과 HIPAA용 배포를 참조하세요.

​
7. 하나의 워크스페이스에서 모든 테넌트 지켜보기

모든 관측성은 워크스페이스 범위이므로, 하나의 피드 세트가 모든 테넌트를 커버합니다 — 단일 테넌트로 필터링 가능:
  • Guardrails → Matches(모든 Member) — 모든 테넌트에 걸쳐 발동한 모든 규칙: 타입, 액션, 단계, 상세. 매치된 부분 문자열은 그 guardrail에 대해 Log raw content가 켜져 있을 때만 기록됩니다(기본 꺼짐 — 프라이버시 보수적 자세, 멀티 테넌트에서 가장 중요). 튜닝하려면 거짓 양성을 표시하세요 (Admin).
  • Firewall → Events / Runs(Developer+) — 모든 툴 호출이, 에이전트 run별로 롤업됨, 그래서 시끄러운 테넌트의 루프나 새로운 egress가 두드러집니다.
  • 이상 피드(Member) — 학습된 주중 시간대 베이스라인에 대해 채점된 속도/비용 급증은 각 호출이 개별적으로 허용되더라도 패턴을 벗어나 태우는 한 테넌트를 잡습니다.
차단된 요청은 HTTP 400(guardrail_blocked / firewall_blocked)을 반환하고, 그 테넌트에게 쿼터를 소모하지 않으며, skip-retry로 표시됩니다 — 경계는 거부에 대해 테넌트에게 청구하지 않고 유지되었습니다.

​
8. 더 깊이 들어가려면

범위 키, 정책, 워크스페이스

키 연결과 워크스페이스 기본값을 위한 전체 해석 순서.

Guardrails 레퍼런스

모든 규칙 타입, PII 엔티티, 그리고 엔티티별 오버라이드를 전부.

Firewall 레퍼런스

판정, 표면, 자율성 수준, 그리고 정책 평면.

데이터 유출 중지

테넌트 에이전트의 아웃바운드 egress를 잠그세요.