메인 콘텐츠로 건너뛰기
컴플라이언스 팩은 프레임워크 — SOC 2, HIPAA, GDPR, ISO 27001, OWASP LLM Top 10 — 를 그것을 충족하는 게이트웨이 컨트롤에 매핑한 것입니다. 컴플라이언스 팩을 설치하면, OrcaRouter는 단지 프레임워크를 북마크하지 않습니다: 팩의 컨트롤을 실제로 편집 가능한 Guardrail(콘텐츠 평면)과 실제 Firewall 정책(툴 호출 평면)으로 구체화하며, 팩의 출처로 태그하므로 모든 기존 강제, 연결, 히스토리 경로가 변경 없이 작동합니다. 설치는 관찰 모드로 도착합니다 — guardrail은 차단하는 대신 플래그하고, firewall은 shadow에서 실행됩니다 — 그래서 어떤 것이 라이브 트래픽에 영향을 미치기 전에 “차단되었을” 증거를 수집합니다. 나중에, 의도적으로, 콘솔에서 라이브로 전환합니다.
카탈로그 탐색과 준비 상태 확인은 모든 워크스페이스 멤버에게 무료입니다. 팩을 설치하는 것은 워크스페이스 Admin 액션이며 유료 플랜을 요구합니다 — 게이트웨이가 두 가지를 모두 서버 측에서 강제하므로 직접 API 호출이 게이트를 우회할 수 없습니다.

​
1. “컴플라이언스 팩 설치”가 실제로 하는 것

한 번의 설치 호출이 워크스페이스에 세 가지를 원자적으로 씁니다:
팩의 콘텐츠 평면 컨트롤이 이름이 지정된 하나의 guardrail로 병합됩니다 — <Pack> (Compliance)(예: SOC 2 (Compliance)). 관찰 모드에서는 모든 액션(그리고 모든 엔티티별 액션)이 flag로 강제되므로, 실제 트래픽을 차단하거나 마스킹하지 않고 매치를 주석 처리합니다.
팩의 툴 호출 컨트롤이 이름이 지정된 하나의 firewall 정책으로 병합됩니다 — <Pack> (Compliance — tools)(예: SOC 2 (Compliance — tools)) — shadow_mode가 켜진 상태로 생성되므로, 커버된 모든 호출을 [shadow] would …로 평가하고 로깅하지만 결코 거부하지 않습니다.
워크스페이스 컴플라이언스 팩 행이 두 구체화된 정책을 연결하고, 카탈로그 버전을 고정하고, 어떤 컨트롤을 선택했는지 기록하고, 누가 설치했는지 스탬프합니다 — 더불어 감사 로그 항목.
설치가 표준 guardrail과 firewall 객체를 생성하기 때문에, 이후 콘솔에서 그것들을 열고, 모든 규칙을 읽고, 튜닝하고, firewall 정책을 firewall_policy_id로 키에 연결할 수 있습니다 — 손으로 작성한 어떤 정책과 정확히 똑같이.

​
2. 콘솔에서 컴플라이언스 팩 설치하기

컴플라이언스 구성은 릴레이 키가 아니라 콘솔 세션(UserAuth)을 사용합니다. 콘솔에서 하세요:
1

컴플라이언스 카탈로그 열기

워크스페이스 콘솔의 Compliance로 이동하세요. 카탈로그를 탐색하고 필요한 프레임워크를 여세요 — 예를 들어 SOC 2(soc2) 또는 OWASP LLM Top-10(owasp_llm). 각 팩은 그것의 컨트롤, 각 컨트롤이 어느 평면에 도착하는지, 그리고 공식 레퍼런스를 나열합니다.
2

컨트롤 선택 (또는 모두 선택)

전체 프레임워크를 설치하거나, 컨트롤의 하위 집합을 선택하세요. 빈 선택은 팩의 모든 컨트롤을 설치합니다.
3

설치

유료 플랜의 워크스페이스 Admin으로 Install을 클릭하세요. 팩이 즉시 관찰 모드로 구체화됩니다. 이미 설치된 팩을 재설치하는 것은 멱등적입니다 — 중복이 아니라 기존 레코드를 반환합니다.
4

증거를 지켜본 다음 라이브 전환

shadow guardrail과 firewall이 차단되었을 매치를 축적하게 두세요. 자세가 맞아 보이면, 팩을 라이브로 가져가 선언된 액션을 켜고 (선택적으로) 정책을 워크스페이스 기본값으로 프로모트하세요. 관찰 vs 강제를 참조하세요.
어디서 시작할지 확실하지 않다면 OWASP LLM Top-10 팩을 먼저 설치하세요 — 그것은 이 문서 섹션이 다루는 위협(인젝션, 안전하지 않은 출력 처리, 민감 정보 노출, 시스템 프롬프트 유출, 과도한 자율성)에 직접 매핑되며 관찰할 구체적인 자세를 제공합니다.

​
3. 기저 호출

콘솔은 하나의 엔드포인트를 구동합니다. 형태를 보거나, 감사하거나, 내부 프로비저닝 흐름을 스크립트화할 수 있도록 여기에 문서화되어 있습니다 — 그러나 게이트웨이는 그것에 도달하기 위해 워크스페이스 Admin 세션 토큰과 유료 플랜을 요구합니다: 
POST /api/compliance/packs/{key}/install
Authorization: Bearer <your-console-session-token>
Content-Type: application/json

{ "controls": ["owasp.llm01_injection", "owasp.llm08_excessive_agency"] }
빈 본문은 팩의 모든 컨트롤을 설치합니다: 
POST /api/compliance/packs/owasp_llm/install
응답은 설치 레코드입니다 — 팩 키, 고정된 버전, mode: observe, 그리고 구체화된 guardrail_id와 firewall_policy_id의 id이므로 즉시 그것들을 열 수 있습니다.
잘못된 형식의(비어 있지 않지만 파싱 불가능한) 본문은 조용히 “모두 설치”로 처리되지 않고 거부됩니다 — 그래서 클라이언트 직렬화 버그가 부분 설치를 전체 프레임워크로 조용히 넓힐 수 없습니다. 유효한 JSON을 보내거나, 아예 아무것도 보내지 마세요.

​
4. 설치 후

그다음어디서
팩에 무엇이 있는지 보기팩 내용
라이브로 전환관찰 vs 강제
서명된 증거 생성서명된 보고서
설치는 저렴하고 되돌릴 수 있는 첫 수입니다: 라이브 트래픽에 비용이 들지 않고, 멱등적이며, 설치 제거는 두 구체화된 평면을 깔끔하게 제거합니다. 의도적인 단계는 라이브 전환입니다 — 거기서 선언된 block/mask/deny 액션이 켜집니다.
왜 강제가 아니라 설치에 유료 플랜이 필요한가요? 프레임워크를 라이브 편집 가능한 정책으로 구체화하는 것이 가치의 순간입니다 — 게이트웨이는 설치에서 그것을 게이트하고 라이브 전환에서 다시 게이트하므로 업그레이드 경계가 명시적이며, 롤아웃 도중 놀라운 403이 결코 아닙니다.

​
5. 관련

플랜 게이팅

어떤 컴플라이언스 액션이 무료이고, 어떤 것이 유료 플랜이 필요한지 정확하게.

관찰 vs 강제

관찰 모드가 증거를 어떻게 수집하고 라이브 전환에서 무엇이 변하는지.

컨트롤 매트릭스

각 프레임워크 컨트롤이 게이트웨이 guardrail과 firewall 규칙에 어떻게 매핑되는지.

OWASP LLM Top 10

이 섹션의 에이전트 보안 위협에 매핑되는 팩.

Guardrails 레퍼런스

설치가 구체화하는 콘텐츠 평면 — 규칙, PII, 액션.

Agent Firewall 레퍼런스

설치가 구체화하는 툴 호출 평면 — 판정과 표면.
게이트웨이 대 당신이 선의 어느 쪽을 소유하는지에 대한 더 큰 그림은 책임 범위를 참조하세요; 프레임워크 카탈로그는 프레임워크를 참조하세요.